[Bug preprocessor/69543] [6/7/8 Regression] _Pragma does not apply within macro

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Target Milestone|7.0 |8.0
Summary|[6/7 Regression] _Pragma|[6/7/8 Regression] _Pragma
   |does not apply within macro |does not apply within macro

[Bug tree-optimization/79534] [7 Regression] tree-ifcombine aarch64 performance regression with trunk@245151

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at redhat dot com

[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at redhat dot com

[Bug rtl-optimization/79405] [8 Regression] Compile-time hog w/ -O2 (-Os, -O3) on 32-bit BE powerpc targets

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Target Milestone|7.0 |8.0
Summary|[7 Regression] Compile-time |[8 Regression] Compile-time
   |hog w/ -O2 (-Os, -O3) on|hog w/ -O2 (-Os, -O3) on
   |32-bit BE powerpc targets   |32-bit BE powerpc targets

--- Comment #9 from Jeffrey A. Law  ---
Targeting gcc-8 to attempt Richi's suggestion to change iteration ordre to look
like:

  for (BBs in RPO order)
for (insn in BB)
repeat:
  for (use in insn)
 if (propagate_into (use))
   goto repeat;

[Bug rtl-optimization/79405] [7 Regression] Compile-time hog w/ -O2 (-Os, -O3) on 32-bit BE powerpc targets

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Fri Mar 31 22:49:53 2017
New Revision: 246627

URL: https://gcc.gnu.org/viewcvs?rev=246627=gcc=rev
Log:
PR rtl-optimization/79405
* fwprop.c (propagations_left): New variable.
(forward_propagate_into): Decrement it.
(fwprop_init): Initialize it.
(fw_prop): If the variable has reached zero, stop propagating.
(fwprop_addr): Ditto.

gcc/testsuite/
PR rtl-optimization/79405
gcc.dg/pr79405.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr79405.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fwprop.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/61428] wrong "maybe-uninitialized" (jump threading? predicate analysis?)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
This is a case where DOM, VRP and backwards jump threading all fail to simplify
the CFG enough, leaving it in a state where the uninit pass is unable to prove
the all the paths to free lock_1 are properly guarded.

It is the case that VRP1, DOM2, DOM3, VRP2 all successively simplify the CFG,
each time they expose an opportunity to thread jumps deeper int the CFG.  But
in the end, we can only thread through a single join point in the CFG each
iteration due to limitations in the copier used by VRP/DOM.

The pass best suited for tackling this would be the backwards jump threader. 
But it doesn't yet know how to extract a constant equivalence from a
conditional.  So it never has the chance to see the deep jump threads because
there  are no assignments to need_lock_1.  If we were able to derive those
equivalences, I suspect the backward threader would likely clean up the CFG
significantly.

ANyway, we're left with a fairly complex CFG with merge points in very
inconvenient places -- making it impossible for tree-ssa-uninit to prove the
uses of lock_1 are properly guarded.

[Bug middle-end/59500] Bogus maybe-uninitialized (|| converted to nested-if)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #7 from Jeffrey A. Law  ---
Per c#6.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[law at redhat dot com]

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

Bug 59500 Summary: Bogus maybe-uninitialized (|| converted to nested-if)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500

   What|Removed |Added

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

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[law at redhat dot com]

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

Bug 56748 Summary: Bogus uninitialized warning with nested if condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56748

   What|Removed |Added

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

[Bug middle-end/56748] Bogus uninitialized warning with nested if condition

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
Not sure when this was fixed, but it works fine on the trunk.  VRP1/DOM2 are
able to thread the conditional branches (which removes unexecutable paths) with
the net result is all the uninitialized uses of b.0 are ultimately removed.

[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #10 from Bill Schmidt  ---
For C++, "type_6" indicates that TYPE_DEPENDENT_P_VALID is nonzero for the
type.  This apparently gets set for the basic SI type during C++
language-dependent initialization, but only after the first two V4SI types are
created.  Here's the backtrace when this occurs:

Breakpoint 8, dependent_type_p (type=0x3fffb5b10738)
at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23486
23486 TYPE_DEPENDENT_P_VALID (type) = 1;
(gdb) ptr type
  constant 32>
unit size  constant 4>
align 32 symtab 0 alias set -1 canonical type 0x3fffb5b10738 precision 32
min  max 
pointer_to_this >
(gdb) bt
#0  dependent_type_p (type=0x3fffb5b10738)
at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23486
#1  0x104c7220 in dependent_type_p_r (type=0x3fffb5d33fa8)
at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23366
#2  0x104c7c10 in dependent_type_p (type=0x3fffb5d33fa8)
at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23485
#3  0x104c71c0 in dependent_type_p_r (type=0x3fffb5d34050)
at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23360
#4  0x104c7c10 in dependent_type_p (type=0x3fffb5d34050)
at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23485
#5  0x1046fa5c in uses_template_parms (t=0x3fffb5d34050)
at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:9351
#6  0x106d0b3c in build_cplus_array_type (elt_type=0x3fffb5d34050, 
index_type=0x0) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/tree.c:899
#7  0x103db958 in cxx_init_decl_processing ()
at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/decl.c:4154
#8  0x1057c22c in cxx_init ()
at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/lex.c:250
#9  0x1119a5a8 in lang_dependent_init (
name=0x3bb8 "pr79905.cpp")
at /home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:1763
#10 0x1119ae7c in do_compile ()
at /home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:1986
#11 0x1119b448 in toplev::main (this=0x3316, argc=24, 
argv=0x3738)
at /home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:2134
#12 0x11f2f160 in main (argc=24, argv=0x3738)
at /home/wschmidt/gcc/gcc-mainline-test2/gcc/main.c:39
(gdb) 

I think we will need a C++ expert to advise what to do about this.  I'm now
officially out of my league.  CCing Jason for advice on who we should ask.

[Bug target/80108] ICE in aggregate_value_p at function.c:2028

[kelvin at gcc dot gnu.org]

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

--- Comment #10 from kelvin at gcc dot gnu.org ---
FWIW, I tried another variant on the patch, which is shown below.  This variant
handles all of the p9-specific target options the same, as seen below:

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 246573)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -4273,8 +4273,32 @@ rs6000_option_override_internal (bool global_init_
   /* For the newer switches (vsx, dfp, etc.) set some of the older options,
  unless the user explicitly used the -mno- to disable the code. 
*/
   if (TARGET_P9_VECTOR || TARGET_MODULO || TARGET_P9_DFORM_SCALAR
-  || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0 ||
TARGET_P9_MINMAX)
-rs6000_isa_flags |= (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit);
+  || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0
+  || TARGET_P9_MINMAX)
+{
+  if (have_cpu)
+   {
+ if (cpu_index == PROCESSOR_POWER9)
+   /* legacy behavior: allow -mcpu-power9 with certain capabilities
+  (eg -mno-vsx) explicitly disabled.  */
+   rs6000_isa_flags |=
+ (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit);
+ else
+   error ("Power9 target option is incompatible with -mcpu= for "
+  " less than power9");
+   }
+#ifdef KELVIN_REMOVE
+  else if ((ISA_3_0_MASKS_SERVER & rs6000_isa_flags_explicit)
+  != (ISA_3_0_MASKS_SERVER & rs6000_isa_flags
+  & rs6000_isa_flags_explicit))
+   /* Enforce that none of the ISA_3_0_MASKS_SERVER flags
+  were explicitly cleared.  */
+   error ("-mpower9-minmax incompatible with explicitly disabled
options");
+#endif
+  else
+   rs6000_isa_flags |= 
+ (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit);
+}
   else if (TARGET_P8_VECTOR || TARGET_DIRECT_MOVE || TARGET_CRYPTO)
 rs6000_isa_flags |= (ISA_2_7_MASKS_SERVER & ~rs6000_isa_flags_explicit);
   else if (TARGET_VSX)

This variant also results in numerous regressions: 942 new fewer "expected
passes", 4 more "unexpected failures", 339 more "unsupported tests".

[Bug c/80274] There is an unoptimized direct memory write of 16bit value on x86_64 with O2 and O3.

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from H.J. Lu  ---
It is done on purpose to avoid Length Changing Prefix Stall:

[hjl@gnu-6 tmp]$ cat s.c
void foo() {
 *(unsigned short *)0x=1;
}
[hjl@gnu-6 tmp]$ gcc -S -O2 s.c -mtune-ctrl="^lcp_stall" 
[hjl@gnu-6 tmp]$ cat s.s
.file   "s.c"
.text
.p2align 4,,15
.globl  fo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movw$1, 65535
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 6.3.1 20170216 (Red Hat 6.3.1-3)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 tmp]$

[Bug c++/77339] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: in cp_parser_type_name, at cp/parser.c:16532

[reichelt at gcc dot gnu.org]

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

