[Bug c/69197] Can't compile older

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Note the referenced failure looks like it can be fixed by using -std=gnu89 as
part of the CFLAGS.  That is it gcc 2.95 uses GNU 89 style inline which is
incompatible with C99 inline.

[Bug sanitizer/69204] ThreadSanitizer: False positive on std::promise usage

[bugzil...@reto-schneider.ch]

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

--- Comment #5 from bugzil...@reto-schneider.ch ---
The generated binaries use the same libraries:

$ clang++-3.6 -fsanitize=thread -Wall -Wextra -std=c++11 -pthread -o
tsan-test-clang tsan-test.cpp
$ ldd tsan-test-clang
linux-vdso.so.1 (0x7fff1d397000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7fcf82df)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fcf82aeb000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fcf828cd000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fcf826c5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fcf824c1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7fcf822aa000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fcf81f06000)
/lib64/ld-linux-x86-64.so.2 (0x55e4931e1000)

$ g++-5 -fsanitize=thread -Wall -Wextra -std=c++11 -pthread -static-libtsan -o
tsan-test-gcc tsan-test.cpp
$ ldd tsan-test-gcc
linux-vdso.so.1 (0x7ffc8a382000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7fa9b9778000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fa9b9473000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fa9b9255000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fa9b9051000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7fa9b8e3b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fa9b8a96000)
/lib64/ld-linux-x86-64.so.2 (0x564f3130c000)

[Bug c/23087] Misleading warning, "... differ in signedness"

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #15 from Bernd Schmidt  ---
Joseph, based on gcc-patches discussion, should we close this as invalid, or do
you think there is a beneficial change that could be made?

[Bug rtl-optimization/69206] testsuite/gcc.c-torture/execute/alias-2.c fails on aarch64-linux-gnu at -O1 and above

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
the fix for PR 68832 is still being discussed on the ml AFAIK

[Bug tree-optimization/69207] [6 Regression] gcc.target/aarch64/vldN_1.c ICEs at -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Depends on||69083

--- Comment #1 from Andrew Pinski  ---
I think this introduced by the fix for PR 69083 but I have not evidence besides
the error message seems similar and the change between VCE and NOP_EXPR
happened with that bug.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69083
[Bug 69083] [6 Regression] ICE at -O3 in 64-bit mode on x86_64-linux-gnu
(verify_gimple failed)

[Bug c++/69113] [6 Regression] ICE: in vague_linkage_p, at cp/decl2.c:1875 with -fno-weak

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Sat Jan  9 11:15:26 2016
New Revision: 232189

URL: https://gcc.gnu.org/viewcvs?rev=232189=gcc=rev
Log:
PR c++/69113
* decl2.c (comdat_linkage): Only set DECL_COMDAT if TREE_PUBLIC is set.

* g++.dg/pr69113.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr69113.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/69207] [6 Regression] gcc.target/aarch64/vldN_1.c ICEs at -O3

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Seems there is a mismatch in between fold_convertible_p and
verify_gimple_assign_unary (and also the gimplifier).
E.g. for this special case fold_convertible_p has some weird exception:
2188  return (TREE_CODE (orig) == VECTOR_TYPE
2189  && tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE
(orig)));
But verify_gimple_assign_unary certainly doesn't allow that.  It has also
various other restrictions, e.g. on pointer conversions etc.
So, Richard, do we or should we have another predicate that says for outer and
inner type if it is ok to use GIMPLE_ASSIGN with NOP_EXPR?
Most of the uses that use fold_convertible_p in the middle-end actually perform
fold_convert or fold_build1 (... NOP_EXPR, ...), which creates a NOP_EXPR from
the VECTOR_TYPE to same sized integral type.  Strangely, when trying to
gimplify that it just creates a NOP_EXPR GIMPLE_ASSIGN, which then fails
verification.
So, what is the above mentioned 2188/2189 there for and corresponding
fold_convert_loc:
2246  gcc_assert (TREE_CODE (orig) == VECTOR_TYPE
2247  && tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE
(orig)));
2248  return fold_build1_loc (loc, NOP_EXPR, type, arg);
Shall it not create a VCE instead?
Or shall it at least not gimplify to a VCE instead of a NOP_EXPR?
For the tree-vect-slp.c case it is of course enough to just replace
fold_convertible_p with INTEGRAL_TYPE_P && INTEGRAL_TYPE_P check, but I really
think we should figure out what we want and have proper predicates for it.

[Bug sanitizer/69204] ThreadSanitizer: False positive on std::promise usage

[bugzil...@reto-schneider.ch]

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

--- Comment #4 from bugzil...@reto-schneider.ch ---
Created attachment 37295
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37295=edit
g++-5 -fsanitize=thread -Wall -Wextra -std=c++11 -pthread -static-libtsan
tsan-test.cpp && ./a.out > sanitizer-output.txt 2>&1

