[Bug tree-optimization/79622] [6/7/8 Regression] Wrong code w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 07:34:04 2017
New Revision: 252905

URL: https://gcc.gnu.org/viewcvs?rev=252905&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

PR tree-optimization/79622
* graphite-scop-detection.c (build_cross_bb_scalars_def): Properly
handle PHIs.
(build_cross_bb_scalars_use): Likewise.

* gcc.dg/graphite/pr79622.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr79622.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-scop-detection.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/79622] [6/7 Regression] Wrong code w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to work||8.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|[6/7/8 Regression] Wrong|[6/7 Regression] Wrong code
   |code w/ -O2 |w/ -O2 -floop-nest-optimize
   |-floop-nest-optimize|

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar.

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Liška  ---
You're right, but it's not ASAN-related: one needs to backport r236630
(PR70434).
I guess it's not subject for backport. Thus I'll probably revert the patch?

[Bug other/39851] gcc -Q --help=target does not list extensions selected by -march=

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
(In reply to Daniel Santos from comment #17)
> Thanks for all your work on this Martin.  I've put a script up on my github
> account (https://github.com/daniel-santos/distccflags), updated the Gentoo
> Distcc instructions and sent distcc a mail to notify them.
> 
> Thanks!

Good to hear it helped ;)

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Or just remove or xfail the testcase.  The asan.c change is right even for the
branches...

BTW, just for completeness, I'm also seeing
+FAIL: gcc.target/i386/pr69255-2.c (test for excess errors)
+FAIL: gcc.target/i386/pr69255-3.c (test for excess errors)
regression on 6.x branch, in that case no idea what has caused it, just that it
appeared in between June 22nd and September 15th.

[Bug c++/82230] [8 Regression] Segfault when binding lambda to variable inside a generic lambda inside a template member function inside a template class

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.2.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2017-09-18
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Segfault when binding   |[8 Regression] Segfault
   |lambda to variable inside a |when binding lambda to
   |generic lambda inside a |variable inside a generic
   |template member function|lambda inside a template
   |inside a template class |member function inside a
   ||template class
   Target Milestone|--- |8.0
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r251433, probably dup of PR82082.

[Bug c++/82231] [7/8 Regression] ICE when deducing non-type template parameter value whose type depends on a non-type `auto` template parameter from function arguments

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.1.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2017-09-18
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE when deducing non-type  |[7/8 Regression] ICE when
   |template parameter value|deducing non-type template
   |whose type depends on a |parameter value whose type
   |non-type `auto` template|depends on a non-type
   |parameter from function |`auto` template parameter
   |arguments   |from function arguments
   Target Milestone|--- |7.3
  Known to fail||7.2.0, 8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r249320.

[Bug target/81736] Unnecessary save and restore frame pointer with -fno-omit-frame-pointer

[ro at gcc dot gnu.org]

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

--- Comment #12 from Rainer Orth  ---
Author: ro
Date: Mon Sep 18 08:25:11 2017
New Revision: 252908

URL: https://gcc.gnu.org/viewcvs?rev=252908&root=gcc&view=rev
Log:
Fix gcc.target/i386/pr81736-[34].c on 32-bit Solaris/x86 (PR target/81736)

PR target/81736
* gcc.target/i386/pr81736-3.c: Add -mno-omit-leaf-frame-pointer.
* gcc.target/i386/pr81736-4.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr81736-3.c
trunk/gcc/testsuite/gcc.target/i386/pr81736-4.c

[Bug ada/71358] GNAT.Command_Line.Getopt fails if there are no switches

[pmderodat at gcc dot gnu.org]

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

--- Comment #6 from pmderodat at gcc dot gnu.org ---
Author: pmderodat
Date: Mon Sep 18 08:43:37 2017
New Revision: 252909

URL: https://gcc.gnu.org/viewcvs?rev=252909&root=gcc&view=rev
Log:
2017-09-18  Bob Duff  

Alternate fix for PR ada/71358
* libgnat/g-comlin.adb (Getopt): Remove manual null access checks.
Instead, make a local copy of Config, and if it's null, allocate an
empty Command_Line_Configuration_Record, so we won't crash on null
pointer dereference.


Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/libgnat/g-comlin.adb

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #12)
> Or just remove or xfail the testcase.  The asan.c change is right even for
> the branches...
> 
> BTW, just for completeness, I'm also seeing
> +FAIL: gcc.target/i386/pr69255-2.c (test for excess errors)
> +FAIL: gcc.target/i386/pr69255-3.c (test for excess errors)
> regression on 6.x branch, in that case no idea what has caused it, just that
> it appeared in between June 22nd and September 15th.

I'll mark them as XFAIL then.

The i386 test-case started to fail with mine r252795. I'll take a look.

[Bug target/81733] stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Iain Sandoe  ---
> Is this still current?

It is: just tried with a vanilla tree at r252892.

> The ld64 assert is most likely triggered by a 0-length FDE.  That could be
> caused by confusion over the partitioning.

That's certainly true considering the hack I'm using to allow bootstrap
to finish.

> I don't see this on 10.11.6 with my bootstrap setup, what version of ld64 /
> cctools / bootstrap compiler are you using?

I'm on 10.11.2, ld64 is ld64-128.2 (but I also tried with the ld64 from
your darwin-xtools repo on github, ld64-253.9, with same results).
Bootstrapping with gcc 7.1.0.

Rainer

[Bug lto/82229] GCC7's LTO underperforms compared to GCC6

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto, missed-optimization
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-09-18
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
I suspect changes in cross-module inlining causing the issue.  Without some
analysis from your side it's really hard to do anything about this.  A good
start is to do some profiling.

[Bug libfortran/82233] [6/7/8 Regression] execute_command_line causes program to stop when command fails (or does not exist)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug lto/82229] GCC7's LTO underperforms compared to GCC6

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Moreover, if there's an automatic way how one can get FPS without GUI
interaction, I can bisect revision that's responsible for that.

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
(In reply to Martin Liška from comment #13)
> (In reply to Jakub Jelinek from comment #12)
> > Or just remove or xfail the testcase.  The asan.c change is right even for
> > the branches...
> > 
> > BTW, just for completeness, I'm also seeing
> > +FAIL: gcc.target/i386/pr69255-2.c (test for excess errors)
> > +FAIL: gcc.target/i386/pr69255-3.c (test for excess errors)
> > regression on 6.x branch, in that case no idea what has caused it, just that
> > it appeared in between June 22nd and September 15th.
> 
> I'll mark them as XFAIL then.
> 
> The i386 test-case started to fail with mine r252795. I'll take a look.

We need there your revision r242740. May I backport it? Or just the hunk that
adjusts the test-case?

[Bug target/81422] [aarch64] internal compiler error: in update_equiv_regs, at ira.c:3425

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/81733] stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> > --- Comment #1 from Iain Sandoe  ---
> > Is this still current?
> 
> It is: just tried with a vanilla tree at r252892.
> 
> > The ld64 assert is most likely triggered by a 0-length FDE.  That could be
> > caused by confusion over the partitioning.
> 
> That's certainly true considering the hack I'm using to allow bootstrap
> to finish.
> > I don't see this on 10.11.6 with my bootstrap setup, what version of ld64 /
> > cctools / bootstrap compiler are you using?
> 
> I'm on 10.11.2, ld64 is ld64-128.2 (but I also tried with the ld64 from
> your darwin-xtools repo on github, ld64-253.9, with same results).

OK. I do have a patch to make ld64 drop 0-length FDEs silently (but, in some
respects, it's probably actually better to have the assert - since it probably
indicates something is wrong earlier in the toolchain).

> Bootstrapping with gcc 7.1.0.

OK.. let me see if I can reproduce - I can certainly see bad EH being generated
with the bootstrap toolchain I'm using (but it doesn't kill bootstrap for me). 
Things a bit hectic this week, but will try to fit it in.

I had some patches to make the partitioning output more ld64-atom-friendly, but
they didn't rebase cleanly (some turbulence in the hot/cold partitioning
stuff), so it will take some more analysis to re-apply them - hope is that they
will squash some of the problems, and then we just need to analyse the rest.. 

incidentally, probably, 80556 is caused by the libgcc_eh unwinder being broken
itself from this (since -static-libgcc _should_ work providing there's _only_
the libgcc unwinder in use).

[Bug target/81361] [8 regression] broken exception handling at -O2

[ebotcazou at gcc dot gnu.org]

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

--- Comment #25 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Sep 18 09:15:32 2017
New Revision: 252914

URL: https://gcc.gnu.org/viewcvs?rev=252914&root=gcc&view=rev
Log:
PR target/81361
* dwarf2cfi.c (add_cfis_to_fde): Do not generate DW_CFA_set_loc after
switching to a new text section.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2cfi.c

[Bug c++/80947] [6/7/8 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot 
com,
   ||redi at gcc dot gnu.org

--- Comment #12 from Paolo Carlini  ---
As far as the snippet in Comment #4 is concerned, current trunk seems fine to
me. To be clear, I'm only adding -fvisibility-inlines-hidden
-fvisibility=hidden to the command line (which reproduces the issue in
gcc-7-branch; in fact -fvisibility=hidden is enough).

Jonathsn, can you double check and confirm that the snippet is supposed to
require only the above?

[Bug target/81361] [8 regression] broken exception handling at -O2

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #26 from Eric Botcazou  ---
.

[Bug middle-end/82145] [8 regression] i386/pr38988.c, i386/pr46254.c, i386/pr55154.c, i386/pr81766.c fails

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Sep 18 09:31:14 2017
New Revision: 252915

URL: https://gcc.gnu.org/viewcvs?rev=252915&root=gcc&view=rev
Log:
PR target/82145
* config/i386/i386.c (ix86_init_large_pic_reg): Revert 2017-09-01
changes.  Turn CODE_LABEL into NOTE_INSN_DELETED_LABEL immediately.
(ix86_init_pic_reg): Revert 2017-09-01 changes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug c++/58894] C++11 lambda doesn't take const variable by reference

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Yes.

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