--- Comment #6 from Volker Reichelt  ---
*** Bug 58987 has been marked as a duplicate of this bug. ***

[Bug c++/58987] [5/6/7 Regression] ICE with template alias

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.0.1
 Resolution|--- |DUPLICATE

--- Comment #2 from Volker Reichelt  ---
Fixed with the patch for PR77339, so marking as duplicate.

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

[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
I believe the problem has to do with the basic integer type for SI mode
changing hash values after it is first created.  I stopped in make_vector_type
for all vectors created with 4 elements, and found three of them with a base
type having SI mode.

The first two had the same base integer type, reported as "int public SI". 
Both were canonicalized to the first one that was created, all good.

The third had the same base integer type, but that type had changed slightly in
the meanwhile.  It was now reported as "int public type_6 SI".  As a result,
this appeared to change the hash for vector types based upon it.  This third
type was created in response to the "vector int b;" decl (the AltiVec decl);
and the hash of this type was now unique, so it was canonicalized to itself.

Interestingly, the V4i type was created without ever going through the
make_vector_type interface.  I haven't tracked down where it came from, but I
believe that to be irrelevant.  When we ICE, the V4i type exists, is based on
the same "int public type_6 SI" type, and canonicalizes to the AltiVec type.

So the problem is not that the AltiVec and V4i types are incompatible.  We ICE
when observing that the very first type created is not canonicalized to the
same type as the V4i type is.  My theory is that the change involving "type_6"
is responsible for this.

[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 (could not split insn) on mips* when compiling libstdc++ with -mlong-calls -mno-abicalls

[mpf at gcc dot gnu.org]

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

mpf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-31
 CC||mpf at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.0.1

--- Comment #5 from mpf at gcc dot gnu.org ---
This is a bug coming from LRA rematerialisation. The issue is that one or more
LEA64 instructions get rematerialized at a point where there are no other
spills to resolve. Each LEA64 instruction introduces a new scratch which is a
copy of the original scratch but is unallocated. lra_need_for_spills_p says
false in this circumstance but is 'wrong'. One option is to simply go round the
LRA loop one more time (and ensure that the lra_spill code does not assert
because of there being no spills to deal with; it effectively becomes a NOP).
There are plenty of alternative solutions which would involve determining
whether remat introduced any new scratches and only running the loop again in
that situation. We could also optimise to avoid running the lra_spill code as
we really need to get to the top of the loop to re-run assignment I believe.

It almost seems cleaner to continue round the LRA loop after remat and rely on
the single exit point but I assume it was an optimisation to exit immediately
after remat if it resolves all remaining spills.

Vladimir: Is my description detailed enough for you to understand the issue or
should I add dumps as well for a testcase? Is there anything 'safe enough' to
do at this point of release? I'm testing my quick fix as below in case it is a
suitable solution.

diff --git a/gcc/lra-spills.c b/gcc/lra-spills.c
index 492fc18..863136d 100644
--- a/gcc/lra-spills.c
+++ b/gcc/lra-spills.c
@@ -565,7 +565,6 @@ lra_spill (void)
/* We do not want to assign memory for former scratches.  */
&& ! lra_former_scratch_p (i))
   pseudo_regnos[n++] = i;
-  lra_assert (n > 0);
   pseudo_slots = XNEWVEC (struct pseudo_slot, regs_num);
   for (i = FIRST_PSEUDO_REGISTER; i < regs_num; i++)
 {
diff --git a/gcc/lra.c b/gcc/lra.c
index ed1f062..c906d94 100644
--- a/gcc/lra.c
+++ b/gcc/lra.c
@@ -2490,8 +2490,6 @@ lra (FILE *f)
  /* We need full live info -- see the comment above.  */
  lra_create_live_ranges (lra_reg_spill_p, true);
  live_p = true;
- if (! lra_need_for_spills_p ())
-   break;
}
   lra_spill ();
   /* Assignment of stack slots changes elimination offsets for

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jason at gcc dot gnu.org]

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

--- Comment #85 from Jason Merrill  ---
(In reply to Bernd Edlinger from comment #84)
> all valid examples used a union with an array of unsigned char.  Right?

There doesn't need to be a union, just an array of unsigned char.

[Bug middle-end/63224] false positive for -Wmaybe-uninitialized at -Os (not -O2) with && transformed to

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #11 from Jeffrey A. Law  ---
Because of the -Os & size of duplicated block heuristic issue, this is
ultimately a duplicate of 36550.  Fix jump threading to recognize when the
duplicate block will ultimately be eliminated as dead code and both bugs get
fixed.

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

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[law at redhat dot com]

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

Bug 63224 Summary: false positive for -Wmaybe-uninitialized at -Os (not -O2) 
with && transformed to &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||joel at gcc dot gnu.org

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

[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #15 from Jeffrey A. Law  ---
Note that Os throttles jump threading as jump threading often increases
codesize.  

That's why you get this warning at -Os, but not at -O2.Jump threading does
not have a good way to estimate how much of the duplicated block will be
eliminated as dead code.

In this testcase, the contents of the duplicated block would be entirely
eliminated as dead code making threading jumps 100% free from a codesize
standpoint.

That's where I think the focus is better spent (rather than adding additional
cases to tree-ssa-uninit.c).  Improve the jump threading heuristics -- the net
result will be better code *and* the warning goes away as a side effect.

[Bug target/80086] ICE: in extract_constrain_insn, at recog.c:2213 for the gcc.dg/vect/slp-perm-6.c test on MIPS

[mpf at gcc dot gnu.org]

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

mpf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from mpf at gcc dot gnu.org ---
Same issue as reported against GCC 5 and 6.

[Bug middle-end/70736] false positive uninitialized warning

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
Fixed a year or so (gcc-6 era).  No plans to backport.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[law at redhat dot com]

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

Bug 70736 Summary: false positive uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70736

   What|Removed |Added

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

[Bug middle-end/63224] false positive for -Wmaybe-uninitialized at -Os (not -O2) with && transformed to

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #10 from Jeffrey A. Law  ---
Note that Os throttles jump threading as jump threading often increases
codesize.  

That's why you get this warning at -Os, but not at -O2.Jump threading does
not have a good way to estimate how much of the duplicated block will be
eliminated as dead code.

In the reduced testcase, the contents of the duplicated block would be entirely
eliminated as dead code making threading jumps 100% free from a codesize
standpoint.

That's where I think the focus is better spent (rather than adding additional
cases to tree-ssa-uninit.c).  Improve the jump threading heuristics -- the net
result will be better code *and* the warning goes away as a side effect.

[Bug target/80057] typo in mips.opt: Virtualization Application Specific

[mpf at gcc dot gnu.org]

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

mpf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mpf at gcc dot gnu.org

--- Comment #3 from mpf at gcc dot gnu.org ---
I agree there is an inconsistency here (or several actually but not all can be
fixed).

We refer to the Virtualization Application-Specific Extension with shortened
forms of Virtualization ASE or VZ ASE.

Unfortunately the option name -mvirt is not -mvz but I can't fix that. We can
fix the description though so it matches terms used elsewhere:

Use Virtualization (VZ) instructions.

I'll push a patch for it.

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[segher at gcc dot gnu.org]

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

--- Comment #23 from Segher Boessenkool  ---
I have a patch for the problem in comments 17 and 19 (which is different from
the problems in earlier comments, only some of which i can reproduce).

[Bug middle-end/61112] Simple example triggers false-positive -Wmaybe-uninitialized warning

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #4 from Jeffrey A. Law  ---
Fixed long ago.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[law at redhat dot com]

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

Bug 61112 Summary: Simple example triggers false-positive -Wmaybe-uninitialized 
warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61112

   What|Removed |Added

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

[Bug middle-end/59500] Bogus maybe-uninitialized (|| converted to nested-if)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #6 from Jeffrey A. Law  ---
This was fixed a few years ago by:

Author: amker 
Date:   Wed Feb 26 01:49:35 2014 +

PR target/60280
* tree-cfgcleanup.c (tree_forwarder_block_p): Protect loop
preheaders and latches only if requested.  Fix latch if it
is removed.
* tree-ssa-dom.c (tree_ssa_dominator_optimize): Set
LOOPS_HAVE_PREHEADERS.

PR target/60280
* gnat.dg/renaming5.adb: Change to two expected gotos.
* gcc.dg/tree-ssa/pr21559.c: Change back to three expected
jump threads.
* gcc.dg/tree-prof/update-loopch.c: Check two "Invalid sum"
messages for removed basic block.
* gcc.dg/tree-ssa/ivopt_1.c: Fix unreliable scanning string.
* gcc.dg/tree-ssa/ivopt_2.c: Ditto.
* gcc.dg/tree-ssa/ivopt_3.c: Ditto.
* gcc.dg/tree-ssa/ivopt_4.c: Ditto.

[Bug sanitizer/79572] [6 Regression] reference binding to null pointer not reported with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org
Summary|[6/7 Regression] reference  |[6 Regression] reference
   |binding to null pointer not |binding to null pointer not
   |reported with   |reported with
   |-fsanitize=undefined|-fsanitize=undefined

--- Comment #14 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug bootstrap/79255] [6 Regression] PGO bootstrap fails on x86_64/ppc64le building Ada

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[6/7 Regression] PGO|[6 Regression] PGO
   |bootstrap fails on  |bootstrap fails on
   |x86_64/ppc64le building Ada |x86_64/ppc64le building Ada

--- Comment #10 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug bootstrap/79255] [6/7 Regression] PGO bootstrap fails on x86_64/ppc64le building Ada

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 31 18:40:35 2017
New Revision: 246622

URL: https://gcc.gnu.org/viewcvs?rev=246622=gcc=rev
Log:
PR debug/79255
* dwarf2out.c (decls_for_scope): If BLOCK_NONLOCALIZED_VAR is
a FUNCTION_DECL, pass it as decl instead of origin to
process_scope_var.

* gcc.dg/pr79255.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr79255.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 31 18:39:25 2017
New Revision: 246621

URL: https://gcc.gnu.org/viewcvs?rev=246621=gcc=rev
Log:
PR c++/79572
* c-ubsan.h (ubsan_maybe_instrument_reference): Change argument to
tree *.
* c-ubsan.c (ubsan_maybe_instrument_reference): Likewise.  Handle
not just NOP_EXPR to REFERENCE_TYPE, but also INTEGER_CST with
REFERENCE_TYPE.

* cp-gimplify.c (cp_genericize_r): Sanitize INTEGER_CSTs with
REFERENCE_TYPE.  Adjust ubsan_maybe_instrument_reference caller
for NOP_EXPR to REFERENCE_TYPE.

* g++.dg/ubsan/null-8.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ubsan/null-8.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-ubsan.c
trunk/gcc/c-family/c-ubsan.h
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug target/80108] ICE in aggregate_value_p at function.c:2028

[kelvin at gcc dot gnu.org]

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

--- Comment #9 from kelvin at gcc dot gnu.org ---
I've got a patch now that resolves this problem without creating regressions. 
I'm attaching it for "discussion" here before I post for "official review".

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 246573)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -4273,8 +4273,30 @@ rs6000_option_override_internal (bool global_init_
   /* For the newer switches (vsx, dfp, etc.) set some of the older options,
  unless the user explicitly used the -mno- to disable the code. 
*/
   if (TARGET_P9_VECTOR || TARGET_MODULO || TARGET_P9_DFORM_SCALAR
-  || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0 ||
TARGET_P9_MINMAX)
+  || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0)
 rs6000_isa_flags |= (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit);
