[Bug rtl-optimization/78671] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213 with -Og -march=skylake-avx512

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE: in |[7 Regression] ICE: in
   |extract_constrain_insn, at  |extract_constrain_insn, at
   |recog.c:2213 with -Og   |recog.c:2213 with -Og
   |-march=skylake-avx512   |-march=skylake-avx512

--- Comment #2 from Jakub Jelinek  ---
Started with r243038.

[Bug rtl-optimization/78669] [7 Regression]: ICE: in combine_and_move_insns, at ira.c:3665 with -Os -fno-tree-ter -mavx512bw

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r242832.

[Bug tree-optimization/78675] [7 Regression] ICE: verify_gimple failed (error: integral result type precision does not match field size of BIT_FIELD_REF)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-05
 CC||alan.hayward at arm dot com,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

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

[Bug fortran/78676] [5/6/7 Regression] Optimizer bug exposed by program with many bit operations

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||janus at gcc dot gnu.org
  Known to work||4.7.4, 4.8.5
Summary|Optimizer bug exposed by|[5/6/7 Regression]
   |program with many bit   |Optimizer bug exposed by
   |operations. |program with many bit
   ||operations
  Known to fail||4.9.4

--- Comment #4 from janus at gcc dot gnu.org ---
This seems to be a regression that started with version 4.9. In 4.7 and 4.8 I
see the same results with all optimization levels.

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #6 from James Greenhalgh  ---
Author: jgreenhalgh
Date: Mon Dec  5 09:35:28 2016
New Revision: 243239

URL: https://gcc.gnu.org/viewcvs?rev=243239&root=gcc&view=rev
Log:
[Patch 2/2 PR78561] Recalculate constant pool size before emitting it

gcc/testsuite/

PR rtl-optimization/78561
* gcc.target/aarch64/pr78561.c: Add missing testcase from r243183.



Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr78561.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #7 from James Greenhalgh  ---
(In reply to Segher Boessenkool from comment #5)
> Oh btw, you forgot to commit the testcase in 2/2.

Thanks, that's the easy one to fix. Would you be able to help me with a
configure line I can use for a PowerPC bootstrap on one of the compile farm
machines so I can debug the issue I've introduced?

[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'

[andyg1001 at hotmail dot co.uk]

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

andyg1001 at hotmail dot co.uk changed:

   What|Removed |Added

 CC||andyg1001 at hotmail dot co.uk

--- Comment #4 from andyg1001 at hotmail dot co.uk ---
Did this bug ever get resolved satisfactorily?

For now, the only solution, as suggested by Rich Felker, is to have for example
a dummy division instruction somewhere in the code that's being compiled.

I'm using gcc 4.8.5 with musl-libc 1.1.12.

[Bug other/78678] New: possibly missing -Warray-bounds warning

[clyon at gcc dot gnu.org]

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

Bug ID: 78678
   Summary: possibly missing -Warray-bounds warning
   Product: gcc
   Version: 7.0
   URL: https://bugs.linaro.org/show_bug.cgi?id=2349
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Arnd reported bug https://bugs.linaro.org/show_bug.cgi?id=2349.

gcc -fsanitize=object-size shows a useful warning that is not seen without that
option.

Compiling the attached code results in a warning:
atyfb_base.c:167:33: warning: array subscript is above array bounds
[-Warray-bounds]
only if one uses -fsanitize=object-size.

Removing this flag also removes the warning, which could probably be generated.

I've checked with today's trunk on arm-linux-gnueabi.

To reproduce the problem, compile with:
$ arm-none-linux-gnueabi-gcc -Wall -O2 -fno-partial-inlining
-Wno-unused-but-set-variable -Wno-pointer-sign -fsanitize=object-size
atyfb_base.i -c
[generates warning]

recompile without -fsanitize=object-size, it does not generate any warning.

[Bug other/78678] possibly missing -Warray-bounds warning

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
Created attachment 40245
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40245&action=edit
proprocessed source file from linux/drivers/video/fbdev/aty/atyfb_base.c,
compressed

[Bug tree-optimization/78675] [7 Regression] ICE: verify_gimple failed (error: integral result type precision does not match field size of BIT_FIELD_REF)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 40246
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40246&action=edit
gcc7-pr78675.patch

Untested fix.

[Bug libstdc++/78677] __gthread_key_create assumed not to fail in eh_globals.cc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-05
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Chris Johns from comment #0)
> Some operating system, for example RTEMS, may fail to create a POSIX key if
> not configured with enough resources. The lack of any error reporting in
> __eh_globals_init::__eh_globals_init() means exceptions are silently
> switched from thread safe to not being thread safe and this is not a concern
> for RTEMS.

I assume this is a typo and you mean this *is* a concern for RTEMS? :-)

> A way to report errors would be welcomed by RTEMS. We could hook this is a
> fatal error so the user is aware there is a critical issue that needs to be
> addressed.

I agree there should be some code to deal with the error there.

This seems like a specific example of the broader problem you described in PR
60645.

[Bug fortran/78676] [5/6/7 Regression] Optimizer bug exposed by program with many bit operations

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-05
 Ever confirmed|0   |1

--- Comment #5 from janus at gcc dot gnu.org ---
Reduced test case:


program testKISS64
  integer, parameter :: Q(2) = [ 393809176, 220190059 ]
  integer :: i, z, carry = 415

  do i=1,2
z = ishft(ishft(Q(i),9),-1) + &
ishft(ishft(Q(i),7),-1) + &
ishft(carry,-1)
carry = ishft(Q(i),-23) + ishft(Q(i),-25) + ishft(z,-31)
print *, z, carry
  end do

end program


gfortran 4.7 and 4.8 print at all optimization levels:

  -682598705  58
  1741342173  32

That's also what 4.9 prints at -00 and -01. But then 4.9 (and upwards) print at
-O2 and -O3:

  -682598705  57
  1741342172  32

The error goes away if I remove the loop (even though it occurs already for
i=1).

[Bug libstdc++/66414] Regression: string::find ten times slower than strstr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-05
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
I think we can simply hoist the code out into a helper function and then
overload that for the common char_traits and char_traits cases,
where we know the char_traits doesn't do anything funky and we can forward to
optimized libc calls. The generic version can't do that.

[Bug rtl-optimization/78669] [7 Regression]: ICE: in combine_and_move_insns, at ira.c:3665 with -Os -fno-tree-ter -mavx512bw

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC|segher at gcc dot gnu.org  |vmakarov at gcc dot 
gnu.org

--- Comment #3 from Jakub Jelinek  ---
The insn 125 is removed in earlier iteration of the combine_and_move_insns
loop, when processing regno 119, insn 25 is deleted:
  remove_death (regno, use_insn);
  SET_REG_N_REFS (regno, 0);
  REG_FREQ (regno) = 0;
  delete_insn (def_insn);
So, I think either combine_and_move_insns should not assert there are still
some non-debug uses and instead just do partly what it does if it replaces the
uses of regno in use_insn with the equiv replacement, or when deleting some
def_insn it should also adjust the uses, or we should just continue if we find
replaceable regs without any uses.

[Bug ada/48835] porting GNAT to m68k-linux

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #61 from John Paul Adrian Glaubitz  ---
So, I have had a closer look and there is still no complete support for
m68k-linux in gnat. We are still missing the changes to
gcc/ada/gcc-interface/Makefile.in as well as the new file
gcc/ada/system-linux-m68k.ads.

I'm attaching a patch with these changes which is just an updated patch from
the Debian gcc package. This is just Mikael's patch with the changes to
gcc/ada/s-memory.adb and gcc/ada/s-memory.ads removed since these shouldn't be
necessary any longer according to comment #58.

Could we re-open this bug report, please? Because the main part of this bug
report which is porting GNAT to m68k-linux is actually not resolved.

Thanks,
Adrian

[Bug ada/48835] porting GNAT to m68k-linux

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #62 from John Paul Adrian Glaubitz  ---
Created attachment 40247
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40247&action=edit
Ada support patch updated for gcc-7.0.

[Bug ada/48835] porting GNAT to m68k-linux

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #63 from Eric Botcazou  ---
> Could we re-open this bug report, please? Because the main part of this bug
> report which is porting GNAT to m68k-linux is actually not resolved.

Done.

[Bug ada/48835] porting GNAT to m68k-linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #64 from Eric Botcazou  ---
> Created attachment 40247 [details]
> Ada support patch updated for gcc-7.0.

The variables $(arch) and $(osys) are obsolete in Makefile.in and the line
"Frontend_Exceptions   : constant Boolean := False;" is missing.

[Bug ada/48835] porting GNAT to m68k-linux

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #65 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #64)
> > Created attachment 40247 [details]
> > Ada support patch updated for gcc-7.0.
> 
> The variables $(arch) and $(osys) are obsolete in Makefile.in and the line
> "Frontend_Exceptions   : constant Boolean := False;" is missing.

Ok, thanks for the comment. I'll look into updating the patch.

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
I usually use --disable-libgomp, but otherwise everything default (well,
--enable-languages=all,ada,go,obj-c++).

[Bug fortran/78676] [5/6/7 Regression] Optimizer bug with -ftree-vrp exposed by program with many bit operations

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[5/6/7 Regression]  |[5/6/7 Regression]
   |Optimizer bug exposed by|Optimizer bug with
   |program with many bit   |-ftree-vrp exposed by
   |operations  |program with many bit
   ||operations

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> gfortran 4.7 and 4.8 print at all optimization levels:
> 
>   -682598705  58
>   1741342173  32
> 
> That's also what 4.9 prints at -00 and -01. But then 4.9 (and upwards) print
> at -O2 and -O3:
> 
>   -682598705  57
>   1741342172  32
> 
> The error goes away if I remove the loop (even though it occurs already for
> i=1).

The latter is printed by 4.9 also with "-O1 -ftree-vrp", but not with
"-ftree-vrp" alone. In any case, this flag seems to be the culprit here.

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #9 from James Greenhalgh  ---
(In reply to Segher Boessenkool from comment #8)
> I usually use --disable-libgomp, but otherwise everything default (well,
> --enable-languages=all,ada,go,obj-c++).

I need a bit more hand holding on this one - is there a compile farm machine
set up that if I log in and run your configure line I'll be able to get a
32-bit PowerPC ADA bootstrap going? (I tried gcc112, but that doesn't have GNAT
installed).

[Bug ada/48835] porting GNAT to m68k-linux

[glaubitz at physik dot fu-berlin.de]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

  Attachment #40247|0   |1
is obsolete||

--- Comment #66 from John Paul Adrian Glaubitz  ---
Created attachment 40248
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40248&action=edit
Ada support patch updated for gcc-7.0.

Alright, updated the patch accordingly. Hope it can be applied now :).

I think Mikael should still be set as the author when committing as the wrote
the actual patch, I just updated it.

Thanks,
Adrian

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
gcc112 is LE, it cannot run 32-bit at all :-)

