[Bug middle-end/71002] [6 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
Author: rguenth
Date: Wed Jun 29 07:30:31 2016
New Revision: 237839

URL: https://gcc.gnu.org/viewcvs?rev=237839&root=gcc&view=rev
Log:
2016-06-29  Richard Biener  

PR middle-end/71002
* alias.c (component_uses_parent_alias_set_from): Handle
type punning through union accesses by using the union alias set.
* gimple.c (gimple_get_alias_set): Remove union type punning case.

c-family/
* c-common.c (c_common_get_alias_set): Remove union type punning case.

fortran/
* f95-lang.c (LANG_HOOKS_GET_ALIAS_SET): Remove (un-)define.
(gfc_get_alias_set): Remove.

* g++.dg/torture/pr71002.C: Adjust testcase.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/f95-lang.c
trunk/gcc/gimple.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/torture/pr71002.C

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

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Wed Jun 29 07:52:35 2016
New Revision: 237840

URL: https://gcc.gnu.org/viewcvs?rev=237840&root=gcc&view=rev
Log:
2016-06-29  Richard Biener  

PR rtl-optimization/68961
* simplify-rtx.c (simplify_subreg): Handle VEC_CONCAT like CONCAT.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c

[Bug inline-asm/68095] "cc" clobber with Flag Output Operands

[jbeulich at novell dot com]

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

jbeulich at novell dot com changed:

   What|Removed |Added

 CC||jbeulich at novell dot com

--- Comment #7 from jbeulich at novell dot com ---
I don't think duplicate clobber specifications should be an error. Otherwise
you'd be limiting (or complicating) the use in (perhaps multiple nested levels
of) macros.

And the traditional x86 behavior of always clobbering CC and FPSR isn't really
set in stone: As previously proposed
(https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03251.html) an "inverse" clobber
could be used to suppress that behavior. I'm in the process of updating that
patch for re-submission.

Finally I'd like to note that for me in plain 6.1.0

void test(void)
{
  int v;

  asm ("" : "=@ccz" (v) :: "cc");
  asm ("" : "=@ccz" (v) :: "flags");
}

causes an internal compiler error due to expand_asm_stmt()'s initial conflict
checking (3rd pass) being insufficient for the final check (when about to store
the clobbers) to not trigger. A possible x86-specific approach might be to
detect and report the conflict in ix86_md_asm_adjust() and remove the bad
clobber there. But a generic approach would seem better, yet I have no idea how
that would need to be done.

[Bug fortran/71688] ICE in analyze, at cgraphunit.c:632

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-29
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, regression starts with GCC 4.9.0.

  4.7.0: running command with result: OK
  4.7.1: running command with result: OK
  4.7.2: running command with result: OK
  4.7.3: running command with result: OK
  4.7.4: running command with result: OK
  4.8.0: running command with result: OK
  4.8.1: running command with result: OK
  4.8.2: running command with result: OK
  4.8.3: running command with result: OK
  4.8.4: running command with result: OK
  4.8.5: running command with result: OK
  4.9.0: running command with result: FAILED
  4.9.1: running command with result: FAILED
  4.9.2: running command with result: FAILED
  4.9.3: running command with result: FAILED
  5.1.0: running command with result: FAILED
  5.2.0: running command with result: FAILED
  5.3.0: running command with result: FAILED
  6.1.0: running command with result: FAILED

[Bug fortran/71687] ICE in omp_add_variable, at gimplify.c:5821

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-29
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started from GCC 4.7.0.

[Bug fortran/69281] gfortran ICE on temporary array in function call with -fstack-arrays -fopenmp

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started in 4.7.0, where -fstack-arrays option was added.

[Bug tree-optimization/71691] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Floating point exception)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed that -m64 started to fail with GCC 6.1.0.

[Bug tree-optimization/71625] missing strlen optimization on different array initialization style

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun 29 08:47:46 2016
New Revision: 237841

URL: https://gcc.gnu.org/viewcvs?rev=237841&root=gcc&view=rev
Log:
PR tree-optimization/71625
* tree-ssa-strlen.c (get_addr_stridx): Add PTR argument.  Assume list
is sorted by ascending list->offset.  If PTR is non-NULL and there is
previous strinfo, call get_stridx_plus_constant.
(get_stridx): Pass exp as second argument to get_addr_stridx.
(addr_stridxptr): Add missing list = list->next, so that there can be
more than one entries in the list.  Bump limit from 16 to 32.  Ensure
the list is sorted by ascending list->offset.
(get_stridx_plus_constant): Adjust so that it can be also called with
ADDR_EXPR instead of SSA_NAME as PTR.
(handle_char_store): Pass NULL_TREE as second argument to
get_addr_stridx.

* gcc.dg/strlenopt-28.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/strlenopt-28.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug fortran/71688] [4.9/5/6/7 Regression] ICE in analyze, at cgraphunit.c:632 with -fcoarray=lib

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jamborm at gcc dot gnu.org
  Known to work||4.8.5
Summary|ICE in analyze, at  |[4.9/5/6/7 Regression] ICE
   |cgraphunit.c:632|in analyze, at
   ||cgraphunit.c:632 with
   ||-fcoarray=lib
  Known to fail||4.9.3, 5.4.0, 6.1.0, 7.0

--- Comment #3 from Dominique d'Humieres  ---
> Confirmed, regression starts with GCC 4.9.0.
> ...

The change occurred between revisions r201266 (2013-07-26, OK) and r201631
(2013-08-09, ICE), likely r201526 (pr57987).

[Bug go/71692] New: Running target unix FAIL: syscall

[horta at ebi dot ac.uk]

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

Bug ID: 71692
   Summary: Running target unix FAIL: syscall
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: horta at ebi dot ac.uk
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 38784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38784&action=edit
It contains libgo.log and libgo.sum, regarding only to go compilation but it
also contains all the errors reported by gcc in check.log

$ uname -a
Linux hh-yoda-11-01.ebi.ac.uk 3.10.0-229.14.1.el7.x86_64 #1 SMP Tue Aug 25
11:21:22 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
LSB Version:   
:core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: RedHatEnterpriseServer
Description:Red Hat Enterprise Linux Server release 7.1 (Maipo)
Release:7.1
Codename:   Maipo

And I performed the following commands:

$ cd gcc-6.1.0
$ ./contrib/download_prerequisites
$ cd ..
$ mkdir build
$ cd build
$ ../gcc-6.1.0/configure --prefix=$BASESYS --enable-languages=c,c++,fortran,go
--disable-multilib --with-system-zlib
$ make
$ make -k check


$ ../gcc-6.1.0/contrib/test_summary
 test summary results

cat <<'EOF' |
LAST_UPDATED: Obtained from SVN: tags/gcc_6_1_0_release revision 235474

Native configuration is x86_64-pc-linux-gnu

=== libgo tests ===


Running target unix
FAIL: syscall

=== libgo Summary ===

# of expected passes133
# of unexpected failures1
/hps/nobackup/stegle/users/horta/tmp/build/./gcc/gccgo version 6.1.0 (GCC)

Compiler version: 6.1.0 (GCC) libgo
Platform: x86_64-pc-linux-gnu
configure flags: --prefix=/nfs/software/stegle/basesys
--enable-languages=c,c++,fortran,go --disable-multilib --with-system-zlib
EOF
Mail -s "Results for 6.1.0 (GCC) libgo testsuite on x86_64-pc-linux-gnu"
gcc-testresu...@gcc.gnu.org &&
mv
/hps/nobackup/stegle/users/horta/tmp/build/./x86_64-pc-linux-gnu/libgo/libgo.sum
/hps/nobackup/stegle/users/horta/tmp/build/./x86_64-pc-linux-gnu/libgo/libgo.sum.sent
&&
mv
/hps/nobackup/stegle/users/horta/tmp/build/./x86_64-pc-linux-gnu/libgo/libgo.log
/hps/nobackup/stegle/users/horta/tmp/build/./x86_64-pc-linux-gnu/libgo/libgo.log.sent
&&
true
 test summary results

[Bug c++/53646] Surprising effects of cxx11 vs cxx98 ABI compatibility

[paolo.carlini at oracle dot com]

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

--- Comment #22 from Paolo Carlini  ---
Not sure if we still want to keep this open!?! Anyone willing to comment /
summarize?

[Bug middle-end/71693] New: ICE: verify_gimple failed (type mismatch in shift expression, -O0, -O1, -O2, -O3)

[niva at niisi dot msk.ru]

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

Bug ID: 71693
   Summary: ICE: verify_gimple failed (type mismatch in shift
expression, -O0, -O1, -O2, -O3)
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niva at niisi dot msk.ru
  Target Milestone: ---

Created attachment 38785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38785&action=edit
The source file to reproduce the problem.

