[Bug bootstrap/81459] New: GNAT 7.1.0 build failed on the Debian 9/x86_64

[barbos at inbox dot ru]

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

Bug ID: 81459
   Summary: GNAT 7.1.0 build failed on the Debian 9/x86_64
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barbos at inbox dot ru
  Target Milestone: ---

The build of GNAT 7.1 failed:

$ uname -a
Linux softlab2 4.9.0-2-amd64 #1 SMP Debian 4.9.18-1 (2017-03-30) x86_64
GNU/Linux

$ gnat --version
GNAT GPL 2016 (20160515-49)
...

$ ../gcc-7.1.0/configure --enable-languages=ada
$ make

gcc -c -I./
-I/opt/gnat/lib/gcc/x86_64-pc-linux-gnu/4.9.4/rts-native/adalib/../adainclude
-I/opt/gnat/lib/gcc/x86_64-pc-linux-gnu/4.9.4/rts-native/adalib -I.
-I/home/pum/Projects/xgcc/gcc-7.1.0/gcc/ada -g -O2 -W -Wall -gnatpg -gnata -I-
/home/pum/Projects/xgcc/gcc-7.1.0/gcc/ada/err_vars.ads
gcc -c -I./
-I/opt/gnat/lib/gcc/x86_64-pc-linux-gnu/4.9.4/rts-native/adalib/../adainclude
-I/opt/gnat/lib/gcc/x86_64-pc-linux-gnu/4.9.4/rts-native/adalib -I.
-I/home/pum/Projects/xgcc/gcc-7.1.0/gcc/ada -g -O2 -W -Wall -gnatpg -gnata -I-
/home/pum/Projects/xgcc/gcc-7.1.0/gcc/ada/restrict.adb
restrict.adb:1199:46: "Restricted_Tasking" not declared in "Rident"
restrict.adb:1201:46: "Restricted_Tasking" not declared in "Rident"
gnatmake: "/home/pum/Projects/xgcc/gcc-7.1.0/gcc/ada/restrict.adb" compilation
error
../gcc-interface/Makefile:2640: recipe for target 'gnatmake-re' failed
make[3]: *** [gnatmake-re] Error 4
make[3]: Leaving directory '/home/pum/Projects/xgcc/build-gcc/gcc/ada/tools'
Makefile:215: recipe for target 'gnattools-cross' failed
make[2]: *** [gnattools-cross] Error 2
make[2]: Leaving directory '/home/pum/Projects/xgcc/build-gcc/gnattools'
Makefile:10872: recipe for target 'all-gnattools' failed
make[1]: *** [all-gnattools] Error 2
make[1]: Leaving directory '/home/pum/Projects/xgcc/build-gcc'
Makefile:885: recipe for target 'all' failed
make: *** [all] Error 2

[Bug target/81317] builtin_vec_ld fails for powerpc with altivec

[randy.macleod at windriver dot com]

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

--- Comment #17 from Randy MacLeod  ---
Back from vacation, I plan to test the latest patch this week.

[Bug tree-optimization/35503] Warning about restricted pointers?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #11 from Martin Sebor  ---
The following patch (submitted under bug 78918) extends -Wrestrict to the
middle-end letting the warning detect more involved aliasing violations.  It
also includes -Wrestrict in -Wall.
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00917.html

[Bug middle-end/78918] missing -Wrestrict on memcpy copying over self

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00917.html

[Bug rtl-optimization/81424] [7/8 regression] internal error on GPRbuild with -O2

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug rtl-optimization/81424] [7/8 regression] internal error on GPRbuild with -O2

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
Author: ebotcazou
Date: Sun Jul 16 22:07:15 2017
New Revision: 250247

URL: https://gcc.gnu.org/viewcvs?rev=250247=gcc=rev
Log:
PR rtl-optimization/81424
* optabs.c (prepare_cmp_insn): Use copy_to_reg instead of force_reg
to remove potential trapping from operands if -fnon-call-exceptions.

Added:
branches/gcc-7-branch/gcc/testsuite/gnat.dg/opt65.adb   (props changed)
  - copied unchanged from r250246, trunk/gcc/testsuite/gnat.dg/opt65.adb
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/optabs.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-7-branch/gcc/testsuite/gnat.dg/opt65.adb
('svn:mergeinfo' added)

[Bug other/81458] Misdetection of gcc_cv_as_cfi_advance_working

[joerg at netbsd dot org]

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

--- Comment #1 from Joerg Sonnenberger  ---
Created attachment 41769
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41769=edit
Using readelf in configure.ac (against 5.4.0)