Try gcc110, that works.

[Bug ada/48835] porting GNAT to m68k-linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #67 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Dec  5 11:27:55 2016
New Revision: 243247

URL: https://gcc.gnu.org/viewcvs?rev=243247&root=gcc&view=rev
Log:
PR ada/48835
* gcc-interface/Makefile.in: Add support for m68k-linux.
* system-linux-m68k.ads: New file.

Added:
trunk/gcc/ada/system-linux-m68k.ads
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in

[Bug ada/48835] porting GNAT to m68k-linux

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #68 from Eric Botcazou  ---
Thanks, patch applied on the mainline.

[Bug ada/48835] porting GNAT to m68k-linux

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #69 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #68)
> Thanks, patch applied on the mainline.

Thanks a lot! Would you also mind backporting it to the gcc-7 branch?

Thanks,
Adrian

[Bug fortran/78676] [5/6/7 Regression] Optimizer bug with -ftree-vrp exposed by program with many bit operations

[mecej4 at operamail dot com]

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

--- Comment #7 from mecej4 at operamail dot com ---
(In reply to Andrew Pinski from comment #3)
> Try -fwrapv .

Thanks! Using that flag with -O2 does make the program give correct results,
but I am a little confused about what that flag does and when it should be
used. Obviously, it would be safe to use -fwrapv with any bit-twiddling Fortran
routine, but it is not obvious which optimizations are impacted by the use of
this option.

The online documentation at
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options
says "See also the -fwrapv option" as part of the description of
-fstrict-overflow, but I cannot find a separate entry that explains -fwrapv, at
least not on that page.

I did find a description of -fwrapv on a page for an older version of GCC,
namely, 3.0, at http://www.cs.fsu.edu/~baker/ada/gnat/html/gcc_3.html#IDX1319 ,
but it says "This flag enables some optimizations and disables other." and I
was not able to find which ones. Anyway, I am doubtful whether the old manual
page is applicable to GCC 6.2.

[Bug ada/48835] porting GNAT to m68k-linux

[ebotcazou at gcc dot gnu.org]

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

--- Comment #70 from Eric Botcazou  ---
> Thanks a lot! Would you also mind backporting it to the gcc-7 branch?

There is no gcc-7 branch yet.

[Bug ada/48835] porting GNAT to m68k-linux

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #71 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #70)
> > Thanks a lot! Would you also mind backporting it to the gcc-7 branch?
> 
> There is no gcc-7 branch yet.

Ah, sorry. I thought there already was since Matthias Klose recently started
uploading gcc-7 to Debian experimental and I thought this means that it has
been branched from master now.

Then I guess I'll just have to wait for the next upload.

[Bug c++/77353] uint16_t instead uint8_t comparison

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|other   |c++
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #13 from Georg-Johann Lay  ---
This works with v7 as expected, closing thusly (optimization PRs are usually
not backported to older versions).

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Created attachment 40249
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40249&action=edit
gcc7-pr71537-strchr.patch

For the builtins, it seems to be just recent regressions, people are moving
builtins folding out of builtins.c into gimple-fold.c and totally forgetting
constexpr.  Here is a patch to handle strchr/strrchr.  I'll look at memchr
next.

[Bug other/78680] New: [7 Regression] ICE in get_substring_ranges_for_loc, at input.c:1398

[doko at gcc dot gnu.org]

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

Bug ID: 78680
   Summary: [7 Regression] ICE in get_substring_ranges_for_loc, at
input.c:1398
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

I'm aware of PR78569, but this is r243108, seen multiple times when test
rebuilding the Debian archive.  It is reproducible, however not when adding
-save-temps. Seen in the packages:

cpl-plugin-uves
ctn
nspr
rxtx
tcptrace
wv

/home/packages/tmp/rxtx-2.2pre2/./src/SerialImp.c:4651:28: note: in expansion
of macro 'RXTXCommDriver'
 JNIEXPORT jboolean JNICALL RXTXCommDriver(registerKnownPorts)(JNIEnv *env,
^~
0x10d2358 get_substring_ranges_for_loc
../../src/gcc/input.c:1398
0x10d2358 get_source_location_for_substring(cpp_reader*, string_concat_db*,
unsigned int, cpp_ttype, int, int, int, unsigned int*)
../../src/gcc/input.c:1468
0x621654 c_get_substring_location(substring_loc const&, unsigned int*)
../../src/gcc/c-family/c-common.c:865
0x9ff32d substring_loc::get_location(unsigned int*) const
../../src/gcc/substring-locations.c:194
0x9ff32d format_warning_va(substring_loc const&, source_range const*, char
const*, int, char const*, __va_list_tag (*) [1])
../../src/gcc/substring-locations.c:112
0x9ff627 format_warning_at_substring(substring_loc const&, source_range const*,
char const*, int, char const*, ...)
../../src/gcc/substring-locations.c:179
0xffd2ed add_bytes
../../src/gcc/gimple-ssa-sprintf.c:2077
0xffd2ed compute_format_length
../../src/gcc/gimple-ssa-sprintf.c:2223
0xffd2ed handle_gimple_call
../../src/gcc/gimple-ssa-sprintf.c:2835
0xffd2ed execute
../../src/gcc/gimple-ssa-sprintf.c:2863
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/70676] suboptimal code generation on AVR

[night_ghost at ykoctpa dot ru]

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

--- Comment #6 from night_ghost at ykoctpa dot ru ---
I reported not one case but suboptimal behavior while optimizing size - GCC
optimization of sibling calls increases size of binary. There are a lot of such
places in this code.

And GCC never replaces call-ret sequence to jmp, relying on linkers optimizing
by -relax. But including -relax flag often spoils the project to complete
failure.

[Bug tree-optimization/78681] New: [7 Regressions] ICE in determine_value_range, at tree-ssa-loop-niter.c:413

[doko at gcc dot gnu.org]

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

Bug ID: 78681
   Summary: [7 Regressions] ICE in determine_value_range, at
tree-ssa-loop-niter.c:413
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with r243108, works with -O1, different backtrace than the one in PR78365

$ cat mklev.i
typedef char a;
typedef struct { a b; } c;
a d, e, f, l, m;
c n;
int o();
static void p(c *, int, int, int, int);
void p(cc, g, h, i, j) c *cc;
a g, h, i, j;
{
  a k;
  for (; k <= j; k++)
if (o(g, k))
  for (; i; k++)
if (d)
  cc->b = g;
}
void r(q) int q;
{
  p(&n, m, l, f, 1);
  p(&n, m, e, f, e - 1);
}

$ gcc -c -O2 mklev.i
mklev.i: In function 'p.constprop':
mklev.i:7:6: internal compiler error: in determine_value_range, at
tree-ssa-loop-niter.c:413
 void p(cc, g, h, i, j) c *cc;
  ^
0xb0ce8b determine_value_range
../../src/gcc/tree-ssa-loop-niter.c:413
0xb0d3a5 bound_difference
../../src/gcc/tree-ssa-loop-niter.c:743
0xb0d3a5 number_of_iterations_cond
../../src/gcc/tree-ssa-loop-niter.c:1714
0xb0d3a5 number_of_iterations_exit_assumptions(loop*, edge_def*,
tree_niter_desc*, gcond**, bool)  
../../src/gcc/tree-ssa-loop-niter.c:2290
0xb0e473 number_of_iterations_exit_assumptions(loop*, edge_def*,
tree_niter_desc*, gcond**, bool)  
../../src/gcc/tree-ssa-loop-niter.c:2374
0xb0e473 number_of_iterations_exit(loop*, edge_def*, tree_niter_desc*, bool,
bool)
../../src/gcc/tree-ssa-loop-niter.c:2357
0xb0e7b9 estimate_numbers_of_iterations_loop
../../src/gcc/tree-ssa-loop-niter.c:3793
0xb10ed9 loop_exits_before_overflow
../../src/gcc/tree-ssa-loop-niter.c:4197
0xb10ed9 scev_probably_wraps_p(tree_node*, tree_node*, tree_node*, gimple*,
loop*, bool)
../../src/gcc/tree-ssa-loop-niter.c:4453
0x10902c2 convert_affine_scev(loop*, tree_node*, tree_node**, tree_node**,
gimple*, bool, tree_node*)
../../src/gcc/tree-chrec.c:1271
0x10905e7 chrec_convert_1
../../src/gcc/tree-chrec.c:1329
0xaa88a9 follow_ssa_edge_in_rhs
../../src/gcc/tree-scalar-evolution.c:1139
0xaa88a9 follow_ssa_edge
../../src/gcc/tree-scalar-evolution.c:1364
0xaa7043 analyze_evolution_in_loop
../../src/gcc/tree-scalar-evolution.c:1475
0xaa7043 interpret_loop_phi
../../src/gcc/tree-scalar-evolution.c:1647
0xaa7043 analyze_scalar_evolution_1
../../src/gcc/tree-scalar-evolution.c:2095
0xaa74ae analyze_scalar_evolution(loop*, tree_node*)
../../src/gcc/tree-scalar-evolution.c:2145
0x4d scev_const_prop()
../../src/gcc/tree-scalar-evolution.c:3847
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug libstdc++/66414] string::find ten times slower than strstr

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Although we can only do that for the overload that assumes null-terminated
input, not all cases that basic_string::find supports.