The error is reproduced with gcc 5.4.0 (and also with earlier versions: 5.3.1,
4.7.4).

Target: x86_64-unknown-linux-gnu
Configured with: /home/niva/src/gcc-5.4.0/configure
--srcdir=/home/niva/src/gcc-5.4.0 --verbose --enable-checking
--enable-languages=c --enable-lto --with-gmp=/usr/local --with-mpfr=/usr/local
--with-mpc=/usr/local --with-isl=/usr/local --with-cloog=/usr/local
--prefix=/home/niva/local-gcc54
Thread model: posix
gcc version 5.4.0 (GCC) 

The command line is:  gcc -O0 -S small.i
The compiler output is:

small.i: In function ‘init’:
small.i:3:5: error: type mismatch in shift expression
 int init (signed int m_CL)
 ^
short unsigned int
signed short
short unsigned int
D.1836 = D.1835 r>> 8;
small.i:3:5: internal compiler error: verify_gimple failed
0xb475df verify_gimple_in_seq(gimple_statement_base*)
/home/niva/src/gcc-5.4.0/gcc/tree-cfg.c:4739
0x9150ec gimplify_body(tree_node*, bool)
/home/niva/src/gcc-5.4.0/gcc/gimplify.c:9329
0x915456 gimplify_function_tree(tree_node*)
/home/niva/src/gcc-5.4.0/gcc/gimplify.c:9414
0x758117 cgraph_node::analyze()
/home/niva/src/gcc-5.4.0/gcc/cgraphunit.c:634
0x75b1ed analyze_functions
/home/niva/src/gcc-5.4.0/gcc/cgraphunit.c:1024
0x75bad5 symbol_table::finalize_compilation_unit()
/home/niva/src/gcc-5.4.0/gcc/cgraphunit.c:2453
0x600dda c_write_global_declarations()
/home/niva/src/gcc-5.4.0/gcc/c/c-decl.c:10857
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug go/71692] Running target unix FAIL: syscall

[horta at ebi dot ac.uk]

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

--- Comment #1 from Danilo Horta  ---
There is also this output from grep -o '$BASESYS/lib.*/crt[1in].*succeeded'
dummy.log that my be useful.


[horta@hh-yoda-11-01 tmp]$ grep succeeded dummy.log
attempt to open /lib/../lib64/crt1.o succeeded
attempt to open /lib/../lib64/crti.o succeeded
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/crtbegin.o
succeeded
attempt to open /tmp/ccWXRNZA.o succeeded
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/libgcc.a
succeeded
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libgcc_s.so
succeeded
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libgcc_s.so.1
succeeded
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/libgcc.a
succeeded
attempt to open /lib/../lib64/libc.so succeeded
attempt to open /lib64/libc.so.6 succeeded
attempt to open /usr/lib64/libc_nonshared.a succeeded
attempt to open /lib64/ld-linux-x86-64.so.2 succeeded
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/libgcc.a
succeeded
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libgcc_s.so
succeeded
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libgcc_s.so.1
succeeded
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/libgcc.a
succeeded
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/crtend.o
succeeded
attempt to open /lib/../lib64/crtn.o succeeded
[horta@hh-yoda-11-01 tmp]$ grep failed dummy.log
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libgcc.so failed
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libgcc.a failed
attempt to open /nfs/software/stegle/basesys/lib/../lib64/libgcc.so failed
attempt to open /nfs/software/stegle/basesys/lib/../lib64/libgcc.a failed
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/libgcc.so failed
attempt to open libgcc_s.so.1 failed
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libgcc.so failed
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libgcc.a failed
attempt to open /nfs/software/stegle/basesys/lib/../lib64/libgcc.so failed
attempt to open /nfs/software/stegle/basesys/lib/../lib64/libgcc.a failed
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/libgcc.so failed
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libc.so failed
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libc.a failed
attempt to open /nfs/software/stegle/basesys/lib/../lib64/libc.so failed
attempt to open /nfs/software/stegle/basesys/lib/../lib64/libc.a failed
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/libc.so failed
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/libc.a failed
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../lib64/libc.so
failed
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../lib64/libc.a
failed
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libgcc.so failed
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libgcc.a failed
attempt to open /nfs/software/stegle/basesys/lib/../lib64/libgcc.so failed
attempt to open /nfs/software/stegle/basesys/lib/../lib64/libgcc.a failed
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/libgcc.so failed
attempt to open libgcc_s.so.1 failed
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libgcc.so failed
attempt to open /nfs/software/stegle/basesys/lib64/../lib64/libgcc.a failed
attempt to open /nfs/software/stegle/basesys/lib/../lib64/libgcc.so failed
attempt to open /nfs/software/stegle/basesys/lib/../lib64/libgcc.a failed
attempt to open
/nfs/software/stegle/basesys/lib/gcc/x86_64-pc-linux-gnu/6.1.0/libgcc.so failed

[Bug middle-end/71693] ICE: verify_gimple failed (type mismatch in shift expression, -O0, -O1, -O2, -O3)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
This seems to be fixed for GCC 6 and 7.

[Bug tree-optimization/70729] Loop marked with omp simd pragma is not vectorized

[ienkovich at gcc dot gnu.org]

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

--- Comment #27 from Ilya Enkovich  ---
Author: ienkovich
Date: Wed Jun 29 10:16:43 2016
New Revision: 237844

URL: https://gcc.gnu.org/viewcvs?rev=237844&root=gcc&view=rev
Log:
gcc/

2016-06-29  Yuri Rumyantsev  

PR tree-optimization/70729
* tree-ssa-loop-im.c (ref_indep_loop_p_1): Consider memory reference as
independent in loops having positive safelen value.
* tree-vect-loop.c (vect_transform_loop): Clear-up safelen value since
it may be not valid after vectorization.

gcc/testsuite/

2016-06-29  Yuri Rumyantsev  

PR tree-optimization/70729
* g++.dg/vect/pr70729.cc: New test.

Added:
trunk/gcc/testsuite/g++.dg/vect/pr70729.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-im.c
trunk/gcc/tree-vect-loop.c