Output of the program

[Bug c++/69113] [6 Regression] ICE: in vague_linkage_p, at cp/decl2.c:1875 with -fno-weak

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug ada/67086] [5/6 regression] RE_Not_Available error when building ghdl-0.32

[vicencb at gmail dot com]

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

--- Comment #3 from vicencb at gmail dot com ---
Hello,
If this obsolete No_Run_Time pragma makes the compiler to fail and ask the user
to report a bug against GCC, then I would suggest completely deprecating it by
disallowing it.
In my opinion, if a GCC option makes GCC to fail when used, then it is a GCC
bug.
In any case, thanks for searching and finding the root cause of the issue.

[Bug ada/67086] [5/6 regression] RE_Not_Available error when building ghdl-0.32

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Bet diagnosic this is fine and correct, but it shouldn't cause an ICE, but
fatal_error.

[Bug sanitizer/69204] ThreadSanitizer: False positive on std::promise usage

[dvyukov at google dot com]

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

Dmitry Vyukov  changed:

   What|Removed |Added

 CC||dvyukov at google dot com

--- Comment #3 from Dmitry Vyukov  ---
Hi,

Please post full program output with ThreadSanitizer report.
I wonder why clang does not report the same... Does it use the same C++
standard library?
I afraid that the solution is to use a tsan-instrumented libstdc++.

[Bug target/67462] [6 Regression] FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made"

[bernds at gcc dot gnu.org]

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

--- Comment #6 from Bernd Schmidt  ---
That does look dodgy. It's also really old, from when rtx_cost was part of
cse.c. Kenner added it along with many other changes in r754 in 1992.

See what happens to codegen if you just strip SUBREGs before this switch and
lose the MODES_TIEABLE thing?

[Bug c/69197] Can't compile older

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #3 from Eric Botcazou  ---
Sorry, GCC 2.95 is not supported anymore.

[Bug middle-end/68832] FAIL: gcc.c-torture/execute/alias-2.c -O1 execution test

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #8 from Andrew Pinski  ---
*** Bug 69206 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/69206] testsuite/gcc.c-torture/execute/alias-2.c fails on aarch64-linux-gnu at -O1 and above

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup of bug 68832.  I missed the dup sorry.

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