We can use the GNU memmem extension for the general case, but that's not
standard.

[Bug fortran/78674] [cleanup] merge gfc_convert_type_warn and gfc_convert_chartype

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org ---
gfc_convert_chartype was introduced in r135515, which implemented support for
wide characters in gfortran 4.4. gfc_convert_type_warn is much older.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  ---
Maybe it's this thread?
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00334.html

[Bug fortran/61767] [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1491

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to janus from comment #7)
> This alternative patch fixes the ICE as well:
> [...]
> It avoids calling generate_finalization_wrapper for non-finalizable types at
> all, and thus might even be preferable over the previous patch (provided it
> regtests fine, which I don't know yet).

I think this is wrong. In fact we do not only use calls to a _final routine for
actual finalization, but also for polymorphic deallocation (see PR46321)!

Thus: The patch in comment #7 should be discarded, and comment #5 is the way to
go here.

[Bug rtl-optimization/78669] [7 Regression]: ICE: in combine_and_move_insns, at ira.c:3665 with -Os -fno-tree-ter -mavx512bw

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  ---
Something like this perhaps.

Index: ira.c
===
--- ira.c   (revision 242958)
+++ ira.c   (working copy)
@@ -3705,6 +3705,14 @@ combine_and_move_insns (void)
  remove_death (regno, use_insn);
  SET_REG_N_REFS (regno, 0);
  REG_FREQ (regno) = 0;
+ df_ref use;
+ FOR_EACH_INSN_USE (use, def_insn)
+   {
+ unsigned int use_regno = DF_REF_REGNO (use);
+ if (!HARD_REGISTER_NUM_P (use_regno))
+   reg_equiv[use_regno].replace = 0;
+   }
+
  delete_insn (def_insn);

  reg_equiv[regno].init_insns = NULL;

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Created attachment 40250
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40250&action=edit
gcc7-pr71537-memchr.patch

And this patch handles memchr.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #8 from Dominik Vogt  ---
There's a typo in the patch.  Should be reverted in a minute.  Sorry for the
trouble.

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #11 from James Greenhalgh  ---
My bootstrap at r243245 on gcc110 seemed to work fine.

[jgreenhalgh@gcc1-power7 gcc]$ ../build-gcc/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=../build-gcc/gcc/xgcc
Target: powerpc64-unknown-linux-gnu
Configured with: ../gcc/configure --enable-languages=all,ada,go,obj-c++
Thread model: posix
gcc version 7.0.0 20161205 (experimental) (GCC)

The file you mentioned (gcc/ada/rts_32/a-chahan.adb) seemed to have been
compiled with no issues.

Am I missing something to get the 32-bit multilib buiild, or maybe I need to
target it explicitly?

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
 r234635 compiles w/o error -- i.e. has already lost the diagnostic Jonathan
mentioned.  Tracking down when the diag was lost ...

[Bug target/70676] suboptimal code generation on AVR

[gjl at gcc dot gnu.org]

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

--- Comment #7 from Georg-Johann Lay  ---
Sorry, but guessing around has proben to be extremely unefficient and error
prone, in particular if the information is available on the other end of the
wire.

If -mrelax leads to wrong code, then you shoulr report this to the Binutils
project, because avr-gcc just passes through -mrelax to Binutils.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[vogt at linux dot vnet.ibm.com]

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

--- Comment #9 from Dominik Vogt  ---
The faulty patch has been reverted in r243256.

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Created attachment 40251
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40251&action=edit
gcc7-pr71537.patch

Patch for the comparison of string_cst + const offset with nullptr.

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Note, lately lots of various PRs have been filed that started to ICE with the
r234636 change.  But it looks that usually we've just been generating silent
wrong-code or not accepts-invalid.

[Bug rtl-optimization/78652] [7 regression]LRA generates wrong code by inheriting changed register

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
I bisected and found it was caused by below change:

commit ab4ea053bf71c5571df344d5d5f5bd7ecc5ede8e
Author: vmakarov 
Date:   Tue Aug 2 16:07:36 2016 +

2016-08-02  Vladimir Makarov  

PR rtl-optimization/69847
* lra-int.h (struct lra-reg): Use restore_rtx instead of
restore_regno.
(lra_rtx_hash): New.
* lra.c (initialize_lra_reg_info_element): Use restore_rtx instead
of restore_regno.
(lra_rtx_hash): Rename and move lra-remat.c::rtx_hash.
* lra-remat.c (rtx_hash): Rename and Move to lra.c.
* lra-spills.c (lra_final_code_change): Don't delete insn when the
next insn is USE with the same reg as the current insn source.
* lra-constraints.c (curr_insn_transform): Use restore_rtx instead
of restore_regno.
(lra_constraints_init): Call initiate_invariants.
(lra_constraints_finish): Call finish_invariants.
(struct invariant, invariant_t, invariant_ptr_t): New.
(const_invariant_ptr_t, invariants, invariants_pool): New.
(invariant_table, invariant_hash, invariant_eq_p): New.
(insert_invariant, initiate_invariants, finish_invariants): New.
(clear_invariants, invalid_invariant_regs): New.
(inherit_reload_reg, split_reg, fix_bb_live_info): Use restore_rtx
instead of restore_regno.
(invariant_p, process_invariant_for_inheritance): New.
(inherit_in_ebb): Implement invariant inheritance.
(lra_inheritance): Initialize and finalize invalid_invariant_regs.
(remove_inheritance_pseudos): Implement undoing invariant
inheritance.
(undo_optional_reloads, lra_undo_inheritance): Use restore_rtx
instead of restore_regno.
* lra-assigns.c (regno_live_length): New.
(reload_pseudo_compare_func): Use regno_live_length.
(assign_by_spills): Use restore_rtx instead of restore_regno.
(lra_assign): Ditto.  Initiate regno_live_length.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@238991
138bc75d-0d04-0410-961f-82ee72b054a4

It is a big change.

[Bug tree-optimization/78681] [7 Regressions] ICE in determine_value_range, at tree-ssa-loop-niter.c:413

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-05
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r240292.

[Bug tree-optimization/78681] [7 Regressions] ICE in determine_value_range, at tree-ssa-loop-niter.c:413

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
We shouldn't ICE on this, but otherwise, garbage in, garbage out.  The
prototype doesn't match the K&R definition.

Slightly cleaned up testcase:

struct S { char b; };
char d, e, f, l, m;
struct S n;
int bar (char, char);
static void foo (struct S *, int, int, int, int);

static void
foo (x, g, h, i, j)
  struct S *x;
  char g, h, i, j;
{
  char k;
  for (k = 0; k <= j; k++)
if (bar (g, k))
  for (; i; k++)
if (d)
  x->b = g;
}

void
baz (int q)
{
  foo (&n, m, l, f, 1);
  foo (&n, m, e, f, e - 1);
}

It is enough if just one argument disagrees (e.g. the int vs. char on just j,
not all the others).

[Bug fortran/78676] [5/6/7 Regression] Optimizer bug with -ftree-vrp exposed by program with many bit operations

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to janus from comment #4)
> This seems to be a regression that started with version 4.9. In 4.7 and 4.8
> I see the same results with all optimization levels.

It is not a regression.  It is invalid code, so the compiler can generate
whatever results it wants.  Fortran does not have an unsigned integer
type, which KISS requires.

  13.7.1 General

  Detailed specifications of the standard generic intrinsic
  procedures are provided in 13.7 in alphabetical order.

  The types and type parameters of standard intrinsic procedure
  arguments and function results are determined by these specifications.
  The "Argument(s)" paragraphs specify requirements on the actual
  arguments of the procedures.  The result characteristics are sometimes
  specified in terms of the characteristics of dummy arguments.
  A program is prohibited from invoking an intrinsic procedure under
  circumstances where a value to be returned in a subroutine argument or
  function result is outside the range of values representable by objects
  of the specified type and type parameters, unless ... (stuff about IEEE). 

  13.3 Bit model

  13.3.1 General

  ... (stuff about nonnegative integers) ...

  The interpretation of a negative integer as a sequence of bits is
  processor dependent.

  13.7.78 IEOR (I, J)

  ... (stuff about IEOR) ...

  The model for the interpretation of an integer value as a sequence of
  bits is in 13.3.

  13.7.84 ISHFT (I, SHIFT)

  ... (stuff about ISHFT) ...

  The model for the interpretation of an integer value as a sequence of
  bits is in 13.3.

OP has three options.  1) Change his/her code to use INTEGER(8) for 
intermediate computations.  Results can then be converted to 
INTEGER(4) by "mod(result, HUGE(I))".  2) Use ISO C binding to call
a C implementation of KISS.  3) Use -fwrapv as indicated in comment #1.