[Bug target/70814] atomic store of __int128 is not lock free on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #10 from Richard Earnshaw  ---
(In reply to Andrew Pinski from comment #9)
> On x86, they use ifuncs for this purpose inside libatomic. Basically the
> requirement is only one libatomic can be used at a time.

If we can guarantee that, then yes, we could do something similar if we had
fully atomic 128-bit loads.

[Bug middle-end/71693] ICE: verify_gimple failed (type mismatch in shift expression, -O0, -O1, -O2, -O3)

[niva at niisi dot msk.ru]

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

--- Comment #2 from niva at niisi dot msk.ru ---
Is it possible to obtain a patch fixing this bug?

(We are using a cross compiler based on 4.7.4, with
substantial changes in backend).

[Bug ada/67494] xsinfo sanitizer detects overlapping strings in assignment statement

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Previously reported.

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

[Bug ada/64057] possible issue in the shared implementation of Ada.Strings.Unbounded

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #4 from Eric Botcazou  ---
*** Bug 67494 has been marked as a duplicate of this bug. ***

[Bug testsuite/67905] running the libstdc++ testsuite as root removed /dev/null from my system

[egall at gwmail dot gwu.edu]

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

--- Comment #2 from Eric Gallager  ---
Created attachment 38786
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38786&action=edit
bzipped testsuite log

It happened again with yesterday's trunk. I'm attaching the logfile this time.

[Bug c++/71628] ICE on valid C++11 code (with lambda expression, __typeof operator and variable length array): verify_gimple failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-29
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, fails for me since GCC 4.5.0 (I don't have an older compiler).

[Bug tree-optimization/71595] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:704

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-29
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, all releases between 4.5.0 to 6.1.0 work fine.

[Bug inline-asm/71572] ICE with VLA and "+g" inline-asm in force_constant_size, at gimplify.c:671

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Fails since 4.5.0 (I don't have an older compiler).

[Bug c++/71553] [6 regression]ICE in assign_temp, at function.c:961

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
All releases in between 4.5.0 to 5.4.0 work fine on x86_64-linux, trunk also
works for me.

[Bug middle-end/71473] cilkplus sum reducer ICE

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Confirmed that original cilkplus C source ICE in all releases starting from GCC
5.2.0.

[Bug tree-optimization/71170] [7 Regression] ICE in rewrite_expr_tree, at tree-ssa-reassoc.c:3898

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #18 from Martin Liška  ---
Closing due to last comment in this PR.

[Bug other/71627] AVR error: unable to find a register to spill in class 'POINTER_X_REGS'

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  ---
Also confirmed on current trunk.

[Bug fortran/71067] ICE on data initialization with insufficient value

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Confirmed, affects all releases starting from 5.1.0 and current trunk is also
affected.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
I also can't reproduce the ICE on x86_64-linux-gnu.

[Bug middle-end/70980] ICE pre_and_rev_post_order_compute, at cfganal.c:1056

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Can't reproduce the problem with current trunk of x86_64-linux-gnu.

[Bug fortran/71067] [5/6/7 Regression] ICE on data initialization with insufficient value

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
I am not 100% sure that is a regression: with 4.8 and 4.9 I get

Internal Error at (1):
free_expr0(): Bad expr type

i.e., old version of an ICE.

[Bug middle-end/70980] ICE pre_and_rev_post_order_compute, at cfganal.c:1056

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Martin Liška  ---
> Can't reproduce the problem with current trunk of x86_64-linux-gnu.

Seems the ICE went away after 20160506 (either hidden or fixed).

Rainer

[Bug fortran/71067] [5/6/7 Regression] ICE on data initialization with insufficient value

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
You are right, however 4.7.4 produces an error message:

  4.7.4: running command with result: FAILED
/home/marxin/Programming/testcases/pr71067.f90:4.14:

   data z /2*i/
  1
Error: Symbol 'i' must be a PARAMETER in DATA statement at (1)

Thus I would consider the PR as 4.8/4.9/5/6/7 regression, do you agree?

[Bug middle-end/70980] ICE pre_and_rev_post_order_compute, at cfganal.c:1056

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Martin Liška  ---
Ok, thus I'm closing the issue as invalid.

[Bug fortran/71066] ICE in set_loop_bounds, at fortran/trans-array.c:4680

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-29
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, ICEs since GCC 4.6.0.

[Bug c++/71694] New: store-data race with bitfields and tail-padding in C++

[rguenth at gcc dot gnu.org]

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

Bug ID: 71694
   Summary: store-data race with bitfields and tail-padding in C++
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

struct B {
B() {}
int x;
int a : 6;
int b : 6;
int c : 6;
};

struct C : B {
char d;
};

C c;

int main()
{
  c.c = 1;
  c.d = 2;
}

produces on x86_64

main:
.LFB6:
.cfi_startproc
movlc+4(%rip), %eax
andl$-258049, %eax
orb $16, %ah
movl%eax, c+4(%rip)
movb$2, c+7(%rip)
xorl%eax, %eax
ret

as you can see the store to c.c races with another thread accessing c.d.

[Bug c++/71694] store-data race with bitfields and tail-padding in C++

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01962.html

[Bug fortran/71067] [5/6/7 Regression] ICE on data initialization with insufficient value

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
GCC 4.8 branch is frozen, thus just '4.9/5/6/7 Regression'.

[Bug c++/71694] store-data race with bitfields and tail-padding in C++

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I guess even if not obviously used as a base we need to consider it being a
base.
Thus for

void foo (B *b)
{
  b->c = 1;
}

we may not access tail padding either.

So stor-layout.c needs to be conservative in finish_bitfield_representative
with including tail-padding which will pessimize code quite a bit unless
the middle-end has a way to identify types that can not possibly have their
tail-padding re-used by inheritance (or other means).  I don't think we have
a way to determine this at the moment.

[Bug c++/71694] store-data race with bitfields and tail-padding in C++

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
The C++ FE identifies such types with

  CLASSTYPE_NON_LAYOUT_POD_P (t) || CLASSTYPE_EMPTY_P (t)

where only CLASSTYPE_NON_LAYOUT_POD_P is interesting to us.  Only available
in struct lang_type.  Possibly able to expose that via a new langhook.

[Bug middle-end/71693] ICE: verify_gimple failed (type mismatch in shift expression, -O0, -O1, -O2, -O3)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
It went away with r228661, which looks like an optimization (not to be
backported) rather than a fix.

[Bug middle-end/71585] Cannot selectively disable stack protector with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Wed Jun 29 12:12:56 2016
New Revision: 237845

URL: https://gcc.gnu.org/viewcvs?rev=237845&root=gcc&view=rev
Log:
Mark -fstack-protect as optimization flag.

PR middle-end/71585
* common.opt (flag_stack_protect): Mark the flag as optimization
flag.
* ipa-inline-transform.c (inline_call): Remove unnecessary call
of build_optimization_node.
* gcc.dg/pr71585.c: New test.
* gcc.dg/pr71585-2.c: New test.
* gcc.dg/pr71585-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr71585-2.c
trunk/gcc/testsuite/gcc.dg/pr71585-3.c
trunk/gcc/testsuite/gcc.dg/pr71585.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/ipa-inline-transform.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70971] ICE in parameter pack expansion

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-29
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
ICEs from GCC 5.1.0 on all releases (including current trunk).

This is a bit reduced test-case:

#include 
struct A {};
template  struct typelist {};
template  std::unique_ptr chooseB(typelist);
template 
std::unique_ptr chooseB(typelist choices, Idx, Rest... rest) {
  auto f = [=](auto) { return [=] { return chooseB(choices, rest...); }; };
  std::function()> fs[]{f(Cs{})...};
}
main() { chooseB(typelist{}, 0, 1, 2); }

[Bug middle-end/71693] [4.9/5 Regression] ICE: verify_gimple failed (type mismatch in shift expression, -O0, -O1, -O2, -O3)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-29
   Target Milestone|--- |4.9.4
Summary|ICE: verify_gimple failed   |[4.9/5 Regression] ICE:
   |(type mismatch in shift |verify_gimple failed (type
   |expression, -O0, -O1, -O2,  |mismatch in shift
   |-O3)|expression, -O0, -O1, -O2,
   ||-O3)
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
ICE started most likely with r145256 or r145254 or r145250, at least r145256
ICEs and r145245 works.

[Bug tree-optimization/71691] [6/7 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Floating point exception)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org
   Target Milestone|--- |6.2

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

[Bug tree-optimization/71655] [7 Regression] GCC trunk ICE on westmere target

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #3 from Ilya Enkovich  ---
Fixed

[Bug tree-optimization/71488] [6 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[ienkovich at gcc dot gnu.org]

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

Bug 71655 Summary: [7 Regression] GCC trunk ICE on westmere target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71655

   What|Removed |Added

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

[Bug tree-optimization/71655] [7 Regression] GCC trunk ICE on westmere target

[ienkovich at gcc dot gnu.org]

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

--- Comment #2 from Ilya Enkovich  ---
Author: ienkovich
Date: Wed Jun 29 12:26:40 2016
New Revision: 237846

URL: https://gcc.gnu.org/viewcvs?rev=237846&root=gcc&view=rev
Log:
gcc/

PR tree-optimization/71655
* tree-vect-stmts.c (vectorizable_comparison): Swap definition
types when swapping operands.

gcc/testsuite/

PR tree-optimization/71655
* g++.dg/pr71655.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr71655.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug preprocessor/69869] internal compiler error: Segmentation fault in call to skip_macro_block_comment when using '-traditional-cpp'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Can't reproduced that on x86_64-linux-gnu, all releases starting from 4.5.0 to
current trunk work fine.

[Bug middle-end/71585] Cannot selectively disable stack protector with LTO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
Fixed on trunk.

[Bug fortran/71067] [4.9/5/6/7 Regression] ICE on data initialization with insufficient value

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> Thus I would consider the PR as 4.8/4.9/5/6/7 regression, do you agree?

Yes, the change occurred between revisions r190641 (2012-08-24, error) and
r190786 (2012-08-29, ICE). The backtrace is

* thread #1: tid = 0x8d8367, 0x7fff811f2f06
libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread',
stop reason = signal SIGABRT
  * frame #0: 0x7fff811f2f06 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fff8cfc74ec libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x7fff8a5106e7 libsystem_c.dylib`abort + 129
frame #3: 0x0001010497b1 f951`uw_init_context_1(context=,
outer_cfa=, outer_ra=) + 353 at unwind-dw2.c:1563
frame #4: 0x00010104a098 f951`_Unwind_Backtrace(trace=(f951`unwind at
backtrace.c:68), trace_argument=0x7fff5fbfeb40) + 56 at unwind.inc:283
frame #5: 0x000100fa4589 f951`backtrace_full(state=0x0001426ff000,
skip=, callback=, error_callback=,
data=) + 105 at backtrace.c:127
frame #6: 0x000100f66213
f951`diagnostic_action_after_output(context=0x000141979dc0,
diag_kind=) + 435 at diagnostic.c:481
frame #7: 0x000100f66828
f951`diagnostic_report_diagnostic(context=0x000141979dc0,
diagnostic=0x7fff5fbfec10) + 680 at diagnostic.c:943
frame #8: 0x000100033fbd f951`gfc_internal_error(gmsgid="free_expr0():
Bad expr type") + 237 at error.c:1312
frame #9: 0x000100034d5e f951`::free_expr0(e=0x000144307ac0) + 286
at expr.c:494
frame #10: 0x000100034db9 f951`gfc_free_expr(e=0x000144307ac0) + 9
at expr.c:513
frame #11: 0x00010001f625 f951`gfc_free_data(gfc_data*) + 34 at
decl.c:143
frame #12: 0x00010001f603 f951`gfc_free_data(p=0x000144307330) + 51
frame #13: 0x000100020747 f951`gfc_match_data() + 471 at decl.c:626
frame #14: 0x00010008286a
f951`::match_word_omp_simd(subr=, old_locus=0x7fff5fbfee70,
simd_matched=, str=)(), locus *, bool *, const char
*) + 10 at parse.c:93
frame #15: 0x000100086ffa f951`::decode_statement() + 5322 at
parse.c:457
frame #16: 0x000100087d24 f951`::next_statement() + 276 at parse.c:1080
frame #17: 0x00010008991d f951`::parse_spec(st=ST_DATA_DECL) + 3325 at
parse.c:3637
frame #18: 0x00010008cbf7 f951`::parse_progunit(st=) + 39
at parse.c:5420
frame #19: 0x00010008e56a f951`gfc_parse_file() + 1146 at parse.c:5928
frame #20: 0x0001000d563b f951`::gfc_be_parse_file() + 59 at
f95-lang.c:198
frame #21: 0x000100b663ca f951`::compile_file() + 58 at toplev.c:465
frame #22: 0x00010104e5d6 f951`toplev::main(int, char**) + 1561 at
toplev.c:1998
frame #23: 0x00010104dfbd f951`toplev::main(this=0x7fff5fbff340,
argc=, argv=) + 733
frame #24: 0x00010104fe29 f951`main(argc=2, argv=0x7fff5fbff380) +
41 at main.c:39
frame #25: 0x7fff810c35ad libdyld.dylib`start + 1