[Bug c++/54367] [meta-bug] lambda expressions

[paolo.carlini at oracle dot com]

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

Bug 58894 Summary: C++11 lambda doesn't take const variable by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58894

   What|Removed |Added

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

[Bug c++/53157] within lambda, error: lvalue required as unary ‘&’ operand

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||abyss.7 at gmail dot com

--- Comment #5 from Paolo Carlini  ---
*** Bug 58894 has been marked as a duplicate of this bug. ***

[Bug target/80566] no use of avx vmovups on ymm registry in set and copy

[vladimir.solontsov at mlp dot com]

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

Vlad  changed:

   What|Removed |Added

 CC||vladimir.solontsov at mlp dot 
com

--- Comment #1 from Vlad  ---
I can confirm this for gcc7.2 (-O3 -g -mavx2): https://godbolt.org/g/h7TNJV.

[Bug target/80566] no use of avx vmovups on ymm registry in set and copy

[vladimir.solontsov at mlp dot com]

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

--- Comment #2 from Vlad  ---
I can confirm this for gcc7.1/7.2 with -O3 -g -mavx2:
https://godbolt.org/g/h7TNJV

[Bug tree-optimization/82224] Strict-aliasing not noticing valid aliasing of two unions with active members

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-18
  Component|c   |tree-optimization
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
It's more related to PR77745.  With the testcase we are still removing the
stores that change the active union member.  They do have the same alias set
unfortunately given they use union s1s2 * in their access path.

The IL that we then up optimizing is

   [100.00%] [count: INV]:
  q[0].v1.x = 4321;
...
  _3 = &q + _2;
  _14 = MEM[(struct s1 *)&q].x;
...
  if (_15 != 0)
goto ; [33.00%] [count: INV]
  else
goto ; [67.00%] [count: INV]

   [33.00%] [count: INV]:
  MEM[(struct s2 *)_3].x = 1234;

   [100.00%] [count: INV]:
  _17 = MEM[(struct s1 *)&q].x;
...

where you can see all loads/stores being done through s1/s2 types which do
_not_ alias.

So we have

 q->v1.x = 4321; // make v1 active
 if ((&q->v1)->x) // read via pointer to active member, supposedly valid
   {
 q->v2.x = q->v1.x; // change v2 to be active, same value, optimized away
 (&q->v2)->x = 1234; // write via pointer to active member
 q->v1.x = q->v2.x; // change v1 to be active, same value, optimized away
   }
 if ((&q->v1)->x != 1234)
   abort ();

if we do not DSE the active member changing stores everything works as
desired.

Note that for GCC it isn't necessary to go through the union type when
changing the active type.  Note it definitely is desirable to elide
the load/store changing the active member in the end.

It's going to be tricky to find a solution that doesn't pessimize optimization
when unions are involved.  DOM is similarly affected, in the end it needs
sufficiently obfuscated IL to trick our "handle must-aliases conservatively"
code enough.

[Bug tree-optimization/82220] [8 Regression] SPEC CPU2006 482.sphinx3 ~10% performance regression with trunk@250416

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 10:10:31 2017
New Revision: 252917

URL: https://gcc.gnu.org/viewcvs?rev=252917&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

PR tree-optimization/82220
* tree-vect-loop.c (vect_estimate_min_profitable_iters): Exclude
epilogue niters from the min_profitable_iters compute.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/82220] [8 Regression] SPEC CPU2006 482.sphinx3 ~10% performance regression with trunk@250416

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/80920] warnings get position wrong - very confusing

[jason.vas.dias at gmail dot com]

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

--- Comment #5 from Jason Vas Dias  ---
I think if GCC cannot get the position of an error correct, 
then it should not show the position at all .

[Bug target/82108] [7 Regression] Wrong vectorized code generated for x86_64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.2.1
 Resolution|--- |FIXED

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

[Bug c++/82084] [5/6/7 Regression] ICE: constructing wstring with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 10:13:54 2017
New Revision: 252918

URL: https://gcc.gnu.org/viewcvs?rev=252918&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

Backport from mainline
2017-09-04  Richard Biener  

PR tree-optimization/82084
* fold-const.h (can_native_encode_string_p): Declare.
* fold-const.c (can_native_encode_string_p): Factor out from ...
(native_encode_string): ... here.
* tree-vect-stmts.c (vectorizable_store): Call it to avoid
vectorizing stores from constants we later cannot handle.

* g++.dg/torture/pr82084.C: New testcase.

2017-09-06  Richard Biener  

PR tree-optimization/82108
* tree-vect-stmts.c (vectorizable_load): Fix pointer adjustment
for gap in the non-permutation SLP case.

* gcc.dg/vect/pr82108.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr82084.C
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr82108.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/fold-const.c
branches/gcc-7-branch/gcc/fold-const.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-vect-stmts.c

[Bug target/82108] [7 Regression] Wrong vectorized code generated for x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 10:13:54 2017
New Revision: 252918

URL: https://gcc.gnu.org/viewcvs?rev=252918&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

Backport from mainline
2017-09-04  Richard Biener  

PR tree-optimization/82084
* fold-const.h (can_native_encode_string_p): Declare.
* fold-const.c (can_native_encode_string_p): Factor out from ...
(native_encode_string): ... here.
* tree-vect-stmts.c (vectorizable_store): Call it to avoid
vectorizing stores from constants we later cannot handle.

* g++.dg/torture/pr82084.C: New testcase.

2017-09-06  Richard Biener  

PR tree-optimization/82108
* tree-vect-stmts.c (vectorizable_load): Fix pointer adjustment
for gap in the non-permutation SLP case.

* gcc.dg/vect/pr82108.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr82084.C
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr82108.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/fold-const.c
branches/gcc-7-branch/gcc/fold-const.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/81410] [5/6 Regression] -O3 breaks code

[rguenth at gcc dot gnu.org]

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

Bug 82108 Summary: [7 Regression] Wrong vectorized code generated for x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82108

   What|Removed |Added

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

[Bug fortran/25071] dummy argument larger than actual argument

[dominiq at lps dot ens.fr]

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

--- Comment #21 from Dominique d'Humieres  ---
> Please do if you can, after testing on trunk.

I can do it if Janus unassign himself.

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
That looks risky to me, changes behavior.  Can't you instead of the warning +
removal from attributes just do something that doesn't crash when it sees an
empty string wherever it crashed?