BTW, until very recently, gfortran used 4 independent KISS generators
for random_number. BUt, that implementation was done in C.

[Bug libstdc++/66414] string::find ten times slower than strstr

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
This patch would implement the requested change:

--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -2291,9 +2291,28 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
*  it begins.  If not found, returns npos.
   */
   size_type
-  find(const _CharT* __s, size_type __pos = 0) const
+  find(const _CharT* __s, size_type __pos = 0) const _GLIBCXX_NOEXCEPT
   {
__glibcxx_requires_string(__s);
+   if (__are_same<_Traits, char_traits<_CharT>>::__value)
+ {
+   if (__are_same<_CharT, char>::__value)
+ {
+   const char* __data = (const char*)data();
+   const char* __p
+ = __builtin_strstr(__data + __pos, (const char*)__s);
+   return __p ? (__p - __data) : npos;
+ }
+#if _GLIBCXX_USE_WCHAR_T
+   else if (__are_same<_CharT, wchar_t>::__value)
+ {
+   const wchar_t* __data = (const wchar_t*)data();
+   const wchar_t* __p
+ = __builtin_wcsstr(__data + __pos, (const wchar_t*)__s);
+   return __p ? (__p - __data) : npos;
+ }
+#endif
+ }
return this->find(__s, __pos, traits_type::length(__s));
   }


But it causes a huge regression in this example, where currently it is hundreds
of times faster than strstr:

#include 
#include 
#include 
#include 
#include 

int main()
{
  std::string haystack(5000, 'a');
  std::string needle = haystack;
  needle.back() = 'b';
  std::size_t pos[1000];

  auto start = std::chrono::high_resolution_clock::now();
  for (auto& p : pos)
p = haystack.find(needle.c_str());
  auto stop = std::chrono::high_resolution_clock::now();
  std::cout << (stop - start).count() << std::endl;
  for (auto p : pos)
assert(p == std::string::npos);

  start = std::chrono::high_resolution_clock::now();
  for (auto& p : pos)
  {
auto ptr = std::strstr(haystack.c_str(), needle.c_str());
p = ptr ? ptr - haystack.c_str() : std::string::npos;
  }
  stop = std::chrono::high_resolution_clock::now();
  std::cout << (stop - start).count() << std::endl;
  for (auto p : pos)
assert(p == std::string::npos);
}

This is because the current code uses char_traits::length() (i.e. strlen)
first, so if the needle is longer than the haystack we don't bother looking for
it.

I don't think it's clear that using strstr is an improvement.

The C++17 library provides Boyer-Moore and Boyer-Moore-Horspool searchers, so
that already offers you more control than basic_string::find or strstr.

[Bug fortran/70244] [OOP] ICE in spec_dimen_size(): Bad dimension

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[OOP] ICE spec_dimen_size() |[OOP] ICE in
   |Bad dimension   |spec_dimen_size(): Bad
   ||dimension

--- Comment #2 from janus at gcc dot gnu.org ---
Slightly reduced test case:


module mymodule
implicit none
type :: deriv_t
contains
procedure :: fun
end type
type :: base_a
class(deriv_t), allocatable :: obj
end type
contains
function fun( self ) result( val )
class(deriv_t), intent(in) :: self
real, dimension(:,:), allocatable :: val
end function
end module

program bug
use mymodule
implicit none
type(base_a), dimension(1) :: e
real, dimension(:,:), allocatable :: m
allocate( deriv_t :: e(1)%obj )
m = e(1)%obj%fun()
end


Backtrace with current trunk:

f951: internal compiler error: spec_dimen_size(): Bad dimension
0x7de01e gfc_internal_error(char const*, ...)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/error.c:1328
0x7a3453 spec_dimen_size(gfc_array_spec*, int, __mpz_struct (*) [1])
/home/jweil/gcc/gcc7/trunk/gcc/fortran/array.c:2148
0x7a3ea8 gfc_array_dimen_size(gfc_expr*, int, __mpz_struct (*) [1])
/home/jweil/gcc/gcc7/trunk/gcc/fortran/array.c:2423
0x7e4a5d gfc_check_conformance(gfc_expr*, gfc_expr*, char const*, ...)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/expr.c:3103
0x7e4fe5 gfc_check_assign(gfc_expr*, gfc_expr*, int, bool)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/expr.c:3244
0x87dae6 resolve_ordinary_assign
/home/jweil/gcc/gcc7/trunk/gcc/fortran/resolve.c:10101
0x87f97b gfc_resolve_code(gfc_code*, gfc_namespace*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/resolve.c:10919
0x88ca24 resolve_codes
/home/jweil/gcc/gcc7/trunk/gcc/fortran/resolve.c:16028
0x88cb71 gfc_resolve(gfc_namespace*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/resolve.c:16063
0x85d493 resolve_all_program_units
/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:5977
0x85dcaf gfc_parse_file()
/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:6224
0x8b6fea gfc_be_parse_file
/home/jweil/gcc/gcc7/trunk/gcc/fortran/f95-lang.c:202

[Bug fortran/78226] Fill out location information everywhere

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #10 from vehre at gcc dot gnu.org ---
Hi Thomas,

allow me a stupid question: I have applied your patch and added
--enable-checking=yes to configure when preping gfortran. Compiling and
regression testing shows no regressions. 

/configure --disable-multilib --enable-languages=c,fortran,c++
--enable-stage1-languages=fortran --enable-libgfortran --enable-checking=yes
--prefix=/home/vehre/Projekte/gfortran/ CFLAGS='-g -O0
-DENABLE_ASSERT_CHECKING' CXXFLAGS='-g -O0' 'STAGE1_CFLAGS=-g -O0
-DENABLE_ASSERT_CHECKING' 'STAGE1_CXXFLAGS=-g -O0'

What am I doing wrong? Or are there no more regressions when the patch is
applied?

- Andre

[Bug tree-optimization/57361] Remove self memory assignment

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

[Bug fortran/78676] [5/6/7 Regression] Optimizer bug with -ftree-vrp exposed by program with many bit operations

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #8)
> (In reply to janus from comment #4)
> > This seems to be a regression that started with version 4.9. In 4.7 and 4.8
> > I see the same results with all optimization levels.
> 
> It is not a regression.  It is invalid code, so the compiler can generate
> whatever results it wants.  Fortran does not have an unsigned integer
> type, which KISS requires.
> 
>   13.7.1 General
> 
>   Detailed specifications of the standard generic intrinsic
>   procedures are provided in 13.7 in alphabetical order.
> 
>   The types and type parameters of standard intrinsic procedure
>   arguments and function results are determined by these specifications.
>   The "Argument(s)" paragraphs specify requirements on the actual
>   arguments of the procedures.  The result characteristics are sometimes
>   specified in terms of the characteristics of dummy arguments.
>   A program is prohibited from invoking an intrinsic procedure under
>   circumstances where a value to be returned in a subroutine argument or
>   function result is outside the range of values representable by objects
>   of the specified type and type parameters, unless ... (stuff about IEEE). 
> 
>   13.3 Bit model
> 
>   13.3.1 General
> 
>   ... (stuff about nonnegative integers) ...
> 
>   The interpretation of a negative integer as a sequence of bits is
>   processor dependent.
> 
>   13.7.78 IEOR (I, J)
>   
>   ... (stuff about IEOR) ...
> 
>   The model for the interpretation of an integer value as a sequence of
>   bits is in 13.3.
> 
>   13.7.84 ISHFT (I, SHIFT)
> 
>   ... (stuff about ISHFT) ...
> 
>   The model for the interpretation of an integer value as a sequence of
>   bits is in 13.3.
> 
> OP has three options.  1) Change his/her code to use INTEGER(8) for 
> intermediate computations.  Results can then be converted to 
> INTEGER(4) by "mod(result, HUGE(I))".  2) Use ISO C binding to call
> a C implementation of KISS.  3) Use -fwrapv as indicated in comment #1.
> 
> BTW, until very recently, gfortran used 4 independent KISS generators
> for random_number. BUt, that implementation was done in C.

I forgot

  7.1.5.2.4 Evaluation of numeric intrinsic operations

  The execution of any numeric operation whose result is not defined
  by the arithmetic used by the processor is prohibited.

So, the programmer is prohibited from using the addition and
multiplication operators if/when the result of the operation
would overflow (or require wrap-around semantics).