Tobias Burnus has committed several changes around "free" in this range.

[Bug preprocessor/69869] internal compiler error: Segmentation fault in call to skip_macro_block_comment when using '-traditional-cpp'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Weird, I can reproduce it just fine with current trunk or e.g. 3.4 and up.
One problem is that skip_macro_block_comment assumes that the comment must be
terminated, while we have there only "/*\n" in the buffer and nothing else, so
we run off the end of the buffer.
But, I'm not really sure even what this should be preprocessed into.

[Bug preprocessor/69869] [4.9/5/6/7 Regression] internal compiler error: Segmentation fault in call to skip_macro_block_comment when using '-traditional-cpp'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-29
 CC||dmalcolm at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|internal compiler error:|[4.9/5/6/7 Regression]
   |Segmentation fault in call  |internal compiler error:
   |to skip_macro_block_comment |Segmentation fault in call
   |when using  |to skip_macro_block_comment
   |'-traditional-cpp'  |when using
   ||'-traditional-cpp'
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
/usr/src/gcc-3.2/obj/gcc/tradcpp0 pr69869.c
# 1 "pr69869.c"


all:
$(RM)   ./bin/*

so the ICE is a regression.

[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 #57 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Jun 29 13:03:22 2016
New Revision: 237850

URL: https://gcc.gnu.org/viewcvs?rev=237850&root=gcc&view=rev
Log:
PR ada/48835
PR ada/61954
* gcc-interface/gigi.h (enum standard_datatypes): Add ADT_realloc_decl
(realloc_decl): New macro.
* gcc-interface/decl.c (gnat_to_gnu_entity) : Use local
variable for the entity type and translate it as void pointer if the
entity has convention C.
(gnat_to_gnu_entity) : If this is not a definition and the
external name matches that of malloc_decl or realloc_decl, return the
correspoding node directly.
(gnat_to_gnu_subprog_type): Likewise for parameter and return types.
* gcc-interface/trans.c (gigi): Initialize void_list_node here, not...
Initialize realloc_decl.
* gcc-interface/utils.c (install_builtin_elementary_types): ...here.
(build_void_list_node): Delete.
* gcc-interface/utils2.c (known_alignment) : Return the
alignment of the system allocator for malloc_decl and realloc_decl.
Do not take alignment from void pointer types either.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/decl.c
trunk/gcc/ada/gcc-interface/gigi.h
trunk/gcc/ada/gcc-interface/trans.c
trunk/gcc/ada/gcc-interface/utils.c
trunk/gcc/ada/gcc-interface/utils2.c

[Bug ada/61954] Ada fails to properly pass pointer arguments on x32

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Jun 29 13:03:22 2016
New Revision: 237850

URL: https://gcc.gnu.org/viewcvs?rev=237850&root=gcc&view=rev
Log:
PR ada/48835
PR ada/61954
* gcc-interface/gigi.h (enum standard_datatypes): Add ADT_realloc_decl
(realloc_decl): New macro.
* gcc-interface/decl.c (gnat_to_gnu_entity) : Use local
variable for the entity type and translate it as void pointer if the
entity has convention C.
(gnat_to_gnu_entity) : If this is not a definition and the
external name matches that of malloc_decl or realloc_decl, return the
correspoding node directly.
(gnat_to_gnu_subprog_type): Likewise for parameter and return types.
* gcc-interface/trans.c (gigi): Initialize void_list_node here, not...
Initialize realloc_decl.
* gcc-interface/utils.c (install_builtin_elementary_types): ...here.
(build_void_list_node): Delete.
* gcc-interface/utils2.c (known_alignment) : Return the
alignment of the system allocator for malloc_decl and realloc_decl.
Do not take alignment from void pointer types either.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/decl.c
trunk/gcc/ada/gcc-interface/gigi.h
trunk/gcc/ada/gcc-interface/trans.c
trunk/gcc/ada/gcc-interface/utils.c
trunk/gcc/ada/gcc-interface/utils2.c

[Bug target/71695] New: m68k: long long multiplication broken

[martin at netbsd dot org]

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

Bug ID: 71695
   Summary: m68k: long long multiplication broken
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin at netbsd dot org
  Target Milestone: ---

Created attachment 38787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38787&action=edit
source code demonstrating the bug

Calculating the nth power of ten in below simple program fails for all input
values != 0; i.e.:

[/tmp] martin@mac-beth > ./a.out 0
10
[/tmp] martin@mac-beth > ./a.out 1
0
[/tmp] martin@mac-beth > ./a.out 2
0
[/tmp] martin@mac-beth > ./a.out 3
0

This is due to muls.l zeroing both registers at .L3 here:

clr.l %d2
moveq #10,%d1
.L3:
muls.l %d2,%d1
move.l %d1,%d3
add.l %d3,%d3
mulu.l %d1,%d2:%d1
add.l %d3,%d2
addq.l #1,%a0
cmp.l %d0,%a0
jne .L3

This is with the gcc 5.4 version in the NetBSD source tree, identifying as:

Using built-in specs.
COLLECT_GCC=/usr/tools/bin/m68k--netbsdelf-gcc
COLLECT_LTO_WRAPPER=/usr/tools/libexec/gcc/m68k--netbsdelf/5.4.0/lto-wrapper
Target: m68k--netbsdelf
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=m68k--netbsdelf --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD
nb1 20160606' --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-time=rt --enable-libstdcxx-threads
--with-diagnostics-color=auto-if-env --with-sysroot=/hosts/mac68k
--with-mpc=/usr/tools --with-mpfr=/usr/tools --with-gmp=/usr/tools
--disable-nls --disable-multilib --program-transform-name=s,^,m68k--netbsdelf-,
--enable-languages='c c++ objc' --prefix=/usr/tools
Thread model: posix
gcc version 5.4.0 (NetBSD nb1 20160606) 

Compiler invocation:

m68k--netbsdelf-gcc -S -Wall -O2 bug-m68k.c

Any value of -O will cause the bad code.

[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 #58 from Eric Botcazou  ---
> OK, so the fix is that the System.Address type must be changed in GNAT
> to be handled as pointer in the GCC middle-/back-end. Is any GCC/GNAT
> developer please working on this?

That's at last implemented on the mainline.

[Bug ada/61954] Ada fails to properly pass pointer arguments on x32

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Botcazou  ---
.

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
GCC 6 at -O2 on x86_64 produces

foo:
.LFB0:
.cfi_startproc
movzbl  (%rdi), %eax
movl%eax, %edx
shrb%dl
orl %eax, %edx
andl$-2, %eax
andl$1, %edx
orl %edx, %eax
movb%al, (%rdi)
ret

If we lower bitfield accesses to BIT_FIELD_REF / BIT_INSERT_EXPR we get

  :
  _7 = b_5(D)->D.1753;
  _1 = BIT_FIELD_REF <_7, 1, 0>;
  _2 = BIT_FIELD_REF <_7, 1, 1>;
  _3 = _1 | _2;
  _8 = BIT_INSERT_EXPR <_7, _3, 0 (1 bits)>;
  b_5(D)->D.1753 = _8;
  return;

if we lower to shifts/masks then

  :
  _7 = b_5(D)->D.1753;
  _11 = _7 >> 1;
  _1 = _7 | _11;
  _14 = _7 & 254;
  _10 = _1 & 1;
  _16 = _10 | _14;
  b_5(D)->D.1753 = _16;
  return;

it fails to notice that the & 254 is not necessary.  That's easier to
grasp from the first lowering.

[Bug rtl-optimization/48696] Horrible bitfield code generation on x86

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||71509

--- Comment #16 from Richard Biener  ---
Re-confirmed for GCC 6.  Related to PR71509.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509
[Bug 71509] Bitfield causes load hit store with larger store than load

[Bug lto/71499] ICE in LTO1 when attempting NVPTX offloading (-fopenacc)

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Schwinge  ---
The is the OpenACC variant of OpenMP's PR71535.

You need to add "#pragma acc routine" for function "test".  (Of course, we
shouldn't run into an ICE nevertheless.)

[Bug lto/71535] ICE in LTO1 with -fopenmp offloading

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #2 from Thomas Schwinge  ---
The is the OpenMP variant of OpenACC's PR71499.

[Bug target/71695] m68k: long long multiplication broken

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-06-29
 Ever confirmed|0   |1

--- Comment #1 from Andreas Schwab  ---
Worksforme with gcc 7:

clr.l %d2
moveq #10,%d3
.L3:
move.l %d2,%d1
muls.l %d3,%d1
add.l %d1,%d1
mulu.l %d3,%d2:%d3
add.l %d1,%d2
addq.l #1,%a0
cmp.l %d0,%a0
jne .L3

Please check that there is no local patch that breaks that.

[Bug middle-end/55266] vector expansion: 24 movs for 4 adds

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 Blocks||53947
 Depends on||65832

--- Comment #5 from Richard Biener  ---
The latter is because of 'convert' leaving us with

  _1 = BIT_FIELD_REF ;
  _2 = (double) _1;
  _3 = BIT_FIELD_REF ;
  _4 = (double) _3;
  _5 = BIT_FIELD_REF ;
  _6 = (double) _5;
  _7 = BIT_FIELD_REF ;
  _8 = (double) _7;
  _9 = {_2, _4, _6, _8};

rather than

  vect__1.83_46 = x;
  vect__2.84_47 = [vec_unpack_lo_expr] vect__1.83_46;
  vect__2.84_48 = [vec_unpack_hi_expr] vect__1.83_46;
  MEM[(vector(4) double *)&dx] = vect__2.84_47;
  MEM[(vector(4) double *)&dx + 16B] = vect__2.84_48;

(which is in itself not optimal because not being in SSA form).

This means generic vector support lacks widening/shortening and thus you
have to jump through hoops with things like 'convert'.  And SLP vectorization
doesn't "vectorize" with vector CONSTRUCTORs as root (a possible enhancement I
think).

For the original testcase it's a duplicate of PR65832 as we get

  :
  _1 = *x_5(D);
  _7 = BIT_FIELD_REF <_1, 128, 0>;
  _9 = _7 + _7;
  _10 = BIT_FIELD_REF <_1, 128, 128>;
  _12 = _10 + _10;
  _14 = _7 + _9;
  _16 = _10 + _12;
  _3 = {_14, _16};
  *x_5(D) = _3;

w/o fixing PR65832 this can be improved by "combining" the loads with the
extracts and the CONSTRUCTOR with the store.

I have done sth similar for COMPLEX_EXPR in tree-ssa-forwprop.c ... (not
that I am very proud of that - heh).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65832
[Bug 65832] Inefficient vector construction

[Bug fortran/71688] [4.9/5/6/7 Regression] ICE in analyze, at cgraphunit.c:632 with -fcoarray=lib

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
(In reply to Dominique d'Humieres from comment #3)
> The change occurred between revisions r201266 (2013-07-26, OK) and r201631
> (2013-08-09, ICE), likely r201526 (pr57987).

Indeed.  But I believe the problem is that lower_nested_functions does
not work properly.  At the time of calling unnest_nesting_tree, the
nesting tree seems not to contain one nested function while another
one is present twice.

[Bug c++/71696] New: Libiberty Demangler segfaults (6)

[boehme.marcel at gmail dot com]

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

Bug ID: 71696
   Summary: Libiberty Demangler segfaults (6)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boehme.marcel at gmail dot com
  Target Milestone: ---

A stackoverflow in the libiberty demangler causes its host application to crash
on a tainted branch instruction. The problem is caused by a self-reference in a
mangled type string that is "remembered" for later reference. This leads to an
infinite recursion during the demangling.

How to reproduce:
$ valgrind cxxfilt __33%__S8_00TT0
==30184== Memcheck, a memory error detector
==30184== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==30184== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==30184== Command: ../../binutils_git5/libiberty/testsuite/test-demangle
==30184== 
==30184== Stack overflow in thread 1: can't grow stack to 0xffe801ff8
..

$ valgrind cxxfilt __10%0__S4_0T0T0
..

Analysis: The demangler "remembers" mangled types that can later be referenced
in the mangled string. In this case the complete string is remembered in
work->typevec[0] before it is demangled in cplus-dem.c:4534. Now, a part of the
mangled string ("T") references the remembered type stored at
work->typevec[0] which is supposed to be demangled as well (cplus-dem.c:3632).

The tool was found with a more efficient version of AFL, called AFL-Fast.
I am preparing a patch.

[Bug tree-optimization/15256] [tree-ssa] Optimize manual bitfield manipilation.

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Fixed in GCC 6.

[Bug middle-end/19466] [meta-bug] bit-fields are non optimal

[rguenth at gcc dot gnu.org]

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

Bug 15256 Summary: [tree-ssa] Optimize manual bitfield manipilation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15256

   What|Removed |Added

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

[Bug tree-optimization/15256] [tree-ssa] Optimize manual bitfield manipilation.

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Wed Jun 29 13:48:39 2016
New Revision: 237852

URL: https://gcc.gnu.org/viewcvs?rev=237852&root=gcc&view=rev
Log:
2016-06-29  Richard Biener  

PR middle-end/15256
* gcc.dg/tree-ssa/forwprop-34.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-34.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[rguenth at gcc dot gnu.org]

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

Bug 15256 Summary: [tree-ssa] Optimize manual bitfield manipilation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15256

   What|Removed |Added

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

[Bug tree-optimization/15256] [tree-ssa] Optimize manual bitfield manipilation.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
.

[Bug tree-optimization/15826] don't use "if" to extract a single bit bit-field.

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
(In reply to Steven Bosscher from comment #6)
> The tree dump for the original test case now looks like this for me:
> 
> ;; Function foo (foo)
> 
> foo (p)
> {
> :
>   return (unsigned int) ((BIT_FIELD_REF <*p, 8, 0> & 1) != 0);
> 
> }
> 
> 
> 
> ;; Function bar (bar)
> 
> bar (p)
> {
> :
>   return (unsigned int) p->bit;
> 
> }
> 
> 
> 
> The resulting assembler output is the same, but I imagine VRP should be able
> to fold away the "& 1" test.  I don't know if the BIT_FIELD_REF itself
> should be optimized away, but I guess so.  Consider the following test case:
> 
> struct s
> {
>   unsigned int bit:1;
> };
> 
> unsigned int
> foo (struct s *p)
> {
>   if (p->bit)
> return (unsigned int) (p->bit);
>   else
> return 0;
> }
> 
> 
> This gets "optimized" at the tree level to this ugly code:
> ;; Function foo (foo)
> 
> foo (p)
> {
>   unsigned int D.1979;
> 
> :
>   if ((BIT_FIELD_REF <*p, 8, 0> & 1) != 0) goto ; else goto ;
> 
> :;
>   D.1979 = 0;
>   goto  ();
> 
> :;
>   D.1979 = (unsigned int) p->bit;
> 
> :;
>   return D.1979;
> 
> }
> 
> In summary, I don't think we can close this bug just yet.

I don't think VRP can optimize anything here as the BIT_FIELD_REF created
by optimize_bitfield_compare accesses struct s tail-padding.

IMHO this is still very premature optimization done by fold.

[Bug middle-end/45274] __restrict__ type qualifier does not work on pointers to bitfields

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
The alias-set issue doesn't occur since quite some time (it's using alias-set 1
for me).  Also restrict is working.

GCC 6 optimizes this on x86_64 to

foo:
.LFB0:
.cfi_startproc
movzbl  (%rdi), %edx
movzbl  (%rsi), %eax
movl%edx, %r8d
movl%edx, %ecx
andl$-4, %eax
andl$1, %r8d
andl$2, %ecx
orl %r8d, %eax
orl %ecx, %eax
movl%edx, %ecx
andl$8, %edx
andl$4, %ecx
andl$-13, %eax
orl %ecx, %eax
orl %edx, %eax
movb%al, (%rsi)
movl(%rdi), %eax
andl$-16, %eax
movl%eax, %edx
movl(%rsi), %eax
andl$15, %eax
orl %edx, %eax
movl%eax, (%rsi)
ret

thus it is doing a good job in piecewise copying of the struct.  It doesn't
detect that it can simply use a 32bit load/store.  But there are duplicates
in bugzilla for that issue.

Interestingly with some bitfield lowering work plus some match.pd hackery
I get that:

foo:
.LFB0:
.cfi_startproc
movl(%rdi), %eax
movl%eax, (%rsi)
ret

whee.

[Bug fortran/71688] [4.9/5/6/7 Regression] ICE in analyze, at cgraphunit.c:632 with -fcoarray=lib

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
The nesting tree structure contains decls but is built from call graph, in
which there are two different cgraph_nodes for a single decl (s).
Unnesting is done on call graph again but the translation from decls
to nodes of course misses a call graph node which remains to be nested
in the graph and that triggers the assert.

Fortran FE creates both of those cgraph_nodes.  The following
backtrace leads to creation of the first one:

#0  cgraph_node::create (decl=) at
/home/mjambor/gcc/icln/src/gcc/cgraph.c:495
#1  0x00808b60 in cgraph_node::get_create (decl=) at
/home/mjambor/gcc/icln/src/gcc/cgraph.c:529
#2  0x00808d69 in cgraph_node::create (decl=decl@entry=)
at /home/mjambor/gcc/icln/src/gcc/cgraph.c:511
#3  0x006f83ec in generate_coarray_init (ns=ns@entry=0x23d5720)
at /home/mjambor/gcc/icln/src/gcc/fortran/trans-decl.c:5086
#4  0x007097cd in gfc_generate_function_code (ns=ns@entry=0x23d5720)
at /home/mjambor/gcc/icln/src/gcc/fortran/trans-decl.c:6109
#5  0x0070a381 in gfc_generate_contained_functions
(parent=parent@entry=0x23d4d60)
at /home/mjambor/gcc/icln/src/gcc/fortran/trans-decl.c:5161
#6  0x0070978e in gfc_generate_function_code (ns=0x23d4d60)
at /home/mjambor/gcc/icln/src/gcc/fortran/trans-decl.c:6100
#7  0x006dc511 in gfc_generate_code (ns=) at
/home/mjambor/gcc/icln/src/gcc/fortran/trans.c:2006
#8  0x0068da1f in translate_all_program_units
(gfc_global_ns_list=0x23d4d60)
at /home/mjambor/gcc/icln/src/gcc/fortran/parse.c:5843
#9  0x0069426b in gfc_parse_file () at
/home/mjambor/gcc/icln/src/gcc/fortran/parse.c:6049
#10 0x006d3e44 in gfc_be_parse_file () at
/home/mjambor/gcc/icln/src/gcc/fortran/f95-lang.c:201
#11 0x00c9358d in compile_file () at
/home/mjambor/gcc/icln/src/gcc/toplev.c:465
#12 0x00c953b8 in do_compile () at
/home/mjambor/gcc/icln/src/gcc/toplev.c:1998
#13 0x00c955eb in toplev::main (this=this@entry=0x7fffde50,
argc=argc@entry=14,

while the following one leads to creation of the second one:

#0  cgraph_node::create (decl=decl@entry=)
at /home/mjambor/gcc/icln/src/gcc/cgraph.c:495
#1  0x0070a2e1 in gfc_generate_function_code (ns=ns@entry=0x23d5720)
at /home/mjambor/gcc/icln/src/gcc/fortran/trans-decl.c:6339
#2  0x0070a381 in gfc_generate_contained_functions
(parent=parent@entry=0x23d4d60)
at /home/mjambor/gcc/icln/src/gcc/fortran/trans-decl.c:5161
#3  0x0070978e in gfc_generate_function_code (ns=0x23d4d60)
at /home/mjambor/gcc/icln/src/gcc/fortran/trans-decl.c:6100
#4  0x006dc511 in gfc_generate_code (ns=) at
/home/mjambor/gcc/icln/src/gcc/fortran/trans.c:2006
#5  0x0068da1f in translate_all_program_units
(gfc_global_ns_list=0x23d4d60)
at /home/mjambor/gcc/icln/src/gcc/fortran/parse.c:5843
#6  0x0069426b in gfc_parse_file () at
/home/mjambor/gcc/icln/src/gcc/fortran/parse.c:6049
#7  0x006d3e44 in gfc_be_parse_file () at
/home/mjambor/gcc/icln/src/gcc/fortran/f95-lang.c:201
#8  0x00c9358d in compile_file () at
/home/mjambor/gcc/icln/src/gcc/toplev.c:465
#9  0x00c953b8 in do_compile () at
/home/mjambor/gcc/icln/src/gcc/toplev.c:1998
#10 0x00c955eb in toplev::main (this=this@entry=0x7fffde50,
argc=argc@entry=14,

The following seems to be an obvious fix:

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 2f5e434..0e68736 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -6336,7 +6336,7 @@ gfc_generate_function_code (gfc_namespace * ns)
 function has already called cgraph_create_node, which also created
 the cgraph node for this function.  */
   if (!has_coarray_vars || flag_coarray != GFC_FCOARRAY_LIB)