+  else if (TARGET_P9_MINMAX)
+{
+  if (have_cpu)
+   {
+ if (cpu_index == PROCESSOR_POWER9)
+   /* legacy behavior: allow -mcpu-power9 with certain capabilities
+  (eg -mno-vsx) explicitly disabled.  */
+   rs6000_isa_flags |=
+ (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit);
+ else
+   error ("Power9 target option is incompatible with -mcpu= for "
+  " less than power9");
+   }
+  else if ((ISA_3_0_MASKS_SERVER & rs6000_isa_flags_explicit)
+  != (ISA_3_0_MASKS_SERVER & rs6000_isa_flags
+  & rs6000_isa_flags_explicit))
+   /* Enforce that none of the ISA_3_0_MASKS_SERVER flags
+  were explicitly cleared.  */
+   error ("-mpower9-minmax incompatible with explicitly disabled
options");
+  else
+   rs6000_isa_flags |= ISA_3_0_MASKS_SERVER;
+}
   else if (TARGET_P8_VECTOR || TARGET_DIRECT_MOVE || TARGET_CRYPTO)
 rs6000_isa_flags |= (ISA_2_7_MASKS_SERVER & ~rs6000_isa_flags_explicit);
   else if (TARGET_VSX)

I'm seeking feedback on whether this is the treatment you are all comfortable
with.

Note that the way I handle TARGET_P9_MINMAX is very different than the way we
handle other p9-specific target options (see the first line replaced by this
patch).  An earlier draft of my patch handled all six of these options the same
way that my patch handles TARGET_P9_MINMAX, but that resulted in 942 fewer
"expected passes", 4 more "unexpected failures", and 309 more "unsupported
tests" in the gcc summary.  It is these inconsistencies that make me a little
uncomfortable with how this solution is structured.

I welcome feedback and suggestions for further refinement.

[Bug middle-end/56574] False "may be uninitialized variable" warning (&& converted to &)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Blocks||19794
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

--- Comment #11 from Jeffrey A. Law  ---
Ultimately this is a missed jump thread.  In vrp1 after insertion of
ASSERT_EXPRs we have:

;;   basic block 2, loop depth 0, count 0, freq 1005, maybe hot
;;prev block 0, next block 11, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
  if (flag_6(D) == 0)
goto ; [33.00%]
  else
goto ; [67.00%]
;;succ:   3 [33.0%]  (TRUE_VALUE,EXECUTABLE)
;;11 [67.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 11, loop depth 0, count 0, freq 673, maybe hot
;;prev block 2, next block 3, flags: (NEW)
;;pred:   2 [67.0%]  (FALSE_VALUE,EXECUTABLE)
  flag_14 = ASSERT_EXPR ;
  goto ; [100.00%]
;;succ:   4 [100.0%]  (FALLTHRU)

;;   basic block 3, loop depth 0, count 0, freq 332, maybe hot
;;prev block 11, next block 4, flags: (NEW, REACHABLE, VISITED)
;;pred:   2 [33.0%]  (TRUE_VALUE,EXECUTABLE)
  flag_13 = ASSERT_EXPR ;
  value_10 = get_value ();
;;succ:   4 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 4, loop depth 0, count 0, freq 1005, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;pred:   3 [100.0%]  (FALLTHRU,EXECUTABLE)
;;11 [100.0%]  (FALLTHRU)
  # value_12 = PHI 
;;succ:   5 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 5, loop depth 1, count 0, freq 6700, maybe hot
;;prev block 4, next block 8, flags: (NEW, REACHABLE, VISITED)
;;pred:   4 [100.0%]  (FALLTHRU,EXECUTABLE)
;;9 [100.0%]  (FALLTHRU,DFS_BACK,EXECUTABLE)
;;succ:   8 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 8, loop depth 2, count 0, freq 1, maybe hot
;;prev block 5, next block 10, flags: (NEW)
;;pred:   5 [100.0%]  (FALLTHRU,EXECUTABLE)
;;10 [100.0%]  (FALLTHRU,DFS_BACK,EXECUTABLE)
  _1 = flag_6(D) == 0;
  _2 = value_12 != 0;
  _3 = _1 & _2;
  if (_3 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

The key is to realize that the path 2->11->8 will always then transfer control
to 6 (because _3 will always have the value zero).  If we were to thread that
jump, then the uninitialized use of value_7 would disappear.

I've got some code that I think would pick this up, but I haven't installed it
because it was developed after stage1 close and does not fix any known
regressions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
[Bug 19794] [meta-bug] Jump threading related bugs

[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
But hm, build_vector_type calls make_vector_type which canonicalizes using
type_hash_canon, so this seems ok.  Perhaps the problem is with the V4i type?

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[law at redhat dot com]

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

Bug 52078 Summary: Bogus may be used uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52078

   What|Removed |Added

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

[Bug tree-optimization/52078] Bogus may be used uninitialized warning

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
If we look at the VRP dump after ASSERT_EXPR insertion it's obvious what needs
to happen here:

;   basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 7, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
  if (nname_6(D) != oname_7(D))
goto ; [70.00%]
  else
goto ; [30.00%]
;;succ:   3 [70.0%]  (TRUE_VALUE,EXECUTABLE)
;;7 [30.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 7, loop depth 0, count 0, freq 3000, maybe hot
;;prev block 2, next block 3, flags: (NEW)
;;pred:   2 [30.0%]  (FALSE_VALUE,EXECUTABLE)
  nname_12 = ASSERT_EXPR ;
  oname_15 = ASSERT_EXPR ;
  goto ; [100.00%]
;;succ:   4 [100.0%]  (FALLTHRU)

;;   basic block 3, loop depth 0, count 0, freq 7000, maybe hot
;;prev block 7, next block 4, flags: (NEW, REACHABLE, VISITED)
;;pred:   2 [70.0%]  (TRUE_VALUE,EXECUTABLE)
  nname_11 = ASSERT_EXPR ;
  oname_14 = ASSERT_EXPR ;
  _10 = __builtin_strcmp (nname_11, oname_14);
  oname_16 = ASSERT_EXPR ;
  nname_13 = ASSERT_EXPR ;
;;succ:   4 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 4, loop depth 0, count 0, freq 1, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;pred:   3 [100.0%]  (FALLTHRU,EXECUTABLE)
;;7 [100.0%]  (FALLTHRU)
  # cmp_4 = PHI <_10(3), cmp_8(D)(7)>
  _1 = nname_6(D) == oname_7(D);
  _2 = cmp_4 == 0;
  _3 = _1 | _2;
  if (_3 != 0)
goto ; [46.00%]
  else
goto ; [54.00%]
;;succ:   6 [46.0%]  (TRUE_VALUE,EXECUTABLE)
;;5 [54.0%]  (FALSE_VALUE,EXECUTABLE)

If we traverse the edge 2->7, then we know that nname == oname (which is shown
in the IL via the ASSERT_EXPRs in BB7).We can use that to simplify the
computation of _3 in BB4 and ultimately thread 2->7->6 and eliminate the test
of cmp_4 on the threaded path (it becomes dead).

That eliminates the uninitialized use.

This is fixed on the trunk, most likely due to the work for pr71437 which looks
to exploit ASSERT_EXPRs more aggressively.

[Bug tree-optimization/80275] New: Poor (but valid) code generated by optimizer passing optimizer list to function

[cuzdav at gmail dot com]

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

Bug ID: 80275
   Summary: Poor (but valid) code generated by optimizer passing
optimizer list to function
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

Codegen regression from the 5.x series of g++.  After 6.1, g++ produces poor
code for f2() below, when it should be identical to f1().

Command line: g++ -O2 -v -std=c++14 minbad.cpp


// minbad.cpp
#include 

int g()  {
  return 1234;
}

int f1() {
  return std::min(std::min(1, g()), 4);
}

int f2() {
  return std::min({1, g(), 4});
}



The actual disassembly looks like this:

g():
mov eax, 1234
ret


f1():
mov eax, 1
ret


f2():
lea rsi, [rsp-24]
lea rax, [rsp-24]
mov DWORD PTR [rsp-24], 1
mov DWORD PTR [rsp-20], 1234
mov DWORD PTR [rsp-16], 4
lea rcx, [rsi+12]
lea rdx, [rax+4]
mov eax, 1
.L4:
add rdx, 4
cmp rdx, rcx
je  .L3
.L8:
cmp eax, DWORD PTR [rdx]
jle .L4
mov eax, DWORD PTR [rdx]
add rdx, 4
cmp rdx, rcx
jne .L8
.L3:
rep ret



Compiler Info (this is not a mac-specific problem.)
-
g++-6 -v -std=c++14 /tmp/minbad.cpp
Using built-in specs.
COLLECT_GCC=g++-6
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/6.3.0_1/libexec/gcc/x86_64-apple-darwin16.3.0/6.3.0/lto-wrapper
Target: x86_64-apple-darwin16.3.0
Configured with: ../configure --build=x86_64-apple-darwin16.3.0
--prefix=/usr/local/Cellar/gcc/6.3.0_1
--libdir=/usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-6
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking
--enable-checking=release --enable-lto --with-build-config=bootstrap-debug
--disable-werror --with-pkgversion='Homebrew GCC 6.3.0_1'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues --enable-plugin
--disable-nls --enable-multilib
Thread model: posix
gcc version 6.3.0 (Homebrew GCC 6.3.0_1) 
COLLECT_GCC_OPTIONS='-v' '-std=c++14' '-mmacosx-version-min=10.12.4'
'-asm_macosx_version_min=10.12' '-shared-libgcc' '-mtune=core2'

/usr/local/Cellar/gcc/6.3.0_1/libexec/gcc/x86_64-apple-darwin16.3.0/6.3.0/cc1plus
-quiet -v -D__DYNAMIC__ /tmp/minbad.cpp -fPIC -quiet -dumpbase minbad.cpp
-mmacosx-version-min=10.12.4 -mtune=core2 -auxbase minbad -std=c++14 -version
-o /var/folders/d_/97dm5hss6cq7y8jlfxh3k6xrsw2_zt/T//cc9vAOcI.s
GNU C++14 (Homebrew GCC 6.3.0_1) version 6.3.0 (x86_64-apple-darwin16.3.0)
compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5,
MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6/gcc/x86_64-apple-darwin16.3.0/6.3.0/../../../../../../x86_64-apple-darwin16.3.0/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6/gcc/x86_64-apple-darwin16.3.0/6.3.0/../../../../../../include/c++/6.3.0

/usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6/gcc/x86_64-apple-darwin16.3.0/6.3.0/../../../../../../include/c++/6.3.0/x86_64-apple-darwin16.3.0

/usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6/gcc/x86_64-apple-darwin16.3.0/6.3.0/../../../../../../include/c++/6.3.0/backward

/usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6/gcc/x86_64-apple-darwin16.3.0/6.3.0/include
 /usr/local/include
 /usr/local/Cellar/gcc/6.3.0_1/include

/usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6/gcc/x86_64-apple-darwin16.3.0/6.3.0/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
GNU C++14 (Homebrew GCC 6.3.0_1) version 6.3.0 (x86_64-apple-darwin16.3.0)
compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5,
MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 61c7027fd27bf9cda4c9b1dfc6e5d124
COLLECT_GCC_OPTIONS='-v' '-std=c++14' '-mmacosx-version-min=10.12.4' 
'-shared-libgcc' '-mtune=core2'
 as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=10.12 -o
/var/folders/d_/97dm5hss6cq7y8jlfxh3k6xrsw2_zt/T//ccipBAqo.o
/var/folders/d_/97dm5hss6cq7y8jlfxh3k6xrsw2_zt/T//cc9vAOcI.s
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.4.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
In rs6000.c: rs6000_handle_altivec_attribute(), the altivec(vector__) attribute
is used to assign V4SI_type_node as the associated type in this case. 
V4SI_type_node has a canonical type field that points to itself.  This type is
created in rs6000_init_builtins() as follows:

  V4SI_type_node = build_vector_type (intSI_type_node, 4);

My guess is that we need to call some interface that will look for an existing
type and canonicalize to that one, but I don't know how any of this
front-endish stuff works.  I'll keep looking.

[Bug c++/78850] Parameter of returned generic lambda allegedly shadows parameter of free function

[miklcct at gmail dot com]

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

Michael Tsang  changed:

   What|Removed |Added

 CC||miklcct at gmail dot com

--- Comment #1 from Michael Tsang  ---
I think the following is related to this, where the parameter of a returned
lambda is mis-interpreted as shadowing a local variable:

[michael@samsung-rv510 ~]$ cat fix.cpp
#include 

using std::cin;
using std::cout;

struct Factorial {
template unsigned long operator()(Function self, unsigned
long n) const {
return n ? n * self(self, n - 1) : 1;
}
};

template auto y(Function f) {
return [f](auto n) {
return f(f, n);
};
}

int main() {
unsigned long n;
cin >> n;
cout << y(Factorial())(n) << '\n';
return 0;
}
[michael@samsung-rv510 ~]$ g++ -Wshadow -std=c++14 fix.cpp -o fix
fix.cpp: In instantiation of 'y(Function):: [with auto:1 = long
unsigned int; Function = Factorial]':
fix.cpp:21:29:   required from here
fix.cpp:13:22: warning: declaration of 'n' shadows a previous local [-Wshadow]
 return [f](auto n) {
  ^
fix.cpp:19:19: note: shadowed declaration is here
 unsigned long n;
   ^

[Bug c/80274] New: There is an unoptimized direct memory write of 16bit value on x86_64 with O2 and O3.

[zloten at mail dot ru]

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

Bug ID: 80274
   Summary: There is an unoptimized direct memory write of 16bit
value on x86_64 with O2 and O3.
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zloten at mail dot ru
  Target Milestone: ---

The next code:

void foo() {
 *(unsigned short*)0x=1;
}

Compiles to:

foo():
mov eax, 1
mov WORD PTR ds:65535, ax
ret

But must be:

foo():
mov WORD PTR ds:65535, 1
ret

The bug occurs with any options at optimization levels O2, O3. But this is ok
at optimization level O.
The bug occurs since 4.8.1 version of GCC.

PS: For any other sizes (8bit, 32bit and 64bit) the output is correct:
mov BYTE PTR ds:65535, 1 ;unsigned byte
mov DWORD PTR ds:65535, 1;unsigned int
mov QWORD PTR ds:65535, 1;unsigned long long int

[Bug c++/80273] New: cv-qualified auto with trailing return type incorrectly accepted

[rs2740 at gmail dot com]

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

Bug ID: 80273
   Summary: cv-qualified auto with trailing return type
incorrectly accepted
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

GCC incorrectly accepts

auto const meow() -> int;

[dcl.fct]/2 says only plain 'auto' is allowed.

Possibly related to bug 67012.

[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Although the problem probably arises in process_outer_var_ref, where with
decl_maybe_constant_var_p now returning true for references we take a different
path which likely messes things up, but no idea what's going on.

[Bug c++/80272] New: g++ runs out of memory and crashes

[bkropki at yahoo dot co.uk]

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

Bug ID: 80272
   Summary: g++ runs out of memory and crashes
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bkropki at yahoo dot co.uk
  Target Milestone: ---

Created attachment 41096
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41096=edit
C++ code which crashes g++

g++ runs out of memory and crashes, when the following simple code is compiled

#include 
const int ARR_SIZE = 0x1;   // 64 K

struct A {
  char whatever;
  A() { whatever = 0; };   // removing constructor removes the problem
};

class B {
  std::array, ARR_SIZE>  values;
public:
  B();
};

B::B() : values{}   // removing explicit initialisation of values (i.e.
removing ": values{}") removes the problem
{}

int main() {  return 0; }

[Bug c++/80177] wrong fixit hint for misspelled static_assert: __cpp_static_assert

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01580.html

[Bug target/80107] ICE in final_scan_insn, at final.c:2964

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

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

--- Comment #3 from Pat Haugen  ---
Fixed.

[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
(I'm using the testcase in Comment 1.) a() is a function template, so when we
instantiate it, we call tsubst_expr with args = int to all stuff in
BIND_EXPR_BODY of the function.  We'll end up calling tsubst_copy for VAR_DECL
'c' in the nested lambda.  lookup_name tries to find an instatiation of 'c',
but the one it finds has a different context ("auto  = b;" vs "c;" from the
outer lambda), so we ignore that and do
  r = tsubst_decl (t, args, complain);
which created a new VAR_DECL, with DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P =
0.
The type of this decl is a reference, so
  if (decl_maybe_constant_var_p (r))
is true 
so we do
  tree init = tsubst_init (DECL_INITIAL (t), r, args,
   complain, in_decl);
and
  init = maybe_constant_init (init);
so INIT is "*b".  It's not reduced_constant_expression_p so
DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P is left unset.  Which means that
decl_constant_var_p (r) in the assert doesn't hold and we crash.

So there's a discrepancy in DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P for the
specializations of 'c'.  The original one has it (set in cp_finish_decl -- the
initializer "b" is potential_constant_expression), but the second one doesn't
have it ("*b" isn't reduced_constant_expression_p.

[Bug target/80107] ICE in final_scan_insn, at final.c:2964

[pthaugen at gcc dot gnu.org]

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

--- Comment #2 from Pat Haugen  ---
Author: pthaugen
Date: Fri Mar 31 15:59:46 2017
New Revision: 246619

URL: https://gcc.gnu.org/viewcvs?rev=246619=gcc=rev
Log:
PR target/80107
* config/rs6000/rs6000.md (extendhi2): Add test for
TARGET_VSX_SMALL_INTEGER.
* gfortran.dg/pr80107.f: New.


Added:
trunk/gcc/testsuite/gfortran.dg/pr80107.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10

[nightstrike at gmail dot com]

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

--- Comment #46 from nightstrike  ---
Test now passes on mingw-w64

[Bug tree-optimization/49498] [5/6/7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning (predicate analysis bugs)

[law at gcc dot gnu.org]

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

--- Comment #30 from Jeffrey A. Law  ---
Author: law
Date: Fri Mar 31 15:26:18 2017
New Revision: 246618

URL: https://gcc.gnu.org/viewcvs?rev=246618=gcc=rev
Log:
PR tree-optimization/49498
* gcc.dg/uninit-pred-8_b.c: Reenable DOM.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/uninit-pred-8_b.c

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10

[nightstrike at gmail dot com]

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

--- Comment #45 from nightstrike  ---
Testing these now:

https://sourceforge.net/p/mingw-w64/mingw-w64/ci/466ef13e8468636e76a80342c6c0ee9e4c17bca3/

https://sourceforge.net/p/mingw-w64/mingw-w64/ci/edd8fa8648ae04a2f63d92498abeccffbfd0ba1f/

[Bug c++/77277] -fdiagnostics-color=always disabled on _WIN32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The author of that patch should contribute it then, see that
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
There are some minor formatting issues and some other issues (e.g. the arrays
should be static const, there is no need to initialize them at runtime, it just
wants a "named" string literal), but the most important thing is we can't just
take random patches out of other spots without the author contributing them.

[Bug tree-optimization/49498] [5/6/7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning (predicate analysis bugs)

[law at redhat dot com]

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

--- Comment #29 from Jeffrey A. Law  ---
Yes, I checked cris-elf.  I've got the patch to reenable DOM for that test in
my local tree.

[Bug sanitizer/79993] [5/6/7 Regression] ICE in tree_to_uhwi, at tree.c:7344

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
So far I have:
--- gcc/cp/typeck2.c.jj 2017-03-02 08:08:42.0 +0100
+++ gcc/cp/typeck2.c2017-03-31 15:36:54.366928789 +0200
@@ -739,7 +739,9 @@ split_nonconstant_init (tree dest, tree

   if (TREE_CODE (init) == TARGET_EXPR)
 init = TARGET_EXPR_INITIAL (init);
-  if (TREE_CODE (init) == CONSTRUCTOR)
+  if (TREE_CODE (init) == CONSTRUCTOR
+  || (TREE_CODE (init) == STRING_CST
+ && array_of_runtime_bound_p (TREE_TYPE (dest
 {
   init = cp_fully_fold (init);
   code = push_stmt_list ();
@@ -1066,7 +1068,7 @@ digest_init_r (tree type, tree init, boo
}
}

- if (type != TREE_TYPE (init))
+ if (type != TREE_TYPE (init) && !array_of_runtime_bound_p (type))
{
  init = copy_node (init);
  TREE_TYPE (init) = type;
--- gcc/cp/init.c.jj2017-03-21 08:04:13.0 +0100
+++ gcc/cp/init.c   2017-03-31 16:38:18.346535659 +0200
@@ -4199,7 +4199,12 @@ build_vec_init (tree base, tree maxindex
   else if (from_array)
 {
   if (init)
-   /* OK, we set base2 above.  */;
+   {
+ /* OK, we set base2 above.  */
+ if (TREE_CODE (init) == STRING_CST
+ && array_of_runtime_bound_p (atype))
+   empty_list = true;
+   }
   else if (CLASS_TYPE_P (type)
   && ! TYPE_HAS_DEFAULT_CONSTRUCTOR (type))
{
and the remaining part is changing build_vec_init, so that it will perform the
memcpy (MEM_REF = STRING_CST) followed by the initialization of the rest.

[Bug c/78732] Wrong description for Wendif-labels

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Fixed on trunk in r246616.

[Bug c/78732] Wrong description for Wendif-labels

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Fri Mar 31 14:24:27 2017
New Revision: 246616

URL: https://gcc.gnu.org/viewcvs?rev=246616=gcc=rev
Log:
Fix description of Wendif-labels (PR documentation/78732)

gcc/c-family/ChangeLog:
PR documentation/78732
* c.opt (Wendif-labels): Fix description to refer to
#else rather than #elif.


Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt

[Bug middle-end/26461] liveness of thread local references across function calls

[tmyklebu at gmail dot com]

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

Tor Myklebust  changed:

   What|Removed |Added

 CC||tmyklebu at gmail dot com

--- Comment #17 from Tor Myklebust  ---
(In reply to Jakub Jelinek from comment #14)
> Even if we have an option that avoids CSE of TLS addresses across function
> calls (or attribute for specific function), what would you expect to happen
> when user takes address of TLS variables himself:
> __thread int a;
> void
> foo ()
> {
>   int *p = 
>   *p = 10;
>   bar (); // Changes threads
>   *p += 10;
> }
> ?  The address can be stored anywhere, so the compiler can't do anything
> with it.  And of course such an option would cause major slowdown of
> anything using TLS, not only it would need to stop CSEing TLS addresses
> late, but stop treating TLS addresses as constant in all early optimizations
> as well.

When you take , gcc docs specify that you get the address of the running
thread's instance of a, which is a reasonable pointer for any thread to use as
long as the running thread is alive.  So everyone already expects that code
like this:

__thread int a;

void *bar(void *p) { printf("%i %i\n", *(int *)p, a); }
int main() {
  a = 42;
  pthread_t pth;
  pthread_create(, bar, );
  pthread_join(pth, 0);
}

should print "42 0" as p should point to the main thread's instance of a while
the reference of a in the third argument to printf in bar should reference the
child thread's instance of a, which is zero because TLS is initialised to zero.

It seems that your example:

__thread int a;

void foo() {
  int *p = 
  *p = 10;
  bar (); // Changes threads
  *p += 10;
}

must twice modify the instance of a in the thread that started running foo,
which is different behaviour from:

__thread int a;

void baz() {
  int *p = 
  *p = 10;
  bar (); // Changes threads
  p = 
  *p += 10;
}

which must modify the instance of a in the thread that started running baz()
once and the instance of a that finishes running baz() once, since bar may
change the value at %fs:0 by changing threads.

Perhaps there is a more serious problem with this whole idea if signal handlers
are permitted to twiddle the running thread.

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[segher at gcc dot gnu.org]

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

--- Comment #22 from Segher Boessenkool  ---
The combination that makes it die is:

Trying 18, 17 -> 19:
Successfully matched this instruction:
(set (reg:CC 176)
(reg:CC 164))

Where insn 18 is

(set (reg:SI 174)
(gt:SI (reg:CC 164)
(const_int 0 [0])))

and insn 17 is

(set (reg:SI 173)
(lt:SI (reg:CC 164)
(const_int 0 [0])))

and insn 19 is

(insn 19 18 22 2 (set (reg:CCUNS 176)
(compare:CCUNS (reg:SI 173)
(reg:SI 174))) "60818-19.c":4 772 {*cmpsi_unsigned}
 (expr_list:REG_DEAD (reg:SI 174)
(expr_list:REG_DEAD (reg:SI 173)
(nil

the combined insn should not simply copy the CC (it needs to swap
the greater-than and smaller-than results), and it needs to return
a CCUNS anyway.  Where did this come from...

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[segher at gcc dot gnu.org]

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

--- Comment #21 from Segher Boessenkool  ---
You don't even need -Os for this last testcase, only -misel.

[Bug driver/80271] New: Support environment variable CLICOLOR_FORCE to enable -fdiagnostics-color

[jhasse at bixense dot com]

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

Bug ID: 80271
   Summary: Support environment variable CLICOLOR_FORCE to enable
-fdiagnostics-color
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jhasse at bixense dot com
  Target Milestone: ---

When piping gcc, colored output gets disabled because isatty returns false. But
for many people this is the normal way of running gcc, as most build systems
(e. g. ninja or Waf) and build servers (e. g. Drone or Jenkins) pipe it to
print its output delayed. In these cases ANSI colors would still work though
and therefore many people set -fdiagnostics-color=always (see
https://github.com/KDE/extra-cmake-modules/commit/dc525a42ae70a68d67aa49d6453d4b6de4ecb561
for example).

It would be nice, if there would be a better way to auto detect that case. An
environment variable would be a good choice, as build tools, build servers or
IDEs with ANSI escape code support can set it.

The name CLICOLOR_FORCE was chosen, because it is already used by some tools
and a unified naming for this would be nice. See https://bixense.com/clicolors/

(A flag like -fdiagnostics-color also has the disadvantage that changes trigger
a complete rebuild in most build system although the flag doesn't influence the
object code output.)

[Bug sanitizer/79993] [5/6/7 Regression] ICE in tree_to_uhwi, at tree.c:7344

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||nils at os dot 
inf.tu-dresden.de

--- Comment #7 from Jakub Jelinek  ---
*** Bug 80269 has been marked as a duplicate of this bug. ***

[Bug sanitizer/80269] ICE with compile time constant sized array when using address sanitizer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jakub Jelinek  ---
With -std=c++11 the assumption that this is compile time constant sized array
is bogus, std::max is constexpr only in -std=c++14 and later.  It doesn't
matter if your variable is const, it is still initialized at runtime, so char
array[LIM]
is a VLA and this ICEs because of the PR79993.

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

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Perhaps we then need some helper function partly similar to cxx_eval_array_ref,
that would for an object (or address of it?) and some uhwi index attempt to
return some byte from the object, and then if the middle-end folding doesn't
yield anything, handle these builtins by using that helper in a loop to grab
bytes from one or two input strings, then perform the needed action on them as
if we have open-coded those routines in trivial C loops.
As even
constexpr char
foo (int x)
{
  char a[] = { 'a', 'b', 'c', 'd', '\0' };
  char *b = [0];
  return ((unsigned char *)b)[x];
}

constexpr char a = foo (0);
is rejected, I think we can't use the existing routines here though, we want to
be able to access bytes of anything initialized.

[Bug c++/77277] -fdiagnostics-color=always disabled on _WIN32

[jhasse at bixense dot com]

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

Jan Niklas Hasse  changed:

   What|Removed |Added

 CC||jhasse at bixense dot com

--- Comment #2 from Jan Niklas Hasse  ---
Maybe this patch can simply be upstreamed?
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gcc/0017-diagnostic-color.patch

I've been using GCC on Window with it for a few months and it works fine :)

[Bug middle-end/80270] ICE in extract_bit_field_1 at gcc/expmed.c:1798

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-31
  Component|tree-optimization   |middle-end
 Ever confirmed|0   |1
  Known to fail||4.8.5, 6.3.1, 7.0.1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/80218] [6 Regression] tree-call-cdce does not update block frequencies

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk and GCC 6 branch.

[Bug tree-optimization/80218] [6 Regression] tree-call-cdce does not update block frequencies

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Fri Mar 31 11:51:32 2017
New Revision: 246614

URL: https://gcc.gnu.org/viewcvs?rev=246614=gcc=rev
Log:
PR80218: Call CDCE fails to update the block profile

tree-call-cdce.c was updating the edge probabilities and counts but
it wasn't updating the corresponding block information.  Among other
things, this tricked the register allocator into thinking that the
libm call was relatively hot and that it wasn't worth assigning
call-clobbered registers to values that were live across the call.
With correct frequency information, the RA instead keeps x in the
first argument register and spills it only around the call.

Although the problem has been around for a long time, it became more
acute (and would only trigger for the first function in the testcase)
after r230488.  Until that patch, the code was specific to calls that
had no lhs, but that we still had to keep for their effect on errno.
After the patch we also used the code for calls with an lhs, provided
that the hardware could calculate the lhs directly.

gcc/
PR tree-optimization/80218
* tree-call-cdce.c (shrink_wrap_one_built_in_call_with_conds):
Update block frequencies and counts.

gcc/testsuite/
PR tree-optimization/80218
* gcc.dg/pr80218.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr80218.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-call-cdce.c

[Bug tree-optimization/80270] New: ICE in extract_bit_field_1 at gcc/expmed.c:1798

[aivchenk at gmail dot com]

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

Bug ID: 80270
   Summary: ICE in extract_bit_field_1 at gcc/expmed.c:1798
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aivchenk at gmail dot com
  Target Milestone: ---

> cat struct_hard_reg.c 

#include 

typedef int v8 __attribute__((vector_size(8)));
struct S1 {
  v8 s1f;
};
struct S2 {
  struct S1 s2f1;
  v8 s2f2;
};

void fn1() {
  int __trans_tmp_2, i = 3;
  register struct S2 b asm("xmm0");
  __trans_tmp_2 = b.s2f1.s1f[i];
  printf("%d", __trans_tmp_2);
}

> gcc ./struct_hard_reg.c  -O1

./new_bug.c: In function ‘fn1’:
./new_bug.c:17:3: internal compiler error: Segmentation fault
   printf("%d", __trans_tmp_2);
   ^~~
0xe92cda crash_signal
../../gcc/gcc/toplev.c:337
0xa3284a extract_bit_field_1
../../gcc/gcc/expmed.c:1798
0xa32e01 extract_bit_field(rtx_def*, unsigned long, unsigned long, int,
rtx_def*, machine_mode, machine_mode, bool)
../../gcc/gcc/expmed.c:1932
0xa63501 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10702
0xa5821f expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/gcc/expr.c:8072
0xa5f27e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:9775
0xa5821f expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/gcc/expr.c:8072
0x8d448f expand_normal
../../gcc/gcc/expr.h:282
0x8d647d precompute_register_parameters
../../gcc/gcc/calls.c:956

[Bug sanitizer/80269] ICE with compile time constant sized array when using address sanitizer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-31
 Ever confirmed|0   |1
  Known to fail||6.3.1, 7.0.1

--- Comment #1 from Richard Biener  ---
Confirmed on trunk/branch.  Works with c++14 (detail of std::max?).

[Bug middle-end/26461] liveness of thread local references across function calls

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
Implementing a switch that assumes that function calls (what about async
events??) can switch threads to the effect that the location of TLS variables
change would be a challenge.  Basically you have to implement sth that prevents
assumptions of a variables location inside a function, not only its value. 
That's currently done nowhere and I don't know how to model such kind of
dependency.

So I don't think it's easy to model.  It might be possible to put in place
more strict constraints to avoid the issue, like instructing the compiler
that it can't ever take the address of a __tls object.  But then array
accesses are modeled as  + index in the language so I can't see how this
would work reliably.

You'd have to expose __tls'ness by lowering that very early, not only during
RTL expansion.  That is, place TLS base reg loads and do accesses via them. 
Then
make sure calls clobber that base reg load.  So put all TLS data into sth like
a static frame where you'd have a global variable pointing to that.  I expect
this to be not-fun(TM) for performance.

[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Botcazou  ---
Created attachment 41095
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41095=edit
Tentative fix

Tested in LP64 mode, needs to be tested in ILP32 mode.

[Bug middle-end/26461] liveness of thread local references across function calls

[torvald at gcc dot gnu.org]

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

--- Comment #15 from torvald at gcc dot gnu.org ---
From a ISO C/C++ conformance perspective, this is not a bug:

* Pre-C11/C++11, threading was basically undefined.

* Starting with C11 and C++11, "threads of execution" (as they're called in
C++11 and more recent, often abbreviated in the standard as "threads") are the
lowest level of how execution is modelled.  They are defined as single flows of
control.  Nothing is promised about any resources that may be used to implement
threads of execution (e.g., similar to the "execution context" notion mentioned
in comment #10).

* Thread-specific state is bound to a particular thread of execution (e.g.,
regarding lifetime).  A thread of execution accessing a __thread variable
accesses the thread-specific state of this thread of execution in the abstract
machine.  (Of course, one can still access other threads's thread-specific
state through pointers initially provided by those threads.)

* Only the standards' mechanisms can create threads of execution.  There is
nothing in these standards that would break up the concept of a single flow of
control (ie, that what "looks" like a single flow of control in a program is
actually not always the same thread of execution when executed).  (Also note
that fork/join parallelism is not a counter-example to this.)


That said, I can see that this doesn't match nicely with the fact that we have
things like swapcontext elsewhere.  Do we have any data on what the performance
impact where if the compiler would assume that function calls to functions it
cannot analyze could switch the thread of execution.  Data for several
architectures and different TLS models would be helpful.

Coming back to C++, currently I think there is only one Technical Specification
(TS) that allows breaking up a single flow of control: .then() in the
Concurrency TS (whose specification is certainly not ready for the standard). 
Maybe the Networking TS has something similar, but I can't remember right now. 
There are a few proposals that either allow it (Task Blocks, targeting
Parallelism TS version 2) or require it for good performance ("stackful"
coroutines).
The "stackless" coroutines in the upcoming Coroutines TS are not really
affected by thread-specific state; it's not the coroutines code that would
potentially switch threads, but any runtime that would supply a particular
Awaitable implementation that then may switch threads (e.g., if using .then()).
 The Coroutines does not specify any actual runtime.

However, I don't think the existence of some C++ proposals that may switch
threads necessarily means that the compiler would have to take this into
account when those proposals should become part of the standard.  The other way
this could play out is that the standard simply makes using thread-specific
state undefined for those threads of execution that can use these proposals.

Overall, I think it may be useful to experiment with a command line switch or
something like that, primarily to assess how big the performance degradation
would be caused by having the compiler assume that threads can switch on
function calls.

(In reply to Jakub Jelinek from comment #14)
> Even if we have an option that avoids CSE of TLS addresses across function
> calls (or attribute for specific function), what would you expect to happen
> when user takes address of TLS variables himself:
> __thread int a;
> void
> foo ()
> {
>   int *p = 
>   *p = 10;
>   bar (); // Changes threads
>   *p += 10;
> }

I think that p would point to the initial thread's TLS, even after bar().   The
user would be wrong to assume that it still is the initial thread's object "a"
after having called bar().

[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r242422.

[Bug rtl-optimization/70703] [6/7 regression] Regression in register usage on x86

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Created attachment 41094
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41094=edit
gcc7-pr70703-widen.patch

The widening_mult change.  We get tiny bit better code with it with the #c0
testcase:
-   movl$6700417, %ecx
-   movl%ecx, %eax
+   movl$6700417, %edx
+   movl%edx, %eax
mull4(%esp)
-   movl%edx, %ecx
-   movl%ecx, %eax
+   movl%edx, %eax
but still not ideal.  On the other side, we regress on -m64:
unsigned long
foo (unsigned long x)
{
  return ((__uint128_t) x * 0x663d811234567ULL) >> 64;
}

-   movabsq $1798629511873895, %rax
-   mulq%rdi
+   movq%rdi, %rax
+   movabsq $1798629511873895, %rdx
+   mulq%rdx

Another option is to deal with this at combine time, I see on the unpatched
compiler:
Failed to match this instruction:
(set (reg:SI 95)
(subreg:SI (mult:DI (zero_extend:DI (mem/c:SI (reg/f:SI 16 argp) [1 x+0 S4
A32]))
(const_int 6700417 [0x663d81])) 4))

Maybe we could add some define_insn_and_split that would deal with this and
make sure the constant is forced into a register (if the constant has depending
on  all upper bits zero or set) and transform it into the highpart insns?
Though, I'm worried about the regression above we got with the TImode highpart.

[Bug libstdc++/69853] An inheriting constructor of the class that inherited std::tuple isn't called correctly

[redboltz at gmail dot com]

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

--- Comment #4 from Takatoshi Kondo  ---
Thank you for the comment. I understand.
I use perfect forwarding in this case.

[Bug sanitizer/80269] New: ICE with compile time constant sized array when using address sanitizer

[nils at os dot inf.tu-dresden.de]

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

Bug ID: 80269
   Summary: ICE with compile time constant sized array when using
address sanitizer
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nils at os dot inf.tu-dresden.de
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: ---

Created attachment 41093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41093=edit
Preprocessed test file

I experience an internal compiler error when assigning to an array with
constant size, given by an expression, and building with C++11 and address
sanitizers. Here is a minimal example:

#include 
#include 

const int LIM = std::max(10, 12);

int main() {
char array[LIM] = "";
printf("%s\n", array);
return 0;
}

And compiling with:

g++ -std=c++11 -fsanitize=address test.cc

The result is:

test.cc:10:1: internal compiler error: in tree_to_uhwi, at tree.h:4044
 }
 ^
0xae594f tree_to_uhwi(tree_node const*)
../../gcc/gcc/tree.h:4044
0xae594f asan_add_global
../../gcc/gcc/asan.c:2269
0xae59b2 add_string_csts(constant_descriptor_tree**,
asan_add_string_csts_data*)
../../gcc/gcc/asan.c:2483
0xae5e2a void hash_table::traverse_noresize(asan_add_string_csts_data*)
../../gcc/gcc/hash-table.h:950
0xae5e2a void hash_table::traverse(asan_add_string_csts_data*)
../../gcc/gcc/hash-table.h:972
0xae5e2a asan_finish_file()
../../gcc/gcc/asan.c:2555


My system is:
$ uname -a
Linux erwin 4.9.5 #1 SMP Mon Jan 23 14:42:51 CET 2017 x86_64 GNU/Linux

$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/host-x86_64/6/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc/host-x86_64/6/libexec/gcc/x86_64-pc-linux-gnu/6.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gcc/host-x86_64/6
--enable-shared --enable-__cxa_atexit
--enable-languages=c,c++,fortran,go,java,lto,objc --enable-libmpx
--enable-plugin --enable-default-pie --with-system-zlib
--disable-browser-plugin --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --enable-multilib --with-tune=generic :
(reconfigured) ../gcc/configure --prefix=/usr/local/gcc/host-x86_64/6
--enable-shared --enable-__cxa_atexit
--enable-languages=c,c++,fortran,go,java,lto,objc --enable-libmpx
--enable-plugin --enable-default-pie --with-system-zlib
--disable-browser-plugin --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --enable-multilib --with-tune=generic
Thread model: posix
gcc version 6.3.1 20170326 (GCC)

I've attached the preprocessor output, just in case.

[Bug rtl-optimization/70703] [6/7 regression] Regression in register usage on x86

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Vlad, any thoughts on this?

I'll try to deal with this in the widening_mul pass too, that pass converts:
   _1 = (long long unsigned int) x_4(D);
-  _2 = _1 * 6700417;
+  _2 = x_4(D) w* 6700417;
   _3 = _2 >> 32;
   _5 = (unsigned int) _3;
but as the only user cares about the high part of the widened result, we could
convert it into:
   _1 = (long long unsigned int) x_4(D);
   _2 = _1 * 6700417;
   _3 = _2 >> 32;
-  _5 = (unsigned int) _3;
+  _5 = x_4(D) h* 6700417;
There is nothing that would attempt match.pd foldings after this.

[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
I still see inlining differences (comparing to GCC 6).  The profile looks like

  33.18%  c-ray-f-7  c-ray-f-7 [.] shade
  28.18%  c-ray-f-6  c-ray-f-6 [.] shade
  11.50%  c-ray-f-7  c-ray-f-7 [.] ray_sphere
   9.32%  c-ray-f-6  c-ray-f-6 [.] trace
   7.40%  c-ray-f-7  c-ray-f-7 [.] render
   7.26%  c-ray-f-6  c-ray-f-6 [.] render

GCC 6:
Inlining ray_sphere.constprop to shade with frequency 10
Inlining ray_sphere to trace with frequency 6169
Inlining get_sample_pos to get_primary_ray with frequency 1000
Inlining trace.constprop to render with frequency 10
Inlining ray_sphere to render with frequency 10
Inlining get_msec.part.0 to get_msec with frequency 390

GCC 7:
Inlining get_sample_pos to get_primary_ray with frequency 1000
Inlining ray_sphere.constprop to shade with frequency 36274
Inlining trace to shade with frequency 505
Inlining ray_sphere to trace with frequency 3059
Inlining trace.constprop to render with frequency 10
Inlining get_primary_ray to render with frequency 10
Inlining get_sample_pos to render with frequency 10
Inlining ray_sphere to render with frequency 10

so the difference is that with GCC 6 we inline ray_shpere to trace
(and that not into shade) while with GCC 7 we inline trace into shade
but before inlining ray_sphere into trace.

We know that for good performance inlining ray_sphere is critical and
for some reason that's still not prioritized on trunk.

Of course it's just a benchmark and using -fwhole-program fixes it
on trunk (to faster than GCC 6 w/o -fwhole-program, GCC 6 with
-fwhole-program actually regresses...).

[Bug middle-end/79989] [7 Regression][CHKP] ICE in assign_temp, at function.c:968

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug testsuite/78529] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.0 |---
Summary|[7 Regression]  |gcc.c-torture/execute/built
   |gcc.c-torture/execute/built |ins/strcat-chk.c failed
   |ins/strcat-chk.c failed |with lto/O2
   |with lto/O2 |

--- Comment #35 from Richard Biener  ---
And not really a regression thus.  Either INVALID or leave it open as testsuite
enhancement.

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[asolokha at gmx dot com]

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

--- Comment #20 from Arseny Solokha  ---
(In reply to Alan Modra from comment #19)
> Yes, r246294 powerpc64le-linux-gcc -O1 -misel ICEs on the last testcase.  An
> earlier compiler I had laying around, 7.0.0 20160616, does not.

Here's a simplified version, then (-misel -Os):

int
lx (int oi, int mb)
{
  return (oi < mb) < (mb < oi);
}

Note that this snippet as well as one from comment 17 both have comparison
patterns similar to those from snippets in comment 3 and comment 4.

[Bug rtl-optimization/77499] [7/8 Regression] Regression after code-hoisting, due to combine pass failing to evaluate known value range

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm-none-eabi
   Target Milestone|7.0 |8.0
Summary|[7 Regression] Regression   |[7/8 Regression] Regression
   |after code-hoisting, due to |after code-hoisting, due to
   |combine pass failing to |combine pass failing to
   |evaluate known value range  |evaluate known value range

--- Comment #15 from Richard Biener  ---
There's no simple fix here, defering to GCC 8.

[Bug middle-end/63184] [5/6/7/8 Regression] Fails to simplify comparison

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|5.5 |8.0
Summary|[5/6/7 Regression] Fails to |[5/6/7/8 Regression] Fails
   |simplify comparison |to simplify comparison

[Bug tree-optimization/71361] [7/8 Regression] Changes in ivopts caused perf regression on x86

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|7.0 |8.0
Summary|[7 Regression] Changes in   |[7/8 Regression] Changes in
   |ivopts caused perf  |ivopts caused perf
   |regression on x86   |regression on x86

[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
trippels@gcc75 ~ % cat bug.ii
template  void a() {
  int b;
  auto  = b;
  [&] {
c;
[&] { c; };
  };
}
void d() { a(); }

trippels@gcc75 ~ % g++ -c bug.ii
bug.ii: In instantiation of ‘a():::: [with
 = int]’:
bug.ii:6:7:   required from ‘struct a():: [with
 = int]::’
bug.ii:6:5:   required from ‘a():: [with  =
int]’
bug.ii:4:5:   required from ‘struct a() [with  =
int]::’
bug.ii:4:3:   required from ‘void a() [with  = int]’
bug.ii:9:19:   required from here
bug.ii:6:11: internal compiler error: in tsubst_copy, at cp/pt.c:14609

[Bug tree-optimization/49498] [5/6/7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning (predicate analysis bugs)

[rguenth at gcc dot gnu.org]

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

--- Comment #28 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #27)
> Must. Read. dg-comments in testcase. More. Carefully.
> 
> 
> This was actually fixed a couple years ago with some pass ordering changes. 
> The testsuite hack mentioned in c#12 is no longer needed.

Hmm, note the report states it worked on x86_64/i586/arm anyway and only
some other archs were broken.

Did you verify any of those?  Iff it's really fixed we should remove the
testcase workaround (enable DOM again).

A quick check on avr doesn't reproduce the issue when re-enabling DOM.

[Bug tree-optimization/80248] sparse access to Array of structures does not vectorize using gathers

[vincenzo.innocente at cern dot ch]

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

--- Comment #2 from vincenzo Innocente  ---
side note: the difference is timing between "aos2" and "soa" seems to be fully
accounted by the integer multiplication "3*k[i]".

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I think you need to handle some of the builtin folding in the C++ FE.

[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |7.0

[Bug target/80266] ICE in store_pairsi condition with -mabi=ilp32

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|7.0 |---

[Bug middle-end/80173] [5/6 Regression] ICE in store_bit_field_1, at expmed.c:787

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE in   |[5/6 Regression] ICE in
   |store_bit_field_1, at   |store_bit_field_1, at
   |expmed.c:787|expmed.c:787

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug debug/80025] [5/6 Regression] ICE w/ -O2 (-O3, -Ofast) -g -ftracer (infinite recursion in rtx_equal_for_cselib_1)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE w/   |[5/6 Regression] ICE w/ -O2
   |-O2 (-O3, -Ofast) -g|(-O3, -Ofast) -g -ftracer
   |-ftracer (infinite  |(infinite recursion in
   |recursion in|rtx_equal_for_cselib_1)
   |rtx_equal_for_cselib_1) |

--- Comment #15 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug middle-end/26461] liveness of thread local references across function calls

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||torvald at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
Even if we have an option that avoids CSE of TLS addresses across function
calls (or attribute for specific function), what would you expect to happen
when user takes address of TLS variables himself:
__thread int a;
void
foo ()
{
  int *p = 
  *p = 10;
  bar (); // Changes threads
  *p += 10;
}
?  The address can be stored anywhere, so the compiler can't do anything with
it.  And of course such an option would cause major slowdown of anything using
TLS, not only it would need to stop CSEing TLS addresses late, but stop
treating TLS addresses as constant in all early optimizations as well.

[Bug libstdc++/80251] Is the is_aggregate meta function missing?

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 31 06:40:39 2017
New Revision: 246609

URL: https://gcc.gnu.org/viewcvs?rev=246609=gcc=rev
Log:
PR libstdc++/80251
c-family/
* c-common.h (enum rid): Add RID_IS_AGGREGATE.
* c-common.c (c_common_reswords): Add __is_aggregate trait.
cp/
* cp-tree.h (enum cp_trait_kind): Add CPTK_IS_AGGREGATE.
* cxx-pretty-print.c (pp_cxx_trait_expression): Handle
CPTK_IS_AGGREGATE.
* semantics.c (trait_expr_value): Handle CPTK_IS_AGGREGATE.
Remove extraneous parens.
(finish_trait_expr): Handle CPTK_IS_AGGREGATE.
* parser.c (cp_parser_primary_expression): Handle RID_IS_AGGREGATE.
(cp_parser_trait_expr): Likewise.
testsuite/
* g++.dg/ext/is_aggregate.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/is_aggregate.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cxx-pretty-print.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/80173] [5/6/7 Regression] ICE in store_bit_field_1, at expmed.c:787

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 31 06:38:35 2017
New Revision: 246608

URL: https://gcc.gnu.org/viewcvs?rev=246608=gcc=rev
Log:
PR middle-end/80173
* expmed.c (store_bit_field_1): Don't attempt to create
a word subreg out of hard registers wider than word if they
have HARD_REGNO_NREGS of 1 for their mode.

* gcc.target/i386/pr80173.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr80173.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expmed.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/80163] ICE on hopefully valid code

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 31 06:32:46 2017
New Revision: 246607

URL: https://gcc.gnu.org/viewcvs?rev=246607=gcc=rev
Log:
PR middle-end/80163
* varasm.c (initializer_constant_valid_p_1): Disallow sign-extending
conversions to integer types wider than word and pointer.

* gcc.dg/pr80163.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr80163.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c