[Bug fortran/78682] New: ICE calling (locally) a TBP of a remote CAF derived type

[stefano.zaghi at cnr dot it]

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

Bug ID: 78682
   Summary: ICE calling (locally) a TBP of a remote CAF derived
type
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefano.zaghi at cnr dot it
  Target Milestone: ---

Created attachment 40252
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40252&action=edit
the MCVE reproducing the ICE

Dear all,

I get an ICE when I try to call (locally) a type-bound-procedure of
derived-type coarray on a remote image, see the attached MCVE. 

I know that very very probably my code is invalid with respect the current
standard, but because with GNU gfortran 6.2.1 I obtain the following Internal
Compiler Error, I would like to let you know.

Compilation/Error results

gfortran -fcoarray=lib gfortran_ice_caf.f90
gfortran_ice_caf.f90:31:0:

   if (this_image()==2) call core_caf[1]%core_value_print

internal compiler error: in gfc_get_tree_for_caf_expr, at
fortran/trans-expr.c:1818
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Architecture details

Linux 4.8.8-2-ARCH #1 SMP PREEMPT Thu Nov 17 14:51:03 CET 2016 x86_64 GNU/Linux

Intel(R) Xeon(R) CPU X5650@2.67GHz

GNU Fortran (GCC) 6.2.1 20160830 

My best regards.

P.S. thank you very very much for your work, you are my superheroes!

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
r231665 lost the diagnostic

+2015-12-15  Martin Sebor  
+
+   c++/42121
+   * tree-chkp.c (chkp_find_bound_slots_1): Handle flexible array
+   members.
+   * tree.c (type_contains_placeholder_1): Avoid assuming type has
+   a non-null domain or an upper bound to handle flexible array
+   members.
+   * varasm.c (output_constructor_regular_field):  Same.
+   (output_constructor): Set min_index to integer_zero_node rather
+   than null when a type has no domain to avoid crashing later.
+

[Bug fortran/78682] ICE calling (locally) a TBP of a remote CAF derived type

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-05
 CC||afanfa at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
This seems to have been fixed on trunk (7.0), likely r238007.

[Bug fortran/78682] ICE calling (locally) a TBP of a remote CAF derived type

[stefano.zaghi at cnr dot it]

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