-   (void) cgraph_node::create (fndecl);
+   (void) cgraph_node::get_create (fndecl);
 }
   else
 cgraph_node::finalize_function (fndecl, true);

[Bug go/71697] New: go link error

[rootkit85 at yahoo dot it]

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

Bug ID: 71697
   Summary: go link error
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: rootkit85 at yahoo dot it
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 38788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38788&action=edit
workaround to compile go tool

the go tool fails to link.
configure options:

./configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=i486-openwrt-linux-gnu --with-gnu-ld --enable-target-optspace
--disable-libgomp --disable-libmudflap --disable-multilib --disable-nls
--without-isl --without-cloog --with-host-libstdcxx=-lstdc++
--disable-decimal-float --with-diagnostics-color=auto-if-env --enable-libssp
--enable-__cxa_atexit --disable-libsanitizer --enable-languages=c,c++,go
--enable-shared --enable-threads --enable-lto

error:

make[2]: Entering directory '/home/matteo/src/openwrt/gccbuild/gcc'
x86_64-linux-gnu-gcc   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE 
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmivirtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H  -o go1 \
  go/ast-dump.o go/dataflow.o go/export.o go/expressions.o go/go-backend.o
go/go-dump.o go/go-gcc.o go/go-lang.o go/go-linemap.o go/go-optimize.o go/go.o
go/gogo.o go/import.o e.o go/runtime.o go/statements.o go/types.o go/unsafe.o
attribs.o libbackend.a main.o  libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
-lstdc++  -lmpc -lmpfr -lgmp -rdynamic -ldl -lstdc++ -L../zlib -lz
/usr/bin/ld: go/export.o: undefined reference to symbol 'ceilf@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from
command line
collect2: error: ld returned 1 exit status
../../gcc-5.3.0/gcc/go/Make-lang.in:76: recipe for target 'go1' failed
make[2]: *** [go1] Error 1
make[2]: Leaving directory '/home/matteo/src/openwrt/gccbuild/gcc'
Makefile:4122: recipe for target 'all-gcc' failed
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory '/home/matteo/src/openwrt/gccbuild'
Makefile:876: recipe for target 'all' failed
make: *** [all] Error 2