[Bug other/81458] New: Misdetection of gcc_cv_as_cfi_advance_working

[joerg at netbsd dot org]

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

Bug ID: 81458
   Summary: Misdetection of gcc_cv_as_cfi_advance_working
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg at netbsd dot org
  Target Milestone: ---

Created attachment 41768
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41768=edit
Problematic object file

The gcc_cv_as_cfi_advance_working test case can misdetect support due to bugs
in objdump. Please consider switching to readelf instead. Attached is the
assembled test case from NetBSD.

readelf --debug-dump=frames gives:

0018 0018 001c FDE cie= pc=..00012520
  DW_CFA_advance_loc4: 75040 to 00012520
  DW_CFA_def_cfa_offset: 192
...

and objdump -Wf gives:

0018 0018 001c FDE cie=
pc=00012520..c00f252125200400
  Augmentation data: 00

  DW_CFA_nop
  DW_CFA_nop

[Bug rtl-optimization/81424] [7/8 regression] internal error on GPRbuild with -O2

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
Author: ebotcazou
Date: Sun Jul 16 22:03:54 2017
New Revision: 250246

URL: https://gcc.gnu.org/viewcvs?rev=250246=gcc=rev
Log:
PR rtl-optimization/81424
* optabs.c (prepare_cmp_insn): Use copy_to_reg instead of force_reg
to remove potential trapping from operands if -fnon-call-exceptions.

Added:
trunk/gcc/testsuite/gnat.dg/opt65.adb
Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c
trunk/gcc/testsuite/ChangeLog

[Bug other/81457] New: Inconsistent section flags for section attribute

[joerg at netbsd dot org]

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

Bug ID: 81457
   Summary: Inconsistent section flags for section attribute
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg at netbsd dot org
  Target Milestone: ---

Created attachment 41767
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41767=edit
Potential fix, relative to GCC 5.4.0.

Assemble the following input for any ELF target:

__attribute__((section("foo1s"))) const int foo1;
__attribute__((section("foo2s"))) const int foo2 = 42;

Note that foo1s has flags "AW", but foo2s has flags "A".

Bug reproduces on the GCC snapshot option of godbolt.org. The attached patch
applies against GCC 5.4.0, it might need shuffling for newer versions. The
additional null checks are required for correct handling of e.g. __thread
variables.

[Bug lto/81430] nvptx acceleration compilation broken because of running pass_partition_blocks

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-16
 Ever confirmed|0   |1

--- Comment #3 from Thomas Schwinge  ---
Per my testing, r249070 is causing the regressions listed below.  Looking at a
few cases, we're running into:

[...]/libgomp.oacc-c-c++-common/vector-type-1.c: In function
'main._omp_fn.0':
[...]/libgomp.oacc-c-c++-common/vector-type-1.c:7:9: sorry, unimplemented:
target cannot support label values
 #pragma acc parallel copy(vi)
 ^
[...]/libgomp.oacc-c-c++-common/vector-type-1.c:7:9: sorry, unimplemented:
indirect jumps are not available on this target

Program received signal SIGSEGV, Segmentation fault.
fix_crossing_unconditional_branches () at [...]/gcc/bb-reorder.c:2215
2215  JUMP_LABEL (jump_insn) = label;
(gdb) bt
#0  fix_crossing_unconditional_branches () at [...]/gcc/bb-reorder.c:2215
#1  (anonymous namespace)::pass_partition_blocks::execute (this=, fun=0x76956000) at [...]/gcc/bb-reorder.c:2910
#2  0x0098364d in execute_one_pass (pass=pass@entry=0x1725070) at
[...]/gcc/passes.c:2491
#3  0x00983f18 in execute_pass_list_1 (pass=0x1725070) at
[...]/gcc/passes.c:2580
#4  0x00983f2a in execute_pass_list_1 (pass=0x1724470) at
[...]/gcc/passes.c:2581
#5  0x00983f75 in execute_pass_list (fn=,
pass=) at [...]/gcc/passes.c:2591
#6  0x00635217 in cgraph_node::expand
(this=this@entry=0x76952000) at [...]/gcc/cgraphunit.c:2050
#7  0x00636bbc in expand_all_functions () at
[...]/gcc/cgraphunit.c:2186
#8  symbol_table::compile (this=0x76888000) at
[...]/gcc/cgraphunit.c:2543
#9  0x006370a6 in symbol_table::compile (this=) at
[...]/gcc/cgraphunit.c:2576
#10 0x00593462 in lto_main () at [...]/gcc/lto/lto.c:3334
#11 0x00a5ad8f in compile_file () at [...]/gcc/toplev.c:468
#12 0x00560e82 in do_compile () at [...]/gcc/toplev.c:2021
#13 toplev::main (this=this@entry=0x7fffcfb0, argc=argc@entry=19,
argv=0x16fc7d0, argv@entry=0x7fffd0b8) at [...]/gcc/toplev.c:2155
#14 0x005632f7 in main (argc=19, argv=0x7fffd0b8) at
[...]/gcc/main.c:39