--- Comment #2 from Stefano Zaghi  ---
(In reply to Dominique d'Humieres from comment #1)
> This seems to have been fixed on trunk (7.0), likely r238007.

Dear Dominique, thank you for your fast replay. I can check this tomorrow after
a fresh download/build of the 7.0 trunk.

My best regards.

[Bug target/78683] New: [ppc] __builtin_ctlz code gen can be improved for -mcpu=power8 and earlier

[wschmidt at gcc dot gnu.org]

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

Bug ID: 78683
   Summary: [ppc] __builtin_ctlz code gen can be improved for
-mcpu=power8 and earlier
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

For this code:

unsigned r; r = (unsigned) __builtin_ctzl(v); return r;

GCC on POWER produces:

 neg 9,3
 and 3,9,3
 cntlzd 3,3
 subfic 3,3,63
 rldicl 3,3,0,32

Two other compilers produce the following sequences:

 addi 4, 3, -1
 andc 3, 4, 3
 popcntd 3, 3

or

 addi   r0,r3,-1
 andc   r0,r0,r3
 cntlzd r0,r0
 subfic r3,r0,64

We should probably be using the short and elegant popcntd solution.

[Bug target/78683] [ppc] __builtin_ctlz code gen can be improved for -mcpu=power8 and earlier

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Target||powerpc*-*-*
 CC||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
I cannot reproduce on native and valgrind doesn't complain.  Can you attach the
first RTL dump which contains the problematic insn?

(insn 196 94 197 (clobber (reg/i:SI 8 %o0 [24]))

[Bug fortran/78226] Fill out location information everywhere

[vehre at gcc dot gnu.org]

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

--- Comment #11 from vehre at gcc dot gnu.org ---
Please ignore my previous unqualified comment. I had applied you patch on a git
branch and based my own in that, but failed to merge yours into mine. Doing so
immediately gave the errors.

[Bug tree-optimization/49599] FRE/DSE not performing well on aggregates

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
This was fixed a little over a year ago:
Author: alalaw01 
Date:   Fri Sep 18 10:55:11 2015 +

completely_scalarize arrays as well as records.

gcc/:

PR tree-optimization/67283
* tree-sra.c (type_consists_of_records_p): Rename to...
(scalarizable_type_p): ...this, add case for ARRAY_TYPE.
(completely_scalarize_record): Rename to...
(completely_scalarize): ...this, add ARRAY_TYPE case, move some code
to:
(scalarize_elem): New.
(analyze_all_variable_accesses): Follow renamings.

gcc/testsuite/:

* gcc.dg/tree-ssa/sra-15.c: New.
* gcc.dg/tree-ssa/sra-16.c: New.

[Bug middle-end/78684] New: [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074

[doko at gcc dot gnu.org]

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

Bug ID: 78684
   Summary: [7 Regression] ICE in
create_intersect_range_checks_index, at
tree-vect-loop-manip.c:2074
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with r243108 on x86_64-linux-gnu, works with -O2.

$ cat RapMapMapper.ii
class a {
public:
  a(long);
  void operator<<=(long) {
long b;
for (unsigned long c; c; c--)
  d[c + b] = d[c];
  }
  a &g();
  long d[28];
};
long e;
int f;
void j() {
  a h(e), i = h;
  i.g() <<= f;
}

$ g++ -std=c++11 -c -march=broadwell -g -O3 RapMapMapper.ii
RapMapMapper.ii: In function 'void j()':
RapMapMapper.ii:14:6: internal compiler error: in
create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
 void j() {
  ^
0xcdb7be create_intersect_range_checks_index
../../src/gcc/tree-vect-loop-manip.c:2073
0xcdb7be create_intersect_range_checks
../../src/gcc/tree-vect-loop-manip.c:2131
0xcdb7be vect_create_cond_for_alias_checks(_loop_vec_info*, tree_node**)
../../src/gcc/tree-vect-loop-manip.c:2219
0xcdbf7c vect_loop_versioning(_loop_vec_info*, unsigned int, bool)
../../src/gcc/tree-vect-loop-manip.c:2293
0xccc064 vect_transform_loop(_loop_vec_info*)
../../src/gcc/tree-vect-loop.c:6773
0xce8d62 vectorize_loops()
../../src/gcc/tree-vectorizer.c:621
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #7 from Eric Botcazou  ---
Never mind, I can reproduce with 20070121.c:

eric@polaris:~/build/gcc/sparc-sun-solaris2.10> gcc/cc1 -quiet 20070121.c -O3
20070121.c: In function 'add234_internal':
20070121.c:18:1: error: invalid rtl sharing found in the insn
 }
 ^
(insn 195 29 194 (clobber (reg/i:SI 8 %o0 [24])) "20070121.c":18 -1
 (nil))
20070121.c:18:1: error: shared rtx
(clobber (reg/i:SI 8 %o0 [24]))
20070121.c:18:1: internal compiler error: internal consistency failure

[Bug rtl-optimization/78652] [7 regression]LRA generates wrong code by inheriting changed register

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Looks like Vlad already fixed this @ below commit:

commit 6526e1b66785b76d71926b20c9eb299e74a2d255
Author: vmakarov 
Date:   Wed Nov 30 17:35:40 2016 +

2016-11-30  Vladimir Makarov  

PR tree-optimization/77856
* lra-constraints.c (inherit_in_ebb): Check original regno for
invalid invariant regs too.  Set only clobbered hard regs for the
invalid invariant regs.

2016-11-30  Vladimir Makarov  

PR tree-optimization/77856
* gcc.target/i386.c (pr77856.c): New.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@243038
138bc75d-0d04-0410-961f-82ee72b054a4


I will double check and close this PR.

Thanks.

[Bug debug/78685] New: -Og generates too many ""s

[eggert at gnu dot org]

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

Bug ID: 78685
   Summary: -Og generates too many ""s
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---
  Host: x86-64

Created attachment 40253
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40253&action=edit
preprocessed C program illustrating -Og problem

Emacs developers are having trouble using -Og to debug Emacs, and so are still
using -O0; see, for example:

http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00199.html

I reproduced the problem and came up with a small program (attached) that
illustrates it. Here's a sample transcript on Fedora 24 x86-64, which uses gcc
(GCC) 6.2.1 20160916 (Red Hat 6.2.1-2):

$ gcc -Og -g3 Ogbug.i
$ gdb a.out
GNU gdb (GDB) Fedora 7.11.1-86.fc24
...
Reading symbols from a.out...done.
(gdb) b call_debugger
Breakpoint 1 at 0x4004d6: file Ogbug.i, line 6.
(gdb) r
Starting program: /home/eggert/junk/a.out 

Breakpoint 1, call_debugger (x=3) at Ogbug.i:6
6 v = x;
(gdb) bt
#0  call_debugger (x=3) at Ogbug.i:6
#1  0x00400519 in apply_lambda (fun=1, args=2, count=)
at Ogbug.i:14
#2  0x00400547 in main (argc=, argv=)
at Ogbug.i:22


It's hard to debug a program with all those ""s getting in the
way.

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
So in what other insn does the clobber appear and which pass introduced it?
Easiest is to
b error
run
then notice the address passed to verify_rtx_sharing and put a breakpoint on
verify_rtx_sharing conditional on orig == $ (of course only in the
same verify_rtl_sharing call).

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
It's apparently the bbro pass.  Fixing.

[Bug rtl-optimization/78652] [7 regression]LRA generates wrong code by inheriting changed register

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
Indeed, it was fixed by that.  I will a test for this and then close.

[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #4 from Gerhard Steinmetz  
---
Update, new backtrace :


$ gfortran-7-20161127 z1t.f90
z1t.f90:3:28:

   character(2) :: z(1) = '' // ['y']
1
Warning: CHARACTER expression at (1) is being truncated (2/1)
[-Wcharacter-truncation]
f951: internal compiler error: free_expr0(): Bad expr type
0x68ea6f gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1327
0x68f7cb free_expr0
../../gcc/fortran/expr.c:494
0x68f81d gfc_free_expr(gfc_expr*)
../../gcc/fortran/expr.c:513
0x71b273 gfc_free_charlen(gfc_charlen*, gfc_charlen*)
../../gcc/fortran/symbol.c:3840
0x71b349 gfc_free_namespace(gfc_namespace*)
../../gcc/fortran/symbol.c:3890
0x71b89c gfc_symbol_done_2()
../../gcc/fortran/symbol.c:3926
0x6c33d8 gfc_done_2()
../../gcc/fortran/misc.c:264
0x6e61f6 translate_all_program_units
../../gcc/fortran/parse.c:6057
0x6e61f6 gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x729ee2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

---


Different ICEs using LANG=de_DE.UTF-8, for example :

$ gfortran-7-20161204 -O2 -fcheck=all z1t.f90
f951: internal compiler error: Speicherzugriffsfehler
0xc4940f crash_signal
../../gcc/toplev.c:333
0x856200 process_function_and_variable_attributes
../../gcc/cgraphunit.c:726
0x856200 analyze_functions
../../gcc/cgraphunit.c:1029
0x857e28 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2562

[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #5 from Gerhard Steinmetz  
---
*** Bug 78570 has been marked as a duplicate of this bug. ***

[Bug fortran/78570] ICE in free_expr0, at fortran/expr.c:494

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

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

--- Comment #3 from Gerhard Steinmetz  
---
> The code is supposed to be valid, I guess?
It's valid, and effectively covered via pr68155.

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

[Bug middle-end/78548] [7 Regression ]ICE on valid C code on x86_64-linux-gnu at -O2 and -O3 in 64-bit mode with -Wall (*** Error in `/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1': d

[aldyh at gcc dot gnu.org]

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

--- Comment #7 from Aldy Hernandez  ---
The following patch has been approved to fix this:

https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00039.html

But it depends on the approval pending patch for pr78566.

[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

Version|5.2.1   |7.0

--- Comment #6 from Gerhard Steinmetz  
---
Valid code :

$ cat zz1.f90
program p
   character(3) :: c1(2) = '' // ['b', 'c']
   character(3) :: c2(2) = 'a' // ['b', 'c']
   character(3) :: c3(2) = 'ax' // ['b', 'c']
   character(3) :: c4(2) = 'axy' // ['b', 'c']
   print *, size(c1), len(c1), c1
   print *, size(c2), len(c2), c2
   print *, size(c3), len(c3), c3
   print *, size(c4), len(c4), c4
end

$ gfortran-7-20161204 zz1.f90
$ a.out
   2   3 b  c
   2   3 ab ac
   2   3 axbaxc
   2   3 axyaxy

---


Similar, embedded in a type :

$ cat zz2.f90
program p
   type t
  character(3) :: c1(2) = '' // ['b', 'c']
  character(3) :: c2(2) = 'a' // ['b', 'c']
  character(3) :: c3(2) = 'ax' // ['b', 'c']
  character(3) :: c4(2) = 'axy' // ['b', 'c']
   end type
   type(t) :: z
   print *, size(z%c1), len(z%c1), z%c1
   print *, size(z%c2), len(z%c2), z%c2
   print *, size(z%c3), len(z%c3), z%c3
   print *, size(z%c4), len(z%c4), z%c4
end

$ gfortran-7-20161204 zz2.f90
zz2.f90:13:0:

 end

internal compiler error: in output_constructor_regular_field, at varasm.c:5017
0xf3fcc4 output_constructor_regular_field
../../gcc/varasm.c:5017
0xf3fcc4 output_constructor
../../gcc/varasm.c:5325
0xf3e7c1 output_constant
../../gcc/varasm.c:4702
0xf3e7c1 output_constructor_regular_field
../../gcc/varasm.c:5055
0xf3e7c1 output_constructor
../../gcc/varasm.c:5325
0xf40064 output_constant
../../gcc/varasm.c:4702
0xf40064 assemble_variable_contents
../../gcc/varasm.c:2083
0xf479c9 assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2259
0xf4d1e8 varpool_node::assemble_decl()
../../gcc/varpool.c:588
0x85501b output_in_order
../../gcc/cgraphunit.c:2248
0x8553ed symbol_table::compile()
../../gcc/cgraphunit.c:2488
0x857ea2 symbol_table::compile()
../../gcc/cgraphunit.c:2558
0x857ea2 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2584

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
It's copy_insn_1:

case CLOBBER:
  /* Share clobbers of hard registers (like cc0), but do not share pseudo
reg
 clobbers or clobbers of hard registers that originated as pseudos.
 This is needed to allow safe register renaming.  */
  if (REG_P (XEXP (orig, 0)) && REGNO (XEXP (orig, 0)) <
FIRST_PSEUDO_REGISTER
  && ORIGINAL_REGNO (XEXP (orig, 0)) == REGNO (XEXP (orig, 0)))
return orig;

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
But verify_rtx_sharing also has:

case CLOBBER:
  /* Share clobbers of hard registers (like cc0), but do not share pseudo
reg
 clobbers or clobbers of hard registers that originated as pseudos.
 This is needed to allow safe register renaming.  */
  if (REG_P (XEXP (x, 0)) && REGNO (XEXP (x, 0)) < FIRST_PSEUDO_REGISTER
  && ORIGINAL_REGNO (XEXP (x, 0)) == REGNO (XEXP (x, 0)))
return;
  break;

So why doesn't it return?  Has ORIGINAL_REGNO changed on the hard reg?

[Bug fortran/65173] ICE while compiling wrong code

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #9 from Gerhard Steinmetz  
---
Another example, together with LANG=de_DE.UTF-8 :


$ cat zz1.f90
program p
   type t
  character, allocatable :: z1(:), z1(:)
   end type
end


$ gfortran-7-20161204 -m32 zz1.f90
zz1.f90:3:37-44:

   character, allocatable :: z1(:), z1(:)
 2  1
Error: Component »z1« at (1) already declared at (2)
f951: internal compiler error: Speicherzugriffsfehler
0xc4940f crash_signal
../../gcc/toplev.c:333
0x6f3aea gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6465
0x6f3e45 resolve_operator
../../gcc/fortran/resolve.c:3639
0x6f3e45 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6475
0x6f6f08 resolve_index_expr
../../gcc/fortran/resolve.c:11379
0x6f6f74 resolve_charlen
../../gcc/fortran/resolve.c:11424
0x702da8 resolve_charlen
../../gcc/fortran/resolve.c:13580
0x702da8 resolve_component
../../gcc/fortran/resolve.c:13506
0x702f0a resolve_fl_derived0
../../gcc/fortran/resolve.c:13738
0x7032d7 resolve_fl_derived0
../../gcc/fortran/resolve.c:13122
0x7032d7 resolve_fl_derived
../../gcc/fortran/resolve.c:13815
0x6fe0a7 resolve_symbol
../../gcc/fortran/resolve.c:14146
0x71825b do_traverse_symtree
../../gcc/fortran/symbol.c:3994
0x70125a resolve_types
../../gcc/fortran/resolve.c:15948
0x6fcdac gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16061
0x6e71fa resolve_all_program_units
../../gcc/fortran/parse.c:5977
0x6e71fa gfc_parse_file()
../../gcc/fortran/parse.c:6224
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug fortran/78686] New: ICE in gfc_apply_init, at fortran/expr.c:4124

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78686
   Summary: ICE in gfc_apply_init, at fortran/expr.c:4124
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With invalid code, down to at least 4.8 :


$ cat z1.f90
program p
   type t
  character :: c(1) = [t()]
   end type
end


$ gfortran-7-20161204 z1.f90
f951: internal compiler error: in gfc_apply_init, at fortran/expr.c:4124
0x6911be gfc_apply_init(gfc_typespec*, symbol_attribute*, gfc_expr*)
../../gcc/fortran/expr.c:4124
0x684d98 build_struct
../../gcc/fortran/decl.c:1942
0x684d98 variable_decl
../../gcc/fortran/decl.c:2437
0x684d98 gfc_match_data_decl()
../../gcc/fortran/decl.c:4892
0x6dca79 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6e002e match_word
../../gcc/fortran/parse.c:377
0x6e002e decode_statement
../../gcc/fortran/parse.c:377
0x6e1e34 next_free
../../gcc/fortran/parse.c:1180
0x6e1e34 next_statement
../../gcc/fortran/parse.c:1413
0x6e337a parse_derived
../../gcc/fortran/parse.c:3233
0x6e337a parse_spec
../../gcc/fortran/parse.c:3773
0x6e5bb3 parse_progunit
../../gcc/fortran/parse.c:5615
0x6e71a4 gfc_parse_file()
../../gcc/fortran/parse.c:6124
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #7 from Gerhard Steinmetz  
---
Sequence changed, still ok :

$ cat zz3.f90
program p
   character(3) :: c1(2) = ['b', 'c'] // ''
   character(3) :: c2(2) = ['b', 'c'] // 'a'
   character(3) :: c3(2) = ['b', 'c'] // 'ax'
   character(3) :: c4(2) = ['b', 'c'] // 'axy'
   print *, size(c1), len(c1), c1
   print *, size(c2), len(c2), c2
   print *, size(c3), len(c3), c3
   print *, size(c4), len(c4), c4
end

$ gfortran-7-20161204 zz3.f90
$ a.out
   2   3 b  c
   2   3 ba ca
   2   3 baxcax
   2   3 baxcax

---


Similar, embedded :

$ cat zz4.f90
program p
   type t
  character(3) :: c1(2) = ['b', 'c'] // ''
  character(3) :: c2(2) = ['b', 'c'] // 'a'
  character(3) :: c3(2) = ['b', 'c'] // 'ax'
  character(3) :: c4(2) = ['b', 'c'] // 'axy'
   end type
   type(t) :: z
   print *, size(z%c1), len(z%c1), z%c1
   print *, size(z%c2), len(z%c2), z%c2
   print *, size(z%c3), len(z%c3), z%c3
   print *, size(z%c4), len(z%c4), z%c4
end

$ gfortran-7-20161204 zz4.f90
zz4.f90:13:0:

 end

internal compiler error: in output_constructor_regular_field, at varasm.c:5017
0xf3fcc4 output_constructor_regular_field
../../gcc/varasm.c:5017
0xf3fcc4 output_constructor
../../gcc/varasm.c:5325
0xf3e7c1 output_constant
../../gcc/varasm.c:4702
0xf3e7c1 output_constructor_regular_field
../../gcc/varasm.c:5055
0xf3e7c1 output_constructor
../../gcc/varasm.c:5325
0xf40064 output_constant
../../gcc/varasm.c:4702
0xf40064 assemble_variable_contents
../../gcc/varasm.c:2083
0xf479c9 assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2259
0xf4d1e8 varpool_node::assemble_decl()
../../gcc/varpool.c:588
0xf4de75 varpool_node::assemble_decl()
../../gcc/cgraph.h:2631
0xf4de75 symbol_table::output_variables()
../../gcc/varpool.c:754
0x855a77 symbol_table::compile()
../../gcc/cgraphunit.c:2495
0x857ea2 symbol_table::compile()
../../gcc/cgraphunit.c:2558
0x857ea2 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2584

[Bug middle-end/35361] Missing IPA DCE and DSE

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
This was fixed a couple years ago:
Author: hubicka 
Date:   Fri May 16 17:49:06 2014 +

* varpool.c (dump_varpool_node): Dump write-only flag.
* lto-cgraph.c (lto_output_varpool_node, input_varpool_node): Stream
write-only flag.
* tree-cfg.c (execute_fixup_cfg): Remove statements setting write-only
variables.


* gcc.c-torture/execute/20101011-1.c: Update testcase.
* gcc.dg/ira-shrinkwrap-prep-1.c: Update testcase.
* gcc.dg/tree-ssa/writeonly.c: New testcase.
* gcc.dg/tree-ssa/ssa-dse-6.c: Update testcase.
* gcc.dg/tree-ssa/pr21559.c: Update testcase.
* gcc.dg/debug/pr35154.c: Update testcase.
* gcc.target/i386/vectorize1.c: Update testcase.
* ipa.c (process_references): New function.
(set_readonly_bit): New function.
(set_writeonly_bit): New function.
(clear_addressable_bit): New function.
(ipa_discover_readonly_nonaddressable_var): Mark write only variables;
fix
handling of aliases.
* cgraph.h (struct varpool_node): Add writeonly flag.

[Bug fortran/78686] ICE in gfc_apply_init, at fortran/expr.c:4124

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

Whereas, for example with "real" :


$ cat z2.f90
program p
   type t
  real :: c(1) = [t()]
   end type
end


$ gfortran-7-20161204 z2.f90
z2.f90:3:20:

   real :: c(1) = [t()]
1
Error: Can't convert TYPE(t) to REAL(4) at (1)

[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-05
 Ever confirmed|0   |1

--- Comment #7 from Bill Schmidt  ---
Confirmed with a powerpc64le->x86_64 cross.  The suggested patch looks correct
to me.  Will regtest it shortly.  Thanks for the report!

[Bug fortran/78682] ICE calling (locally) a TBP of a remote CAF derived type

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|WAITING |RESOLVED
 CC||janus at gcc dot gnu.org
  Known to work||7.0
 Resolution|--- |FIXED
   Target Milestone|--- |7.0
  Known to fail||5.4.1, 6.2.1

--- Comment #3 from janus at gcc dot gnu.org ---
I see the ICE with 5.4.1 and 6.2.0, but I can confirm that it is gone on
current trunk.

For which reason do you think the code is invalid?

[Bug target/71607] [5/6/7 Regression] [ARM] ice due to forbidden enabled attribute dependency on instruction operands

[avieira at gcc dot gnu.org]

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

--- Comment #8 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Mon Dec  5 17:36:03 2016
New Revision: 243266

URL: https://gcc.gnu.org/viewcvs?rev=243266&root=gcc&view=rev
Log:
[ARM] PR71607: New approach to arm_disable_literal_pool

gcc/ChangeLog.arm:
2016-12-05  Andre Vieira  

PR target/71607
* config/arm/arm.md (use_literal_pool): Removes.
(64-bit immediate split): No longer takes cost into consideration
if 'arm_disable_literal_pool' is enabled.
* config/arm/arm.c (arm_use_blocks_for_constant_p): New.
(TARGET_USE_BLOCKS_FOR_CONSTANT_P): Define.
(arm_max_const_double_inline_cost): Remove use of
arm_disable_literal_pool.
* config/arm/vfp.md (no_literal_pool_df_immediate): New.
(no_literal_pool_sf_immediate): New.

gcc/testsuite/ChangeLog.arm:
2016-12-05  Andre Vieira  
Thomas Preud'homme  

PR target/71607
* gcc.target/arm/thumb2-slow-flash-data.c: Renamed to ...
* gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
* gcc.target/arm/thumb2-slow-flash-data-2.c: New.
* gcc.target/arm/thumb2-slow-flash-data-3.c: New.
* gcc.target/arm/thumb2-slow-flash-data-4.c: New.
* gcc.target/arm/thumb2-slow-flash-data-5.c: New.


Added:
   
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-1.c
   
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-2.c
   
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-3.c
   
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-4.c
   
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-5.c
Removed:
   
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data.c
Modified:
branches/ARM/embedded-6-branch/gcc/ChangeLog.arm
branches/ARM/embedded-6-branch/gcc/config/arm/arm.c
branches/ARM/embedded-6-branch/gcc/config/arm/arm.md
branches/ARM/embedded-6-branch/gcc/config/arm/vfp.md
branches/ARM/embedded-6-branch/gcc/testsuite/ChangeLog.arm

[Bug target/71721] uclinux posix threads

[law at gcc dot gnu.org]

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

--- Comment #1 from Jeffrey A. Law  ---
Author: law
Date: Mon Dec  5 17:49:41 2016
New Revision: 243269

URL: https://gcc.gnu.org/viewcvs?rev=243269&root=gcc&view=rev
Log:
PR target/71721
* config.gcc (*-*-uclinux*): Enable posix threads.
Adding BZ marker

Modified:
trunk/gcc/ChangeLog

[Bug target/71721] uclinux posix threads

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Fixed by Waldemar's patch on the trunk.

[Bug c/78666] conflicting attribute alloc_size accepted

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-05
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
diagnose_mismatched_attributes should diagnose this -- it needs to look at
TYPE_ATTRIBUTES, too.  At least assume_aligned and alloc_align should be
diagnosed, too.

[Bug c/78666] conflicting attribute alloc_size accepted

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
And nonnull, sentinel, destructor, constructor too.

[Bug tree-optimization/78681] [7 Regressions] ICE in determine_value_range, at tree-ssa-loop-niter.c:413

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Seems like j_16(D) ends up having VR_RANGE [127, 126].  This range seems to
come from ipcp_update_vr.

[Bug tree-optimization/78681] [7 Regressions] ICE in determine_value_range, at tree-ssa-loop-niter.c:413

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Yeah:
--- gcc/ipa-prop.c.jj   2016-11-25 18:11:05.0 +0100
+++ gcc/ipa-prop.c  2016-12-05 18:48:48.853882864 +0100
@@ -5709,8 +5709,23 @@ ipcp_update_vr (struct cgraph_node *node
{
  tree type = TREE_TYPE (ddef);
  unsigned prec = TYPE_PRECISION (type);
+ unsigned mprec = wi::get_precision (vr[i].min);
+ gcc_assert (mprec == wi::get_precision (vr[i].max));
  if (INTEGRAL_TYPE_P (TREE_TYPE (ddef)))
{
+ if (prec < mprec)
+   {
+ /* If there is a disagreement between callers and callee
+on the argument type, e.g. when using K&R function
+definitions, punt if vr[i].min or vr[i].max are outside
+of type's precision.  */
+ wide_int m = wi::ext (vr[i].min, prec, TYPE_SIGN (type));
+ if (m != vr[i].min)
+   continue;
+ m = wi::ext (vr[i].max, prec, TYPE_SIGN (type));
+ if (m != vr[i].max)
+   continue;
+   }
  if (dump_file)
{
  fprintf (dump_file, "Setting value range of param %u ", i);
@@ -5729,6 +5744,7 @@ ipcp_update_vr (struct cgraph_node *node
}
  else if (POINTER_TYPE_P (TREE_TYPE (ddef))
   && vr[i].type == VR_ANTI_RANGE
+  && mprec <= prec
   && wi::eq_p (vr[i].min, 0)
   && wi::eq_p (vr[i].max, 0))
{
works for me (i.e. if the callers expect higher precision and the range doesn't
fit into the smaller type, punt).
Not sure if one can construct a testcase where prec == mprec, but the
signedness differ (either vr[i].min/vr[i].max is from signed type and type is
unsigned, or vice versa).  Tried:
static void foo (int, unsigned int);

static int
foo (x, y)
  unsigned int x;
  int y;
{
  return x + y;
}

void
bar (int x, unsigned int y)
{
  if (x < - __INT_MAX__ + 3 || x >= __INT_MAX__ - 19)
return;
  if (y < 5 || y >= ~19U)
return;
  x++;
  y++;
  foo (x, y);
  x++;
  y++;
  foo (x, y);
}

but that is rejected.

[Bug c++/78647] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: tree check: expected tree_list, have error_mark in get_attribute_name, at attribs.c:664)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-05
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

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

[Bug target/72742] [7 Regression] ICE in extract_insn, at recog.c:2309 (error: unrecognizable insn) w/ -Os -mlra

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-05
 CC||aldyh at gcc dot gnu.org,
   ||bergner at gcc dot gnu.org,
   ||rguenther at suse dot de,
   ||vmakarov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
Confirmed.  Started with the commit below, though I doubt it has anything to do
with generic changes to the compiler. It looks like an LRA/backend problem.

commit 410372fef14173261ce8e547db98eafb3174921f
Author: rguenth 
Date:   Thu May 19 07:39:52 2016 +

2016-05-19  Richard Biener  

PR tree-optimization/70729
* passes.def: Move LIM pass before PRE.  Remove no longer
required copyprop and move first DCE out of the loop pipeline.

* gcc.dg/autopar/outer-6.c: Adjust to avoid redundant store.
* gcc.dg/graphite/scop-18.c: Likewise.
* gcc.dg/pr41783.c: Disable LIM.
* gcc.dg/tree-ssa/loadpre10.c: Likewise.
* gcc.dg/tree-ssa/loadpre23.c: Likewise.
* gcc.dg/tree-ssa/loadpre24.c: Likewise.
* gcc.dg/tree-ssa/loadpre25.c: Likewise.
* gcc.dg/tree-ssa/loadpre4.c: Likewise.
* gcc.dg/tree-ssa/loadpre8.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-16.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-18.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-20.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-3.c: Likewise.
* gfortran.dg/pr42108.f90: Likewise.

[Bug fortran/65173] ICE while compiling wrong code

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #9)
> Another example, together with LANG=de_DE.UTF-8 :
> 
> 
> $ cat zz1.f90
> program p
>type t
>   character, allocatable :: z1(:), z1(:)
>end type
> end
> 
> 
> $ gfortran-7-20161204 -m32 zz1.f90
> zz1.f90:3:37-44:
> 
>character, allocatable :: z1(:), z1(:)
>  2  1
> Error: Component »z1« at (1) already declared at (2)
> f951: internal compiler error: Speicherzugriffsfehler
> 0xc4940f crash_signal
> ../../gcc/toplev.c:333
> 0x6f3aea gfc_resolve_expr(gfc_expr*)
> ../../gcc/fortran/resolve.c:6465

(gdb) bt
(gdb) bt
#0  gfc_is_constant_expr (e=0x837f) at ../../gcc7/gcc/fortran/expr.c:894
#1  0x0065a320 in resolve_component (c=0x20365f8c0, sym=0x203635f00)
at ../../gcc7/gcc/fortran/resolve.c:13507
#2  0x0065a9ab in resolve_fl_derived0 (sym=sym@entry=0x203635f00)
at ../../gcc7/gcc/fortran/resolve.c:13738
...
(gdb) up
#1  0x0065a320 in resolve_component (c=0x20365f8c0, sym=0x203635f00)
at ../../gcc7/gcc/fortran/resolve.c:13507
13507|| !gfc_is_constant_expr (c->ts.u.cl->length))
(gdb) p *c->ts.u.cl
$5 = {length = 0x837f, next = 0x20362b5d0, length_from_typespec = false, 
  backend_decl = 0x2039d8040, passed_length = 0x0, resolved = 56844672}

length=0x837f is an invalid pointer.  So, gfortran ICE's.  This 
looks similar to the fight that Janus waged this weekend.  For
some reason, a CHARACTER(LEN=) component in a derived type
does not set the length correctly.

[Bug tree-optimization/78687] New: inefficient code generated for eggs.variant

[vanyacpp at gmail dot com]

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

Bug ID: 78687
   Summary: inefficient code generated for eggs.variant
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Created attachment 40254
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40254&action=edit
gcc-eggs-variant-missing-opt.cpp

I have a piece of code that actively uses library called Eggs.Variant. It is a
library that implements C++17-like variant class. Profiling of this piece of
code revealed that the generated code for the most expensive function is quite
inefficient. Here is the generated code (with percentage of time spent in each
instruction and my comments):

 Percent |  Source code & Disassembly of a.out for cycles:pp

 :  ref_proxy > f()
 :  {
0.00 :400710:   sub$0x140,%rsp
0.00 :400717:   mov%rdi,%rax
1.54 :40071a:   movq   $0x2,0x28(%rdi)
0.00 :400722:   movl   $0x0,0x128(%rsp)
   22.36 :40072d:   mov0x128(%rsp),%rdx
!!! reading of stack memory immediately after writing to it
1.63 :400735:   mov%rdx,0xe8(%rsp)
0.00 :40073d:   movl   $0x0,0xe8(%rsp)
!!! writing 0 immediately after writing some other value to it
   22.74 :400748:   mov0xe8(%rsp),%rdx
1.59 :400750:   mov%rdx,0xa8(%rsp)
0.00 :400758:   movl   $0x0,0xa8(%rsp)
   22.72 :400763:   mov0xa8(%rsp),%rdx
!!! writing 0 immediately after writing some other value to it, then reading
from it
2.16 :40076b:   mov%rdx,0x128(%rsp)
0.00 :400773:   mov-0x78(%rsp),%rdx
0.00 :400778:   movl   $0x0,0x128(%rsp)
!!! writing some value to stack memory, then writing 0 to it
0.01 :400783:   mov%rdx,(%rdi)
1.66 :400786:   mov-0x70(%rsp),%rdx
0.00 :40078b:   mov%rdx,0x8(%rdi)
0.00 :40078f:   mov-0x68(%rsp),%rdx
0.01 :400794:   mov%rdx,0x10(%rdi)
1.72 :400798:   mov-0x60(%rsp),%rdx
0.00 :40079d:   mov%rdx,0x18(%rdi)
0.00 :4007a1:   mov-0x58(%rsp),%rdx
0.02 :4007a6:   mov%rdx,0x20(%rdi)
   20.15 :4007aa:   mov0x128(%rsp),%rdx
!!! again reading stack memory where 0 was written several instruction ago
1.68 :4007b2:   mov%rdx,0x30(%rdi)
0.00 :4007b6:   add$0x140,%rsp
0.00 :4007bd:   retq   

Initially I thought that there must be some aliasing issue. But the memory
accessed is the memory of local variables. The program doesn't use volatile
qualifier either. And aliasing does not explain why compiler did two writes to
the same memory location in a row. As you can see this function does not little
more than copying data from one memory location to another.

It turned out that clang generates much better code for the function:

 Percent |  Source code & Disassembly of a.out for cycles:pp

   31.86 :400670:   movq   $0x2,0x28(%rdi)
   32.27 :400678:   movl   $0x0,0x30(%rdi)
0.23 :40067f:   mov%rdi,%rax
   35.65 :400682:   retq   

Unfortunately I didn't manage to make a small snippet to reproduce the issue.
The attached file is quite big (about 500 lines long), still I hope it allows
reproducing the issue.

The command line I used is:
g++ -pthread -Wall -O2 -g -DNDEBUG -fvisibility=hidden -std=gnu++14
gcc-eggs-variant-missing-opt.cpp

The compiler version was 6.2.

[Bug c++/78621] lambda mangling not ABI compliant

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Created attachment 40255
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40255&action=edit
squangling too

This testcase shows problems with the mangling of auto parms themeselves, and
with subsequent fallout of squangling references.  The two forwarding function
instantiations should mangle similarly (with 'i'->'Da' substitution), but they
mangle quite differently.

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
It still happens here, also on gcc110.  Note you need --disable-werror,
to avoid another bootstrap error.

Did you perchance use --disable-bootstrap?