[Bug c/69192] valgrind trunk build fail in predict_loops

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from David Binderman  ---
(In reply to David Binderman from comment #2)
> (In reply to Markus Trippelsdorf from comment #1)
> > May well be a clang bug. Does it also happen if you use gcc to build?
> 
> No. Then it drops back to the # 66420 case.
> 
> I'll try a build without the -O3 -march=native, just -O2 and see what
> happens.

Build successful, so it looks like a clang bug ;-<

I note with interest that, for the build, I had to change my
usual ulimit -t 600 to ulimit -t 1200.

[Bug target/67462] [6 Regression] FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org,
   ||law at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
BTW, the reason why the costs are different is not something in backend's
control.
rtx_cost has:
case SUBREG:
  total = 0;
  /* If we can't tie these modes, make this expensive.  The larger
 the mode, the more expensive it is.  */
  if (! MODES_TIEABLE_P (mode, GET_MODE (SUBREG_REG (x
return COSTS_N_INSNS (2 + factor);
  break;
without the possibility of target to override this, and as for 32-bit arches
HARD_REGNO_MODE_NREGS is different between SImode and DImode, those are
required not to be tieable.
I fail to see why at least on i686/x86_64 for the word mode integral subregs of
integral double word mode there is any higher cost than of simple REG (i.e. 0)
though, if the pseudo the subreg is of is given a hard register, then reload
turns it into access of just one register of the GPR pair, and if it lives in a
stack slot, then reload can just load and/or store one half of the memory slot.

[Bug tree-optimization/69196] code size regression with jump threading at -O2

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|sparc   |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-09
 CC||ebotcazou at gcc dot gnu.org
  Component|target  |tree-optimization
Summary|Code size regression on |code size regression with
   |SPARC   |jump threading at -O2
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
Not target specific.

[Bug tree-optimization/69207] [6 Regression] gcc.target/aarch64/vldN_1.c ICEs at -O3

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Also it was passing here:
https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg00584.html

[Bug tree-optimization/69207] [6 Regression] gcc.target/aarch64/vldN_1.c ICEs at -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-09
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed based on https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg00702.html
which came out after I filed my bug.

[Bug c/69202] semicolon at end of expression statement

[timeraider at gmx dot at]

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

--- Comment #3 from timeraider at gmx dot at ---
Thank you for the clarification. There is something new to learn in C/C++
programming every day ;-).

[Bug target/69129] [6 Regression] ICE in get_attr_got, at config/mips/mips.md:694 on mips-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose  ---
still seen with r232188

[Bug c++/69210] New: False positives from -Wsuggest-final-types/methods

[lloyd at randombit dot net]

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

Bug ID: 69210
   Summary: False positives from -Wsuggest-final-types/methods
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lloyd at randombit dot net
  Target Milestone: ---

In GCC 5.3 -Wsuggest-final-{types,methods} seems a little trigger happy. For
example this code:

$ cat final.cpp
// in a header...
class A
   {
   public:
  virtual ~A() {}
  virtual int f(int x) { return 2*x; }
  virtual int g(int x) = 0;
   };

// later in a source file...

int foo(A& a, int x)
   {
   return a.f(a.g(x));
   }


$ g++ -O3 -std=c++11 -c -Wall -Wextra -Wsuggest-final-types
-Wsuggest-final-methods final.cpp
final.cpp:3:7: warning: Declaring type 'class A' final would enable
devirtualization of 1 call [-Wsuggest-final-types]
 class A
   ^
final.cpp:7:19: warning: Declaring method 'virtual int A::f(int)' final would
enable devirtualization of 1 call [-Wsuggest-final-methods]
   virtual int f(int x) { return 2*x; }

$ g++ -v
Using built-in specs.
COLLECT_GCC=/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5.3.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 5.3.0 (GCC) 

But I think it doesn't make sense to warn that a type should be final, when the
type is directly introducing the new virtual call that could be devirtualized:
if it made sense for A or A::f to be final it would be more reasonable to
remove the virtual keyword entirely. In fact here A can't even be instantiated
due to the pure virtual g(), and thus must be overridden, but gcc seems to miss
that.

This comes up whenever a base type A defines a virtual function with a default
and GCC sees A& being used, without any subclasses of A being visible at the
call.

I have no idea how complicated this would be to fix or if there is any interest
in doing so. I'd be willing to try my hand at a patch, if there is any chance
it would be accepted (if so, any pointers on how/where to proceed would be
great as I'm not that familiar with the gcc sources).

[Bug tree-optimization/69209] [6 Regression] ICE at -Os and above on x86_64-linux-gnu (verify_gimple failed)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-09
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE at -Os and above on |[6 Regression] ICE at -Os
   |x86_64-linux-gnu|and above on
   |(verify_gimple failed)  |x86_64-linux-gnu
   ||(verify_gimple failed)
 Ever confirmed|0   |1

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

[Bug middle-end/68743] [6 Regression] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #27 from John David Anglin  ---
Author: danglin
Date: Sat Jan  9 18:13:44 2016
New Revision: 232191

URL: https://gcc.gnu.org/viewcvs?rev=232191=gcc=rev
Log:
PR middle-end/68743
* match.pd: Require target has function_c99_misc before doing
truncl(extend(x)) and trunc(extend(x)) -> extend(truncf(x)), etc.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd

[Bug middle-end/68743] [6 Regression] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #28 from John David Anglin  ---
Fixed.

[Bug middle-end/69211] New: g++ ICE on x86_64-linux-gnu (verify_gimple failed)

[helloqirun at gmail dot com]

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

Bug ID: 69211
   Summary: g++ ICE on x86_64-linux-gnu (verify_gimple failed)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following code causes an ICE when compiled with the current g++ trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes. The current gcc trunk works
fine.

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160109 (experimental) [trunk revision 232190] (GCC)


$ g++-trunk -c abc.cc
abc.cc: In function ?void fn1()?:
abc.cc:2:6: error: type mismatch in binary expression
 void fn1() { (a & 5UL | (b = 4, 4L)) > 4; }
  ^~~

long unsigned int

long unsigned int

long int

D.2260 = D.2259 | 4;
abc.cc:2:6: internal compiler error: verify_gimple failed
0xd3e0dd verify_gimple_in_seq(gimple*)
../../gcc/gcc/tree-cfg.c:4787
0xacbd42 gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:11313
0xacc0d6 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:11401
0x953e97 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:625
0x957283 analyze_functions
../../gcc/gcc/cgraphunit.c:1080
0x957f68 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2531
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.


--
$ cat abc.cc
int a, b;
void fn1() { (a & 5UL | (b = 4, 4L)) > 4; }

[Bug tree-optimization/69212] New: g++ ICE (segfault) at -O3 on x86_64-linux-gnu in fsm_find_control_statement_thread_paths

[helloqirun at gmail dot com]

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

Bug ID: 69212
   Summary: g++ ICE (segfault) at -O3 on x86_64-linux-gnu in
fsm_find_control_statement_thread_paths
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following code causes an ICE when compiled with the current g++ trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160109 (experimental) [trunk revision 232190] (GCC)




$ g++-trunk -c -O3 abc.cc
abc.cc: In function ?void fn2(int)?:
abc.cc:10:19: error: unknown register name ?? in ?asm?
   asm("" : : : "");
   ^

abc.cc:10:19: error: unknown register name ?? in ?asm?
   asm("" : : : "");
   ^

abc.cc:10:19: error: unknown register name ?? in ?asm?
   asm("" : : : "");
   ^

abc.cc:10:19: error: unknown register name ?? in ?asm?
   asm("" : : : "");
   ^

abc.cc:10:19: error: unknown register name ?? in ?asm?
   asm("" : : : "");
   ^

abc.cc:10:19: error: unknown register name ?? in ?asm?
   asm("" : : : "");
   ^

abc.cc:10:19: error: unknown register name ?? in ?asm?
   asm("" : : : "");
   ^

abc.cc:10:19: error: unknown register name ?? in ?asm?
   asm("" : : : "");
   ^

abc.cc:10:19: error: unknown register name ?? in ?asm?
   asm("" : : : "");
   ^

abc.cc: In function ?void fn2(int)?:
abc.cc:4:6: internal compiler error: Segmentation fault
 void fn2(int p1) {
  ^~~

0xd04cdf crash_signal
../../gcc/gcc/toplev.c:334
0x14549b5 fsm_find_control_statement_thread_paths
../../gcc/gcc/tree-ssa-threadbackward.c:102
0x1455be4 find_jump_threads_backwards(edge_def*)
../../gcc/gcc/tree-ssa-threadbackward.c:382
0xeec0b4 thread_across_edge(gcond*, edge_def*, bool, const_and_copies*,
avail_exprs_stack*, tree_node* (*)(gimple*, gimple*, avail_exprs_stack*))
../../gcc/gcc/tree-ssa-threadedge.c:1027
0xe25a37 dom_opt_dom_walker::thread_across_edge(edge_def*)
../../gcc/gcc/tree-ssa-dom.c:945
0xe25c79 dom_opt_dom_walker::after_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-dom.c:1396
0x1385777 dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:307
0xe280a8 execute
../../gcc/gcc/tree-ssa-dom.c:613
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.




-
$ cat abc.cc
double a;
int b;
void fn1();
void fn2(int p1) {
l:
  b = a;
  if (p1)
if (a)
  goto l;
  asm("" : : : "");
  fn2(1);
  fn1();
}

[Bug tree-optimization/69209] New: ICE at -Os and above on x86_64-linux-gnu (verify_gimple failed)

[su at cs dot ucdavis.edu]

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

Bug ID: 69209
   Summary: ICE at -Os and above on x86_64-linux-gnu
(verify_gimple failed)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-Os and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It is a regression from 5.3.x. 

Possibly related to PR 69083, which has just been fixed. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160108 (experimental) [trunk revision 232154] (GCC) 
$ 
$ gcc-trunk -O1 -c small.c
$ gcc-5.3 -Os -c small.c
$ 
$ gcc-trunk -Os -c small.c
small.c: In function ‘fn1’:
small.c:24:1: error: invalid operand in return statement
 }
 ^

f

# VUSE <.MEM_1(D)>
return f;
small.c:24:1: internal compiler error: verify_gimple failed
0xb30566 verify_gimple_in_cfg(function*, bool)
../../gcc-trunk/gcc/tree-cfg.c:5119
0xa24257 execute_function_todo
../../gcc-trunk/gcc/passes.c:1958
0xa24b4b execute_todo
../../gcc-trunk/gcc/passes.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


--


int a, c, *d, e;

void __assert_fail () __attribute__ ((__noreturn__));

int
fn1 ()
{
  int f;
  if (a)
{
  if (e)
__assert_fail ();
  __assert_fail ();
}
  d ==  ? (void) 0 : __assert_fail ();
  c ? (void) 0 : __assert_fail ();
  return f;
}

void
fn2 ()
{
  fn1 ();
}

[Bug c++/69211] [6 Regression] g++ ICE on x86_64-linux-gnu (verify_gimple failed)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-09
  Component|middle-end  |c++
   Target Milestone|--- |6.0
Summary|g++ ICE on x86_64-linux-gnu |[6 Regression] g++ ICE on
   |(verify_gimple failed)  |x86_64-linux-gnu
   ||(verify_gimple failed)
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.  Also on aarch64-linux-gnu.

[Bug middle-end/69212] [6 Regresion] g++ ICE (segfault) at -O3 on x86_64-linux-gnu in fsm_find_control_statement_thread_paths

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|g++ ICE (segfault) at -O3   |[6 Regresion] g++ ICE
   |on x86_64-linux-gnu in  |(segfault) at -O3 on
   |fsm_find_control_statement_ |x86_64-linux-gnu in
   |thread_paths|fsm_find_control_statement_
   ||thread_paths

[Bug middle-end/69212] [6 Regresion] g++ ICE (segfault) at -O3 on x86_64-linux-gnu in fsm_find_control_statement_thread_paths

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-09
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed also on aarch64-linux-gnu.

Note the multiple error message happen at -O3 only.

[Bug tree-optimization/69213] g++ ICE (segfault) at -O1 and above on x86_64-linux-gnu in "add_dependency"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-09
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed on aarch64-linux-gnu also.  Note this only happens with the C++
front-end.

[Bug tree-optimization/69214] New: ICE (segfault) at -Os on x86_64-linux-gnu in "fail_abnormal_edge_coalesce"

[helloqirun at gmail dot com]

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

Bug ID: 69214
   Summary: ICE (segfault) at -Os on x86_64-linux-gnu in
"fail_abnormal_edge_coalesce"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-Os  on x86_64-linux-gnu in 64-bit mode.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160109 (experimental) [trunk revision 232190] (GCC)



$ gcc-trunk -c -Os abc.c

Unable to coalesce ssa_names 2 and 17 which are marked as MUST COALESCE.
d_2(ab) and  d_17(ab)
abc.c: In function 'foo':
abc.c:8:6: internal compiler error: SSA corruption
 void foo (struct A *x)
  ^~~

0xc3eb26 fail_abnormal_edge_coalesce
../../gcc/gcc/tree-ssa-coalesce.c:936
0xc3eb26 coalesce_partitions
../../gcc/gcc/tree-ssa-coalesce.c:1337
0xc3eb26 coalesce_ssa_name()
../../gcc/gcc/tree-ssa-coalesce.c:1821
0xbcf7d0 remove_ssa_form
../../gcc/gcc/tree-outof-ssa.c:974
0xbcf7d0 rewrite_out_of_ssa(ssaexpand*)
../../gcc/gcc/tree-outof-ssa.c:1198
0x747ad0 execute
../../gcc/gcc/cfgexpand.c:6124
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.



-
$ cat abc.c

extern int setjmp (int);
extern int fun1 (int);
extern int *fun2 (void);

struct A {unsigned a;};

void foo (struct A *x)
{
  int d = 0;
  long f = 0;
  setjmp (*fun2());
  f = d;
  d = 8;
  ((x->a) && !f && fun1 (d));
}

[Bug tree-optimization/69213] New: g++ ICE (segfault) at -O1 and above on x86_64-linux-gnu in "add_dependency"

[helloqirun at gmail dot com]

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

Bug ID: 69213
   Summary: g++ ICE (segfault) at -O1 and above on
x86_64-linux-gnu in "add_dependency"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following code causes an ICE when compiled with the current g++ trunk at
-O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.


$ g++-trunk  -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160109 (experimental) [trunk revision 232190] (GCC)



$ g++-trunk -c -O3 abc.c
abc.c: In function ?void fn1()?:
abc.c:2:40: error: invalid 'asm': operand number out of range
 void fn1() { __asm__("add %w0%w1%w2" :); }
^

abc.c:2:40: error: invalid 'asm': operand number out of range
abc.c:2:40: error: invalid 'asm': operand number out of range
abc.c: In function ?int main()?:
abc.c:3:1: internal compiler error: Segmentation fault
 main() {
 ^~~~

0xd04cdf crash_signal
../../gcc/gcc/toplev.c:334
0xe3c08d add_dependency
../../gcc/gcc/tree-ssa-loop-im.c:419
0xe3c399 determine_max_movement
../../gcc/gcc/tree-ssa-loop-im.c:743
0xe3d833 invariantness_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-loop-im.c:1080
0x13858e2 dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:265
0xe4005f tree_ssa_lim
../../gcc/gcc/tree-ssa-loop-im.c:2518
0xe4005f execute
../../gcc/gcc/tree-ssa-loop-im.c:2572
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.



--
$ cat abc.cc
int a, b;
void fn1() { __asm__("add %w0%w1%w2" :); }
main() {
  for (; a < 0; b++)
a = b;
}

[Bug target/69179] undocumented darwin attributes "apple_kext_compatibility" and "weak_import"

[howarth.at.gcc at gmail dot com]

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

--- Comment #1 from Jack Howarth  ---
Note that weak_import was added by Geoffrey Keating in...

https://gcc.gnu.org/ml/gcc-patches/2004-10/msg02441.html

and tweaked in...

https://gcc.gnu.org/ml/gcc-patches/2005-01/msg00146.html

The last time Geoff referenced it in a patch, he claimed it was 'effectively
deprecated' in gcc...

https://gcc.gnu.org/ml/gcc-patches/2005-12/msg00378.html

It might be worth checking with the Apple clang developers to see what their
current position is on the feature. I would note that
http://clang.llvm.org/docs/AttributeReference.html has...

A declaration can be used even when deploying back to a platform version prior
to when the declaration was introduced. When this happens, the declaration is
weakly linked, as if the weak_import attribute were added to the declaration. A
weakly-linked declaration may or may not be present a run-time, and a program
can determine whether the declaration is present by checking whether the
address of that declaration is non-NULL.

in the section describing the availability attribute so I guess they still
intend to support into the future.

[Bug tree-optimization/69214] ICE (segfault) at -Os on x86_64-linux-gnu in "fail_abnormal_edge_coalesce"

[helloqirun at gmail dot com]

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

--- Comment #1 from Qirun Zhang  ---
Here is a smaller case:


long a;

extern int fun1();
extern void fun2();
extern void setjmp();
void foo() {
  int d = 0;
  fun2();
  setjmp();
  a = d;
  d = 8;
  !a && fun1();
}

[Bug tree-optimization/69214] ICE (segfault) at -Os on x86_64-linux-gnu in "fail_abnormal_edge_coalesce"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Depends on||69167

--- Comment #2 from Andrew Pinski  ---
Related to PR 69167.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69167
[Bug 69167] [6 Regression] internal compiler error: SSA corruption

[Bug c++/69215] New: Improve diagnostic for 'for(i : v)'

[rs2740 at gmail dot com]

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

Bug ID: 69215
   Summary: Improve diagnostic for  'for(i : v)'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Something like

#include 

int main(){
std::vector v;
for(i : v) {}
}

produces a storm of not-very-enlightening errors on trunk:

prog.cc: In function 'int main()':
prog.cc:5:11: error: found ':' in nested-name-specifier, expected '::'
 for(i : v) {}
   ^

prog.cc:5:9: error: 'i' has not been declared
 for(i : v) {}
 ^

prog.cc:6:1: error: expected primary-expression before '}' token
 }
 ^

prog.cc:6:1: error: expected ';' before '}' token
prog.cc:6:1: error: expected primary-expression before '}' token
prog.cc:6:1: error: expected ')' before '}' token
prog.cc:6:1: error: expected primary-expression before '}' token

in contrast to clang's:

prog.cc:5:9: error: range-based for loop requires type for loop variable
for(i : v) {}
^

Perhaps the code implementing N3994, removed by r229632, can be repurposed
instead to produce a better error message?

[Bug rtl-optimization/69206] New: testsuite/gcc.c-torture/execute/alias-2.c fails on aarch64-linux-gnu at -O1 and above

[pinskia at gcc dot gnu.org]

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

Bug ID: 69206
   Summary: testsuite/gcc.c-torture/execute/alias-2.c fails on
aarch64-linux-gnu at -O1 and above
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

The tree level looks correct:

  b[off.0_2] = 1;
  a[off.0_2] = 2;
  _5 = b[off.0_2];
  if (_5 != 2)
goto ;
  else
goto ;

  :
  __builtin_abort ();

But the final output is not:
main:
stp x29, x30, [sp, -16]!
add x29, sp, 0
adrpx0, off
ldrsw   x2, [x0, #:lo12:off]
adrpx1, b
adrpx0, .LANCHOR0
add x1, x1, :lo12:b
mov w4, 1
add x0, x0, :lo12:.LANCHOR0
str w4, [x1, x2, lsl 2]
mov w3, 2
str w3, [x0, x2, lsl 2]
bl  abort

[Bug rtl-optimization/69206] testsuite/gcc.c-torture/execute/alias-2.c fails on aarch64-linux-gnu at -O1 and above

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||aarch64-linux-gnu
  Known to fail||4.8.4, 6.0

--- Comment #1 from Andrew Pinski  ---
This is not a regression as far as I can see.

[Bug target/67462] [6 Regression] FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 37294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37294=edit
gcc6-pr67462.patch

This is not just a cost issue, x86_64 -m32 is a 32-bit wordsize target, some of
the instructions ce1 sees are still DImode, but e.g. the comparisons are ors of
the subreg parts etc.  This really should not be expected to be optimized at
the RTL level, you'd need to optimize it at the gimple level.

[Bug tree-optimization/69207] [6 Regression] gcc.target/aarch64/vldN_1.c ICEs at -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug tree-optimization/69207] New: [6 Regression] gcc.target/aarch64/vldN_1.c ICEs at -O3

[pinskia at gcc dot gnu.org]

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

Bug ID: 69207
   Summary: [6 Regression] gcc.target/aarch64/vldN_1.c ICEs at -O3
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

Excess errors:
/home/apinski/src/local/gcc/gcc/testsuite/gcc.target/aarch64/vldN_1.c:10:1:
error: invalid types in nop conversion
long unsigned int
__Uint64x1_t
_70 = (long unsigned int) _28;

This started recently too:
-LAST_UPDATED: Mon Dec 28 06:11:23 UTC 2015 (revision 231970)
+LAST_UPDATED: Sat Jan  9 02:21:48 UTC 2016 (revision 232185)

[Bug fortran/68829] [4.9/5/6 Regression] Segfaults with -Ofast due to large array on stack

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/67755] [5/6 Regression] Bad edge probability/block freqency for tree jump threading

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Do you happen to still have the patch, even if just WIP?

[Bug target/69051] Misaligned read from the stack when using odd sized character array

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
Per c#3.

[Bug tree-optimization/69166] [6 Regression] ICE in get_initial_def_for_reduction, at tree-vect-loop.c:4188

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Started with r226814 (though, as that is a sccvn change and the ICE in the
vectorizer, likely just a latent issue became reproduceable).

[Bug tree-optimization/67755] [5/6 Regression] Bad edge probability/block freqency for tree jump threading

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
I'm still poking at it.

[Bug debug/69073] internal compiler error: in maybe_record_trace_start

[ysato at users dot sourceforge.jp]

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

--- Comment #4 from Yoshinori Sato  ---
still have problem...
$ LANG=C gcc/xgcc -v -B ./gcc -Os -g -ffixed-r13 -c ~/nfs.c
Reading specs from ./gcc/specs
COLLECT_GCC=gcc/xgcc
Target: rx-elf
Configured with: ../configure --target=rx-elf --prefix=/home/ysato/rxelf
--enable-languages=c --disable-libssp --disable-ssp --disable-mpc --disable-gmp
--disable-mpfr --disable-threads --disable-shared --disable-libmudflap
--disable-libgomp --disable-zlib --disable-libquadmath --without-libc
--disable-libatomic
Thread model: single
gcc version 6.0.0 20160109 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-B' './gcc' '-Os' '-g' '-ffixed-r13' '-c'
 ./gcc/cc1 -quiet -v -iprefix
/home/ysato/dev/gcc/rx/gcc/../lib/gcc/rx-elf/6.0.0/ -isystem ./gcc/include
-isystem ./gcc/include-fixed ../../../nfs.c -quiet -dumpbase nfs.c -auxbase nfs
-g -Os -version -ffixed-r13 -o /tmp/cc5Eo3x1.s
GNU C11 (GCC) version 6.0.0 20160109 (experimental) (rx-elf)
compiled by GNU C version 4.9.3, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/home/ysato/dev/gcc/rx/gcc/../lib/gcc/rx-elf/6.0.0/include"
ignoring nonexistent directory
"/home/ysato/dev/gcc/rx/gcc/../lib/gcc/rx-elf/6.0.0/include-fixed"
ignoring nonexistent directory
"/home/ysato/dev/gcc/rx/gcc/../lib/gcc/rx-elf/6.0.0/../../../../rx-elf/sys-include"
ignoring nonexistent directory
"/home/ysato/dev/gcc/rx/gcc/../lib/gcc/rx-elf/6.0.0/../../../../rx-elf/include"
ignoring nonexistent directory
"/home/ysato/dev/gcc/rx/gcc/../lib/gcc/../../lib/gcc/rx-elf/6.0.0/include"
ignoring nonexistent directory
"/home/ysato/dev/gcc/rx/gcc/../lib/gcc/../../lib/gcc/rx-elf/6.0.0/include-fixed"
ignoring nonexistent directory
"/home/ysato/dev/gcc/rx/gcc/../lib/gcc/../../lib/gcc/rx-elf/6.0.0/../../../../rx-elf/sys-include"
ignoring nonexistent directory
"/home/ysato/dev/gcc/rx/gcc/../lib/gcc/../../lib/gcc/rx-elf/6.0.0/../../../../rx-elf/include"
#include "..." search starts here:
#include <...> search starts here:
 ./gcc/include
 ./gcc/include-fixed
End of search list.
GNU C11 (GCC) version 6.0.0 20160109 (experimental) (rx-elf)
compiled by GNU C version 4.9.3, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 6d61ea74e103f1b6720f7d895a3673eb
In file included from include/common.h:22:0,
 from net/nfs.c:25:
include/linux/string.h:24:7: warning: conflicting types for built-in function
'bcopy'

In file included from net/nfs.c:25:0:
include/common.h:877:6: warning: conflicting types for built-in function 'putc'

include/common.h:878:6: warning: conflicting types for built-in function 'puts'

In file included from net/nfs.c:25:0:
include/common.h:899:6: warning: conflicting types for built-in function
'fputs'

include/common.h:900:6: warning: conflicting types for built-in function
'fputc'

net/nfs.c: In function 'nfs_umountall_req':
net/nfs.c:276:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2284

0x708747 maybe_record_trace_start
../../gcc/dwarf2cfi.c:2284
0x709000 scan_trace
../../gcc/dwarf2cfi.c:2462
0x7097ba create_cfi_notes
../../gcc/dwarf2cfi.c:2616
0x7097ba execute_dwarf2_frame
../../gcc/dwarf2cfi.c:2974
0x7097ba execute
../../gcc/dwarf2cfi.c:3454
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug fortran/69155] [6 Regression] ICE (segfault in gimple_stmt_nonnegative_warnv_p)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase (-O1 is enough):
function pr69155 (a, b)
  complex(kind=8), value :: a, b
  if (dimag (a) .lt. 10) then
  1 continue
if (dble (a) .lt. 10) then
  b = b - 1 / a
  a = a + 1
  goto 1
end if
  end if
  pr69155 = a + b
end

[Bug c++/69208] New: &*this should not be const-qualified

[rs2740 at gmail dot com]

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

Bug ID: 69208
   Summary: &*this should not be const-qualified
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro:

struct A
{
  void f(){ A*&& a = &*this; }
};

results in:

prog.cc: In member function 'void A::f()':
prog.cc:3:24: error: binding 'A* const' to reference of type 'A*&&' discards
qualifiers
   void f(){ A*&& a = &*this; }
^~~~

PR56701 fixed the case where 'this' instead of '&*this' is used, but the above
test case still breaks.

[Bug fortran/69155] [6 Regression] ICE (segfault in gimple_stmt_nonnegative_warnv_p)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #2)
> I think we have a dup/related bug where we run into the issue that
> tree-complex.c
> wrecks SSA form during its rewrite.

That is indeed what happens, but what solution do you see other than avoiding
all the simplifications/optimizations that follow ssa edges?
We have:
:
# a_22 = PHI 
# b_23 = PHI 
# a$real_28 = PHI 
# a$imag_29 = PHI 
# b$real_32 = PHI 
# b$imag_33 = PHI 
_9 = __complex__ (1.0e+0, 0.0) / a_22;
b_10 = b_23 - _9;
a_11 = a_22 + __complex__ (1.0e+0, 0.0);
_8 = REALPART_EXPR ;
if (_8 < 1.0e+1)
  goto ;
else
  goto ;

While we could avoid the crash on lowering the division by handling it last,
e.g. the addition has a loop of dependencies, so either we create a PHI first,
but then don't have definitions for its arguments, or we lower the + first, but
then we don't have definition for the PHI.  We can't create all the statements
in a transaction together.
Do you suggest we set some temporary SSA_NAME_DEF_STMTs for the SSA_NAMEs we
create and we don't have a real definition yet (say GIMPLE_NOP)?
Wouldn't some simplification attempt to optimize it as uninitialized?
Or stop using gimple_build* and revert to constructing it using builders that
don't actually fold anything or try to optimize anything, and when we have
everything fold all newly added statements?

[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault

[eyenseo at gmail dot com]

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

--- Comment #11 from eyenseo at gmail dot com ---
(In reply to Jonathan Wakely from comment #10)
> Use ldd to see which library is used at runtime. See what file that symlink
> points to. Compare with the version numbers of the releases.
> 
> GCC 4.9.0: libstdc++.so.6.0.20
> 
> GCC 5.1.0: libstdc++.so.6.0.21

Ok will do on Monday

[Bug ada/67086] [5/6 regression] RE_Not_Available error when building ghdl-0.32

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Eric Botcazou  ---
grt.adc contains the obsolete No_Run_Time pragma, which is responsible for the
compilation failure.  Just compile without the -gnatec flag as documented.

[Bug c++/69215] Improve diagnostic for 'for(i : v)'

[graham.stott at btinternet dot com]

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

--- Comment #1 from graham.stott at btinternet dot com ---
Ok thats quick only 1 hour plus 2 hour car airport.
I been by train long time sleep on train in bed and by bus both 12 hrs if I
recall correctly.
Might be home now.



 Original message 
From: rs2740 at gmail dot com  
Date: 10/01/2016  05:11  (GMT+00:00) 
To: gcc-bugs@gcc.gnu.org 
Subject: [Bug c++/69215] New: Improve diagnostic for  'for(i : v)' 

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

    Bug ID: 69215
   Summary: Improve diagnostic for  'for(i : v)'
   Product: gcc
   Version: 6.0
    Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Something like

#include 

int main(){
    std::vector v;
    for(i : v) {}
}

produces a storm of not-very-enlightening errors on trunk:

prog.cc: In function 'int main()':
prog.cc:5:11: error: found ':' in nested-name-specifier, expected '::'
 for(i : v) {}
   ^

prog.cc:5:9: error: 'i' has not been declared
 for(i : v) {}
 ^

prog.cc:6:1: error: expected primary-expression before '}' token
 }
 ^

prog.cc:6:1: error: expected ';' before '}' token
prog.cc:6:1: error: expected primary-expression before '}' token
prog.cc:6:1: error: expected ')' before '}' token
prog.cc:6:1: error: expected primary-expression before '}' token

in contrast to clang's:

prog.cc:5:9: error: range-based for loop requires type for loop variable
    for(i : v) {}
    ^

Perhaps the code implementing N3994, removed by r229632, can be repurposed
instead to produce a better error message?