[Bug target/62254] [5/6/7 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3

[arnd at linaro dot org]

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

--- Comment #24 from Arnd Bergmann  ---
Created attachment 42194
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42194&action=edit
r234568 ported to gcc-5

I ran into this old bug again while build testing with gcc-4.9.4 and gcc-5.4.1.
I checked that r234568 is the commit that fixed it on gcc-6, and did a trivial
backport to gcc_5_branch, which fixed it there as well.

Would this be something that could still be applied on gcc_5_branch?

[Bug target/82005] [8 regression] early lto debug creates invalid assembly on Darwin

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
(In reply to Iain Sandoe from comment #18)
> So .. just some notes on thoughts so far, not much conclusion yet.
> 
> (In reply to rguent...@suse.de from comment #17)
> > On September 16, 2017 2:37:02 PM GMT+02:00, "iains at gcc dot gnu.org"
> >  wrote:
> > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
> > >
> 
> > >... and we expect to copy that into a new file, with the 
> > >"__GNU_DWARF_LTO"
> > >renamed to __DWARF so that the content will get linked into the final
> > >debug.
> 
> So far, we've concentrated discussion on this copying, and from what I've
> looked at it's not too hard (as I read the comments, simple-object doesn't
> currently emit symbol tables for Mach-O, but it's likely we want to build a
> very basic one - containing one symbol - the identifier for this set of
> debug).  There shouldn't be any relocs in these sections, since another
> Mach-O debug opt is to elid all relocs that are just file-relative offsets
> (that's what all the .set xxx-yyy is about in the Mach-O debug).
> 
> .byte   0x2 # uleb128 0x2; (DIE (0x13b) DW_TAG_imported_unit)
> > > .quad   _pr82005_a.c.9d5291f5-Lsection__debug_info+11   # DW_AT_import
> > >
> > >^^ so is intended to resolve to the address marked "start + 11" above?
> > 
> > Yes. 
> > 
> > >.. and it's expected that the static linker will resolve that while
> > >linking the
> > >debug sections between different files, including the copy-renamed
> > >dwarf data
> > >from the original?
> > 
> > Yes.
> 
> > >(this is going to be "fun", I suspect).
> 
> So, that's where things start to get more interesting, the debug data for
> Mach-O has a number of optimisatios we need work around.
> 
> Mach-O's static linker doesn't link the debug; rather it notes what object
> files contain the debug and adds information to the exe's (or dylib's)
> symbol table about these.
> 
> then:
> 
>  (optionally) dsymutil uses that information to pick up the objects and
> _does_ link the debug into a single object
> 
>   debug consumers can use the linked debug object from dsymutil (if it's
> available) _or_ they can look at the objects table in the exe and read the
> debug from the original objects (which means that they link those on the
> fly).
> 
> So, it'e not so much the linker (ld64) that needs attention here, but more
> whether the other consumers will deal with out-of-line DIEs (I assume GDB
> will, and therefore the issues will be with dsymutil and possibly LLDB).

Note that the file we do actually end up linking in the end is temporary,
we'll remove it after the link.  The early-debug information stays in the
original object files but only in the DEBUG_LTO segment.  If we need to
patch more than GCC then a final solution should see to elide the
copying of the early debug alltogether.

> most likely ld64 will be OK with the changed files...
> ... but it's quite likely that dsymutil will not be expecting this .. so we
> might have to patch it.
> 
> symbol subtractors with an undefined symbol are not allowed, as you've
> found; However, AFAIR debug sections are 0-based, so we should be OK with
> Sym+0ffset (although this needs to be checked).

Yeah, see my hacks posted in this bug that tried to do that.

> > >At this stage, presumably, we have a single LTO TU and if there were
> > >some way
> > >to reconstruct the (copied renamed) DWARF (re-written as source) in
> > >that file
> > >that would avoid the undefined syms
> 
> this seems quite horrible to implement - although possibly achievable with
> .include in asm.

what if we'd do partial links of the temporary debug object into each of
the ltrans objects?  I would expect that ld -r _has_ to link the debug
data?  We'd end up with quite some duplicated debug that way of course
but it might make the rest of the toolchain happy?

I wonder how Darwin handles split-debug (not implemented AFAICS) or
-feliminate-dwarf2-dups (removed from trunk).  Both generate relocations
to "external" debug in some way.

> > >.. there will be one "copy-renamed" debug-only(+symtab) object for each
> > >original TU ?
> > 
> > Yes.
> 
> ..anyway, now I'm clearer about what needs doing.

Thanks.

[Bug c++/45033] "delete" does overload resolution for class operands, but shouldn't.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #4 from Paolo Carlini  ---
I think we can safely add the testcase and close the bug.

[Bug c++/80920] warnings get position wrong - very confusing

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
The caret location is just using the same info as the diagnostic message:

b.C:7:12:...

Should we suppress that too? So if you have a file with thousands of lines in,
rather than give a location that is in the right part of the right constructor,
it should not tell you where in the file it occurred? That would not be an
improvement.

And if we're showing that location anyway, the caret doesn't make it any worse.

[Bug driver/82236] New: Offloading with -fno-use-linker-plugin fails, poor diagnostics

[amonakov at gcc dot gnu.org]

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

Bug ID: 82236
   Summary: Offloading with -fno-use-linker-plugin fails, poor
diagnostics
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: lto, openacc, openmp
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

When linker plugin is not used (either due to old Binutils, or
-fno-use-linker-plugin), compiling code with offloading fails:

int main()
{
#pragma omp target
  ;
}

$ gcc -Os -fopenmp -fno-use-linker-plugin
gcc: warning: ‘-x lto’ after last input file has no effect
gcc: fatal error: no input files
compilation terminated.
lto-wrapper: fatal error: ./gcc returned 1 exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.

(even with -foffload=disable). Surprisingly, adding either -fno-lto or -flto
(huh?) suppresses the failure, but the offloading compiler is not invoked.

I think this used to "work" in simple situations and got completely broken by
fix for PR 68463. At least issuing a sensible diagnostic would be nice.

[Bug c++/80947] [6/7/8 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Paolo Carlini from comment #12)
> As far as the snippet in Comment #4 is concerned, current trunk seems fine
> to me.

Ah yes. It was fixed on trunk by r251433

[Bug sanitizer/81505] [5/6 Regression] ICE in tree-ssa-loop-manip.c:95 with -fsanitize=signed-integer-overflow

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 11:07:50 2017
New Revision: 252919

URL: https://gcc.gnu.org/viewcvs?rev=252919&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

Backport from mainline
2017-08-28  Richard Biener  

PR tree-optimization/81977
* tree-ssa-sccvn.c (vn_reference_lookup_3): Fix look through
memcpy.

* g++.dg/torture/pr81977.C: New testcase.

2017-09-04  Richard Biener  

PR tree-optimization/82084
* fold-const.h (can_native_encode_string_p): Declare.
* fold-const.c (can_native_encode_string_p): Factor out from ...
(native_encode_string): ... here.
* tree-vect-stmts.c (vectorizable_store): Call it to avoid
vectorizing stores from constants we later cannot handle.

* g++.dg/torture/pr82084.C: New testcase.

2017-07-25  Richard Biener  

PR middle-end/81505
* fold-const.c (fold_negate_const): TREE_OVERFLOW should be
sticky.

* gcc.dg/ubsan/pr81505.c: New testcase.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr81977.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr82084.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/ubsan/pr81505.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/fold-const.c
branches/gcc-6-branch/gcc/fold-const.h
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-sccvn.c
branches/gcc-6-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/81977] [5/6 Regression] Issue with inline memcpy with optimizations enabled

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 11:07:50 2017
New Revision: 252919

URL: https://gcc.gnu.org/viewcvs?rev=252919&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

Backport from mainline
2017-08-28  Richard Biener  

PR tree-optimization/81977
* tree-ssa-sccvn.c (vn_reference_lookup_3): Fix look through
memcpy.

* g++.dg/torture/pr81977.C: New testcase.

2017-09-04  Richard Biener  

PR tree-optimization/82084
* fold-const.h (can_native_encode_string_p): Declare.
* fold-const.c (can_native_encode_string_p): Factor out from ...
(native_encode_string): ... here.
* tree-vect-stmts.c (vectorizable_store): Call it to avoid
vectorizing stores from constants we later cannot handle.

* g++.dg/torture/pr82084.C: New testcase.

2017-07-25  Richard Biener  

PR middle-end/81505
* fold-const.c (fold_negate_const): TREE_OVERFLOW should be
sticky.

* gcc.dg/ubsan/pr81505.c: New testcase.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr81977.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr82084.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/ubsan/pr81505.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/fold-const.c
branches/gcc-6-branch/gcc/fold-const.h
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-sccvn.c
branches/gcc-6-branch/gcc/tree-vect-stmts.c

[Bug c++/82084] [5/6 Regression] ICE: constructing wstring with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 11:07:50 2017
New Revision: 252919

URL: https://gcc.gnu.org/viewcvs?rev=252919&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

Backport from mainline
2017-08-28  Richard Biener  

PR tree-optimization/81977
* tree-ssa-sccvn.c (vn_reference_lookup_3): Fix look through
memcpy.

* g++.dg/torture/pr81977.C: New testcase.

2017-09-04  Richard Biener  

PR tree-optimization/82084
* fold-const.h (can_native_encode_string_p): Declare.
* fold-const.c (can_native_encode_string_p): Factor out from ...
(native_encode_string): ... here.
* tree-vect-stmts.c (vectorizable_store): Call it to avoid
vectorizing stores from constants we later cannot handle.

* g++.dg/torture/pr82084.C: New testcase.

2017-07-25  Richard Biener  

PR middle-end/81505
* fold-const.c (fold_negate_const): TREE_OVERFLOW should be
sticky.

* gcc.dg/ubsan/pr81505.c: New testcase.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr81977.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr82084.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/ubsan/pr81505.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/fold-const.c
branches/gcc-6-branch/gcc/fold-const.h
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-sccvn.c
branches/gcc-6-branch/gcc/tree-vect-stmts.c

[Bug middle-end/80341] [5 Regression] gcc miscompiles division of signed char

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 11:10:06 2017
New Revision: 252920

URL: https://gcc.gnu.org/viewcvs?rev=252920&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

Backport from mainline
2017-04-07  Richard Biener  

PR middle-end/80341
* gcc.dg/torture/pr80341.c: New testcase.

2017-04-04  Richard Biener  

PR middle-end/80281
* gcc.dg/torture/pr80281.c: New testcase.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr80281.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr80341.c
Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/80281] [5 Regression] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 11:10:06 2017
New Revision: 252920

URL: https://gcc.gnu.org/viewcvs?rev=252920&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

Backport from mainline
2017-04-07  Richard Biener  

PR middle-end/80341
* gcc.dg/torture/pr80341.c: New testcase.

2017-04-04  Richard Biener  

PR middle-end/80281
* gcc.dg/torture/pr80281.c: New testcase.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr80281.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr80341.c
Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug driver/82236] Offloading with -fno-use-linker-plugin fails, poor diagnostics

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
IMHO -f[no-]use-linker-plugin should be removed and the collect2 path
"collected".

At least -f[no-]use-linker-plugin should be a noop on hosts/targets where the
linker plugin works.  People tend to shoot themselves in their foot...

