[Bug tree-optimization/71478] [7 Regression] ICE in tree-ssa-reassoc.c after r236564

[kugan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71478

kugan at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kugan at gcc dot gnu.org

--- Comment #2 from kugan at gcc dot gnu.org ---
Sorry for the breakage. Patch that fixes this is posted for review at:
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00768.html

[Bug tree-optimization/71485] New: g++ ICE on x86_64-linux-gnu in “gimplify_expr”

[helloqirun at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71485

Bug ID: 71485
   Summary: g++ ICE on x86_64-linux-gnu in “gimplify_expr”
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following invalid code causes an ICE when compiled with the current g++
trunk on x86_64-linux-gnu in 32-bit mode. 

It is a 7 regression.

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 7.0.0 20160608 (experimental) [trunk revision 237212] (GCC) 


$ g++-trunk -m32 abc.cc
abc.cc:1:33: error: overflow in enumeration values at ‘e3’
 enum { e1 = 0x, e3 } e = e3;
 ^~
abc.cc: In function ‘void __static_initialization_and_destruction_0(int, int)’:
abc.cc:1:38: internal compiler error: in gimplify_expr, at gimplify.c:11097
 enum { e1 = 0x, e3 } e = e3;
  ^
0xaeaa5f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:11097
0xafb5da gimplify_modify_expr
../../gcc/gcc/gimplify.c:4762
0xae893a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10349
0xaec9f8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5731
0xae81fa gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:5507
0xae81fa gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10714
0xaec9f8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5731
0xae7b63 gimplify_statement_list
../../gcc/gcc/gimplify.c:1549
0xae7b63 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10766
0xaec9f8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5731
0xaf0c3d gimplify_cond_expr
../../gcc/gcc/gimplify.c:3286
0xae86d0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10305
0xaec9f8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5731
0xaf0c3d gimplify_cond_expr
../../gcc/gcc/gimplify.c:3286
0xae86d0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10305
0xaec9f8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5731
0xafcd84 gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:11532
0xafd3c6 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:11688
0x969bf7 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:625
0x96ceff analyze_functions
../../gcc/gcc/cgraphunit.c:1086
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ cat abc.cc
enum { e1 = 0x, e3 } e = e3;

[Bug target/71186] PowerPC64: Autovectorised code hits ICE with -O3 -mpower9 -mlra

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71186

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Thu Jun  9 23:28:23 2016
New Revision: 237281

URL: https://gcc.gnu.org/viewcvs?rev=237281=gcc=rev
Log:
[gcc]
2016-06-09  Michael Meissner  

Back port from trunk
2016-05-31  Michael Meissner  

* config/rs6000/vsx.md (vsx_splat_, V2DI/V2DF): Simplify
alternatives, eliminating preferred register class.  Add support
for the MTVSRDD instruction in ISA 3.0.
(vsx_splat_v4si_internal): Use splat_input_operand instead of
reg_or_indexed_operand.
(vsx_splat_v4sf_internal): Likewise.

Back port from trunk
2016-05-31  Michael Meissner  

PR target/71186
* config/rs6000/vsx.md (xxspltib__nosplit): Add alternatives
for loading up all 0's or all 1's.

Back port from trunk
2016-05-18  Michael Meissner  

PR target/70915
* config/rs6000/constraints.md (wE constraint): New constraint
for a vector constant that can be loaded with XXSPLTIB.
(wM constraint): New constraint for a vector constant of a 1's.
(wS constraint): New constraint for a vector constant that can be
loaded with XXSPLTIB and a vector sign extend instruction.
* config/rs6000/predicates.md (xxspltib_constant_split): New
predicates for wE/wS constraints.
(xxspltib_constant_nosplit): Likewise.
(easy_vector_constant): Add support for constants that can be
loaded via XXSPLTIB.
(splat_input_operand): Add support for ISA 3.0 word splat operations.
* config/rs6000/rs6000.c (xxspltib_constant_p): New function to
return if a constant can be loaded with the ISA 3.0 XXSPLTIB
instruction and possibly with a sign extension.
(output_vec_const_move): Add support for XXSPLTIB. If we are
loading up 0/-1 into Altivec registers, prefer using VSPLTISW
instead of XXLXOR/XXLORC.
(rs6000_expand_vector_init): Add support for ISA 3.0 word splat
operations.
(rs6000_legitimize_reload_address): Likewise.
(rs6000_output_move_128bit): Use output_vec_const_move to emit
constants.
* config/rs6000/vsx.md (VSX_M): Add TImode (if -mvsx-timode) and
combine VSX_M and VSX_M2 into one iterator.
(VSX_M2): Likewise.
(VSINT_84): New iterators for loading constants with XXSPLTIB.
(VSINT_842): Likewise.
(UNSPEC_VSX_SIGN_EXTEND): New UNSPEC.
(xxspltib_v16qi): New insns to load up constants with the ISA 3.0
XXSPLTIB instruction.
(xxspltib__nosplit): Likewise.
(xxspltib__split): New insn to load up constants with
XXSPLTIB and a sign extend instruction.
(vsx_mov): Replace single move that handled all vector types
with separate 32-bit and 64-bit moves.  Combine the movti_
moves (when -mvsx-timode is in effect) into the main vector
moves.  Eliminate separate moves for  , where the
preferred register class () is listed first, and the
secondary register class () is listed second with a '?' to
discourage use.  Prefer loading 0/-1 in any VSX register for ISA
3.0, and Altivec registers for ISA 2.06/2.07 (PR target/70915) so
that if the register was involved in a slow operation, the
clear/set operation does not wait for the slow operation to
finish.  Adjust the length attributes for 32-bit mode.  Use
rs6000_output_move_128bit and drop the use of the string
instructions for 32-bit movti when -mvsx-timode is in effect.  Use
spacing so that the alternatives and attributes don't generate
long lines, and put things in columns, so that it is easier to
match up the operands and attributes with the insn alternatives.
(vsx_mov_64bit): Likewise.
(vsx_mov_32bit): Likewise.
(vsx_movti_64bit): Fold movti into normal vector moves.
(vsx_movti_32bit): Likewise.
(vsx_splat_, V4SI/V4SF modes): Add support for ISA 3.0 word
splat instructions.
(vsx_splat_v4si_internal): Likewise.
(vsx_splat_v4sf_internal): Likewise.
(vector fusion peepholes): Use VSX_M instead of VSX_M2.
(vsx_sign_extend_qi_): New ISA 3.0 instructions to sign
extend vector elements.
(vsx_sign_extend_hi_): Likewise.
(vsx_sign_extend_si_v2di): Likewise.
* config/rs6000/rs6000-protos.h (xxspltib_constant_p): Add
declaration.
* doc/md.texi (PowerPC constraints): Document the wE, wM, and wS
constraints.  Add trailing period to wL documentation.

[gcc/testsuite]
2016-06-09  Michael Meissner  

Back port from trunk
2016-05-31  Michael Meissner  

[Bug target/70915] Improve loading 0/-1 in VSX registers on PowerPC

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70915

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Thu Jun  9 23:28:23 2016
New Revision: 237281

URL: https://gcc.gnu.org/viewcvs?rev=237281=gcc=rev
Log:
[gcc]
2016-06-09  Michael Meissner  

Back port from trunk
2016-05-31  Michael Meissner  

* config/rs6000/vsx.md (vsx_splat_, V2DI/V2DF): Simplify
alternatives, eliminating preferred register class.  Add support
for the MTVSRDD instruction in ISA 3.0.
(vsx_splat_v4si_internal): Use splat_input_operand instead of
reg_or_indexed_operand.
(vsx_splat_v4sf_internal): Likewise.

Back port from trunk
2016-05-31  Michael Meissner  

PR target/71186
* config/rs6000/vsx.md (xxspltib__nosplit): Add alternatives
for loading up all 0's or all 1's.

Back port from trunk
2016-05-18  Michael Meissner  

PR target/70915
* config/rs6000/constraints.md (wE constraint): New constraint
for a vector constant that can be loaded with XXSPLTIB.
(wM constraint): New constraint for a vector constant of a 1's.
(wS constraint): New constraint for a vector constant that can be
loaded with XXSPLTIB and a vector sign extend instruction.
* config/rs6000/predicates.md (xxspltib_constant_split): New
predicates for wE/wS constraints.
(xxspltib_constant_nosplit): Likewise.
(easy_vector_constant): Add support for constants that can be
loaded via XXSPLTIB.
(splat_input_operand): Add support for ISA 3.0 word splat operations.
* config/rs6000/rs6000.c (xxspltib_constant_p): New function to
return if a constant can be loaded with the ISA 3.0 XXSPLTIB
instruction and possibly with a sign extension.
(output_vec_const_move): Add support for XXSPLTIB. If we are
loading up 0/-1 into Altivec registers, prefer using VSPLTISW
instead of XXLXOR/XXLORC.
(rs6000_expand_vector_init): Add support for ISA 3.0 word splat
operations.
(rs6000_legitimize_reload_address): Likewise.
(rs6000_output_move_128bit): Use output_vec_const_move to emit
constants.
* config/rs6000/vsx.md (VSX_M): Add TImode (if -mvsx-timode) and
combine VSX_M and VSX_M2 into one iterator.
(VSX_M2): Likewise.
(VSINT_84): New iterators for loading constants with XXSPLTIB.
(VSINT_842): Likewise.
(UNSPEC_VSX_SIGN_EXTEND): New UNSPEC.
(xxspltib_v16qi): New insns to load up constants with the ISA 3.0
XXSPLTIB instruction.
(xxspltib__nosplit): Likewise.
(xxspltib__split): New insn to load up constants with
XXSPLTIB and a sign extend instruction.
(vsx_mov): Replace single move that handled all vector types
with separate 32-bit and 64-bit moves.  Combine the movti_
moves (when -mvsx-timode is in effect) into the main vector
moves.  Eliminate separate moves for  , where the
preferred register class () is listed first, and the
secondary register class () is listed second with a '?' to
discourage use.  Prefer loading 0/-1 in any VSX register for ISA
3.0, and Altivec registers for ISA 2.06/2.07 (PR target/70915) so
that if the register was involved in a slow operation, the
clear/set operation does not wait for the slow operation to
finish.  Adjust the length attributes for 32-bit mode.  Use
rs6000_output_move_128bit and drop the use of the string
instructions for 32-bit movti when -mvsx-timode is in effect.  Use
spacing so that the alternatives and attributes don't generate
long lines, and put things in columns, so that it is easier to
match up the operands and attributes with the insn alternatives.
(vsx_mov_64bit): Likewise.
(vsx_mov_32bit): Likewise.
(vsx_movti_64bit): Fold movti into normal vector moves.
(vsx_movti_32bit): Likewise.
(vsx_splat_, V4SI/V4SF modes): Add support for ISA 3.0 word
splat instructions.
(vsx_splat_v4si_internal): Likewise.
(vsx_splat_v4sf_internal): Likewise.
(vector fusion peepholes): Use VSX_M instead of VSX_M2.
(vsx_sign_extend_qi_): New ISA 3.0 instructions to sign
extend vector elements.
(vsx_sign_extend_hi_): Likewise.
(vsx_sign_extend_si_v2di): Likewise.
* config/rs6000/rs6000-protos.h (xxspltib_constant_p): Add
declaration.
* doc/md.texi (PowerPC constraints): Document the wE, wM, and wS
constraints.  Add trailing period to wL documentation.

[gcc/testsuite]
2016-06-09  Michael Meissner  

Back port from trunk
2016-05-31  Michael Meissner  

[Bug tree-optimization/71416] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (vectorizable_live_operation)

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71416

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |DUPLICATE

--- Comment #4 from Jeffrey A. Law  ---
Duplicate.

*** This bug has been marked as a duplicate of bug 71407 ***

[Bug tree-optimization/71407] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple: integral result type precision does not match field size of BIT_FIELD_REF)

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71407

--- Comment #7 from Jeffrey A. Law  ---
*** Bug 71416 has been marked as a duplicate of this bug. ***

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460

--- Comment #16 from joseph at codesourcery dot com  ---
I've now raised the void context issue on the WG14 reflector 
.

[Bug bootstrap/71435] [7 regression] sparc bootstrap failure since r235625

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71435

--- Comment #4 from Eric Botcazou  ---
> I can (partially) reproduce on Solaris:

The problem looks volatile, unrelated switches change code generation.

[Bug bootstrap/71481] [7 regression] ICE during selftest: input.c: test_reading_source_line

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481

--- Comment #3 from David Malcolm  ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00755.html

[Bug rtl-optimization/70751] [7 Regression] FAIL: gcc.target/arm/eliminate.c scan-assembler-times r0,[\\t ]*sp 3 since r235184

[jiwang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751

Jiong Wang  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jiong Wang  ---
Fixed.

[Bug rtl-optimization/70751] [7 Regression] FAIL: gcc.target/arm/eliminate.c scan-assembler-times r0,[\\t ]*sp 3 since r235184

[jiwang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751

--- Comment #5 from Jiong Wang  ---
Author: jiwang
Date: Thu Jun  9 21:28:31 2016
New Revision: 237277

URL: https://gcc.gnu.org/viewcvs?rev=237277=gcc=rev
Log:
[Patch] PR70751, correct the cost for spilling non-pseudo into memory

PR rtl-optimization/70751
* lra-constraints.c (process_alt_operands): Recognize Non-pseudo
spilled
into memory.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460

--- Comment #15 from joseph at codesourcery dot com  ---
On Thu, 9 Jun 2016, ch3root at openwall dot com wrote:

>  > For *scalar* assignment that would be fine because of TS 18661-1 saying
>  > "Whether C assignment (6.5.16) (and conversion as if by assignment) 
> to the
>  > same format is an IEC 60559 convertFormat or copy operation is
>  > implementation-defined, even if  defines the macro
>  > FE_SNANS_ALWAYS_SIGNAL (F.2.1).".  It's rather less clear for struct
>  > assignment.
> 
> How is it compatible with C11, 6.3p2: "Conversion of an operand value to 
> a compatible type causes no change to the value or the representation."? 
> Ha, even changing representation is prohibited.

That paragraph starts "Unless explicitly stated otherwise,".  C11 does not 
consider sNaNs, and TS 18661 is explicitly stating otherwise for them.

"or the representation" is clearly nonsensical here.  When something is 
converted it's an rvalue, and rvalues aren't associated with 
representations unless and until stored in an object; they are just 
members of the set of values of a type (and on assignment, 6.2.6.1#8 
applies).

> > Rather, it's OK for the loads
> > to raise an exception because assignment / argument passing etc. can be
> 
> I mean that "volatile double x; /* store sNaN to x */; x;" gives SIGFPE 
> currently. It doesn't look like (re)definitions of assignment etc. would 
> be applicable to this case.

That seems rather like an omission in the specification relating to excess 
range and precision, which should be considered like a conversion 
(convertFormat) to the relevant wider format.

[Bug middle-end/71310] Bitfields cause load hit store with smaller store and larger load

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71310

--- Comment #7 from Segher Boessenkool  ---
Well, the code for picking the representative already has computed
the maximum size allowable under the C++11 model there (in maxbitsize).
But this loop always picks the smallest it can.  That probably is not
such a bad choice.

For e.g. a bitfield of 32 bits followed by some other 32-bit it has
maxbitsize = 32, but the BIT_FIELD_REF still does 64,64, which does
not create wrong code but just very slow code (not sure if it's
invalid under the memory model, the "extra" bits read are unused
always).

I'll try your optimize_bit_field idea.

[Bug c/68657] [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68657

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to npl from comment #9)
> test.c:1:32: warning: '-Wpsabi' is not an option that controls warnings
> [-Wpragmas]
>  #pragma GCC diagnostic ignored "-Wpsabi"
> ^

Same problem. It needs to add "Warning" to gcc/c-family/c.opt

[Bug c++/55813] Poorly named/documented option Wctor-dtor-privacy

[kyle.strand at beckman dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55813

--- Comment #6 from Kyle J Strand  ---
(In reply to Manuel López-Ibáñez from comment #5)

> Please open a new PR and copy the testcase on it.

Submitted as Bug 71484 .

[Bug c++/71484] Class with implicit public constructor triggers `-Wctor-dtor-privacy`

[kyle.strand at beckman dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71484

Kyle J Strand  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug c++/71484] New: Class with implicit public constructor triggers `-Wctor-dtor-privacy`

[kyle.strand at beckman dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71484

Bug ID: 71484
   Summary: Class with implicit public constructor triggers
`-Wctor-dtor-privacy`
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyle.strand at beckman dot com
  Target Milestone: ---

A class whose only user-declared methods are `private`, but which *does* have
an implicit public constructor, can trigger `-Wctor-dtor-privacy`.

See http://stackoverflow.com/q/33157248/1858225 for discussion and sample code.

The offending code is copied here for convenience:

struct foo
{
  private:
static int test(void) { return 3; };
};

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[ch3root at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460

--- Comment #14 from Alexander Cherepanov  ---
On 2016-06-08 20:49, joseph at codesourcery dot com wrote:
 >> - sNaNs are turned into qNaNs on x86-32 if traps are turned off. 
Probably ok if
 >> sNaNs and qNaNs are considered different representations of the same 
value;
 >
 > For *scalar* assignment that would be fine because of TS 18661-1 saying
 > "Whether C assignment (6.5.16) (and conversion as if by assignment) 
to the
 > same format is an IEC 60559 convertFormat or copy operation is
 > implementation-defined, even if  defines the macro
 > FE_SNANS_ALWAYS_SIGNAL (F.2.1).".  It's rather less clear for struct
 > assignment.

How is it compatible with C11, 6.3p2: "Conversion of an operand value to 
a compatible type causes no change to the value or the representation."? 
Ha, even changing representation is prohibited.

 > I expect the present bug is essentially the same as bug 58416 (which
 > concerns a union, where the floating-point member isn't even the active
 > one).

Indeed. It seems there are 3 variations of this bug:
- a struct with one FP member -- triggered even without optimizations;
- scalarization of a struct;
- scalarization of a union.
There are testcases for all of them.

On 2016-06-09 19:59, joseph at codesourcery dot com wrote:
>> - mere load (e.g. from a volatile var) of a float or double sNaN traps
>> on x86-32 when traps are enabled;
>
> It raises an exception.  Exception trapping is outside the scope of ISO C.

Yes, so on level of ISO C it's just a trap.

>> - this perfectly fits the description of trap representation.
>> So gcc de facto doesn't support sNaNs in this configuration and any its
>> use is UB.
>
> No, it's not UB (given -fsignaling-nans).

I was too concise. I mean that it's UB from POV of ISO C. But an 
implementation is free define some of it. And the standard doesn't place 
any restrictions on this definition. For example, an implementation can 
say that it's fine to pass sNaN to a function as an argument but it's 
not fine to return it from a function. Or it can say that passing it as 
an argument is not fine too.

So the current behavior of gcc on x86-32 can be considered conforming 
(modulo this bug).

> Rather, it's OK for the loads
> to raise an exception because assignment / argument passing etc. can be

I mean that "volatile double x; /* store sNaN to x */; x;" gives SIGFPE 
currently. It doesn't look like (re)definitions of assignment etc. would 
be applicable to this case.

> implemented as convertFormat rather than copy, which means raising the
> exception and converting to qNaN.

As I wrote above, it's not clear to me that this is compatible with the 
current text of C11. Not that it means much...

> (As a quality-of-implementation issue I
> still think that with -fsignaling-nans, floating-point loads should be
> avoided for simple copies of float and double values where they aren't
> needed in a floating-point register for arithmetic, function return etc. -
> that would allow sNaNs to be passed as function arguments, for example.)

AIUI ABI restricts how FP values are returned from functions so this 
cannot be fixed (bug 57484). But there are 2 cases that can be fixed 
(bug 56831):
- assignments;
- passing arguments to functions.
Plus loads in a void context:-)

[Bug tree-optimization/71483] New: g++ ICE at -O3 on valid code on x86_64-linux-gnu with “Floating point exception”

[helloqirun at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71483

Bug ID: 71483
   Summary: g++ ICE at -O3 on valid code on x86_64-linux-gnu with
“Floating point exception”
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following valid code causes an ICE when compiled with the current g++ trunk
at only -O3 on x86_64-linux-gnu in 32- and 64-bit modes. 

gcc at -O3 works fine.

It started with r237064. I am not sure if it is a dup of pr71416 or pr71407.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 7.0.0 20160608 (experimental) [trunk revision 237212] (GCC) 


$ gcc-trunk -O3 -c abc.c
$
$ g++-trunk -O3 -c abc.c
abc.c: In function ‘void fn1()’:
abc.c:3:6: internal compiler error: Floating point exception
 void fn1() {
  ^~~
0xd3d9cf crash_signal
../../gcc/gcc/toplev.c:335
0xf833cc vectorizable_live_operation(gimple*, gimple_stmt_iterator*,
_slp_tree*, int, gimple**)
../../gcc/gcc/tree-vect-loop.c:6377
0xf7fdb6 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../gcc/gcc/tree-vect-stmts.c:8327
0xf9da2b vect_schedule_slp_instance
../../gcc/gcc/tree-vect-slp.c:3641
0xf9d7f4 vect_schedule_slp_instance
../../gcc/gcc/tree-vect-slp.c:3519
0xf9d7f4 vect_schedule_slp_instance
../../gcc/gcc/tree-vect-slp.c:3519
0xf9e2a6 vect_schedule_slp(vec_info*)
../../gcc/gcc/tree-vect-slp.c:3713
0xf8729d vect_transform_loop(_loop_vec_info*)
../../gcc/gcc/tree-vect-loop.c:6865
0xfa3c85 vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:554
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.




$ cat abc.c
int b, c, d;
short *e;
void fn1() {
  for (; b; b--) {
d = *e >> 2;
*e++ = d;
c = *e;
*e++ = d;
  }
}

[Bug c/68657] [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings

[npl at chello dot at]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68657

npl at chello dot at changed:

   What|Removed |Added

 CC||npl at chello dot at

--- Comment #9 from npl at chello dot at ---
I am using gcc 6.1 and I have the same problem with disabling -Wpsabi


echo '#pragma GCC diagnostic ignored "-Wpsabi"' >test.c
gcc -c test.c


test.c:1:32: warning: '-Wpsabi' is not an option that controls warnings
[-Wpragmas]
 #pragma GCC diagnostic ignored "-Wpsabi"
^

[Bug c++/55813] Poorly named/documented option Wctor-dtor-privacy

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55813

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Kyle J Strand from comment #4)
> See http://stackoverflow.com/q/33157248/1858225 for discussion and sample
> code.

The first testcase has a public static method.
The second testcase seems like a bug, but this bug  was about documentation.
Please open a new PR and copy the testcase on it.

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952

--- Comment #42 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #39)
> 2. Handle non-contiguous strings:
> 
>   __builtin_printf(" %" "d ", 0.5);

Right now, we detect that the offset is outside the first string and give up.
Supporting this might be just as easier as keeping track in
location_column_from_byte_offset of the closing ", skipping to the opening "
and keep counting until reaching the offset.

No time to do it myself but worth a try.

[Bug tree-optimization/71466] [7 Regression] wrong code at -O3 on x86_64-linux-gnu

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #7 from Jan Hubicka  ---
Isn't the problem caused by fact that you end up rolling the loop and thus
increasing number of iterations? Number of iterations is number of execution of
the edge latch->header and is stored perisstently in the loop structure.
If you change shape of the loop and some earlier edge becomes latch, you may
need to adjust the estimate.

If you are busy, I may try to look into this at weekend. I quite like the new
threading code becuase it is simple while it catch many cases in practice. If
it had mode that does not increase code size (which I sent patch for) it may be
a good candidate for an early pass getting profile estimation to work
noticeably better.

Honza

[Bug c/71360] Wrong position for "warning: '0' flag ignored with precision and ‘%d’ gnu_printf format [-Wformat=]"

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71360

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Manuel López-Ibáñez  ---
Locations within strings do not support non-contiguous strings yet:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952#c39

*** This bug has been marked as a duplicate of bug 52952 ***

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||ch3root at openwall dot com

--- Comment #41 from Manuel López-Ibáñez  ---
*** Bug 71360 has been marked as a duplicate of this bug. ***

[Bug c++/71456] missing -Wunused-variable on a static global initialized with another

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71456

--- Comment #4 from Eric Gallager  ---
(In reply to Martin Sebor from comment #3)
> (In reply to Eric Gallager from comment #2)
> > Speaking of -Wglobal-constructors, FSF GCC doesn't support this option. Is
> > there a bug open for adding it? I couldn't find one when searching.
> 
> I couldn't find it either.  It might be a useful feature to request, either
> independent of this bug, or as part of it.

Okay, I opened bug 71482 for it.

[Bug c++/71482] New: Add -Wglobal-constructors warning option

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71482

Bug ID: 71482
   Summary: Add -Wglobal-constructors warning option
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---

Apple's gcc 4.2 has a warning flag called -Wglobal-constructors that they
describe in their invoke.texi like this:

@c APPLE LOCAL begin Wglobal-constructors 6324584
@item -Wglobal-constructors
@opindex Wglobal-constructors
Warn about namespace scope data that requires construction or
destruction, or functions that use the constructor attribute or the
destructor attribute.  Additionally warn if the Objective-C GNU
runtime is used to initialize various metadata.
@c APPLE LOCAL end Wglobal-constructors 6324584

In their c.opt it says:

; APPLE LOCAL begin Wglobal-constructors 6324584
Wglobal-constructors
C ObjC C++ ObjC++ Var(warn_global_constructors)
Warn when global (namespace scope) objects require runtime
construction or destruction or when functions that use attribute
constructor or destructor are used.  This is useful to help maintain
fast program startup and end times.
; APPLE LOCAL end Wglobal-constructors 6324584

Apparently this option has been carried forward to clang, as pointed out in bug
71456. It would be useful for FSF GCC to have this warning option, too.

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460

--- Comment #13 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #7)

> Oh - I hope TYPE_MODE does not affect the ABI here ;)  You might want to
> double-check that (struct-layout tests plus call ABI)
The patch introduces one testsuite failure with -m32:

FAIL: g++.dg/torture/pr67581.C

where:

/home/uros/gcc-svn/trunk/gcc/testsuite/g++.dg/torture/pr67581.C:2:7: error:
type transparent 'union U' cannot be made transparent because the type of the
first field has a different ABI from the class overall

I don't know if this is c++ frontend issue, where BLKmode should be allowed.

[Bug tree-optimization/71433] [7 Regression] -Warray-bounds false positive with -O2

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-09
 Ever confirmed|0   |1

--- Comment #4 from Jeffrey A. Law  ---
Thanks Vincent.   Glad to have this little test.

AFAICT before the recent jump threading changes we had something like this in
VRP1:


;;   basic block 9, loop depth 0, count 0, freq 900, maybe hot
;;prev block 8, next block 10, flags: (NEW, REACHABLE)
;;pred:   5 [50.0%]  (FALSE_VALUE,EXECUTABLE)
  e_23 = ASSERT_EXPR = -52>;
  if (e_23 < 0)
goto ;
  else
goto ;
;;succ:   10 [27.0%]  (TRUE_VALUE,EXECUTABLE)
;;11 [73.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 10, loop depth 0, count 0, freq 243, maybe hot
;;prev block 9, next block 11, flags: (NEW, REACHABLE)
;;pred:   9 [27.0%]  (TRUE_VALUE,EXECUTABLE)
  e_22 = ASSERT_EXPR ;
  _2 = (unsigned int) e_22;
  _3 = _2 + 53;
  n_16 = (int) _3;
;;succ:   11 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 11, loop depth 0, count 0, freq 900, maybe hot
;;prev block 10, next block 12, flags: (NEW, REACHABLE)
;;pred:   9 [73.0%]  (FALSE_VALUE,EXECUTABLE)
;;10 [100.0%]  (FALLTHRU,EXECUTABLE)
  # n_9 = PHI <53(9), n_16(10)>
  goto ;

Note that as written we can pretty easily derive a range for n_16 as [1..52]
which ultimately allows us to remove the block with the out-of-range array
index as unreachable.


With the threading before VRP things are bit more complex as BB10 has 3
predecessors (due to threading).  Now it happens that on each predecessor we
have a suitable ASSERT_EXPR to narrow the range of e_13.  But we're unable to
use them in that form.

Ideally we'd like to either be smarter about the initial insertion point or
sink them  after insertion.  I'm pretty sure that would resolve this issue. 
However, it's not compile-time friendly.  I'm going to need to think a bit more
on this one.

[Bug bootstrap/71481] [7 regression] ICE during selftest: input.c: test_reading_source_line

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
(In reply to David Malcolm from comment #1)
...
> Am investigating the best cross-platform way to open a named tempfile.

libiberty's "make_temp_file" seems to be the best way.

[Bug bootstrap/71481] [7 regression] ICE during selftest: input.c: test_reading_source_line

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481

--- Comment #1 from David Malcolm  ---
Sorry about the breakage.

As a workaround, the failing test can be disabled by commenting-out the call to
input_c_tests:

diff --git a/gcc/selftest-run-tests.c b/gcc/selftest-run-tests.c
index 934e700..c2fd7ac 100644
--- a/gcc/selftest-run-tests.c
+++ b/gcc/selftest-run-tests.c
@@ -48,10 +48,9 @@ selftest::run_tests ()
   vec_c_tests ();
   pretty_print_c_tests ();
   wide_int_cc_tests ();

   /* Mid-level data structures.  */
-  input_c_tests ();
+  //input_c_tests ();
   tree_c_tests ();
   gimple_c_tests ();
   rtl_tests_c_tests ();


Presumably this could be fixed properly by having the selftest write out some
multiline text to a named tempfile, and then read in a line in the middle of
the text.  Am investigating the best cross-platform way to open a named
tempfile.

[Bug bootstrap/71481] [7 regression] ICE during selftest (selftest.c:44)

[vp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481

Vidya Praveen  changed:

   What|Removed |Added

   Last reconfirmed||2016-6-9
 CC||dmalcolm at gcc dot gnu.org,
   ||vp at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug bootstrap/71481] New: [7 regression] ICE during selftest (selftest.c:44)

[vp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481

Bug ID: 71481
   Summary: [7 regression] ICE during selftest (selftest.c:44)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vp at gcc dot gnu.org
  Target Milestone: ---

self-test of cross build would fail when run in an environment different from
where it was built. 

This is because add_file_to_cache_tab() would try to read
/path/to/build/src/gcc/gcc/input.c (__FILE__ expanded while building cross
toolchain) which will be invalid when binaries are ran in a different
machine/environment. 

cc1: internal compiler error: in fail, at selftest.c:44

0x1157822 selftest::fail(char const*, int, char const*)
/path/to/build/src/gcc/gcc/selftest.c:44
0x1160aa4 test_reading_source_line
/path/to/build/src/gcc/gcc/input.c:1230
0x1160aa4 selftest::input_c_tests()
/path/to/build/src/gcc/gcc/input.c:1249
0x1103fae selftest::run_tests()
/path/to/build/src/gcc/gcc/selftest-run-tests.c:52
0xb04699 toplev::run_self_tests()
/path/to/build/src/gcc/gcc/toplev.c:2048
Please submit a full bug report,

[Bug sanitizer/71480] ASan should align string constants to shadow granularity.

[m.ostapenko at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71480

--- Comment #1 from Maxim Ostapenko  ---
The problem appears for arm target only, x86 is fine.

$ armv7l-tizen-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=armv7l-tizen-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/max/install/armv7l-tizen/libexec/gcc/armv7l-tizen-linux-gnueabi/7.0.0/lto-wrapper
Target: armv7l-tizen-linux-gnueabi
Configured with: /home/max/workspace/downloads/gcc/configure
--prefix=/home/max/install/armv7l-tizen --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=armv7l-tizen-linux-gnueabi --disable-nls
--enable-poison-system-directories
--with-pkgversion=Tizen.armv7l.GA2.2015-08-26
--with-sysroot=/home/max/install/armv7l-tizen/armv7l-tizen-linux-gnueabi/sys-root
--with-gmp=/home/max/build/v6/fake-root
--with-libelf=/home/max/build/v6/fake-root
--with-mpc=/home/max/build/v6/fake-root
--with-mpfr=/home/max/build/v6/fake-root --without-cloog --without-ppl
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--enable-languages=c,c++,fortran --disable-libstdcxx-pch --enable-__cxa_atexit
--enable-libssp --enable-lto --enable-checking=release
--with-build-time-tools=/home/max/install/armv7l-tizen/bin --with-gnu-as
--with-gnu-ld
--with-specs='%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
%{!Werror=unused-local-typedefs:%{!Wno-error=unused-local-typedefs:-Wno-error=unused-local-typedefs}}
%{fuse-linker-plugin|fno-use-linker-plugin|flto|flto=*:;:-fno-use-linker-plugin}'
--disable-multilib --disable-gnu-unique-object --enable-linker-build-id
--with-mode=arm --with-fpu=neon-vfpv4 --with-tune=cortex-a8 --with-float=softfp
--enable-libgomp --enable-linux-futex
Thread model: posix
gcc version 7.0.0 20160607 (experimental) (Tizen.armv7l.GA2.2015-08-26)

[Bug sanitizer/71480] New: ASan should align string constants to shadow granularity.

[m.ostapenko at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71480

Bug ID: 71480
   Summary: ASan should align string constants to shadow
granularity.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.ostapenko at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: arm-linux-gnueabi

Consider following testcase:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main (void)
{
  struct stat st;
  char tpl[20] = "/tmp/test.XX";
  char tpl2[20] = "/tmp/test.XX";
  int fd = mkstemp (tpl);
  int fd2 = mkstemp (tpl2);
  if (fd == -1)
{
  if (fd2 != -1)
unlink (tpl2);
  exit (1);
}

  if (fd2 == -1)
exit (1);

  unlink (tpl);
  unlink (tpl2);

  if (fstat (fd, ) != 0)
exit(1);

  if ((st.st_mode & 0777) != 0600)
exit (1);

  if (strcmp (tpl, "/tmp/test.XX") == 0)
exit(1);

  if (strcmp (tpl, tpl2) == 0)
exit(1);

   return 0; 
}

When compiling this code to arm-linux-gnueabi with Thumb mode,
"/tmp/test.XX" may actually stay unaligned to shadow granularity:

$ armv7l-tizen-linux-gnueabi-gcc -O2 -mthumb test.c -S -fno-omit-frame-pointer
$ cat test.s

.section.rodata
.align  2
.set.LANCHOR0,. + 0
.LC4:
.ascii  "/tmp/test.XX\000"
.space  3
.space  44
.data
.align  2
.set.LANCHOR1,. + 0
.type   .LASAN0, %object
.size   .LASAN0, 28
.LASAN0:
.word   .LC4
.word   20
.word   64
.word   .LC6
.word   .LC7
.word   0
.word   0
.space  36
.section.rodata.str1.4,"aMS",%progbits,1
.align  2

Here, we have align == 2 for .LC4, that may cause runtime failure in ASan with
something like this:

bash-3.2# ASAN_OPTIONS=report_globals=2
/home/abuild/rpmbuild/BUILD/tdb-1.3.1/testprog
#0 0x40859645 in __asan_register_globals (/usr/lib/libasan.so+0x25645)
#1 0x10b67 in __libc_csu_init
(/home/abuild/rpmbuild/BUILD/tdb-1.3.1/testprog+0x10b67)
#2 0x40dd848b in __libc_start_main (/lib/libc.so.6+0x1648b)

=== ID 92274689; 0x00020dd0 0x00020dd0
==8205==Added Global[0x00020dd0]: beg=0x00010b8c size=20/64 name=*.LC4
module=test.c dyn_init=0
==8205==AddressSanitizer CHECK failed:
../../../../libsanitizer/asan/asan_globals.cc:145
"((AddrIsAlignedByGranularity(g->beg))) != (0)" (0x0, 0x0)
#0 0x408cd749  (/usr/lib/libasan.so+0x99749)
#1 0x408d1e5d in __sanitizer::CheckFailed(char const*, int, char const*,
unsigned long long, unsigned long long) (/usr/lib/libasan.so+0x9de5d)
#2 0x40859a1f in __asan_register_globals (/usr/lib/libasan.so+0x25a1f)
#3 0x10b67 in __libc_csu_init
(/home/abuild/rpmbuild/BUILD/tdb-1.3.1/testprog+0x10b67)
#4 0x40dd848b in __libc_start_main (/lib/libc.so.6+0x1648b)


The problem here is that for ".LC4" TREE_CONSTANT_POOL_ADDRESS_P (symbol) is
true and we don't enforce additional alignment requirements in
place_block_symbol. Perhaps something like this can fix the issue:

diff --git a/gcc/varasm.c b/gcc/varasm.c
index 4a7124e..de8bcd6 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -7201,7 +7201,11 @@ place_block_symbol (rtx symbol)
   if ((flag_sanitize & SANITIZE_ADDRESS)
  && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST
  && asan_protect_global (DECL_INITIAL (decl)))
-   size += asan_red_zone_size (size);
+   {
+ size += asan_red_zone_size (size);
+ alignment = MAX (alignment,
+  ASAN_RED_ZONE_SIZE * BITS_PER_UNIT);
+   }
 }
   else
 {

[Bug tree-optimization/71466] [7 Regression] wrong code at -O3 on x86_64-linux-gnu

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466

--- Comment #6 from Jeffrey A. Law  ---
FWIW, I've got two other BZs that exhibit at the surface seem to be the same
problem -- namely the new threading code causing the unroller to generate
incorrect code.

The after threading code looks right in the test I've been looking at, but I
find it hard to believe we've got 3 distinct instances where the new threading
code is exposing the same latent bug in the unroller.

So, anyway, at first glance this appears to be the same issue I'm already
tracking.

[Bug c/71479] error on __builtin_add_overflow with bool or enum pointer as last argument

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71479

--- Comment #3 from Martin Sebor  ---
(In reply to Marek Polacek from comment #1)
> Dup of PR66938?

You're right, bug 66938 points out the same problem.  I leave it to you to
decide which one to close as a dupe (this one is broader in mentioning
enumerated types as well and has a test case so I'd be inclined to keep it
open.)

[Bug c/71479] error on __builtin_add_overflow with bool or enum pointer as last argument

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71479

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #2 from Martin Sebor  ---
The three type-generic Built-in Functions to Perform Arithmetic with Overflow
Checking document their interface like so:

  The first built-in function allows arbitrary integral types for operands and
the result type must be pointer to some integer type, ...

The C and C++ standard term /integer type/ encompasses both _Bool and
enumerated types, in addition to signed and unsigned integer types.

Give this, one should expect __builtin_add_overflow to accept a pointer to any
one of these types as the last argument.  However, GCC rejects such calls. 
Either the documentation should be clarified or the argument checking adjusted
to match the existing text.  (I would lean toward accepting _Bool but
continuing to reject enumerated types, especially in C++.)

$ cat z.cpp && /home/msebor/build/gcc-6-branch/gcc/xgcc -B
/home/msebor/build/gcc-6-branch/gcc/ -Wall -Wextra -xc z.cpp
void f (void)
{
  _Bool b;
  __builtin_add_overflow (0, 0, );

  enum E { e0 } e;
  __builtin_add_overflow (0, 0, );

  char c;
  __builtin_add_overflow (0, 0, );
}
z.cpp: In function ‘f’:
z.cpp:4:3: error: argument 3 in call to function ‘__builtin_add_overflow’ does
not have pointer to integer type
   __builtin_add_overflow (0, 0, );
   ^~
z.cpp:7:3: error: argument 3 in call to function ‘__builtin_add_overflow’ does
not have pointer to integer type
   __builtin_add_overflow (0, 0, );
   ^~

[Bug c/71479] error on __builtin_add_overflow with bool or enum pointer as last argument

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71479

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Dup of PR66938?

[Bug c/71479] New: error on __builtin_add_overflow with bool or enum pointer as last argument

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71479

Bug ID: 71479
   Summary: error on __builtin_add_overflow with bool or enum
pointer as last argument
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

[Bug c++/71469] Print possible override candidates when a method is marked override but doesn't override

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71469

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic, easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-09
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
It seems feasible with the current infrastructure. Perhaps an easy-hack for
someone new.

[Bug c++/71472] Wlogical-op misses exhaustive-or case (... || A) || B

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71472

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-09
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
I was sure there was a duplicate of this somewhere. Oh well...

[Bug bootstrap/71471] [7 Regression] Selftest failure in pretty-print.c

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71471

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from David Malcolm  ---
I verified that this fixes the build (of stage 1) on gcc111
(powerpc-ibm-aix7.1.3.0).

Marking this one as resolved.

[Bug bootstrap/71471] [7 Regression] Selftest failure in pretty-print.c

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71471

--- Comment #7 from David Malcolm  ---
Author: dmalcolm
Date: Thu Jun  9 17:27:12 2016
New Revision: 237271

URL: https://gcc.gnu.org/viewcvs?rev=237271=gcc=rev
Log:
PR bootstrap/71471: remove selftest for pp_format (%p)

gcc/ChangeLog:
PR bootstrap/71471
* pretty-print.c (pp_indent): Specify that %p is printed in a
host-dependent manner.
(test_pp_format): Remove the test for %p.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/pretty-print.c

[Bug c/65446] Improve -Wformat-signedness

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65446

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-09
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Ricardo Nabinger Sanchez from comment #5)
> In short: please warn.  Some cases will generate unexpected results (which
> are not compilation errors), simply because the programmer used an incorrect
> format specifier.

I think there is no doubt that we want to warn in cases that lead to different
output (%u + short) or UB and avoid warning in cases that do not have any
effect (%u + unsigned short).

The question is how and who will implement these heuristics:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

You are welcome to try. All the relevant code is in
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c-family/c-format.c;h=c19c411d61a44773c55c8686802787ec7e4c40a4;hb=HEAD

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[ch3root at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460

--- Comment #12 from Alexander Cherepanov  ---
On 2016-06-09 11:22, rguenth at gcc dot gnu.org wrote:
> Would be nice to have a testcase for the SRA case as well.

Source code:

--
#define _GNU_SOURCE
#include 

struct s { double d; char c; };

__attribute__((noinline,noclone))
void copy(struct s *q, struct s *p)
{
   struct s tmp = *p;
   *q = tmp;
}

int main()
{
   feenableexcept(FE_INVALID);

   struct s x = {0}, y;
   ((unsigned char *))[7] = 0x7f;
   ((unsigned char *))[6] = 0xf0; // sNaN
   ((unsigned char *))[0] = 0x01;

   copy(, );
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra -fsignaling-nans -lm -m32 -O3 
test.c && ./a.out
Floating point exception
--

gcc version: gcc (GCC) 7.0.0 20160608 (experimental)

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460

--- Comment #11 from joseph at codesourcery dot com  ---
On Thu, 9 Jun 2016, ch3root at openwall dot com wrote:

> - mere load (e.g. from a volatile var) of a float or double sNaN traps 
> on x86-32 when traps are enabled;

It raises an exception.  Exception trapping is outside the scope of ISO C.

> - this perfectly fits the description of trap representation.
> So gcc de facto doesn't support sNaNs in this configuration and any its 
> use is UB.

No, it's not UB (given -fsignaling-nans).  Rather, it's OK for the loads 
to raise an exception because assignment / argument passing etc. can be 
implemented as convertFormat rather than copy, which means raising the 
exception and converting to qNaN.  (As a quality-of-implementation issue I 
still think that with -fsignaling-nans, floating-point loads should be 
avoided for simple copies of float and double values where they aren't 
needed in a floating-point register for arithmetic, function return etc. - 
that would allow sNaNs to be passed as function arguments, for example.)

> IOW this bug is not about wrong handling of sNaNs, it's about 
> introducing sNaN-related problems where there were none. Like copying a 
> partially initialized struct where one of unknown fields happened to 
> have the double type and sNaN as representation.

Indeed, which is why a fix for this issue / bug 58416 should *not* be 
conditional on -fsignaling-nans - it affects code that doesn't use 
signaling NaNs, just bit patterns that are never actually interpreted with 
type float or double (but if so interpreted, would be signaling NaNs).

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[ch3root at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460

--- Comment #10 from Alexander Cherepanov  ---
On 2016-06-08 20:47, pinskia at gcc dot gnu.org wrote:
> --- Comment #1 from Andrew Pinski  ---
> I think this is really a dup of bug 57484.  The problem is x87 related and
> there is not much to be done.

I don't think so.

I haven't looked into floating-point arithmetic in any details but, as a 
first approximation, I see the situation like this:
- sNaNs are not required by C11 (including by Annex F);
- mere load (e.g. from a volatile var) of a float or double sNaN traps 
on x86-32 when traps are enabled;
- this perfectly fits the description of trap representation.
So gcc de facto doesn't support sNaNs in this configuration and any its 
use is UB.

OTOH copying of structures doesn't invoke UB and is required not to 
trap. (At least if its address is taken:-)
(Not sure if this is contradicted by C11, 6.2.6.1p5: "If such a 
representation is produced by a side effect that modifies all or any 
part of the object by an lvalue expression that does not have character 
type, the behavior is undefined.50)". But the intention of DR 222 is 
quite clear.)

IOW this bug is not about wrong handling of sNaNs, it's about 
introducing sNaN-related problems where there were none. Like copying a 
partially initialized struct where one of unknown fields happened to 
have the double type and sNaN as representation.

[Bug tree-optimization/71478] [7 Regression] ICE in tree-ssa-reassoc.c after r236564

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71478

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.1.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2016-06-09
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE in tree-ssa-reassoc.c   |[7 Regression] ICE in
   |after r236564   |tree-ssa-reassoc.c after
   ||r236564
   Target Milestone|--- |7.0
  Known to fail||7.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed (on aarch64 at least)

[Bug c/70883] inconsistent error message for calls to __builtin_add_overflow with too few arguments

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70883

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail|6.0 |6.1.0

--- Comment #5 from Martin Sebor  ---
Patch committed in r237268.  It's probably not worth backporting to 6.x branch.

[Bug c/70883] inconsistent error message for calls to __builtin_add_overflow with too few arguments

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70883

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Thu Jun  9 16:32:25 2016
New Revision: 237268

URL: https://gcc.gnu.org/viewcvs?rev=237268=gcc=rev
Log:
PR c/70883 - inconsistent error message for calls to __builtin_add_overflow
  with too few arguments

gcc/c-family/ChangeLog:
2016-06-09  Martin Sebor  

PR c/70883
* c-common.c (builtin_function_validate_nargs): Make text of error
message consistent with others like it.

gcc/testsuite/ChangeLog:
2016-06-09  Martin Sebor  

PR c/70883
* c-c++-common/builtin-arith-overflow-1.c: Adjust diagnostic text.
* gcc.dg/builtin-constant_p-1.c: Same.
* gcc.dg/builtins-error.c: Same.
* gcc.dg/pr70859.c: Same.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/builtin-arith-overflow-1.c
trunk/gcc/testsuite/gcc.dg/builtin-constant_p-1.c
trunk/gcc/testsuite/gcc.dg/builtins-error.c
trunk/gcc/testsuite/gcc.dg/pr70859.c

[Bug tree-optimization/71478] New: ICE in tree-ssa-reassoc.c after r236564

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71478

Bug ID: 71478
   Summary: ICE in tree-ssa-reassoc.c after r236564
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org
CC: kugan.vivekanandarajah at linaro dot org
  Target Milestone: ---

Created attachment 38671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38671=edit
Reduced testcase

I took a look at PR71170, PR71230, PR71252 and PR 71281, but they seemed subtly
different to my issue.

The attached testcase fails for me on trunk with -O1 on
x86_x64-unknown-linux-gnu and aarch64-none-linux-gnu.

The ICE looks like:

x.c: In function 'foo':
x.c:7:1: internal compiler error: gimple check: expected
gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs1, at
gimple.h:2493
 foo (void)
 ^~~
0x856d7b gimple_check_failed(gimple const*, char const*, int, char const*,
gimple_code, tree_code)
.../gcc/gimple.c:1177
0xc92547 GIMPLE_CHECK2
.../gcc/gimple.h:73
0xc92547 gimple_assign_rhs1
.../gcc/gimple.h:2493
0xc96d28 rewrite_expr_tree
.../gcc/tree-ssa-reassoc.c:3834
0xc97112 rewrite_expr_tree
.../gcc/tree-ssa-reassoc.c:3931
0xca1970 reassociate_bb
.../gcc/tree-ssa-reassoc.c:5372
0xca1c07 reassociate_bb
.../gcc/tree-ssa-reassoc.c:5414
0xca21c0 do_reassoc
.../gcc/tree-ssa-reassoc.c:5528
0xca21c0 execute_reassoc
.../gcc/tree-ssa-reassoc.c:5615
0xca21c0 execute
.../gcc/tree-ssa-reassoc.c:5654
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug debug/71432] [7 Regression] -fcompare-debug failure (length)

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71432

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Bernd Schmidt  ---
Fixed.

[Bug tree-optimization/52171] memcmp/strcmp/strncmp can be optimized when the result is tested for [in]equality with 0

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52171
Bug 52171 depends on bug 71413, which changed state.

Bug 71413 Summary: [7 Regression] bootstrap (gnat) broken on arm-linux-gnueabi*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71413

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug ada/71413] [7 Regression] bootstrap (gnat) broken on arm-linux-gnueabi*

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71413

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Bernd Schmidt  ---
Assuming fixed. Reopen if not.

[Bug c++/71456] missing -Wunused-variable on a static global initialized with another

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71456

--- Comment #3 from Martin Sebor  ---
(In reply to Eric Gallager from comment #2)
> Speaking of -Wglobal-constructors, FSF GCC doesn't support this option. Is
> there a bug open for adding it? I couldn't find one when searching.

I couldn't find it either.  It might be a useful feature to request, either
independent of this bug, or as part of it.

[Bug tree-optimization/71407] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple: integral result type precision does not match field size of BIT_FIELD_REF)

[helloqirun at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71407

--- Comment #6 from Qirun Zhang  ---
(In reply to alahay01 from comment #5)
> Qirun Zhang :
> 
> That's a different issue (original test fails due to data type mismatch,
> this test fails because the loop boundary is unset).
> 
> Please could you raise your test as a new bug and assign it to me (I think I
> have a fix for it).

Thanks. I have opened as PR71477.

[Bug tree-optimization/71477] New: gcc ICE at -O3 on valid code on x86_64-linux-gnu with “seg fault”

[helloqirun at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71477

Bug ID: 71477
   Summary: gcc ICE at -O3 on valid code on x86_64-linux-gnu with
“seg fault”
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following valid code causes an ICE when compiled with the current gcc trunk
at only -O3 on x86_64-linux-gnu in 64-bit mode. 32-bit mode works fine.

It appears to be a 7 regression.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 7.0.0 20160608 (experimental) [trunk revision 237212] (GCC)


$ gcc-trunk -O3 abc.c
abc.c: In function ‘fn1’:
abc.c:3:6: internal compiler error: Segmentation fault
 void fn1() {
  ^~~
0xb635cf crash_signal
../../gcc/gcc/toplev.c:335
0xe5a184 top_bit_of
../../gcc/gcc/wide-int.cc:424
0xe5a184 wi::add_large(long*, long const*, unsigned int, long const*, unsigned
int, unsigned int, signop, bool*)
../../gcc/gcc/wide-int.cc:1143
0xdad921 wi::binary_traits >, int,
wi::int_traits >
>::precision_type, wi::int_traits::precision_type>::result_type
wi::add >,
int>(generic_wide_int > const&, int const&)
../../gcc/gcc/wide-int.h:2330
0xdad921 wi::binary_traits >, int,
(wi::precision_type)2, wi::int_traits::precision_type>::result_type
generic_wide_int >::operator+(int const&)
const
../../gcc/gcc/wide-int.h:711
0xdad921 vect_transform_loop(_loop_vec_info*)
../../gcc/gcc/tree-vect-loop.c:6935
0xdc9bc5 vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:554
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ cat abc.c
#define N 6
int a;
void fn1() {
  int k = 0;
  for (; k < N;)
for (a = 0; a < N; k++)
  a = k + N;
}

[Bug bootstrap/71471] [7 Regression] Selftest failure in pretty-print.c

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71471

--- Comment #6 from David Malcolm  ---
Thanks.

Sorry about the breakage.

Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00703.html

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[carlos at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445

Carlos O'Donell  changed:

   What|Removed |Added

 CC||carlos at redhat dot com

--- Comment #13 from Carlos O'Donell  ---
(In reply to Adhemerval Zanella from comment #12)
> After checking the work required for enable symbol versioning wrapper on
> libsanitizer I am more inclined to go with always ignore the high bits (at
> least for backports). The versioning enablement will require some changes
> and I foresee it will generate some discussion in sanitizer side before a
> settle solution is used. Any suggestions?

+1

That sounds like the most sensible course of action.

The real solution IMO is for the interposer to provide all the various versions
of a function and sanitize them each as needs be. There is no other way around
this and this was a problem that was going to happen some day, we are just
having it happen today because of the changes in glibc.

[Bug bootstrap/71471] [7 Regression] Selftest failure in pretty-print.c

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71471

--- Comment #5 from David Edelsohn  ---
 ah, no, it must be the %p one
 and that is indeed arch specific I think
 c99 says:
 The value of the pointer is
 converted to a sequence of printing characters, in an
implementation-defined
 manner.

[Bug bootstrap/71471] [7 Regression] Selftest failure in pretty-print.c

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71471

--- Comment #4 from David Malcolm  ---
Reproduced on gcc111 (powerpc-ibm-aix7.1.3.0)

(gdb) bt
#0  _Z11fancy_abortPKciS0_ (file=0x12557bbc 
"../../src/gcc/selftest.c", line=44, 
function=0x12557be0  "fail") at
../../src/gcc/diagnostic.c:1281
#1  0x10d2a088 in _ZN8selftest4failEPKciS1_ (file=0x125574b8
 "../../src/gcc/pretty-print.c", 
line=1246, msg=0x125575a4  "ASSERT_STREQ
(expected, pp_formatted_text ())")
at ../../src/gcc/selftest.c:44
#2  0x10d28634 in _ZN8selftestL19assert_pp_format_vaEPKcbS1_PPc (
expected=0x125576cc  "0xcafebabe 12345678",
show_color=false, 
fmt=0x1255771c  "%p %x", ap=0x2ff21de8) at
../../src/gcc/pretty-print.c:1246
#3  0x10d28700 in _ZN8selftestL16assert_pp_formatEPKcS1_z (
expected=0x125576cc  "0xcafebabe 12345678",
fmt=0x1255771c  "%p %x")
at ../../src/gcc/pretty-print.c:1258
#4  0x10d28ab8 in _ZN8selftestL14test_pp_formatEv () at
../../src/gcc/pretty-print.c:1321
#5  0x10d28c60 in _ZN8selftest20pretty_print_c_testsEv () at
../../src/gcc/pretty-print.c:1362
#6  0x1231c5d0 in _ZN8selftest9run_testsEv () at
../../src/gcc/selftest-run-tests.c:49
#7  0x10006544 in _ZN6toplev14run_self_testsEv (this=0x2ff21fc8) at
../../src/gcc/toplev.c:2048
#8  0x100067cc in _ZN6toplev4mainEiPPc (this=0x2ff21fc8, argc=21,
argv=0x2ff22074) at ../../src/gcc/toplev.c:2125
#9  0x16ec in main (argc=21, argv=0x2ff22074) at ../../src/gcc/main.c:39

The issue is:

1320  assert_pp_format ("0xcafebabe 12345678", "%p %x", (void *)0xcafebabe,
13210x12345678);

(gdb) p expected
$1 = 0x125576cc  "0xcafebabe 12345678"
(gdb) call pp_formatted_text ()
$2 = 811804352
(gdb) p (const char *)$2
$3 = 0x306326c0 "cafebabe 12345678"

i.e. the test for "%p" expects "0x" header, which isn't present.

This is implemented as:
  #define pp_pointer(PP, P)  pp_scalar (PP, "%p", P)

which uses sprintf.

Is pp_format's printing of %p meant to be host-dependent?

[Bug middle-end/71476] ICE in gimplify_switch_expr with -Wswitch-unreachable

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71476

Marek Polacek  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-09
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Mine.

[Bug middle-end/71476] New: ICE in gimplify_switch_expr with -Wswitch-unreachable

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71476

Bug ID: 71476
   Summary: ICE in gimplify_switch_expr with -Wswitch-unreachable
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

void
foo (int a)
{
  switch (a)
{
  void f (void) { break; }
}
}

$ ./cc1 -quiet n.c  
n.c: In function ‘f’:
n.c:6:23: error: break statement not within loop or switch
   void f (void) { break; }
   ^
n.c: In function ‘foo’:
n.c:4:3: internal compiler error: Segmentation fault
   switch (a)
   ^~
0xe453e0 crash_signal
/home/marek/src/gcc/gcc/toplev.c:335
0xb04d2d gimple_code
/home/marek/src/gcc/gcc/gimple.h:1674
0xb0a041 gimplify_switch_expr
/home/marek/src/gcc/gcc/gimplify.c:1609
0xb30019 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marek/src/gcc/gcc/gimplify.c:10556
0xb19669 gimplify_stmt(tree_node**, gimple**)
/home/marek/src/gcc/gcc/gimplify.c:5731
0xb086d1 gimplify_bind_expr
/home/marek/src/gcc/gcc/gimplify.c:1154
0xb2ffd7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marek/src/gcc/gcc/gimplify.c:10548
0xb19669 gimplify_stmt(tree_node**, gimple**)
/home/marek/src/gcc/gcc/gimplify.c:5731
0xb335fc gimplify_body(tree_node*, bool)
/home/marek/src/gcc/gcc/gimplify.c:11532
0xb33e98 gimplify_function_tree(tree_node*)
/home/marek/src/gcc/gcc/gimplify.c:11688
0x939f0b cgraph_node::analyze()
/home/marek/src/gcc/gcc/cgraphunit.c:625
0x93b792 analyze_functions
/home/marek/src/gcc/gcc/cgraphunit.c:1086
0x93fdb8 symbol_table::finalize_compilation_unit()
/home/marek/src/gcc/gcc/cgraphunit.c:2543
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/71357] [7 Regression] [graphite] ICE: verify_ssa failed (error: definition in block follows the use for SSA_NAME) w/ -O2 -floop-nest-optimize

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71357

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-09
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug fortran/71203] ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71203

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-09
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Confirmed.

[Bug target/58416] Incorrect x87-based union copying code

[ch3root at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416

Alexander Cherepanov  changed:

   What|Removed |Added

 CC||ch3root at openwall dot com

--- Comment #5 from Alexander Cherepanov  ---
Not sure if it's still the same bug but the pattern from this PR leads to
problems with long double on x86-64. The optimization looses data in bytes
corresponding to padding in long double.

Transformation from a string to a long double is wrong too, filed separately --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71475. But here this example is
only to illustrate that the padding is lost.

Source code:

--
#include 

struct s {
  char s[sizeof(long double)];
};

union u {
  long double d;
  struct s s;
};

int main()
{
  union u x = {0};
  x.s = (struct s){""};

  union u y = x;

  // start from the big end
  for (unsigned char *p = (unsigned char *) + sizeof y; p-- > (unsigned char
*))
printf("%02x ", *p);
  puts("");
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 

$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
00 00 00 00 00 40 00 00 78 78 78 78 78 78 78 78 
--

gcc version: gcc (GCC) 7.0.0 20160608 (experimental)

[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009

--- Comment #3 from Eric Gallager  ---
Still happens with:

$ /usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/7.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C
--with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --without-isl --enable-objc-gc --enable-host-shared
CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++
Thread model: posix
gcc version 7.0.0 20160526 (experimental) (GCC) 


This time I attached gdb and got a backtrace:

(gdb) bt
#0  0x00ed6004 in internal_error ()
#1  0x00ed5040 in fancy_abort ()
#2  0x00719077 in gen_reg_rtx ()
#3  0x0048fc28 in gen_split_343 ()
#4  0x00569b62 in split_8 ()
#5  0x00720956 in try_split ()
#6  0x00a6a7be in split_insn ()
#7  0x00a6ec9a in split_all_insns ()
#8  0x00a6ecfb in (anonymous namespace)::pass_split_after_reload::execute ()
#9  0x00a3c567 in execute_one_pass ()
#10 0x00a3cb59 in execute_pass_list_1 ()
#11 0x00a3cb6c in execute_pass_list_1 ()
#12 0x00a3cb6c in execute_pass_list_1 ()
#13 0x00a3cbba in execute_pass_list ()
#14 0x0063b7d9 in cgraph_node::expand ()
#15 0x0063d244 in symbol_table::compile ()
#16 0x0063f74d in symbol_table::finalize_compilation_unit ()
#17 0x00b19b51 in compile_file ()
#18 0x0177f168 in toplev::main ()
#19 0x01780a24 in main ()

I'll have to rebuild gcc for debugging to get further info.

[Bug c/71475] New: Optimization of copying into long double looses bytes

[ch3root at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71475

Bug ID: 71475
   Summary: Optimization of copying into long double looses bytes
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

It seems that copying of bytes into a long double with memcpy or in some other
way is sometimes optimized by converting these bytes into long double at
compile-time and the process looses two higher bytes -- see the output "after
memcpy" with -O3 (bytes are printed starting from the big end).

Source code:

--
#include 
#include 

int main()
{
  long double d0, d;

  memset(, 'A', sizeof d0);
  d = d0;

  printf("after memset: %Lf\n", d);
  for (unsigned char *p = (unsigned char *) + sizeof d; p-- > (unsigned char
*))
printf("%02x ", *p);
  printf("\n");
  printf("\n");

  memcpy(, "", sizeof d0);
  d = d0;

  printf("after memcpy: %Lf\n", d);
  for (unsigned char *p = (unsigned char *) + sizeof d; p-- > (unsigned char
*))
printf("%02x ", *p);
  printf("\n");
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
after memset:
4355738269328914677589017258057892854796664468317418542308867623691847702374177028736570422722560.00
00 00 00 00 00 00 41 41 41 41 41 41 41 41 41 41 

after memcpy:
4355738269328914677589017258057892854796664468317418542308867623691847702374177028736570422722560.00
00 00 00 00 00 00 41 41 41 41 41 41 41 41 41 41 

$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
after memset:
4355738269328914677589017258057892854796664468317418542308867623691847702374177028736570422722560.00
00 00 00 00 00 40 41 41 41 41 41 41 41 41 41 41 

after memcpy: 0.00
00 00 00 00 00 40 00 00 41 41 41 41 41 41 41 41 
--

gcc version: gcc (GCC) 7.0.0 20160608 (experimental)

[Bug middle-end/71474] PRED_LOOP_IV_COMPARE wrongly calculates number of iterations of a loop

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71474

--- Comment #1 from Martin Liška  ---
Created attachment 38670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38670=edit
Candidate patch

Following patch uses loop upper_bound to make the # of iterations properly
estimated.

[Bug c/71473] cilkplus sum reducer ICE

[tprince at computer dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473

--- Comment #2 from tprince at computer dot org ---
Created attachment 38669
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38669=edit
C include file

[Bug middle-end/71474] New: PRED_LOOP_IV_COMPARE wrongly calculates number of iterations of a loop

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71474

Bug ID: 71474
   Summary: PRED_LOOP_IV_COMPARE wrongly calculates number of
iterations of a loop
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello.

During investigation of poor predictor 'loop iv compare' heuristics, I've come
to a problematic test-case:

subroutine rubber(arg1, arg2)

integer k,l
real*8 arg1(3,3,3), arg2(3,3,3)

  do l=1,3
 do k=1,l
arg1(k,l,1) = arg2(k,l,1)
 enddo
  enddo

end

042t.profile_estimate gimple looks as follows:

  :
  # l_13 = PHI <1(2), l_28(8)>
  if (l_13 > 0)
goto ;
  else
goto ;

  :
  # k_6 = PHI <1(3)>

  :
  # k_12 = PHI 
  _1 = (integer(kind=8)) l_13;
  _2 = _1 * 3;
  _3 = (integer(kind=8)) k_12;
  _4 = _2 + _3;
  _5 = _4 + -4;
  _11 = *arg2_22(D)[_5];
  *arg1_23(D)[_5] = _11;
  k_26 = k_12 + 1;
  if (k_12 == l_13)
goto ;
  else
goto ;

  :
  goto ;

  :
  l_28 = l_13 + 1;
  if (l_13 == 3)
goto ;
  else
goto ;

  :
  goto ;

  :
  return;

Problem is that is_comparison_with_loop_invariant_p is called for the gimple
compare in BB 3 (if (l_13 > 0)),
which does not determine a number of iterations of the loop. As a result we get
confusing loop_bound_step, loop_iv_base
that are eventually used by predict_iv_comparison to calculate the misleading
probability:

  loop iv compare heuristics of edge 3->4: 0.0%

While the proper value should be 100% as l_13 is always a positive number.

[Bug c/71473] cilkplus sum reducer ICE

[tprince at computer dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473

--- Comment #1 from tprince at computer dot org ---
Created attachment 38668
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38668=edit
cilkplus C source (before preprocessing)

[Bug c/71473] New: cilkplus sum reducer ICE

[tprince at computer dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473

Bug ID: 71473
   Summary: cilkplus sum reducer ICE
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tprince at computer dot org
  Target Milestone: ---

Created attachment 38667
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38667=edit
cilkplus C source

gcc 5.3 does not ICE on this case but run-time result is wrong.
gcc -fcilkplus -std=c99 -c  s176.i

[Bug c/65446] Improve -Wformat-signedness

[rnsanchez at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65446

Ricardo Nabinger Sanchez  changed:

   What|Removed |Added

 CC||rnsanchez at gmail dot com

--- Comment #5 from Ricardo Nabinger Sanchez  ---
Created attachment 38666
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38666=edit
Simple test case

I understand the reasoning behind the implicit promotions.

Here is my rationale, asking for the warning to be emitted nonetheless: suppose
the first test in the test case I supplied is used in code that emits assembly
for an assembler.  If the programmer mistakenly used %hu for a int16 type, and
that happened to generate a jump address, the implicit promotion would silently
hide an important error (possibly jumping to the opposite direction).  The
printed-out value is clearly incorrect.  It's not a compiler fault, but it just
so happens that the compiler is in the best position to warn the user that s/he
might run into problems.  Let the programmer decide whether this should be
looked into (fixing his/her code) or if s/he will ignore.

In my case, I noticed this issue (silent signedess-mismatch) because I was
getting negative ports (IPv4/IPv6) on someone else's code, which was only a
visual nuisance.  It would have been caught with the warning, but there was no
way I could get one.  Clang failed to generate such a warning as well (and in
fact produces the same output).

The same happens with %hhd/%hhu specifiers when given mismatching
uint8_t/int8_t.

In short: please warn.  Some cases will generate unexpected results (which are
not compilation errors), simply because the programmer used an incorrect format
specifier.

[Bug bootstrap/71471] [7 Regression] Selftest failure in pretty-print.c

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71471

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #3 from David Malcolm  ---
The failure was reported on IRC as being on AIX ppc; unknown for other ppc
configurations.

I successfully build and ran the selftests for stage1 on
  build=host=target=powerpc64-unknown-linux-gnu (on ggc110, which is
big-endian)
I'm trying a bootstrap on that machine.

I'll try on an AIX box.

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[adhemerval.zanella at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445

--- Comment #12 from Adhemerval Zanella  
---
After checking the work required for enable symbol versioning wrapper on
libsanitizer I am more inclined to go with always ignore the high bits (at
least for backports). The versioning enablement will require some changes and I
foresee it will generate some discussion in sanitizer side before a settle
solution is used. Any suggestions?

[Bug bootstrap/71471] [7 Regression] Selftest failure in pretty-print.c

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71471

--- Comment #2 from David Malcolm  ---
Which target?  (and host?)

FWIW before I committed it I successfully tested building gcc stage1 with the
patch using contrib/config-list.mk, with build=host=x86_64-pc-linux-gnu with
target= everything other than rs6000-ibm-aix{4.3|5.1.0} (omitting these due to
PR target/71375).

[Bug c++/71472] New: Wlogical-op misses exhaustive-or case (... || A) || B

[terra at gnome dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71472

Bug ID: 71472
   Summary: Wlogical-op misses exhaustive-or case (... || A) || B
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

g++ 6.1 fails to complain about "bar" below.  The other two get the
expected "logical 'or' of collectively exhaustive tests is always true"
warning.


enum Enum { ENUM_A, ENUM_B, ENUM_C };

int
foo (enum Enum e)
{
  // This produces a warning
  return e != ENUM_A || e != ENUM_B;
}

int
bar (int i, enum Enum e)
{
  // This does not produce a warning
  return i != 42 || e != ENUM_A || e != ENUM_B;
}

int
baz (int i, enum Enum e)
{
  // This produces a warning
  return e != ENUM_A || e != ENUM_B || i != 42;
}

[Bug bootstrap/71471] [7 Regression] Selftest failure in pretty-print.c

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71471

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug bootstrap/71471] [7 Regression] Selftest failure in pretty-print.c

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71471

David Edelsohn  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-09
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |blocker

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug bootstrap/71471] New: [7 Regression] Selftest failure in pretty-print.c

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71471

Bug ID: 71471
   Summary: [7 Regression] Selftest failure in pretty-print.c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

/tmp/20160608/./gcc/xgcc -B/tmp/20160608/./gcc/ -xc -S -c /dev/null -fself-test
/nasfarm/edelsohn/src/src/gcc/pretty-print.c:1246: FAIL: ASSERT_STREQ
(expected,
 pp_formatted_text ())
cc1: internal compiler error: in fail, at selftest.c:44

[Bug c++/70202] ICE on invalid code on x86_64-linux-gnu in build_simple_base_path, at cp/class.c:579

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70202

Paolo Carlini  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from Paolo Carlini  ---
Patch reverted unfortunately.

[Bug c++/71465] [7 Regression] ICE on invalid C++ code (with duplicate base) on x86_64-linux-gnu: in dfs_build_secondary_vptr_vtt_inits, at cp/class.c:9075

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71465

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Paolo Carlini  ---
Done.

[Bug c++/71465] [7 Regression] ICE on invalid C++ code (with duplicate base) on x86_64-linux-gnu: in dfs_build_secondary_vptr_vtt_inits, at cp/class.c:9075

[paolo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71465

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Jun  9 12:02:17 2016
New Revision: 237258

URL: https://gcc.gnu.org/viewcvs?rev=237258=gcc=rev
Log:
/cp
2016-06-09  Paolo Carlini  

PR c++/71465
Revert:
2016-06-04  Paolo Carlini  

PR c++/70202
* parser.c (cp_parser_class_head): When xref_basetypes fails and
emits an error do not zero the type.

/testsuite
2016-06-09  Paolo Carlini  

PR c++/71465
* g++.dg/inherit/crash5.C: New.
Revert:
2016-06-04  Paolo Carlini  

PR c++/70202
* g++.dg/inherit/crash5.C: New.
* g++.dg/inherit/virtual1.C: Adjust.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/inherit/crash5.C
trunk/gcc/testsuite/g++.dg/inherit/virtual1.C

[Bug c++/70202] ICE on invalid code on x86_64-linux-gnu in build_simple_base_path, at cp/class.c:579

[paolo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70202

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Jun  9 12:02:17 2016
New Revision: 237258

URL: https://gcc.gnu.org/viewcvs?rev=237258=gcc=rev
Log:
/cp
2016-06-09  Paolo Carlini  

PR c++/71465
Revert:
2016-06-04  Paolo Carlini  

PR c++/70202
* parser.c (cp_parser_class_head): When xref_basetypes fails and
emits an error do not zero the type.

/testsuite
2016-06-09  Paolo Carlini  

PR c++/71465
* g++.dg/inherit/crash5.C: New.
Revert:
2016-06-04  Paolo Carlini  

PR c++/70202
* g++.dg/inherit/crash5.C: New.
* g++.dg/inherit/virtual1.C: Adjust.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/inherit/crash5.C
trunk/gcc/testsuite/g++.dg/inherit/virtual1.C

[Bug tree-optimization/71462] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu with “seg fault”

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71462

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug tree-optimization/68961] [6 regression] Test case gcc.target/powerpc/pr60203.c fails since r231674

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68961

--- Comment #11 from Richard Biener  ---
Note that the fix depends on "bogus" cost for the vector construction on
x86_64.
Currently it is two stmts (nunits / 2 + 1) but the vector can be constructed
by a single unpcklpd stmt.  The correct cost is nunits - 1.

Similar to the PPC case the main issue is that the fact that incoming registers
have an exact overlap with the return value registers is hidden from the GIMPLE
IL:

pack (double a, double aa)
{
  struct x D.1756;

  :
  MEM[(struct x *)] = a_2(D);
  MEM[(struct x *) + 8B] = aa_3(D);
  return D.1756;
}

Detecting the exact overlap is probably too hard but at least detecting that
we don't return in memory and thus the store is not a store and that we return
in two different regs and thus require two vector extractions should be
possible.

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460

--- Comment #9 from Uroš Bizjak  ---
(In reply to jos...@codesourcery.com from comment #8)
> It's not correct to use flag_signaling_nans for a fix.  
> flag_signaling_nans is only for cases where a bit-pattern for a signaling 
> NaN is interpreted as a floating-point value.  It's not where a struct or 
> union element has floating-point type but is never interpreted as a value 
> of that type, just the whole aggregate copied.  It's completely valid 
> without flag_signaling_nans to copy a struct that happens to have such a 
> bit pattern.

Indeed. I have removed this condition, and the patch I'm testing is:

--cut here--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b807a9a..a719d62 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -10311,9 +10311,25 @@ static bool
 ix86_member_type_forces_blk (const_tree field, machine_mode mode)
 {
   /* Union with XFmode must be in BLKmode.  */
-  return (mode == XFmode
- && (TREE_CODE (DECL_FIELD_CONTEXT (field)) == UNION_TYPE
- || TREE_CODE (DECL_FIELD_CONTEXT (field)) == QUAL_UNION_TYPE));
+  if (mode == XFmode
+  && (TREE_CODE (DECL_FIELD_CONTEXT (field)) == UNION_TYPE
+ || TREE_CODE (DECL_FIELD_CONTEXT (field)) == QUAL_UNION_TYPE))
+return true;
+
+  /* Early exit for XFmode moves, they don't trap
+ on sNaNs and don't convert sNaNs into qNaNs.  */
+  if (mode == XFmode)
+return false;
+
+  /* DFmode and SFmode moves through X87 stack trap on sNaNs if traps
+ are turned on or convert sNaNs to qNaNs if traps are turned off.
+ This violates C11, 6.2.6.1p6, that specifically says that
+ "[t]he value of a structure or union object is never a trap
+ representation, even though the value of a member of the structure
+ or union object may be a trap representation."  */
+
+  return (IS_STACK_MODE (mode)
+ && RECORD_OR_UNION_TYPE_P (DECL_FIELD_CONTEXT (field)));
 }

 rtx
--cut here--

> Does the patch (without flag_signaling_nans) help with the bug 58416 case 
> or not?

Using the patched compiler, I get:

$ ~/gcc-build/gcc/xgcc -B ~/gcc-build/gcc/ -O2 -m32 -mfpmath=387 pr58416.C 
$ ./a.out
magic=fff1
copy= fff1

... which looks OK to me.

[Bug tree-optimization/71462] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu with “seg fault”

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71462

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Jun  9 11:36:22 2016
New Revision: 237254

URL: https://gcc.gnu.org/viewcvs?rev=237254=gcc=rev
Log:
2016-06-09  Richard Biener  

PR tree-optimization/71462
* tree-ssa-loop-manip.c (find_uses_to_rename): Guard against
removed blocks.

* gcc.dg/torture/pr71462.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71462.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-manip.c

[Bug c++/71456] missing -Wunused-variable on a static global initialized with another

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71456

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
(In reply to Martin Sebor from comment #0)
> (Clang only diagnoses the dynamic initialization with potential side-effects
> with -Wglobal-constructors, and regardless of whether the static variable is
> used or not.)

Speaking of -Wglobal-constructors, FSF GCC doesn't support this option. Is
there a bug open for adding it? I couldn't find one when searching.

[Bug tree-optimization/71466] [7 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |7.0
Summary|wrong code at -O3 on|[7 Regression] wrong code
   |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu

[Bug target/71460] Copying structs can trap (on x86-32) due to SNaN to QNaN

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460

--- Comment #8 from joseph at codesourcery dot com  ---
It's not correct to use flag_signaling_nans for a fix.  
flag_signaling_nans is only for cases where a bit-pattern for a signaling 
NaN is interpreted as a floating-point value.  It's not where a struct or 
union element has floating-point type but is never interpreted as a value 
of that type, just the whole aggregate copied.  It's completely valid 
without flag_signaling_nans to copy a struct that happens to have such a 
bit pattern.

Does the patch (without flag_signaling_nans) help with the bug 58416 case 
or not?

[Bug tree-optimization/71466] wrong code at -O3 on x86_64-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466

--- Comment #5 from Martin Liška  ---
Started with r236831:

Author: law 
Date:   Fri May 27 16:32:38 2016 +

* tree-ssa-threadedge.c: Remove include of tree-ssa-threadbackward.h.
(thread_across_edge): Remove calls to find_jump_threads_backwards.
* passes.def: Add jump threading passes before DOM/VRP.
* tree-ssa-threadbackward.c (find_jump_threads_backwards): Change
argument to a basic block from an edge.  Remove tests which are
handled elsewhere.
(pass_data_thread_jumps, class pass_thread_jumps): New.
(pass_thread_jumps::gate, pass_thread_jumps::execute): New.
(make_pass_thread_jumps): Likewise.
* tree-pass.h (make_pass_thread_jumps): Declare.

[Bug tree-optimization/71407] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple: integral result type precision does not match field size of BIT_FIELD_REF)

[alahay01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71407

--- Comment #5 from alahay01 at gcc dot gnu.org ---
Qirun Zhang :

That's a different issue (original test fails due to data type mismatch, this
test fails because the loop boundary is unset).

Please could you raise your test as a new bug and assign it to me (I think I
have a fix for it).

[Bug c++/71465] [7 Regression] ICE on invalid C++ code (with duplicate base) on x86_64-linux-gnu: in dfs_build_secondary_vptr_vtt_inits, at cp/class.c:9075

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71465

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
Caused by my patchlet for c++/70202, I'm going to revert it (c++/70202 isn't a
regression) and close this one with a testcase.

[Bug tree-optimization/71466] wrong code at -O3 on x86_64-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-09
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
Confirmed.

[Bug tree-optimization/71466] wrong code at -O3 on x86_64-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466

--- Comment #3 from Martin Liška  ---
The problem is caused by loop unroller:

144t.ivcanon looks good:

fn1 ()
{
  _Bool c_lsm.12;
  int c_lsm.11;
  _Bool d_lsm.10;
  int d_lsm.9;
  int f;
  int e;
  int _5;
  int c.3_9;
  int _13;
  int c.3_21;

  :
  c = 0;
  goto ;

  :
  # e_4 = PHI 
  # c.3_9 = PHI 

  :
  # e_35 = PHI <0(2), e_4(3)>
  # c.3_21 = PHI <0(2), c.3_9(3)>
  e_20 = e_35 + 1;
  if (e_20 != 2)
goto ;
  else
goto ;

  :
  _5 = c.3_21 + 1;
  if (_5 <= 1)
goto ;
  else
goto ;

  :
  # _13 = PHI <_5(5)>
  d = 0;
  c = _13;
  return;

}

While 152t.cunroll contains wrongly unrolled code:

fn1 ()
{
  _Bool c_lsm.12;
  int c_lsm.11;
  _Bool d_lsm.10;
  int d_lsm.9;
  int f;
  int e;
  int _1;
  int _5;
  int c.3_9;
  int _10;
  int c.3_12;
  int _13;
  int c.3_16;

  :
  c = 0;
  e_36 = 1;
  if (e_36 != 2)
goto ;
  else
goto ;

  :
  _1 = 1;
  if (_1 <= 1)
goto ;
  else
goto ;

  :
  # e_25 = PHI 
  # c.3_16 = PHI <0(2), _1(3)>
  e_8 = e_25 + 1; /* here:   e_8 == 2 */
  if (e_8 != 2)
goto ;
  else
goto ;

  :
  _10 = c.3_16 + 1;
  if (_10 <= 1)
goto ;
  else
goto ;

  :
  # e_17 = PHI 
  # c.3_12 = PHI 
  e_20 = e_17 + 1; /* here:   e_20 == 3 */
  if (e_20 != 2)
goto ;
  else
goto ;

  :
  # e_4 = PHI 
  # c.3_9 = PHI 
  __builtin_unreachable ();

  :
  _5 = c.3_12 + 1;
  if (_5 <= 1)
goto ;
  else
goto ;

  :
  # _13 = PHI <_5(8), _1(3), _10(5)>
  d = 0;
  c = _13;
  return;
}

I've been bisecting to understand what has changed since gcc 6.

[Bug tree-optimization/71466] wrong code at -O3 on x86_64-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Can reproduce with:

$ gcc tc3.c -O2 -fsanitize=unreachable -fpeel-loops -mtune=generic
-march=x86-64

$ ./a.out 
: runtime error: execution reached a __builtin_unreachable() call

[Bug target/71338] [RL78] mulu instruction not used on G10

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71338

--- Comment #1 from Oleg Endo  ---
ping ... anybody?