Actually I'm compiling it with a workaround, patch is attached

Cheers,

[Bug c++/71665] [4.9/5/6/7 Regression] ICE on invalid C++ code with non-integral constant enumerator value: in cxx_eval_constant_expression, at cp/constexpr.c:3918

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug target/71698] New: ICE related to decimal float when compiling with -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

Bug ID: 71698
   Summary: ICE related to decimal float when compiling with
-mcpu=power9
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: dje at watson dot ibm.com, segher at gcc dot gnu.org,
wschmidt at linux dot vnet.ibm.com
  Target Milestone: ---

There are a number of these that fell out when running a make check with
-mcpu=power9. The common pattern seems to involve decimal float and looks like
this:

Executing on host: /home/sawdey/src/gcc/build-regtest/gcc/xgcc
-B/home/sawdey/src/gcc/build-regtest/gcc/  -mcpu=power9 -Wl,-rpath=/tmp/lib64
-fno-diagnostics-show-caret -fdiagnostics-color=never-c -o c_compa
t_x_tst.o
/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/gcc.dg/compat//scalar-by-value-dfp_x.c
   (timeout = 3600)
spawn /home/sawdey/src/gcc/build-regtest/gcc/xgcc
-B/home/sawdey/src/gcc/build-regtest/gcc/ -mcpu=power9 -Wl,-rpath=/tmp/lib64
-fno-diagnostics-show-caret -fdiagnostics-color=never -c -o c_compat_x_tst.o
/home/s
awdey/src/gcc/trunk/gcc/gcc/testsuite/gcc.dg/compat//scalar-by-value-dfp_x.c
/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/gcc.dg/compat//scalar-by-value-dfp_x.c:
In function 'testitd128':
/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/gcc.dg/compat//scalar-by-value-dfp_x.c:149:1:
internal compiler error: Segmentation fault
0x108b93f3 crash_signal
../../trunk/gcc/gcc/toplev.c:335
0x1047445c mark_label_nuses
../../trunk/gcc/gcc/emit-rtl.c:3612
0x1047456f mark_label_nuses
../../trunk/gcc/gcc/emit-rtl.c:3620
0x1047eaeb try_split(rtx_def*, rtx_insn*, int)
../../trunk/gcc/gcc/emit-rtl.c:3809
0x107efe97 split_insn
../../trunk/gcc/gcc/recog.c:2887
0x107f7357 split_all_insns_noflow()
../../trunk/gcc/gcc/recog.c:3026
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