[Bug target/62254] [5/6/7 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3

[arnd at linaro dot org]

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

--- Comment #25 from Arnd Bergmann  ---
(In reply to Arnd Bergmann from comment #24)
> Created attachment 42194 [details]
> r234568 ported to gcc-5
> 
> I ran into this old bug again while build testing with gcc-4.9.4 and
> gcc-5.4.1. I checked that r234568 is the commit that fixed it on gcc-6, and
> did a trivial backport to gcc_5_branch, which fixed it there as well.
> 
> Would this be something that could still be applied on gcc_5_branch?

Nevermind, that patch was incomplete, out of the two build failures I saw, one
was fixed with this patch, the other one was not.

[Bug target/81733] stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #4)
> (In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> > > --- Comment #1 from Iain Sandoe  ---
> > > Is this still current?
> > 
> > It is: just tried with a vanilla tree at r252892.

So with Eric's fix for 81361, and jamming reorder_and_partition = 0, most of
the dwarfdump --verify fails go away, but not all (and the unwinder is still
broken).   Will take a look at them later.

[Bug libstdc++/71187] declval() can be implemented without requiring a template instantiation

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Sep 18 11:40:10 2017
New Revision: 252922

URL: https://gcc.gnu.org/viewcvs?rev=252922&root=gcc&view=rev
Log:
PR libstdc++/71187 reimplement declval without add_rvalue_reference

PR libstdc++/71187
* include/std/type_traits (__declval): New function to deduce return
type of declval.
(__declval_protector::_delegate): Remove.
(declval): Use __declval instead of add_rvalue_reference and
__declval_protector::__delegate.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error
lineno.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/type_traits
trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc

[Bug c++/80947] [6/7 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[paolo.carlini at oracle dot com]

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

--- Comment #14 from Paolo Carlini  ---
I see. I'm adding the testcase, but it's still a 6/7 Regression, hopefully part
of the lambda overhaul can be easily backported.

[Bug libstdc++/71187] declval() can be implemented without requiring a template instantiation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #5 from Jonathan Wakely  ---
I've committed this change on trunk. Thanks for the suggestion.

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #15)
> That looks risky to me, changes behavior.  Can't you instead of the warning
> + removal from attributes just do something that doesn't crash when it sees
> an empty string wherever it crashed?

Yes, we can either:

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 5089013ddcd..17c98bcba8b 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -9447,7 +9447,6 @@ handle_target_attribute (tree *node, tree name, tree
args, int flags,
  && TREE_STRING_LENGTH (value) == 1
  && TREE_STRING_POINTER (value)[0] == '\0')
{
- warning (OPT_Wattributes, "empty string in attribute %");
  *no_add_attrs = true;
}
 }

That will however skip entire attribute:
__attribute__((target("sse4.2", "", "")))

Or I can do patch that will just remove empty strings in a TREE_LIST.
What way do you prefer?

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #16)
> --- a/gcc/c-family/c-common.c
> +++ b/gcc/c-family/c-common.c
> @@ -9447,7 +9447,6 @@ handle_target_attribute (tree *node, tree name, tree
> args, int flags,
> && TREE_STRING_LENGTH (value) == 1
> && TREE_STRING_POINTER (value)[0] == '\0')
>   {
> -   warning (OPT_Wattributes, "empty string in attribute %");
> *no_add_attrs = true;
>   }
>  }
> 
> That will however skip entire attribute:
> __attribute__((target("sse4.2", "", "")))
> 
> Or I can do patch that will just remove empty strings in a TREE_LIST.
> What way do you prefer?

Something that doesn't change behavior.  So the latter is better than the
former, but I wonder if just some return or continue when seeing empty string
later on isn't even easier/safer.

[Bug tree-optimization/80105] [6/7/8 Regression] ICE in outer_projection_mupa, at graphite-sese-to-poly.c:1019

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-18
 CC||spop at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
The cases I've seen this ICE hitting is when we have a conditional loop like
one resulting from unswitching of

SUBROUTINE rk_addtend_dry ( t_tend, t_tendf, t_save, rk_step, &
h_diabatic, mut, msft, ide, jde,  &
ims,ime, jms,jme, kms,kme,&
its,ite, jts,jte, kts,kte)
   IMPLICIT NONE
   INTEGER ,  INTENT(IN   ) :: ide, jde, ims, ime, jms, jme, kms, kme, &
   its, ite, jts, jte, kts, kte
   INTEGER ,  INTENT(IN   ) :: rk_step
   REAL , DIMENSION( ims:ime , kms:kme, jms:jme  ), &
   INTENT(INOUT) :: t_tend, t_tendf
   REAL , DIMENSION( ims:ime , kms:kme, jms:jme  ) , &
   INTENT(IN   ) ::  t_save, h_diabatic
   REAL , DIMENSION( ims:ime , jms:jme ) , INTENT(IN   ) :: mut, msft
   INTEGER :: i, j, k
   DO j = jts,MIN(jte,jde-1)
   DO k = kts,kte-1
   DO i = its,MIN(ite,ide-1)
 IF(rk_step == 1)t_tendf(i,k,j) = t_tendf(i,k,j) +  t_save(i,k,j)
  t_tend(i,k,j) =  t_tend(i,k,j) +  t_tendf(i,k,j)/msft(i,j)  &
 +  mut(i,j)*h_diabatic(i,k,j)/msft(i,j)
   ENDDO
   ENDDO
   ENDDO
END SUBROUTINE rk_addtend_dry

not sure if we are supposed to handle this or not.  But it seems like
in case ISL gets confused enough we end up with an empty scheduling domain
which we assert on.

The "easy" way is proagating the error up along build_original_schedule ->
build_poly_scop but eventually we can detect this earlier?

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #17)
> (In reply to Martin Liška from comment #16)
> > --- a/gcc/c-family/c-common.c
> > +++ b/gcc/c-family/c-common.c
> > @@ -9447,7 +9447,6 @@ handle_target_attribute (tree *node, tree name, tree
> > args, int flags,
> >   && TREE_STRING_LENGTH (value) == 1
> >   && TREE_STRING_POINTER (value)[0] == '\0')
> > {
> > - warning (OPT_Wattributes, "empty string in attribute %");
> >   *no_add_attrs = true;
> > }
> >  }
> > 
> > That will however skip entire attribute:
> > __attribute__((target("sse4.2", "", "")))
> > 
> > Or I can do patch that will just remove empty strings in a TREE_LIST.
> > What way do you prefer?
> 
> Something that doesn't change behavior.  So the latter is better than the
> former, but I wonder if just some return or continue when seeing empty
> string later on isn't even easier/safer.

Well, for this purpose, maybe the original patch can be handy:
https://patchwork.ozlabs.org/patch/794801/ ?

[Bug c++/45033] "delete" does overload resolution for class operands, but shouldn't.

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Sep 18 12:08:14 2017
New Revision: 252924

URL: https://gcc.gnu.org/viewcvs?rev=252924&root=gcc&view=rev
Log:
2017-09-18  Paolo Carlini  

PR c++/45033
* g++.dg/expr/delete1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/expr/delete1.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/45033] "delete" does overload resolution for class operands, but shouldn't.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

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

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

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

--- Comment #49 from Dominique d'Humieres  ---
The patch at https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html is still
needed after revision r252914 (fix for pr81361).

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[marxin at gcc dot gnu.org]

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

--- Comment #19 from Martin Liška  ---
(In reply to Martin Liška from comment #18)
> (In reply to Jakub Jelinek from comment #17)
> > (In reply to Martin Liška from comment #16)
> > > --- a/gcc/c-family/c-common.c
> > > +++ b/gcc/c-family/c-common.c
> > > @@ -9447,7 +9447,6 @@ handle_target_attribute (tree *node, tree name, tree
> > > args, int flags,
> > > && TREE_STRING_LENGTH (value) == 1
> > > && TREE_STRING_POINTER (value)[0] == '\0')
> > >   {
> > > -   warning (OPT_Wattributes, "empty string in attribute %");
> > > *no_add_attrs = true;
> > >   }
> > >  }
> > > 
> > > That will however skip entire attribute:
> > > __attribute__((target("sse4.2", "", "")))
> > > 
> > > Or I can do patch that will just remove empty strings in a TREE_LIST.
> > > What way do you prefer?
> > 
> > Something that doesn't change behavior.  So the latter is better than the
> > former, but I wonder if just some return or continue when seeing empty
> > string later on isn't even easier/safer.
> 
> Well, for this purpose, maybe the original patch can be handy:
> https://patchwork.ozlabs.org/patch/794801/ ?

This one works for some situations, however it's quite painful to handle it
properly, for instance:

$ cat /tmp/ice.C
__attribute__((target("default")))
int foo() {return 99;}
__attribute__((target("sse4.2","")))
int foo() {return 1;}
__attribute__((target("","")))
int foo() {return 1;}

int main() {
return foo();
}

$ ./xg++ -B. /tmp/ice.C -S -c
/tmp/ice.C: In function ‘’:
/tmp/ice.C:6:5: error: No dispatcher found for the versioning attributes : 
 int foo() {return 1;}
 ^~~

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
That would be my preference (perhaps even for GCC 7, only do the warning and
attribute removal on the trunk).

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

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

--- Comment #50 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #49)
> The patch at https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00045.html is
> still needed after revision r252914 (fix for pr81361).

Yes, that's expected at present.
a. there's evidently some more EH breakage caused by the reorder-and-partition
(see 81733)
b. the libgcc unwinder seems to have some issues even on systems that should
support it
c. we need to do some checking on the availability of the kernel call to fetch
the FDEs and setup the specs accordingly.

 -static-libstdc++ is a workaround (actually, all it's really doing is
overriding the -static-libgcc).

IMO we need to get to the bottom of the various breakages, and preferably fix
them properly - rather than applying a band-aid patch to place libSystem ahead
of libgcc_eh.

[Bug target/81733] stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > (In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> > > > --- Comment #1 from Iain Sandoe  ---
> > > > Is this still current?
> > > 
> > > It is: just tried with a vanilla tree at r252892.
> 
> So with Eric's fix for 81361, and jamming reorder_and_partition = 0, most of
> the dwarfdump --verify fails go away, but not all (and the unwinder is still
> broken).   Will take a look at them later.

some of the verify fails seem to be caused by the ancient dwarfdump not being
smart enough; ld64 and BINUTILS objdump seem to be happy that the FDEs are
well-formed (more checking to be done)

[Bug libstdc++/60936] [5/6 Regression] Binary code bloat with std::string

[redi at gcc dot gnu.org]

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

--- Comment #36 from Jonathan Wakely  ---
Author: redi
Date: Mon Sep 18 12:57:05 2017
New Revision: 252925

URL: https://gcc.gnu.org/viewcvs?rev=252925&root=gcc&view=rev
Log:
PR libstdc++/60936 reduce coupling between objects in libstdc++.a

Backport from mainline
2017-02-03  Jonathan Wakely  

PR libstdc++/60936
* src/c++11/Makefile.am: Add new files.
* src/c++11/Makefile.in: Regenerate.
* src/c++11/cow-string-inst.cc [!_GLIBCXX_USE_CXX11_ABI]
(operator<<, operator>>, getline): Move explicit instantiations to ...
* src/c++11/cow-string-io-inst.cc: ... new file.
* src/c++11/cow-wstring-inst.cc [!_GLIBCXX_USE_CXX11_ABI]
(operator<<, operator>>, getline): Move explicit instantiations to ...
* src/c++11/cow-wstring-io-inst.cc: ... new file.
* src/c++11/functexcept.cc (__throw_ios_failure, __throw_system_error)
(__throw_future_error, __throw_bad_function_call):
(__throw_regex_error): Move functions for C++11 exceptions to the
files that define the exception types.
* src/c++11/functional.cc (__throw_bad_function_call): Move here.
* src/c++11/future.cc (__throw_future_error): Likewise.
* src/c++11/ios.cc (__throw_ios_failure): Likewise.
* src/c++11/regex.cc (__throw_regex_error): Likewise.
* src/c++11/snprintf_lite.cc (__concat_size_t): Print decimal
representation directly instead of calling __int_to_char.
* src/c++11/sso_string.cc (__sso_string): New file for definition
of __sso_string type.
* src/c++11/string-io-inst.cc [_GLIBCXX_USE_CXX11_ABI]: New file for
explicit instantiations of narrow string I/O functions.
* src/c++11/system_error.cc (__throw_system_error): Move here.
(__sso_string): Move to new file.
* src/c++11/wstring-io-inst.cc [_GLIBCXX_USE_CXX11_ABI]: New file for
explicit instantiations of wide string I/O functions.
* src/c++98/misc-inst.cc [_GLIBCXX_USE_CXX11_ABI] (operator<<)
(operator>>, getline): Remove explicit instantiations from here.

Added:
branches/gcc-6-branch/libstdc++-v3/src/c++11/cow-string-io-inst.cc
  - copied, changed from r252920,
branches/gcc-6-branch/libstdc++-v3/src/c++11/cow-wstring-inst.cc
branches/gcc-6-branch/libstdc++-v3/src/c++11/cow-wstring-io-inst.cc
  - copied, changed from r252920,
branches/gcc-6-branch/libstdc++-v3/src/c++11/cow-wstring-inst.cc
branches/gcc-6-branch/libstdc++-v3/src/c++11/sso_string.cc
  - copied, changed from r252920,
branches/gcc-6-branch/libstdc++-v3/src/c++11/system_error.cc
branches/gcc-6-branch/libstdc++-v3/src/c++11/string-io-inst.cc
  - copied, changed from r252920,
branches/gcc-6-branch/libstdc++-v3/src/c++11/functional.cc
branches/gcc-6-branch/libstdc++-v3/src/c++11/wstring-io-inst.cc
  - copied, changed from r252920,
branches/gcc-6-branch/libstdc++-v3/src/c++11/cow-wstring-inst.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/src/c++11/Makefile.am
branches/gcc-6-branch/libstdc++-v3/src/c++11/Makefile.in
branches/gcc-6-branch/libstdc++-v3/src/c++11/cow-string-inst.cc
branches/gcc-6-branch/libstdc++-v3/src/c++11/cow-wstring-inst.cc
branches/gcc-6-branch/libstdc++-v3/src/c++11/functexcept.cc
branches/gcc-6-branch/libstdc++-v3/src/c++11/functional.cc
branches/gcc-6-branch/libstdc++-v3/src/c++11/future.cc
branches/gcc-6-branch/libstdc++-v3/src/c++11/ios.cc
branches/gcc-6-branch/libstdc++-v3/src/c++11/regex.cc
branches/gcc-6-branch/libstdc++-v3/src/c++11/snprintf_lite.cc
branches/gcc-6-branch/libstdc++-v3/src/c++11/system_error.cc
branches/gcc-6-branch/libstdc++-v3/src/c++98/misc-inst.cc

[Bug libstdc++/60936] [5 Regression] Binary code bloat with std::string

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2015-04-15 00:00:00 |2017-9-18
  Known to work||4.8.5, 6.4.1, 7.1.0
Summary|[5/6 Regression] Binary |[5 Regression] Binary code
   |code bloat with std::string |bloat with std::string
  Known to fail|4.9.0, 4.9.1, 4.9.2, 5.0,   |4.9.4, 5.4.0, 6.4.0
   |6.1.0, 6.2.0|

--- Comment #37 from Jonathan Wakely  ---
Fixed for 6.5 as well. I'm probably not going to change this on the
gcc-5-branch though.

[Bug tree-optimization/69728] [6/7/8 Regression] internal compiler error: in outer_projection_mupa, at graphite-sese-to-poly.c:1175

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #13 from Richard Biener  ---
A "simple" patch like the following seems to "work".

Index: gcc/graphite-sese-to-poly.c
===
--- gcc/graphite-sese-to-poly.c (revision 252920)
+++ gcc/graphite-sese-to-poly.c (working copy)
@@ -1043,6 +1043,13 @@ add_loop_schedule (__isl_take isl_schedu
   if (empty < 0 || empty)
 return empty < 0 ? isl_schedule_free (schedule) : schedule;

+  isl_union_set *domain = isl_schedule_get_domain (schedule);
+  if (isl_union_set_is_empty (domain))
+{
+  isl_union_set_free (domain);
+  return schedule;
+}
+
   isl_space *space = isl_set_get_space (iterators);
   int loop_index = isl_space_dim (space, isl_dim_set) - 1;

@@ -1063,7 +1070,6 @@ add_loop_schedule (__isl_take isl_schedu
   prefix = isl_multi_aff_set_tuple_id (prefix, isl_dim_out, label);

   int n = isl_multi_aff_dim (prefix, isl_dim_in);
-  isl_union_set *domain = isl_schedule_get_domain (schedule);
   isl_multi_union_pw_aff *mupa = outer_projection_mupa (domain, n);
   mupa = isl_multi_union_pw_aff_apply_multi_aff (mupa, prefix);
   return isl_schedule_insert_partial_schedule (schedule, mupa);


but it results in a bougs initial schedule:

[scheduler] original ast:
{
  for (int c0 = 0; c0 < -P_21; c0 += 1) {
S_9(c0);
if (P_21 + c0 <= -2)
  S_8(c0);
  }
  S_10();
}

so the conditional loop ended up not being a loop.  I believe in this
case we are somehow confused by 'c' wrapping?  niter is computed
as -(unsigned int) (c.7_21 + 1).  Can we really "handle" negating
an unsigned value?

static isl_pw_aff *
extract_affine (scop_p s, tree e, __isl_take isl_space *space)
{
..
case NEGATE_EXPR:
case BIT_NOT_EXPR:
  lhs = extract_affine (s, TREE_OPERAND (e, 0), isl_space_copy (space));
  rhs = extract_affine (s, integer_minus_one_node, space);
  res = isl_pw_aff_mul (lhs, rhs);
  break;

so we do x * -1 for negate -- that looks ok.  At least bogus for
BIT_NOT_EXPR which is really -1 - x, not x * -1.

Doesn't seem to handle any conversion to signed correctly either as it
misses an appropriate 'wrap' operation (the existing one only works
for unsigned).  The offset argument in POINTER_PLUS_EXPR handling needs
to be interpreted as signed.

So for the ICE I now have the hackish

Index: gcc/graphite-sese-to-poly.c
===
--- gcc/graphite-sese-to-poly.c (revision 252920)
+++ gcc/graphite-sese-to-poly.c (working copy)
@@ -1030,6 +1035,8 @@ outer_projection_mupa (__isl_take isl_un
   return isl_multi_union_pw_aff_from_union_pw_multi_aff (data.res);
 }

+static bool schedule_error;
+
 /* Embed SCHEDULE in the constraints of the LOOP domain.  */

 static isl_schedule *
@@ -1043,6 +1050,14 @@ add_loop_schedule (__isl_take isl_schedu
   if (empty < 0 || empty)
 return empty < 0 ? isl_schedule_free (schedule) : schedule;

+  isl_union_set *domain = isl_schedule_get_domain (schedule);
+  if (isl_union_set_is_empty (domain))
+{
+  schedule_error = true;
+  isl_union_set_free (domain);
+  return schedule;
+}
+
   isl_space *space = isl_set_get_space (iterators);
   int loop_index = isl_space_dim (space, isl_dim_set) - 1;

@@ -1169,6 +1183,8 @@ build_schedule_loop_nest (scop_p scop, i
 static bool
 build_original_schedule (scop_p scop)
 {
+  schedule_error = false;
+
   int i = 0;
   int n = scop->pbbs.length ();
   while (i < n)
@@ -1183,6 +1199,14 @@ build_original_schedule (scop_p scop)
   scop->original_schedule = add_in_sequence (scop->original_schedule, s);
 }

+  if (schedule_error)
+{
+  if (dump_file)
+   fprintf (dump_file, "[sese-to-poly] failed to build "
+"original schedule\n");
+  return false;
+}
+
   if (dump_file)
 {
   fprintf (dump_file, "[sese-to-poly] original schedule:\n");

[Bug tree-optimization/80171] [5 Regression] ICE (Segmentation fault) with optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 13:14:45 2017
New Revision: 252926

URL: https://gcc.gnu.org/viewcvs?rev=252926&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

Backport from mainline
2017-04-10  Richard Biener  

PR middle-end/80362
* fold-const.c (fold_binary_loc): Look at unstripped ops when
looking for NEGATE_EXPR in -A / -B to A / B folding.

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

2015-11-25  Richard Biener  

PR middle-end/68528
* fold-const.c (fold_binary_loc): Do not call negate_expr_p
on stripped operands.

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

2017-03-27  Richard Biener  

PR middle-end/80171
* gimple-fold.c (fold_ctor_reference): Properly guard against
NULL return value from canonicalize_constructor_val.

* g++.dg/torture/pr80171.C: New testcase.

2016-06-13  Richard Biener  

PR middle-end/64516
* fold-const.c (fold_unary_loc): Preserve alignment when
folding a VIEW_CONVERT_EXPR into a MEM_REF.

* gcc.dg/align-3.c: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/torture/pr80171.C
branches/gcc-5-branch/gcc/testsuite/gcc.dg/align-3.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr68528.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr80362.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/fold-const.c
branches/gcc-5-branch/gcc/gimple-fold.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/68528] [5 Only] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||5.4.1
 Resolution|--- |FIXED
  Known to fail||5.4.0

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 13:14:45 2017
New Revision: 252926

URL: https://gcc.gnu.org/viewcvs?rev=252926&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

Backport from mainline
2017-04-10  Richard Biener  

PR middle-end/80362
* fold-const.c (fold_binary_loc): Look at unstripped ops when
looking for NEGATE_EXPR in -A / -B to A / B folding.

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

2015-11-25  Richard Biener  

PR middle-end/68528
* fold-const.c (fold_binary_loc): Do not call negate_expr_p
on stripped operands.

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

2017-03-27  Richard Biener  

PR middle-end/80171
* gimple-fold.c (fold_ctor_reference): Properly guard against
NULL return value from canonicalize_constructor_val.

* g++.dg/torture/pr80171.C: New testcase.

2016-06-13  Richard Biener  

PR middle-end/64516
* fold-const.c (fold_unary_loc): Preserve alignment when
folding a VIEW_CONVERT_EXPR into a MEM_REF.

* gcc.dg/align-3.c: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/torture/pr80171.C
branches/gcc-5-branch/gcc/testsuite/gcc.dg/align-3.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr68528.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr80362.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/fold-const.c
branches/gcc-5-branch/gcc/gimple-fold.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

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

[Bug middle-end/64516] [5 Regression] arm: wrong unaligned load generated

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 13:14:45 2017
New Revision: 252926

URL: https://gcc.gnu.org/viewcvs?rev=252926&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

Backport from mainline
2017-04-10  Richard Biener  

PR middle-end/80362
* fold-const.c (fold_binary_loc): Look at unstripped ops when
looking for NEGATE_EXPR in -A / -B to A / B folding.

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

2015-11-25  Richard Biener  

PR middle-end/68528
* fold-const.c (fold_binary_loc): Do not call negate_expr_p
on stripped operands.

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

2017-03-27  Richard Biener  

PR middle-end/80171
* gimple-fold.c (fold_ctor_reference): Properly guard against
NULL return value from canonicalize_constructor_val.

* g++.dg/torture/pr80171.C: New testcase.

2016-06-13  Richard Biener  

PR middle-end/64516
* fold-const.c (fold_unary_loc): Preserve alignment when
folding a VIEW_CONVERT_EXPR into a MEM_REF.

* gcc.dg/align-3.c: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/torture/pr80171.C
branches/gcc-5-branch/gcc/testsuite/gcc.dg/align-3.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr68528.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr80362.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/fold-const.c
branches/gcc-5-branch/gcc/gimple-fold.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/80362] [5 Regression] gcc miscompiles arithmetic with signed char

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 13:14:45 2017
New Revision: 252926

URL: https://gcc.gnu.org/viewcvs?rev=252926&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

Backport from mainline
2017-04-10  Richard Biener  

PR middle-end/80362
* fold-const.c (fold_binary_loc): Look at unstripped ops when
looking for NEGATE_EXPR in -A / -B to A / B folding.

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

2015-11-25  Richard Biener  

PR middle-end/68528
* fold-const.c (fold_binary_loc): Do not call negate_expr_p
on stripped operands.

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

2017-03-27  Richard Biener  

PR middle-end/80171
* gimple-fold.c (fold_ctor_reference): Properly guard against
NULL return value from canonicalize_constructor_val.

* g++.dg/torture/pr80171.C: New testcase.

2016-06-13  Richard Biener  

PR middle-end/64516
* fold-const.c (fold_unary_loc): Preserve alignment when
folding a VIEW_CONVERT_EXPR into a MEM_REF.

* gcc.dg/align-3.c: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/torture/pr80171.C
branches/gcc-5-branch/gcc/testsuite/gcc.dg/align-3.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr68528.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr80362.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/fold-const.c
branches/gcc-5-branch/gcc/gimple-fold.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/68528] [5 Only] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 18 13:14:45 2017
New Revision: 252926

URL: https://gcc.gnu.org/viewcvs?rev=252926&root=gcc&view=rev
Log:
2017-09-18  Richard Biener  

Backport from mainline
2017-04-10  Richard Biener  

PR middle-end/80362
* fold-const.c (fold_binary_loc): Look at unstripped ops when
looking for NEGATE_EXPR in -A / -B to A / B folding.

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

2015-11-25  Richard Biener  

PR middle-end/68528
* fold-const.c (fold_binary_loc): Do not call negate_expr_p
on stripped operands.

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

2017-03-27  Richard Biener  

PR middle-end/80171
* gimple-fold.c (fold_ctor_reference): Properly guard against
NULL return value from canonicalize_constructor_val.

* g++.dg/torture/pr80171.C: New testcase.

2016-06-13  Richard Biener  

PR middle-end/64516
* fold-const.c (fold_unary_loc): Preserve alignment when
folding a VIEW_CONVERT_EXPR into a MEM_REF.

* gcc.dg/align-3.c: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/torture/pr80171.C
branches/gcc-5-branch/gcc/testsuite/gcc.dg/align-3.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr68528.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr80362.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/fold-const.c
branches/gcc-5-branch/gcc/gimple-fold.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/68528] [5 Only] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||5.4.1
 Resolution|--- |FIXED
  Known to fail||5.4.0

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

[Bug middle-end/80362] [5 Regression] gcc miscompiles arithmetic with signed char

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||5.4.1
 Resolution|--- |FIXED
  Known to fail||5.4.0

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

[Bug tree-optimization/80171] [5 Regression] ICE (Segmentation fault) with optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||5.4.1
 Resolution|--- |FIXED
  Known to fail|5.4.1   |5.4.0

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

[Bug middle-end/64516] [5 Regression] arm: wrong unaligned load generated

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||5.4.1
 Resolution|--- |FIXED
  Known to fail||5.4.0

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

[Bug tree-optimization/69728] [6/7/8 Regression] internal compiler error: in outer_projection_mupa, at graphite-sese-to-poly.c:1175

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
*** Bug 80105 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/80105] [6/7/8 Regression] ICE in outer_projection_mupa, at graphite-sese-to-poly.c:1019

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

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

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

[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues

[rguenth at gcc dot gnu.org]

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

Bug 80105 Summary: [6/7/8 Regression] ICE in outer_projection_mupa, at 
graphite-sese-to-poly.c:1019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80105

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

[Bug target/81733] stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #6)
> (In reply to Iain Sandoe from comment #5)
> > (In reply to Iain Sandoe from comment #4)
> > > (In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> > > > > --- Comment #1 from Iain Sandoe  ---
> > > > > Is this still current?
> > > > 
> > > > It is: just tried with a vanilla tree at r252892.
> > 
> > So with Eric's fix for 81361, and jamming reorder_and_partition = 0, most of
> > the dwarfdump --verify fails go away, but not all (and the unwinder is still
> > broken).   Will take a look at them later.
> 
> some of the verify fails seem to be caused by the ancient dwarfdump not
> being smart enough; ld64 and BINUTILS objdump seem to be happy that the FDEs
> are well-formed (more checking to be done)

however (on 10.11.6), a trivial c++ try catch, succeeds -static-libgcc with 7.2
but not with trunk.. and the c++ code is essentially unchanged.

[Bug rtl-optimization/82237] New: [AArch64] Destructive operations result in poor register allocation after scheduling

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 82237
   Summary: [AArch64] Destructive operations result in poor
register allocation after scheduling
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org
  Target Milestone: ---

A destructive operation is one in which an input operand is both read and
written. For example, in the vector FMLA instruction in AArch64:

  FMLA v0.4s, v1.4s, v2.4s

The first operand is used for the accumulator value (the operation is v0 = v0 +
v1 * v2) and is both read and written by the instruction.

In RTL terms, this is:

  (define_insn "fma4"
[(set (match_operand:VHSDF 0 "register_operand" "=w")
 (fma:VHSDF (match_operand:VHSDF 1 "register_operand" "w")
  (match_operand:VHSDF 2 "register_operand" "w")
(match_operand:VHSDF 3 "register_operand" "0")))]
"TARGET_SIMD"
   "fmla\\t%0., %1., %2."
[(set_attr "type" "neon_fp_mla_")]
  )

from config/aarch64/aarch64-simd.md .

We can get suboptimal code where a read/write operand is used both by a
destructive operation, and a non-destructive operation, and the destructive
operation is scheduled before the non-destructive operation. For example, with
this auto-vectorizable code (with trunk, -O3 -mcpu=cortex-a57):

  void
  foo (float* __restrict__ in1, float* __restrict__ in2,
   float* __restrict__ out1, float* __restrict__ out2)
  {
for (int i = 0; i < 1024; i++)
  {
float t = out1[i];
out1[i] = t + in1[i] * in2[i];
out2[i] = t + in1[i];
  }
  }

ldr q1, [x2, x4]
ldr q0, [x0, x4]
ldr q2, [x1, x4]
mov v3.16b, v1.16b  // << 1)
fmlav3.4s, v2.4s, v0.4s // << 2)
faddv0.4s, v0.4s, v1.4s // << 3)
str q3, [x2, x4]
str q0, [x3, x4]


The scheduling of 2) before 3) forces a reload from v1 in to v3 at 1). With an
improved schedule, this could be:

ldr q1, [x2, x4]
ldr q0, [x0, x4]
ldr q2, [x1, x4]
faddv4.4s, v0.4s, v1.4s // << 3)
fmlav3.4s, v2.4s, v0.4s // << 2)
str q3, [x2, x4]
str q4, [x3, x4]

In larger loops, we can end up in this situation more frequently than we would
like - the cost of the extra move instructions can be high.

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[arnd at linaro dot org]

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

--- Comment #4 from Arnd Bergmann  ---
Created attachment 42195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42195&action=edit
preprocessed net/wireless/nl80211.c, compressed

This is another file that shows the problem, in fact we hit this with every
allmodconfig build using gcc-5 through gcc-8.0.0:

/home/arnd/cross-gcc/bin/x86_64-linux-gcc-5.4.1 -c nl80211.i -O2  --std=gnu89
-Wall -Wno-unused -Wno-pointer-sign -Wframe-larger-than=1024
-fno-strict-aliasing -fno-strict-overflow -fsanitize=kernel-address --param
asan-stack=1  -fconserve-stack/git/arm-soc/net/wireless/nl80211.c: In function
'nl80211_add_commands_unsplit':
/git/arm-soc/net/wireless/nl80211.c:1411:1: warning: the frame size of 2208
bytes is larger than 1024 bytes [-Wframe-larger-than=]
 }
 ^
/git/arm-soc/net/wireless/nl80211.c: In function 'nl80211_get_mesh_config':
/git/arm-soc/net/wireless/nl80211.c:5779:1: warning: the frame size of 2048
bytes is larger than 1024 bytes [-Wframe-larger-than=]
 }
 ^
/git/arm-soc/net/wireless/nl80211.c: In function 'nl80211_send_wiphy':
/git/arm-soc/net/wireless/nl80211.c:1905:1: warning: the frame size of 3856
bytes is larger than 1024 bytes [-Wframe-larger-than=]
 }
...
/git/arm-soc/net/wireless/nl80211.c: In function
'nl80211_send_station.isra.47':
/git/arm-soc/net/wireless/nl80211.c:4476:1: warning: the frame size of 2240
bytes is larger than 1024 bytes [-Wframe-larger-than=]
 }
 ^
/git/arm-soc/net/wireless/nl80211.c: In function 'nl80211_dump_station':
/git/arm-soc/net/wireless/nl80211.c:4529:1: warning: the frame size of 1168
bytes is larger than 1024 bytes [-Wframe-larger-than=]
 }
 ^
/git/arm-soc/net/wireless/nl80211.c: In function 'nl80211_dump_scan':
/git/arm-soc/net/wireless/nl80211.c:7837:1: warning: the frame size of 1280
bytes is larger than 1024 bytes [-Wframe-larger-than=]
 }

