gcc-7-20190321 is now available
Snapshot gcc-7-20190321 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190321/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 269862 You'll find: gcc-7-20190321.tar.xzComplete GCC SHA256=884056483da03c71cda9e0ca2c30a49bba2db28d9bae22581870b11993c64440 SHA1=53d68f0d5f69fcf55ee965298acecdf6e5f75a17 Diffs from 7-20190314 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC turns &~ into | due to undefined bit-shift without warning
On Thu, Mar 21, 2019 at 11:19:54PM +0100, Allan Sandfeld Jensen wrote: > Hmm, I am curious. How strongly would gcc assume x is 0? If x is not 0, then it is undefined behavior and anything can happen, so yes, it can assume x is 0, sometimes gcc does that, sometimes not, it is not required to do that. > From having fixed UBSAN warnings, I have seen many cases where undefined > behavior was performed, but where the code was aware of it and the final Any program where it printed something (talking about -fsanitize=undefined, not the few sanitizers that go beyond what is required by the language) is undefined, period. It can happen to "work" as some users expect, it can crash, it can format your disk or anything else. There is no well defined after a process runs into UB. Jakub
Re: GCC turns &~ into | due to undefined bit-shift without warning
On Montag, 11. März 2019 10:14:49 CET Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 08:49:30AM +, Moritz Strübe wrote:
> > Considering that C11 6.5.7#3 ("If the value of the right operand
> > is negative or is greater than or equal to the width of the promoted
> > left operand, the behavior is undefined.") is not very widely known, as
> > it "normally" just works, inverting the intent is quite unexpected.
> >
> > Is there any option that would have helped me with this?
>
> You could build with -fsanitize=undefined, that would tell you at runtime
> you have undefined behavior in your code (if the SingleDiff has bit ever
> 0x20 set).
>
> The fact that negative or >= bit precision shifts are UB is widely known,
> and even if it wouldn't, for the compiler all the UBs are just UBs, the
> compiler optimizes on the assumption that UB does not happen, so when it
> sees 32-bit int << (x & 32), it can assume x must be 0 at that point,
> anything else is UB.
>
Hmm, I am curious. How strongly would gcc assume x is 0?
What if you have some expression that is undefined if x is not zero, but x
really isn't zero and the result is temporarily undefined, but then another
statement or part of the expression fixes the final result to something
defined regardless of the intermediate. Would the compiler make assumptions
that the intermediate value is never undefined, and possibly carry that
analysed information over into other expressions?
>From having fixed UBSAN warnings, I have seen many cases where undefined
behavior was performed, but where the code was aware of it and the final
result of the expression was well defined nonetheless.
'Allan
Re: GCC turns &~ into | due to undefined bit-shift without warning
On 3/21/19 8:53 AM, Moritz Strübe wrote:
> Hey.
>
> Am 20.03.2019 um 18:36 schrieb Andrew Haley:
>> On 3/20/19 2:08 PM, Moritz Strübe wrote:
>>> Ok, I played around a bit. Interestingly, if I set
>>> -fsanitize=udefined and -fsanitize-undefined-trap-on-error the
>>> compiler detects that it will always trap, and optimizes the code
>>> accordingly (the code after the trap is removed).* Which kind of
>>> brings me to David's argument: Shouldn't the compiler warn if there
>>> is undefined behavior it certainly knows of?
>> Maybe an example would help.
>>
>> Consider this code:
>>
>> for (int i = start; i < limit; i++) {
>>foo(i * 5);
>> }
>>
>> Should GCC be entitled to turn it into
>>
>> int limit_tmp = i * 5;
>> for (int i = start * 5; i < limit_tmp; i += 5) {
>>foo(i);
>> }
>>
>> If you answered "Yes, GCC should be allowed to do this", would you
>> want a warning? And how many such warnings might there be in a typical
>> program?
>
> Ok, let me see whether I get your point. I assume that should be "int
> limit_tmp = limit * 5;".
Yes, sorry.
> In the original version I have a potential integer overflow while
> passing a parameter. While in the second version, I have a potential
> overflow in limit_tmp and therefore the loop range and number of calls
> of foo is changed.
That's right.
> I think I start getting your point, but I none the less think it would
> be really nice to have an option(!) to warn me about such things
> nonetheless.
There aren't necesarily points in the compiler where GCC says "look,
this would be UB, so delete the code." Sometimes GCC simply assumes
that things like overflows cannot happen, so it ignores the
possibility. The code I provided is an example of that.
I suppose we could utilize the sanitize=undefined framework and emit a
warning everywhere a runtime check was inserted. That will at least
allow you to check in every case that the overflow, null pointer
exception, etc, cannot happen.
There would be a lot of warnings.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd.
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Re: Indicating function exit points in debug data
On Thu, 21 Mar 2019 at 09:11, Justin Paston-Cooper wrote: > > On Thu, 21 Mar 2019 at 08:23, Richard Biener > wrote: > > > > On Wed, Mar 20, 2019 at 8:05 PM Tom Tromey wrote: > > > > > > > "Segher" == Segher Boessenkool writes: > > > > > > >> Section 6.2.5.2 outlines the line number information state machine's > > > >> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition > > > >> is: > > > > > > Segher> How should this work with shrink-wrapping? The whole point of > > > that is > > > Segher> you do not tear down the frame after all other code, etc. I > > > don't see > > > Segher> how we can do better than putting this DW_LNS_set_epilogue_begin > > > right > > > Segher> before the actual return -- and that is after all the tear down > > > etc. > > > > > > I think it's fine if the epilogue marker is inexact or missing from > > > optimized code, because (1) that's the current state, and (2) it doesn't > > > really make sense to talk about an epilogue in some cases. > > > > > > Similarly, IMO it is fine not to worry about non-local exits. You can > > > already catch exceptions and examine them in gdb -- the epilogue marker > > > feature is mostly to address the unmet need of wanting to set a > > > breakpoint at the end of a function. > > > > Btw, the feature I am missing is not breaking at the end of a function > > but conditionally breaking on a specific return value of a specific > > function. > > Those are probably related but my usecase might be easier because > > the return value location is defined by the ABI and catching the actual > > return assembly instruction should already work. > > > > > Ideally, in -O0 / -Og code, the marker would be reliable where it > > > appears. > > > > > > It would be great if there was a way to indicate the location of the > > > value-to-be-returned in the DWARF. That way gdb could extract it at the > > > epilogue point. AFAIK this would require a DWARF extension. > > > > The ABI specifies this at the 'ret' instruction? > > Would this still allow inspection of the function's final state, where > it returns, apart from its return value? That is the original > behaviour I had in mind. Also for completeness it would be nice if > this feature supported inline functions too. 'ret' would not be a > solution for that. From what Segher said, I understand that the > 'epilogue_begin' marker is put right before the 'ret' instruction if > it exists. Does gdb have another way of finding the real epilogue > beginning, before registers are restored? I've looked at function.c a bit more, and I see what Segher is getting at. Also, given that a function might have multiple return statements pointing to a single 'ret' instruction, I'm not sure that 'ret' is the best solution. I also see that there will only be a single epilogue, so that would not be useful either. > > > > > Richard. > > > > > thanks, > > > Tom
Re: Indicating function exit points in debug data
On Thu, 21 Mar 2019 at 08:23, Richard Biener wrote: > > On Wed, Mar 20, 2019 at 8:05 PM Tom Tromey wrote: > > > > > "Segher" == Segher Boessenkool writes: > > > > >> Section 6.2.5.2 outlines the line number information state machine's > > >> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition > > >> is: > > > > Segher> How should this work with shrink-wrapping? The whole point of that > > is > > Segher> you do not tear down the frame after all other code, etc. I don't > > see > > Segher> how we can do better than putting this DW_LNS_set_epilogue_begin > > right > > Segher> before the actual return -- and that is after all the tear down etc. > > > > I think it's fine if the epilogue marker is inexact or missing from > > optimized code, because (1) that's the current state, and (2) it doesn't > > really make sense to talk about an epilogue in some cases. > > > > Similarly, IMO it is fine not to worry about non-local exits. You can > > already catch exceptions and examine them in gdb -- the epilogue marker > > feature is mostly to address the unmet need of wanting to set a > > breakpoint at the end of a function. > > Btw, the feature I am missing is not breaking at the end of a function > but conditionally breaking on a specific return value of a specific function. > Those are probably related but my usecase might be easier because > the return value location is defined by the ABI and catching the actual > return assembly instruction should already work. > > > Ideally, in -O0 / -Og code, the marker would be reliable where it > > appears. > > > > It would be great if there was a way to indicate the location of the > > value-to-be-returned in the DWARF. That way gdb could extract it at the > > epilogue point. AFAIK this would require a DWARF extension. > > The ABI specifies this at the 'ret' instruction? Would this still allow inspection of the function's final state, where it returns, apart from its return value? That is the original behaviour I had in mind. Also for completeness it would be nice if this feature supported inline functions too. 'ret' would not be a solution for that. From what Segher said, I understand that the 'epilogue_begin' marker is put right before the 'ret' instruction if it exists. Does gdb have another way of finding the real epilogue beginning, before registers are restored? > > Richard. > > > thanks, > > Tom
Re: GCC turns &~ into | due to undefined bit-shift without warning
Hey.
Am 20.03.2019 um 18:36 schrieb Andrew Haley:
> On 3/20/19 2:08 PM, Moritz Strübe wrote:
>> Ok, I played around a bit. Interestingly, if I set
>> -fsanitize=udefined and -fsanitize-undefined-trap-on-error the
>> compiler detects that it will always trap, and optimizes the code
>> accordingly (the code after the trap is removed).* Which kind of
>> brings me to David's argument: Shouldn't the compiler warn if there
>> is undefined behavior it certainly knows of?
> Maybe an example would help.
>
> Consider this code:
>
> for (int i = start; i < limit; i++) {
>foo(i * 5);
> }
>
> Should GCC be entitled to turn it into
>
> int limit_tmp = i * 5;
> for (int i = start * 5; i < limit_tmp; i += 5) {
>foo(i);
> }
>
> If you answered "Yes, GCC should be allowed to do this", would you
> want a warning? And how many such warnings might there be in a typical
> program?
Ok, let me see whether I get your point. I assume that should be "int
limit_tmp = limit * 5;".
In the original version I have a potential integer overflow while
passing a parameter. While in the second version, I have a potential
overflow in limit_tmp and therefore the loop range and number of calls
of foo is changed.
I think I start getting your point, but I none the less think it would
be really nice to have an option(!) to warn me about such things
nonetheless. Use cases would be libraries, or at least their interfaces
and critical software or just support finding potential bugs. Especially
when using third party libraries this would can help find potential issues.
Would it be possible to annotate the inserted checks with a debug symbol
or similar? That way one could compile using LTO and then search for the
remaining symbols? That would allow static analysis tools to search for
these symbols and annotate the code.
Cheers
Moritz
--
Redheads Ltd. Softwaredienstleistungen
Schillerstr. 14
90409 Nürnberg
Telefon: +49 (0)911 180778-50
E-Mail: moritz.stru...@redheads.de | Web: www.redheads.de
Geschäftsführer: Andreas Hanke
Sitz der Gesellschaft: Lauf
Amtsgericht Nürnberg HRB 22681
Ust-ID: DE 249436843
Re: GCC turns &~ into | due to undefined bit-shift without warning
On Thu, Mar 21, 2019 at 9:25 AM Alexander Monakov wrote:
>
> On Thu, 21 Mar 2019, Richard Biener wrote:
> > > Maybe an example would help.
> > >
> > > Consider this code:
> > >
> > > for (int i = start; i < limit; i++) {
> > > foo(i * 5);
> > > }
> > >
> > > Should GCC be entitled to turn it into
> > >
> > > int limit_tmp = i * 5;
> > > for (int i = start * 5; i < limit_tmp; i += 5) {
> > > foo(i);
> > > }
> > >
> > > If you answered "Yes, GCC should be allowed to do this", would you
> > > want a warning? And how many such warnings might there be in a typical
> > > program?
> >
> > I assume i is signed int. Even then GCC may not do this unless it knows
> > the loop is entered (start < limit).
>
> Additionally, the compiler needs to prove that 'foo' always returns normally
> (i.e. cannot invoke exit/longjmp or such).
Ah, yes. Andrews example was probably meaning limit_tmp = limit * 5, not i * 5.
Computing start * 5 is fine if the loop is entered.
Richard.
>
> Alexander
Re: GCC turns &~ into | due to undefined bit-shift without warning
On Thu, 21 Mar 2019, Richard Biener wrote:
> > Maybe an example would help.
> >
> > Consider this code:
> >
> > for (int i = start; i < limit; i++) {
> > foo(i * 5);
> > }
> >
> > Should GCC be entitled to turn it into
> >
> > int limit_tmp = i * 5;
> > for (int i = start * 5; i < limit_tmp; i += 5) {
> > foo(i);
> > }
> >
> > If you answered "Yes, GCC should be allowed to do this", would you
> > want a warning? And how many such warnings might there be in a typical
> > program?
>
> I assume i is signed int. Even then GCC may not do this unless it knows
> the loop is entered (start < limit).
Additionally, the compiler needs to prove that 'foo' always returns normally
(i.e. cannot invoke exit/longjmp or such).
Alexander
Re: Indicating function exit points in debug data
On Wed, Mar 20, 2019 at 8:05 PM Tom Tromey wrote: > > > "Segher" == Segher Boessenkool writes: > > >> Section 6.2.5.2 outlines the line number information state machine's > >> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition > >> is: > > Segher> How should this work with shrink-wrapping? The whole point of that is > Segher> you do not tear down the frame after all other code, etc. I don't see > Segher> how we can do better than putting this DW_LNS_set_epilogue_begin right > Segher> before the actual return -- and that is after all the tear down etc. > > I think it's fine if the epilogue marker is inexact or missing from > optimized code, because (1) that's the current state, and (2) it doesn't > really make sense to talk about an epilogue in some cases. > > Similarly, IMO it is fine not to worry about non-local exits. You can > already catch exceptions and examine them in gdb -- the epilogue marker > feature is mostly to address the unmet need of wanting to set a > breakpoint at the end of a function. Btw, the feature I am missing is not breaking at the end of a function but conditionally breaking on a specific return value of a specific function. Those are probably related but my usecase might be easier because the return value location is defined by the ABI and catching the actual return assembly instruction should already work. > Ideally, in -O0 / -Og code, the marker would be reliable where it > appears. > > It would be great if there was a way to indicate the location of the > value-to-be-returned in the DWARF. That way gdb could extract it at the > epilogue point. AFAIK this would require a DWARF extension. The ABI specifies this at the 'ret' instruction? Richard. > thanks, > Tom
Re: GCC turns &~ into | due to undefined bit-shift without warning
On Wed, Mar 20, 2019 at 6:36 PM Andrew Haley wrote:
>
> On 3/20/19 2:08 PM, Moritz Strübe wrote:
> >
> > Ok, I played around a bit. Interestingly, if I set
> > -fsanitize=udefined and -fsanitize-undefined-trap-on-error the
> > compiler detects that it will always trap, and optimizes the code
> > accordingly (the code after the trap is removed).* Which kind of
> > brings me to David's argument: Shouldn't the compiler warn if there
> > is undefined behavior it certainly knows of?
>
> Maybe an example would help.
>
> Consider this code:
>
> for (int i = start; i < limit; i++) {
> foo(i * 5);
> }
>
> Should GCC be entitled to turn it into
>
> int limit_tmp = i * 5;
> for (int i = start * 5; i < limit_tmp; i += 5) {
> foo(i);
> }
>
> If you answered "Yes, GCC should be allowed to do this", would you
> want a warning? And how many such warnings might there be in a typical
> program?
I assume i is signed int. Even then GCC may not do this unless it knows
the loop is entered (start < limit).
Richard.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd.
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