testsuite/gcc.dg/compat//scalar-return-dfp_x.c:88:1

In file included from
/home/sawdey/src/gcc/build-regtest/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t001_y.c:8:0:
/home/sawdey/src/gcc/build-regtest/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t001_test.h:
In function 'check5':
/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1_y1.h:48:8:
internal compiler error: Segmentation fault
/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.h:777:27:
note: in expansion of macro 'TX'
/home/sawdey/src/gcc/build-regtest/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t001_test.h:6:1:
note: in expansion of macro 'T'

In file included from
/home/sawdey/src/gcc/build-regtest/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t002_y.c:8:0:
/home/sawdey/src/gcc/build-regtest/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t002_test.h:
In function 'check351':
/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1_y1.h:48:8:
internal compiler error: Segmentation fault
/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.h:777:27:
note: in expansion of macro 'TX'
/home/sawdey/src/gcc/build-regtest/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t002_test.h:52:1:
note: in expansion of macro 'T'

In file included from
/home/sawdey/src/gcc/build-regtest/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t028_y.c:8:0:
/home/sawdey/src/gcc/build-regtest/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t028_test.h:
In function 'check2828':
/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1_y1.h:48:8:
internal compiler error: Segmentation fault
/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.h:777:27:
note: in expansion of macro 'TX'
/home/sawdey/src/gcc/build-regtest/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t028_test.h:29:1:
note: in expansion of macro 'T'

/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/c-c++-common/dfp/func-vararg-dfp.c:95:1

/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/c-c++-common/dfp/func-vararg-mixed.c:102:1

/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/c-c++-common/dfp/pr36800.c:32:1

/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/g++.dg/compat/decimal//pass_x.h:
In function 'void testitd128()':
/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/g++.dg/compat/decimal//pass_x.h:145:1:
internal compiler error: Segmentation fault
/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/g++.dg/compat/decimal//pass_x.h:149:1:
note: in expansion of macro 'T'

In file included from
/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/g++.dg/compat/decimal//pass-2_x.C:1:0:
/home/sawdey/src/gcc/trunk/gcc/gcc/testsuite/g++.dg/compat/decimal//decimal-dummy.h:
In function 'std::decimal::decimal128
std::decimal::operator+(std::decimal::decimal128, std::decimal::d

[Bug go/71692] Running target unix FAIL: syscall

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  ---
The relevant failures are:

--- FAIL: TestCloneNEWUSERAndRemapNoRootDisableSetgroups (0.00s)
exec_linux_test.go:74: Cmd failed with err fork/exec /usr/bin/whoami:
in
valid argument, output: 
--- FAIL: TestCloneNEWUSERAndRemapNoRootSetgroupsEnableSetgroups (0.00s)
exec_linux_test.go:114: Unprivileged gid_map rewriting with
GidMappingsE
nableSetgroups must fail
--- FAIL: TestEmptyCredGroupsDisableSetgroups (0.00s)
exec_linux_test.go:122: fork/exec /usr/bin/whoami: invalid argument

This means that your system doesn't support some kinds of user namespace
features.  The test should arrange to not fail when those features are not
supported.

[Bug middle-end/71693] [4.9/5 Regression] ICE: verify_gimple failed (type mismatch in shift expression, -O0, -O1, -O2, -O3)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug go/71697] go link error

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
Note that as far as I can tell that error is only emitted by the GNU linker
when the --no-add-needed option is passed to the linker.  Is something on your
system adding that option or making it the default in some way?

[Bug target/71695] m68k: long long multiplication broken

[martin at netbsd dot org]

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

Martin Husemann  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Martin Husemann  ---
Indeed, an unmodified gcc 5.4 configured for linux does not do this - sorry for
the noise.

[Bug c/71699] New: bogus -Wmaybe-uninitialized warning: gcc misses that non-NULL pointer + offset can never be NULL

[palves at redhat dot com]

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

Bug ID: 71699
   Summary: bogus -Wmaybe-uninitialized warning: gcc misses that
non-NULL pointer + offset can never be NULL
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palves at redhat dot com
  Target Milestone: ---

gcc does not understand that adding an offset to a pointer returned by a
returns_nonnull function can never yield a NULL pointer.  Vis:

$ cat test.c 
char *xstrdup (const char *) __attribute__ ((__returns_nonnull__));

#define PREFIX "some "

int
main ()
{
  char *saveptr;
  char *name = xstrdup (PREFIX "name");

  // name = PREFIX "name";  // this makes the warning go away

  char *tail = name + sizeof (PREFIX) - 1;
  // tail = &name[sizeof (PREFIX) - 1]; // this does not help
  // tail = name;   // while this makes the warning go away

  if (tail == 0)
tail = saveptr;
  while (*tail == ' ')
++tail;

  return 0;
}
$ /opt/gcc/bin/gcc test.c -c -Wall
test.c: In function ‘main’:
test.c:18:10: warning: ‘saveptr’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
 tail = saveptr;
 ~^

Enabling optimization does not make it go away:

$ /opt/gcc/bin/gcc -O2 test.c -c -Wall
test.c: In function ‘main’:
test.c:19:10: warning: ‘saveptr’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   while (*tail == ' ')
  ^

That was gcc version 7.0.0 20160503 (experimental) built from sources.

Fedora 23's gcc 5.3.1 shows the same.

This is a reduced testcase based on a warning gcc issued when building gdb:
 https://sourceware.org/ml/gdb-patches/2016-06/msg00515.html

[Bug go/71697] go link error

[rootkit85 at yahoo dot it]

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

--- Comment #2 from Matteo Croce  ---
I run Ubuntu 16.04, how can I check if --no-add-needed is default?

[Bug go/71697] go link error

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
The running the failing command yourself with the -v option and see which
options are being passed to the linker.

[Bug middle-end/71700] New: [4.9/5/6/7 Regression] wrong code with struct assignment with sub-word signed bitfields

[ktkachov at gcc dot gnu.org]

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

Bug ID: 71700
   Summary: [4.9/5/6/7 Regression] wrong code with struct
assignment with sub-word signed bitfields
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: arm

The testcase below fails:

struct S {
  signed f0 : 16;
  unsigned f1 : 1;
};

int b;
static struct S c[] = { { -1, 0 }, { -1, 0 } };
struct S d;

int main() {
  struct S e = c[0];
  d = e;
  if (d.f1 != 0)
__builtin_abort ();
  return 0;
}

on arm targets with optimisation. At -O0 it doesn't abort.
The wrong code is at statement:
struct S e = c[0];

The constructor initialisation RTL emitted is:

;; e = c[0];

(insn 5 4 6 (set (reg/v:SI 112 [ e ])
(const_int 0 [0]))
 (nil))

(insn 6 5 7 (set (reg/v:SI 112 [ e ])
(const_int -1 [0x]))
 (nil))

The second SET clobbers the whole word rather than just the 16 bits it was
supposed to. The problem is in store_constructor in expr.c where it widens the
first store to word mode by sign-extending the value but then tries to avoid
storing the zero bitfield because it had initially cleared out the word (the
first set).

This testcase works for me for GCC 4.8.5 but fails on 4.9 and later

[Bug middle-end/71700] [4.9/5/6/7 Regression] wrong code with struct assignment with sub-word signed bitfields

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-29
  Known to work||4.8.5
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
   Target Milestone|--- |4.9.5
 Ever confirmed|0   |1
  Known to fail||4.9.4, 5.4.1, 6.1.0, 7.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I'm testing a patch

[Bug go/71697] go link error

[rootkit85 at yahoo dot it]

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