In comparison:
/home/arnd/cross-gcc/bin/clang -c nl80211.i -O2 --std=gnu89 -Wno-gnu -Wall
-Wno-unused -Wno-pointer-sign -Wno-tautological-compare
-Wno-constant-logical-operand -no-integrated-as -Wframe-larger-than=1024
-fsanitize=kernel-address -mllvm -asan-stack=1
/git/arm-soc/net/wireless/nl80211.c:1420:12: warning: stack frame size of 1816
bytes in function 'nl80211_send_wiphy'
  [-Wframe-larger-than=]
static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
   ^
/git/arm-soc/net/wireless/nl80211.c:14117:6: warning: stack frame size of 1112
bytes in function
  'cfg80211_del_sta_sinfo' [-Wframe-larger-than=]
void cfg80211_del_sta_sinfo(struct net_device *dev, const u8 *mac_addr,
 ^
/git/arm-soc/net/wireless/nl80211.c:9717:12: warning: stack frame size of 1144
bytes in function
  'cfg80211_cqm_rssi_update' [-Wframe-larger-than=]
static int cfg80211_cqm_rssi_update(struct cfg80211_registered_device *rdev,
   ^
/git/arm-soc/net/wireless/nl80211.c:4531:12: warning: stack frame size of 1112
bytes in function 'nl80211_get_station'
  [-Wframe-larger-than=]
static int nl80211_get_station(struct sk_buff *skb, struct genl_info *info)
   ^
/git/arm-soc/net/wireless/nl80211.c:4478:12: warning: stack frame size of 1240
bytes in function
  'nl80211_dump_station' [-Wframe-larger-than=]
static int nl80211_dump_station(struct sk_buff *skb,

The proposed workaround in the kernel is
https://patchwork.kernel.org/patch/9787449/, but it would be good to not need
this for future compilers.

[Bug rtl-optimization/82237] [AArch64] Destructive operations result in poor register allocation after scheduling

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Target||aarch64*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-18
 Ever confirmed|0   |1

[Bug libstdc++/60936] [5 Regression] Binary code bloat with std::string

[meisenmann....@fh-salzburg.ac.at]

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

--- Comment #38 from Markus Eisenmann  ---
Hi Jonathan!

It seems, that the minor change/fix from comment #31 (rev. 245505) is currently
missing in branches/gcc-6-branch/libstdc++-v3/src/c++11/snprintf_lite.cc; needs
also to be merged into this.

Best regards from Salzburg,
Markus

[Bug tree-optimization/69728] [6/7/8 Regression] internal compiler error: in outer_projection_mupa, at graphite-sese-to-poly.c:1175

[spop at gcc dot gnu.org]

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

--- Comment #15 from Sebastian Pop  ---
It makes sense to early fail when the schedule builder gets confused and built
an empty domain.  Could you please also add a comment around the if that sets
schedule_error?  The change looks good.  Thanks.

[Bug target/81733] stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #7)
> (In reply to Iain Sandoe from comment #6)
> > (In reply to Iain Sandoe from comment #5)
> > > (In reply to Iain Sandoe from comment #4)
> > > > (In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> > > > > > --- Comment #1 from Iain Sandoe  ---
> > > > > > Is this still current?
> > > > > 
> > > > > It is: just tried with a vanilla tree at r252892.
> > > 
> > > So with Eric's fix for 81361, and jamming reorder_and_partition = 0, most 
> > > of
> > > the dwarfdump --verify fails go away, but not all (and the unwinder is 
> > > still
> > > broken).   Will take a look at them later.
> > 
> > some of the verify fails seem to be caused by the ancient dwarfdump not
> > being smart enough; ld64 and BINUTILS objdump seem to be happy that the FDEs
> > are well-formed (more checking to be done)
> 
> however (on 10.11.6), a trivial c++ try catch, succeeds -static-libgcc with
> 7.2 but not with trunk.. and the c++ code is essentially unchanged.

NM, false measurement, not 100% comparable tests.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[ro at gcc dot gnu.org]

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

--- Comment #18 from Rainer Orth  ---
Created attachment 42196
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42196&action=edit
Hacky workaround

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #17 from rguenther at suse dot de  ---
[...]
>>That worked just fine, thanks.
>>
>>While there are still ld warnings
>>
>>ld: warning: file /var/tmp//ccmgPmhadebugobjtem: section [2] has
>>invalid type [
>>SHT_NULL ]
>>
>>ro@lucy 87 > elfdump -c -I 2 cc2qd7lbdebugobjtem 
>>cc2qd7lbdebugobjtem: : invalid sh_type: 0
>>
>>Section Header[2]:  sh_name: 
>>sh_addr:  0   sh_flags:   [ SHF_EXCLUDE ]
>>sh_size:  0   sh_type:[ SHT_NULL ]
>>sh_offset:0x4980  sh_entsize: 0
>>sh_link:  0   sh_info:0
>>sh_addralign: 0x10  
>>
>>and there's no way to silence them from the ld command line, I should
>>be
>>able to prune them for the testsuite at least.
>
> Can you report this issue to the Solaris folks? 

I'd already done so upon the first early lto debug failures.  The ld
SEGV for a symtab referencing an non-string table is already fixed
upstream, but it's unclear when this will be generally available and
older versions (especially Solaris 10) will almost certainly remain
unfixed.

>   However, the final link
>>fails:
>>
>>Undefined   first referenced
>> symbol in file
>>__gnu_lto_v1/var/tmp//ccQylLjddebugobj
>>
>>It turns out that __gnu_lto_v1 in the original object
>>
>>[336] 0x10x1  OBJT GLOB  D0 COMMON 
>>__gnu_lto_v1
>>
>>remains in the one produced by lto-wrapper:
>>
>>  [339]  00  NOTY GLOB  D0 UNDEF   __gnu_lto_v1
>>
>>Need to check what's going on here...
>
> How does it fail? The symbol should be unused...

With the link failure due to undefined __gnu_lto_v1 cited above.  I'd
argue that ld behaves exactly as expected: it tries to resolve the
undefined symbols, cannot find a definition, and stops.

I've had some success with the attached patch, which discards symbols by
marking them weak.  On top of that, right now I need to prune tons of ld
warnings like

ld: warning: file /var/tmp//ccv3Kl9adebugobjtem: section [1] has invalid type [
SHT_NULL ]

(already mentioned) and

ld: warning: file /var/tmp//ccv3Kl9adebugobjtem: section [34].symtab:
symbol[2]:
 global symbol has no name

Pruning the messages is a hack to see how we stand, but certainly not an
option for production use.

Rainer

[Bug demangler/82195] Undemangleable lambda

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #6 from Nathan Sidwell  ---
I flubbed the toplevel case.

[Bug c++/54367] [meta-bug] lambda expressions

[nathan at gcc dot gnu.org]

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

Bug 82195 Summary: Undemangleable lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82195

   What|Removed |Added

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

[Bug tree-optimization/79622] [6/7 Regression] Wrong code w/ -O2 -floop-nest-optimize

[spop at gcc dot gnu.org]

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

--- Comment #8 from Sebastian Pop  ---
> I would have expected at least each memory op to be in a separate "black box"

We could have a pass before graphite that splits BBs with more than one write
into blocks that contain one data write with all the operations and data reads
needed to compute the stored value.  This would allow more freedom to schedule
BBs around.

> if you follow the original go-out-of-SSA approach you'd have their effects
> on the CFG edges.  So a more complete fix would similarly handle uses.

In other words: how do we handle reductions?
As you remember, the original way was to expose reductions by rewriting
out-of-SSA
scalar dependences crossing basic blocks (loop-phi nodes, loop-close-phi
nodes,)
tagging the properties of the reduction (commutative, associative)
on the array, and adding that info to the data dependence graph.
By adding those properties to the dependence graph, we give the scheduler
more freedom to select transforms.

We moved away from rewriting scalar dependences out-of-SSA because we do not
want to transform the code if the scheduler has no better transform to be done:
we do not want to leave around inefficient memory reads/writes.
Instead, we handle SSA names and create scalar references added to the
dependence graph.  We still need to tag scalar reductions with their
associative properties to allow the scheduler to reorder the computations.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenther at suse dot de]

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

--- Comment #20 from rguenther at suse dot de  ---
On Mon, 18 Sep 2017, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
> 
> --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
> > --- Comment #17 from rguenther at suse dot de  ---
> [...]
> >>That worked just fine, thanks.
> >>
> >>While there are still ld warnings
> >>
> >>ld: warning: file /var/tmp//ccmgPmhadebugobjtem: section [2] has
> >>invalid type [
> >>SHT_NULL ]
> >>
> >>ro@lucy 87 > elfdump -c -I 2 cc2qd7lbdebugobjtem 
> >>cc2qd7lbdebugobjtem: : invalid sh_type: 0
> >>
> >>Section Header[2]:  sh_name: 
> >>sh_addr:  0   sh_flags:   [ SHF_EXCLUDE ]
> >>sh_size:  0   sh_type:[ SHT_NULL ]
> >>sh_offset:0x4980  sh_entsize: 0
> >>sh_link:  0   sh_info:0
> >>sh_addralign: 0x10  
> >>
> >>and there's no way to silence them from the ld command line, I should
> >>be
> >>able to prune them for the testsuite at least.
> >
> > Can you report this issue to the Solaris folks? 
> 
> I'd already done so upon the first early lto debug failures.  The ld
> SEGV for a symtab referencing an non-string table is already fixed
> upstream, but it's unclear when this will be generally available and
> older versions (especially Solaris 10) will almost certainly remain
> unfixed.
> 
> >   However, the final link
> >>fails:
> >>
> >>Undefined   first referenced
> >> symbol in file
> >>__gnu_lto_v1/var/tmp//ccQylLjddebugobj
> >>
> >>It turns out that __gnu_lto_v1 in the original object
> >>
> >>[336] 0x10x1  OBJT GLOB  D0 COMMON 
> >>__gnu_lto_v1
> >>
> >>remains in the one produced by lto-wrapper:
> >>
> >>  [339]  00  NOTY GLOB  D0 UNDEF   __gnu_lto_v1
> >>
> >>Need to check what's going on here...
> >
> > How does it fail? The symbol should be unused...
> 
> With the link failure due to undefined __gnu_lto_v1 cited above.  I'd
> argue that ld behaves exactly as expected: it tries to resolve the
> undefined symbols, cannot find a definition, and stops.

Hmm, but the symbol isn't used anywhere (in a relocation)?

> I've had some success with the attached patch, which discards symbols by
> marking them weak.  On top of that, right now I need to prune tons of ld
> warnings like
> 
> ld: warning: file /var/tmp//ccv3Kl9adebugobjtem: section [1] has invalid type 
> [
> SHT_NULL ]
> 
> (already mentioned) and

It would be nice to have an opinion on why this is invalid.  And a
suggested workaround.

> ld: warning: file /var/tmp//ccv3Kl9adebugobjtem: section [34].symtab:
> symbol[2]:
>  global symbol has no name

I thought I fixed those.  What symbols end up with their name stripped?

> Pruning the messages is a hack to see how we stand, but certainly not an
> option for production use.

Sure.

As mentioned we could go full length and re-write all relocation
sections and with that compress both the symbol table and the
section header table.  Maybe for compressing the section header
table rewriting the symbol table is enough?

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

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

--- Comment #51 from Iain Sandoe  ---
(In reply to Rainer Orth from comment #10)
> Interestingly, a i386-apple-darwin16 bootstrap *does* work fine.

That's because the keymgr does work for m32 binaries.
It's never kept track of images for x86_64 (from 10.6+, anyway) I'm not sure if
/ when last I ever tried a static linked libgcc on m64.

[Bug target/81422] [aarch64] internal compiler error: in update_equiv_regs, at ira.c:3425

[qing.zhao at oracle dot com]

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

--- Comment #3 from Qing Zhao  ---
if the DEST is NOT a REG (sometimes it's a SUBREG, for example in the testing
case of this Bug), the REG_EQUIV notes should NOT be added.

[Bug target/82196] -mcall-ms2sysv-xlogues stubs sometimes use wrong MOV instruction

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
This breaks bootstrap on x86_64-apple-darwin10 Core2 duo

/opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/
-B/opt/gcc/gcc8w/x86_64-apple-darwin10.8.0/bin/
-B/opt/gcc/gcc8w/x86_64-apple-darwin10.8.0/lib/ -isystem
/opt/gcc/gcc8w/x86_64-apple-darwin10.8.0/include -isystem
/opt/gcc/gcc8w/x86_64-apple-darwin10.8.0/sys-include-g -O2 -O2  -g -O2
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -mmacosx-version-min=10.5 -pipe -fno-common -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector   -mmacosx-version-min=10.5 -pipe
-fno-common -I. -I. -I../.././gcc -I../../../work/libgcc
-I../../../work/libgcc/. -I../../../work/libgcc/../gcc
-I../../../work/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o
avx_savms64_s.o -MT avx_savms64_s.o -MD -MP -MF avx_savms64_s.dep -DSHARED -c
-xassembler-with-cpp ../../../work/libgcc/config/i386/avx_savms64.S
../../../work/libgcc/config/i386/savms64.h:47:no such instruction: `vmovaps
%xmm15,-0x30(%rax)'
../../../work/libgcc/config/i386/savms64.h:47:no such instruction: `vmovaps
%xmm14,-0x20(%rax)'
../../../work/libgcc/config/i386/savms64.h:47:no such instruction: `vmovaps
%xmm13,-0x10(%rax)'
../../../work/libgcc/config/i386/savms64.h:47:no such instruction: `vmovaps
%xmm12, (%rax)'
../../../work/libgcc/config/i386/savms64.h:47:no such instruction: `vmovaps
%xmm11, 0x10(%rax)'
../../../work/libgcc/config/i386/savms64.h:47:no such instruction: `vmovaps
%xmm10, 0x20(%rax)'
../../../work/libgcc/config/i386/savms64.h:47:no such instruction: `vmovaps
%xmm9, 0x30(%rax)'
../../../work/libgcc/config/i386/savms64.h:47:no such instruction: `vmovaps
%xmm8, 0x40(%rax)'
../../../work/libgcc/config/i386/savms64.h:47:no such instruction: `vmovaps
%xmm7, 0x50(%rax)'
../../../work/libgcc/config/i386/savms64.h:47:no such instruction: `vmovaps
%xmm6, 0x60(%rax)'
make[3]: *** [avx_savms64_s.o] Error 1

[Bug c++/81536] [8 Regression] Recent crash in is_std_substitution

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from David Binderman  ---
I cannot reproduce it here.

I tried about 80 recent versions of gcc and I also used the -g -O3 flags.

I suspect a hardware fault here.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

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

--- Comment #52 from Eric Botcazou  ---
> Yes, that's expected at present.
> a. there's evidently some more EH breakage caused by the
> reorder-and-partition (see 81733)
> b. the libgcc unwinder seems to have some issues even on systems that should
> support it
> c. we need to do some checking on the availability of the kernel call to
> fetch the FDEs and setup the specs accordingly.

IMO a. and b. are not top priority, we should first restore Ada bootstrap on
recent Darwins with the system unwinder.

>  -static-libstdc++ is a workaround (actually, all it's really doing is
> overriding the -static-libgcc).

Yes, -static-libgcc is the problem on Darwin.

[Bug middle-end/82238] New: ICE while building linux kernel

[bernd.edlinger at hotmail dot de]

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

Bug ID: 82238
   Summary: ICE while building linux kernel
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Created attachment 42197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42197&action=edit
preprocessed source code

arm-linux-gnueabihf-gcc -O2 mmu.i
arch/arm/mm/mmu.c: In function '__create_mapping':
arch/arm/mm/mmu.c:1653:1: internal compiler error: in to_reg_br_prob_base, at
profile-count.h:189
0x689cfb profile_probability::to_reg_br_prob_base() const
../../gcc-trunk/gcc/profile-count.h:189
0x689cfb estimate_bb_frequencies(bool)
../../gcc-trunk/gcc/predict.c:3570
0xc976fa tree_estimate_probability(bool)
../../gcc-trunk/gcc/predict.c:2827
0xc97833 execute
../../gcc-trunk/gcc/predict.c:3712
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

happens also with host(x86_64) gcc.

[Bug middle-end/82238] ICE while building linux kernel

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
dup.

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

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #28 from Markus Trippelsdorf  ---
*** Bug 82238 has been marked as a duplicate of this bug. ***