How do I report a compiler bug?

Go To Last Post
59 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

SprinterSB wrote:

*IF* it compiles in C, then you know that any const object in static storage will not be written-to after load-time.

 

Not necessarily.

 

'C' does not guarantee that a const object will go in non-writable memory - so it could still get written-to by errant pointers, etc.

 

That's Undefined Behaviour.  Even if the object gets allocated to volatile memory that can be written-to, a correct C implementation will never ever by itself generate code that writes to such an object.  If the application does so, it's UB.

 

That's quite different in C++, where the implementation may write to objects that the application cannot write to.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As an overview of this quite lenghy thread:

 

When expecting a bug, the best thing to do (for a relative beginner) is very likely to post it here on avrfreaks just as you did.

Some of the Moderators / Gods over here (such as Clawson) are likely to jump on it and give it a thorough review (As he did).

 

In this stadium it is far too early to start running to the bug tracker at gnu.org.

After a while and some more of your own work it's likely there was no bug and you understand the workings of the compiler a little better.

No shame there, GCC has a long history, and every bit has probably been examined weighed and discussed multiple times.

Gosh, I just noticed GCC has just passed it's 30-th birthday:

https://en.wikipedia.org/wiki/GN...

 

If it truly is a bug you are likely to get it verified here after a bunch of posts, or at least more people will suspect it is truly a bug and by then you will  probably also have a 10 line piece of code with no extarnal dependencies (such as arduino) which can reproduce the bug.

 

By then you are probably also advised to send a bugreport, or one of the moderators might make a bug report himself.

 

The idea is that the further you go up the chain, the less time people are willing to spend in spotting silly mistakes.

If the people who are building the tools for us lowly users (myself included ! ) are constantly distracted by trivial mistakes they will never have time to build the next even better version.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
That's Undefined Behaviour
 

Indeed. And the problem in #45 seemed to be that poster just did not understand "undefined behaviour" - and, thus, how something can be "wrong" yet appear to "work".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ugh, if PROGMEM in C++ is undefined behavior, then I will remove it from the compiler.  Will take some days...
 

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I actually know perfectly well what undefined behavior is. I was simply confused as to why two pieces of code which should have theoretically invoked the same undefined behavior did not. I just needed a way to put anonymous data in flash. Removing PROGMEM support from avr-g++ seems to be a reasonable thing to do, given all the trouble it causes.

Last Edited: Fri. Sep 22, 2017 - 06:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

SprinterSB wrote:
*IF* it compiles in C, then you know that any const object in static storage will not be written-to after load-time.

Not necessarily.

 

'C' does not guarantee that a const object will go in non-writable memory - so it could still get written-to by errant pointers, etc.

In fact, I don't think the 'C' standard actually requires that a write to a const object has to be a fatal error - it could just be a warning?

 

Writing to a const object in C is Undefined Behaviour, hence a warning or error would be in order.  However, you cannot guarantee a diagnostic because there are situations where you 'd need to instrument the code to find errant behavior.  For example, when one compilation unit uses a const object and some other module / unit / library accesses through a non-const pointer then you have undefined behaviour.

 

There is also the case of const volatile.  IIRC, GCC allocated such objecte to .data / .bss per default, not to .rodata.  You still cannot write to such objects in C.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
when one compilation unit uses a const object and some other module / unit / library accesses through a non-const pointer

Yes - that's the kind of thing I was getting at with, "errant pointers, etc".

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

e_l_tang wrote:
I actually know perfectly well what undefined behavior is

 

Apparently not:

I was simply confused as to why two pieces of code which should have theoretically invoked the same undefined behavior did not.

"the same undefined behaviour" makes no sense - it is undefined!! 

Pages