--- Comment #4 from Matteo Croce  ---
/home/matteo/src/openwrt/build_dir/toolchain-i386_pentium4_gcc-5.3.0_glibc-2.22/gcc-5.3.0-final/./gcc/collect-ld
-plugin
/home/matteo/src/openwrt/build_dir/toolchain-i386_pentium4_gcc-5.3.0_glibc-2.22/gcc-5.3.0-final/./gcc/liblto_plugin.so
-plugin-opt=/home/matteo/src/openwrt/build_dir/toolchain-i386_pentium4_gcc-5.3.0_glibc-2.22/gcc-5.3.0-final/./gcc/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc50FwqN.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr
-m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o go crt1.o crti.o
/home/matteo/src/openwrt/build_dir/toolchain-i386_pentium4_gcc-5.3.0_glibc-2.22/gcc-5.3.0-final/./gcc/crtbegin.o
-L../i486-openwrt-linux-gnu/libgo -L../i486-openwrt-linux-gnu/libgo/.libs
-L/home/matteo/src/openwrt/build_dir/toolchain-i386_pentium4_gcc-5.3.0_glibc-2.22/gcc-5.3.0-final/./gcc
/tmp/ccSK2xAP.o -lgobegin -lgo -lm --wrap=pthread_create -lgcc_s -lc -lgcc_s
/home/matteo/src/openwrt/build_dir/toolchain-i386_pentium4_gcc-5.3.0_glibc-2.22/gcc-5.3.0-final/./gcc/crtend.o
crtn.o

[Bug c++/70385] Lambda capture by reference of const reference fails

[ostash at ostash dot kiev.ua]

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

Viktor Ostashevskyi  changed:

   What|Removed |Added

 CC||ostash at ostash dot kiev.ua

--- Comment #1 from Viktor Ostashevskyi  ---
I can confirm this with:

gcc version 5.3.1 20160329 (GCC)

and 

gcc version 6.0.0 20160403 (experimental) (GCC).

It also fails with x86 gcc 6.1 (g++ (DRW-internal-build) 6.1.0) on
gcc.godbolt.org

[Bug tree-optimization/71625] missing strlen optimization on different array initialization style

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Martin, the changes you wanted to do are desirable in any case.
The changes I've committed don't fix this, they are just preparation for
further changes that might help.  But there still would be the suboptimal code
generation for the { 'a', 'b', 'c', '\0' }; style initialization.

[Bug c/71701] New: bogus token in -Wmaybe-uninitialized warning

[palves at redhat dot com]

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

Bug ID: 71701
   Summary: bogus token in -Wmaybe-uninitialized warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palves at redhat dot com
  Target Milestone: ---

This testcase makes gcc issue a confusing warning:

$ cat strtok.c 
char *xstrdup (const char *) __attribute__ ((__returns_nonnull__));

#define PREFIX "some "

#include 

int
main ()
{
  char *saveptr;
  char *name = xstrdup (PREFIX "name");
  char *tail = name + sizeof (PREFIX) - 1;
  char *token = strtok_r (tail, " ", &saveptr);

  return token [0];
}
$ /opt/gcc/bin/gcc -O2 strtok.c -c -Wall  
strtok.c: In function ‘main’:
strtok.c:15:16: warning: ‘__s’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   return token [0];
  ~~^~~
$

It's confusing because nowhere in the sources there's "__s" variable.

"__s" here is actually the parameter of an inlined function,
in /usr/include/bits2.h:

__STRING_INLINE char *__strtok_r_1c (char *__s, char __sep, char **__nextp);
__STRING_INLINE char *
__strtok_r_1c (char *__s, char __sep, char **__nextp)
{
  char *__result;
  if (__s == NULL)
__s = *__nextp;
...

[Bug target/71698] ICE related to decimal float when compiling with -mcpu=power9

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #1 from Segher Boessenkool  ---
I'll have a look.

[Bug c/71701] bogus token in -Wmaybe-uninitialized warning

[palves at redhat dot com]

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

--- Comment #1 from Pedro Alves  ---
I tried to reduce this manually, but failed.  My attempt made gcc warn about
the original variable in my test case:

 strtok.c: In function ‘main’:
 strtok.h:30:10: warning: ‘saveptr’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   while (*__s == __sep)
  ^~~~

It may be that glibc's use of __extension__ / __builtin_constant_p is what
triggers this.

[Bug c/71701] bogus token in -Wmaybe-uninitialized warning

[palves at redhat dot com]

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

--- Comment #2 from Pedro Alves  ---
Created attachment 38790
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38790&action=edit
Testcase.

[Bug middle-end/71701] bogus token in -Wmaybe-uninitialized warning

[palves at redhat dot com]

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

--- Comment #3 from Pedro Alves  ---
Created attachment 38791
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38791&action=edit
Preprocessed testcase.

[Bug middle-end/71701] bogus token in -Wmaybe-uninitialized warning

[palves at redhat dot com]

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

--- Comment #4 from Pedro Alves  ---
This was with: gcc version 7.0.0 20160503 (experimental) (GCC)

[Bug middle-end/71701] bogus token in -Wmaybe-uninitialized warning

[palves at redhat dot com]

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

--- Comment #5 from Pedro Alves  ---
See original context here, where the warning was truly puzzling:

 https://sourceware.org/ml/gdb-patches/2016-06/msg00515.html

[Bug go/71697] go link error

[rootkit85 at yahoo dot it]

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

--- Comment #5 from Matteo Croce  ---
$ x86_64-linux-gnu-gcc   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE 
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  
-DHAVE_CONFIG_H  -o go1   go/ast-dump.o go/dataflow.o go/export.o
go/expressions.o go/go-backend.o go/go-dump.o go/go-gcc.o go/go-lang.o
go/go-linemap.o go/go-optimize.o go/go.o go/gogo.o go/import.o
go/import-archive.o go/lex.o go/parse.o go/runtime.o go/statements.o go/types.o
go/unsafe.o attribs.o libbackend.a main.o  libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lstdc++  -lmpc -lmpfr
-lgmp -rdynamic -ldl -lstdc++ -L../zlib -lz -v
Using built-in specs.
COLLECT_GCC=x86_64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.3.1-14ubuntu2.1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2.1) 
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-g' '-O2' '-D' 'IN_GCC' '-D' 'CROSS_DIRECTORY_STRUCTURE'
'-fno-exceptions' '-fno-rtti' '-fasynchronous-unwind-tables' '-Wextra' '-Wall'
'-Wno-narrowing' '-Wwrite-strings' '-Wcast-qual' '-Wsuggest-attribute=format'
'-Woverloaded-virtual' '-Wpedantic' '-Wno-long-long' '-Wno-variadic-macros'
'-Wno-overlength-strings' '-D' 'HAVE_CONFIG_H' '-o' 'go1' '-rdynamic'
'-L../zlib' '-v' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccAV4PQ1.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/
--build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed
-export-dynamic -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o go1
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o -L../zlib
-L/usr/lib/gcc/x86_64-linux-gnu/5
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../.. go/ast-dump.o go/dataflow.o
go/export.o go/expressions.o go/go-backend.o go/go-dump.o go/go-gcc.o
go/go-lang.o go/go-linemap.o go/go-optimize.o go/go.o go/gogo.o go/import.o
go/import-archive.o go/lex.o go/parse.o go/runtime.o go/statements.o go/types.o
go/unsafe.o attribs.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lstdc++ -lmpc -lmpfr
-lgmp -ldl -lstdc++ -lz -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/5/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-

[Bug c/71699] bogus -Wmaybe-uninitialized warning: gcc misses that non-NULL pointer + offset can never be NULL

[palves at redhat dot com]

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

--- Comment #1 from Pedro Alves  ---
Created attachment 38792
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38792&action=edit
Testcase.

[Bug fortran/71066] [4.9/5/6/7 Regression] ICE in set_loop_bounds, at fortran/trans-array.c:4680

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> Confirmed, ICEs since GCC 4.6.0.

The ICE appeared between revisions r162456 (2010-07-23, compiles) and r1635293
(2010-08-24, ICE). The ICE is due to the gcc_assert

  /* An unknown size constructor will always be rank one.
 Higher rank constructors will either have known shape,
 or still be wrapped in a call to reshape.  */
  gcc_assert (loop->dimen == 1);

which is already present at r162456.

IMO the first test in comment 0 is invalid.

[Bug target/70814] atomic store of __int128 is not lock free on aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Richard Earnshaw from comment #10)
> (In reply to Andrew Pinski from comment #9)
> > On x86, they use ifuncs for this purpose inside libatomic. Basically the
> > requirement is only one libatomic can be used at a time.
> 
> If we can guarantee that, then yes, we could do something similar if we had
> fully atomic 128-bit loads.

You have to guarantee that anyways because of the way libatomic is implemented.
 That is the lock used by the implementations has to be the same across all
uses of them.