Tom's patch (plus '#include "common/common-target.h"') does cure this.

List of regressions:

[-PASS:-]{+FAIL: libgomp.c/examples-4/async_target-2.c (internal compiler
error)+}
{+FAIL:+} libgomp.c/examples-4/async_target-2.c (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/examples-4/async_target-2.c [-execution
test-]{+compilation failed to produce executable+}

[-PASS:-]{+FAIL: libgomp.c/examples-4/target-5.c (internal compiler
error)+}
{+FAIL:+} libgomp.c/examples-4/target-5.c (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/examples-4/target-5.c [-execution
test-]{+compilation failed to produce executable+}

[-PASS:-]{+FAIL: libgomp.c/examples-4/target_data-6.c (internal compiler
error)+}
{+FAIL:+} libgomp.c/examples-4/target_data-6.c (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/examples-4/target_data-6.c [-execution
test-]{+compilation failed to produce executable+}

[-PASS:-]{+FAIL: libgomp.c/examples-4/target_data-7.c (internal compiler
error)+}
{+FAIL:+} libgomp.c/examples-4/target_data-7.c (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/examples-4/target_data-7.c [-execution
test-]{+compilation failed to produce executable+}

[-PASS:-]{+FAIL: libgomp.c/target-3.c (internal compiler error)+}
{+FAIL:+} libgomp.c/target-3.c (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/target-3.c [-execution
test-]{+compilation failed to produce executable+}

[-PASS:-]{+FAIL: libgomp.c/target-4.c (internal compiler error)+}
{+FAIL:+} libgomp.c/target-4.c (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/target-4.c [-execution
test-]{+compilation failed to produce executable+}

[-PASS:-]{+FAIL: libgomp.c/target-5.c (internal compiler error)+}
{+FAIL:+} libgomp.c/target-5.c (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/target-5.c [-execution
test-]{+compilation failed to produce executable+}

[-PASS:-]{+FAIL: libgomp.c/target-6.c (internal compiler error)+}
{+FAIL:+} libgomp.c/target-6.c (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/target-6.c [-execution
test-]{+compilation failed to produce executable+}

[-PASS:-]{+FAIL: libgomp.c/target-7.c (internal compiler error)+}
{+FAIL:+} libgomp.c/target-7.c (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/target-7.c [-execution
test-]{+compilation failed to produce executable+}

{+FAIL: 

[Bug rtl-optimization/81424] [7/8 regression] internal error on GPRbuild with -O2

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
Fixing.

[Bug rtl-optimization/81424] [7/8 regression] internal error on GPRbuild with -O2

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|ada |rtl-optimization
Summary|[7 regression]  internal|[7/8 regression]  internal
   |error on GPRbuild with -O2  |error on GPRbuild with -O2

--- Comment #4 from Eric Botcazou  ---
Recategorizing.

[Bug ada/81424] [7 regression] internal error on GPRbuild with -O2

[bj...@xn--rombobjrn-67a.se]

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

--- Comment #3 from Björn Persson  ---
Well it is permissible to change the compilation options if there is a really
good reason. If another optimization level works around the bug, then I think
we can append for example -O1 until the bug is fixed.

[Bug ada/81424] [7 regression] internal error on GPRbuild with -O2

[pavel at zhukoff dot net]

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

--- Comment #2 from Pavel Zhukov  ---
(In reply to Eric Botcazou from comment #1)
> Confirmed, but how can it block anything since the workaround is trivial?

Thanks Eric.

We have to use compiler/linker flags provided by distribution's macros and they
include O2 [1]. While we can change gnat specific flags relatively easy global
optflags is distribution wide.

Ada packaging guidelines:
https://fedoraproject.org/wiki/Packaging:Ada

[1]  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
https://fedoraproject.org/wiki/Packaging:RPMMacros#Build_flags_macros_and_variables

[Bug target/81456] New: x86-64 optimizer makes wrong decision when optimizing for size

[cody at codygray dot com]

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

Bug ID: 81456
   Summary: x86-64 optimizer makes wrong decision when optimizing
for size
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cody at codygray dot com
  Target Milestone: ---
Target: x86_64

Consider the following code (doesn't matter if you compile it as C or C++):

#include 
int Bounce(int a, int b)
{
int mod = abs(a % b);
return (a/b % 2) ? b-mod : mod;
}

When optimizing for speed (whether -O1, -O2, or -O3), this is compiled to the
following x86-64 machine code:

Bounce(int, int):
movl%edi, %eax

cltd
idivl   %esi
movl%edx, %ecx
sarl$31, %ecx
xorl%ecx, %edx
subl%ecx, %edx

subl%edx, %esi
testb   $1, %al
cmovne  %esi, %edx
movl%edx, %eax
ret

That output is observed as far back as (at least) GCC 4.8, and all the way up
to the current 8.0 preview I have (8.0.0 20170716).

However, when optimizing for size (-Os), the same function produces this
output:

Bounce:
movl%edi, %eax

cltd
idivl   %esi
movl%edx, %ecx
sarl$31, %ecx
xorl%ecx, %edx
subl%ecx, %edx

testb   $1, %al
je  .L1
subl%edx, %esi
movl%esi, %edx
.L1:
movl%edx, %eax
ret

This defies expectations because it is actually *larger* (more bytes) than the
version optimized for speed. The JE instruction in this version is 2 bytes, as
is each MOVL instruction, making that section 6 bytes total. However, in the
version optimized for speed, the CMOVNE instruction is 3 bytes, plus a 2-byte
MOVL, for 5 bytes total. (The SUBL instruction there is required either way.)

Now, one byte obviously isn't a big deal in terms of total size, except that
the CMOV version is more performant, so even if these two versions were exactly
the same size, it should be used in preference to the branching version! (The
optimizer has no reason to suspect that the quotient in the division will be
predictably odd or even, so a non-branching conditional move is most
appropriate to get the best worst-case performance.)

I notice that this is a regression post-GCC 6.3. In other words, GCC 6.3
generates the same code for -Os and -O1/-O2/-O3. I don't have GCC 7.0
available, so GCC 7.1 is the first version I have available that reproduces the
described behavior. It continues to be there, as I said, in GCC 8.

This also is *not* observed when targeting 32-bit x86. You get conditional
moves when the target architecture supports them (P6 and later). So this
affects only x86-64, where conditional moves are *always* available.

[Bug tree-optimization/81455] New: [7/8 Regression] Compile-time hog w/ -O1 -funswitch-loops

[asolokha at gmx dot com]

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

Bug ID: 81455
   Summary: [7/8 Regression] Compile-time hog w/ -O1
-funswitch-loops
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 7.1, as well as gcc-8.0.0-alpha20170709 snapshot, takes indefinite time
when compiling the following snippet w/ -O1 -funswitch-loops:

void
jh (unsigned int aw, int sn)
{
  int xs;

  for (xs = 0; xs < 1; ++xs)
aw &= 1;

  while (aw < 1 || ++sn < 1)
{
}
}

[Bug pch/15351] Add option for caching headers

[pskocik at gmail dot com]

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

pskocik at gmail dot com changed:

   What|Removed |Added

 CC||pskocik at gmail dot com

--- Comment #3 from pskocik at gmail dot com ---
>From my reading of the manual, which talks about a *.gch precompiled-header
directory, it seems to me like gcc would be in the perfect position to manage
that directory itself. If the directory has a header matching the current
compiler config, it should use it, otherwise, it should create a new entry and
use that.

The user could simply tell gcc which header it wants precompiled and gcc could
take care of creating the precompiled versions in the appropriate gch directory
as needed.

(If gcc were to manage the *.gch directory itself, it wouldn't also need to try
all directory entries until a match is found -- it could aim directly, based
its established naming system for the entries. The naming system could be such
so that entries from uninstalled compiler versions could be automatically or
manually deleted.)

The cache directories could be in the same directory as the found header, or in
a per-user system-directory that pararellizes the path of the found header in
case the directory of the found header isn't writable by the current user.

[Bug middle-end/81030] [8 Regression] ICE on valid code at -O1 (only) on x86_64-linux-gnu: verify_flow_info failed

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||babokin at gmail dot com

--- Comment #8 from Tom de Vries  ---
*** Bug 81332 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/81332] GCC crash during "RTL pass: expand" - verify_flow_info: REG_BR_PROB does not match cfg

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #3 from Tom de Vries  ---
As per PR81030 comment 7, marking this a duplicate of PR81030.

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

[Bug middle-end/81030] [8 Regression] ICE on valid code at -O1 (only) on x86_64-linux-gnu: verify_flow_info failed

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to Tom de Vries from comment #6)
> Commenting out the else clause gets rid of the ICE.

Same for PR81332, marking it duplicate.