[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #60 from Mikhail Maltsev  ---
(In reply to H.J. Lu from comment #54)
> (In reply to alalaw01 from comment #53)
> > >
> > >So, there is nothing to fix in GCC? Why isn't this bug closed as invalid?
> > 
> > Not everyone wants to patch SPEC sources.
> 
> If the SPEC source is invalid according to Fortran standard, why should
> we change GCC for it?  This isn't the only invalid source in SPEC CPU
> 2006. There are at least 3.

BTW, how to fix this in SPEC? I also noticed this problem with 416.gamess (but
did not report it because my knowledge of Fortran is not enough for correct
triage of this bug). In my build the only 'problematic' file is
'aldeci.fppized.f'.

[Bug tree-optimization/69887] New: gcc ICE at -O1 and above on x86_64-linux-gnu in mark_jump_label_1

[helloqirun at gmail dot com]

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

Bug ID: 69887
   Summary: gcc ICE at -O1 and above on x86_64-linux-gnu in
mark_jump_label_1
   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
-O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It affects gcc-4.6 to trunk.


$ 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 20160220 (experimental) [trunk revision 233587] (GCC)





$ gcc-trunk -O1 abc.c
abc.c: In function 'main':
abc.c:6:1: internal compiler error: in mark_jump_label_1, at jump.c:1159
 }
 ^
0x9d50a9 mark_jump_label_1
../../gcc/gcc/jump.c:1159
0x9d4e8a mark_jump_label_1
../../gcc/gcc/jump.c:1219
0x9d5485 mark_all_labels
../../gcc/gcc/jump.c:313
0x9d5485 rebuild_jump_labels_1
../../gcc/gcc/jump.c:75
0x11da8c1 rest_of_handle_cse
../../gcc/gcc/cse.c:7538
0x11da8c1 execute
../../gcc/gcc/cse.c:7572
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
int a[1];
int main() {
  __builtin_setjmp(a);
  __builtin_longjmp(a, 1);
  return 0;
}

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[mark at gcc dot gnu.org]

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

--- Comment #30 from Mark Wielaard  ---
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01433.html

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[mark at gcc dot gnu.org]

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

--- Comment #29 from Mark Wielaard  ---
(In reply to Manuel López-Ibáñez from comment #27)
> (In reply to Mark Wielaard from comment #21)
> > Although in C a static const is not really like a #define I suspect that
> > there are cases where they are used as such in header files. If that is the
> > major reason for why there are people opposed to the warning then what we
> > could do is hide such (non-)usage of static const variables from header
> > files behind -Wextra and only explicitly warn for static const variable
> > defined (and then not used) in the main file.
> 
> We should not use -Wextra in this way, because after seeing the warning, it
> is not apparent to the user which option controls it. (That is, the same
> warning option printed in the output behaves differently when -Wextra is
> given).

OK, fair point.

> My suggestion is to never warn if declared in a header. If an extra option
> is desired (whether enabled by -Wextra or explicitly), then it would be
> better to call it something like Wunused-any-const-variable, because the
> meaning of numeric values are not apparent (and they do not play nicely with
> -Werror=).

I don't like to introduce yet another warning option name, there are several
warnings with increasing levels. If we go with enabling higher levels only
explicitly it seems fairly clear which level is meant. And I believe they are
clearly documented. If this is an issue with -Werror= then lets fix -Werror.
There are multiple warnings which have increasing levels.

> Note that it is trivial to find all unused static const variables in your
> headers: Just preprocess the file, remove line info and compile with
> -Wunused.
> 
> > +   || filename_cmp (main_input_filename,
> > +DECL_SOURCE_FILE (decl)) == 0)))
> 
> Better use MAIN_FILE_P(DECL_SOURCE_LOCATION (decl))

MAIN_FILE_P doesn't take a source location, but a line_map_ordinary, which
seems more cumbersome to get at from a decl then the filename to compare
against.

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[mark at gcc dot gnu.org]

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

--- Comment #28 from Mark Wielaard  ---
(In reply to Panu Matilainen from comment #26)
> On main files warning on unused junk is certainly useful but static const is
> commonly and deliberately used in headers (eg for arrays such as in comment
> #18) and now produces unhelpful false positives.

I don't think the comment #18 was meant to show a false positive, just the
opposite. The example is not in an header and seems like a simple bug with
misplaced #ifdef/#else statements.

> Just as a random data point: out of the three projects I've so far compiled
> with gcc 6 (on fedora rawhide), two have false positives from static const
> arrays in headers. The other one has them by the dozen.

It would be helpful to make these data points more concrete so we can all
easily check the claims that these are not errors, but false positives.

[Bug c++/69884] [6 Regression] warning: ignoring attributes on template argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r222530 aka PR50800 fix.

[Bug target/69886] New: ICE: in process_insert_insn, at gcse.c:1976 with --param=gcse-unrestricted-cost=0 @ aarch64

[zsojka at seznam dot cz]

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

Bug ID: 69886
   Summary: ICE: in process_insert_insn, at gcse.c:1976 with
--param=gcse-unrestricted-cost=0 @ aarch64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 37745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37745=edit
reduced testcase

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -v   
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-233588-checking-yes-rtl-df-nographite-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as
--with-sysroot=/usr/aarch64-unknown-linux-gnu --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-233588-checking-yes-rtl-df-nographite-aarch64
Thread model: posix
gcc version 6.0.0 20160220 (experimental) (GCC) 

$ aarch64-unknown-linux-gnu-gcc -Os --param=gcse-unrestricted-cost=0 testcase.c 
testcase.c: In function 'foo':
testcase.c:10:1: internal compiler error: in process_insert_insn, at
gcse.c:1976
 }
 ^
0x871150 process_insert_insn
/repo/gcc-trunk/gcc/gcse.c:1976
0x871b24 insert_insn_end_basic_block
/repo/gcc-trunk/gcc/gcse.c:1998
0x8743c8 hoist_code
/repo/gcc-trunk/gcc/gcse.c:3297
0x8743c8 one_code_hoisting_pass
/repo/gcc-trunk/gcc/gcse.c:3527
0x8743c8 execute_rtl_hoist
/repo/gcc-trunk/gcc/gcse.c:4019
0x8743c8 execute
/repo/gcc-trunk/gcc/gcse.c:4100
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.

Only aarch64 seems to fail on this testcase.

Tested revisions:
trunk r233588 - ICE
5-branch r233581 - ICE
4_9-branch r233576 - ICE
4_8-branch r224828 - ICE

[Bug bootstrap/69885] New: [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6903 on arm-linux-gnueabihf

[doko at gcc dot gnu.org]

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

Bug ID: 69885
   Summary: [6 Regression] ICE in maybe_legitimize_operand, at
optabs.c:6903 on arm-linux-gnueabihf
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen building a m68k-linux-gnu cross compiler, trunk 20160220:

$ cat libgcc2.i 
typedef int DItype __attribute__((mode(DI)));
DItype a;
void fn1();
void fn2() {
  if (a >> 1)
fn1();
}

$ build/gcc/xgcc -Bbuild/gcc/ -c -g -O2 libgcc2.i 
libgcc2.i: In function 'fn2':
libgcc2.i:4:6: internal compiler error: in maybe_legitimize_operand, at
optabs.c:6903
 void fn2() {
  ^~~
0x88c932 maybe_legitimize_operand
../../src/gcc/optabs.c:6903
0x88c932 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
../../src/gcc/optabs.c:6971
0x88cb59 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../src/gcc/optabs.c:6989
0x88f112 expand_binop_directly
../../src/gcc/optabs.c:1070
0x88f3fe expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
../../src/gcc/optabs.c:1150
0x6dfc90 expand_shift_1
../../src/gcc/expmed.c:2475
0x6fdde0 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../src/gcc/expr.c:9043
0x6f199c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.c:9577
0x68296b expand_normal
../../src/gcc/expr.h:262
0x68296b do_jump(tree_node*, rtx_code_label*, rtx_code_label*, int)
../../src/gcc/dojump.c:639
0x623fe0 expand_gimple_cond
../../src/gcc/cfgexpand.c:2483
0x623fe0 expand_gimple_basic_block
../../src/gcc/cfgexpand.c:5588
0x6279f6 execute
../../src/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.

 --enable-languages=c,c++,java,d,fortran,objc,obj-c++
 --prefix=/usr
 --program-suffix=-6
 --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-libssp
 --disable-libitm
 --disable-libsanitizer
 --disable-libquadmath
 --enable-plugin
 --with-system-zlib
 --disable-libgcj
 --enable-objc-gc
 --enable-multiarch
 --disable-werror
 --disable-multilib
 --enable-checking=release
 --build=x86_64-linux-gnu
 --host=x86_64-linux-gnu
 --target=m68k-linux-gnu
 --program-prefix=m68k-linux-gnu-

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
Proposed patch:


diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index c1d79457..c4e7974e 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -336,7 +336,7 @@ add_path_to_list (gfc_directorylist **list, const char
*path,
 }
   else if (!S_ISDIR (st.st_mode))
 {
-  gfc_warning_now (0, "%qs is not a directory", path);
+  gfc_fatal_error ("%qs is not a directory", path);
   return;
 }

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

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

--- Comment #13 from Bernd Edlinger  ---
(In reply to Jonathan Wakely from comment #12)
> (In reply to Bernd Edlinger from comment #9)
> > right now I am trying to boot-strap this:
> > 
> > Index: c/cstddef
> > ===
> > --- c/cstddef   (revision 233581)
> > +++ c/cstddef   (working copy)
> > @@ -31,10 +31,11 @@
> >  
> >  #pragma GCC system_header
> >  
> > -#define __need_size_t
> > -#define __need_ptrdiff_t
> > -#define __need_NULL
> > -#define __need_offsetof
> > +#undef __need_wchar_t
> > +#undef __need_size_t
> > +#undef __need_ptrdiff_t
> > +#undef __need_NULL
> > +#undef __need_wint_t
> >  #include_next 
> 
> 
> How do you plan to test this change? Do you have a target that uses this
> header?
> 

Yes, I do have such targets.
We use eCos at Softing as real time O/S a lot.

I think I will build an ecos cross compiler, did so last year with
gcc-5.1, (and had quite a lot of trouble with the bugs in
ecos headers)

./gcc-5.1.0/configure --prefix=/home/ed/gnu/arm-eabi --target=arm-eabi
--with-newlib --enable-languages=c,c++ --disable-hosted-libstdcxx
--disable-__cxa-atexit --disable-libquadmath --disable-decimal-float

> 
> >  #endif
> > Index: c_global/cstddef
> > ===
> > --- c_global/cstddef(revision 233581)
> > +++ c_global/cstddef(working copy)
> > @@ -41,6 +41,11 @@
> >  
> >  #pragma GCC system_header
> >  
> > +#undef __need_wchar_t
> > +#undef __need_size_t
> > +#undef __need_ptrdiff_t
> > +#undef __need_NULL
> > +#undef __need_wint_t
> >  #include 
> >  #include 
> 
> This isn't incorrect, but it should not be necessary. This macros are
> internal implementation details of the standard library headers, and user
> code (like GMP) should not be defining those macros. If GMP wants size_t it
> should include  and if it wants std::size_t it should include
> , and it should not try to play silly games to only get part of the
> header.
> 
> 

Yeah, shit happens.
Anyway boot-strap & reg-testing OK on x86_64-pc-linux-gnu.
gcc-4.9 builds successfully (minus Ada, see pr69883 :()

> 
> > Index: c_std/cstddef
> > ===
> > --- c_std/cstddef   (revision 233581)
> > +++ c_std/cstddef   (working copy)
> > @@ -41,6 +41,11 @@
> >  
> >  #pragma GCC system_header
> >  
> > +#undef __need_wchar_t
> > +#undef __need_size_t
> > +#undef __need_ptrdiff_t
> > +#undef __need_NULL
> > +#undef __need_wint_t
> >  #include 
> >  #include 
> 
> How do you plan to test this?

no idea yet.
under what condition is that header used?

Why does it only differ in the comment from the
previous header?

why are the both files different?
diff c_global/cstddef c_std/cstddef
26c26
<  *  This is a Standard C++ Library file.  You should @c \#include this file
---
>  *  This is a Standard C++ Library file.  You should @c #include this file

is this a mistake?

[Bug fortran/69423] [6 Regression] Invalid optimization with deferred-length character

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas  ---
Author: pault
Date: Sat Feb 20 18:26:59 2016
New Revision: 233589

URL: https://gcc.gnu.org/viewcvs?rev=233589=gcc=rev
Log:
2016-02-20  Paul Thomas  

PR fortran/69423
* trans-decl.c (create_function_arglist): Deferred character
length functions, with and without declared results, address
the passed reference type as '.result' and the local string
length as '..result'.
(gfc_null_and_pass_deferred_len): Helper function to null and
return deferred string lengths, as needed.
(gfc_trans_deferred_vars): Call it, thereby reducing repeated
code, add call for deferred arrays and reroute pointer function
results. Avoid using 'tmp' for anything other that a temporary
tree by introducing 'type_of_array' for the arrayspec type.

2016-02-20  Paul Thomas  

PR fortran/69423
* gfortran.dg/deferred_character_15.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/deferred_character_15.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/69884] [6 Regression] warning: ignoring attributes on template argument

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
At least there should be way to silence this warning.
There is a patch already:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02256.html

[Bug c++/69884] [6 Regression] warning: ignoring attributes on template argument

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 37744
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37744=edit
unreduced testcase

markus@x4 build % g++ -O2 -c sparse_product.ii 2>&1 | grep "ignoring attributes
on template argument" | wc -l
29
markus@x4 build % /usr/x86_64-pc-linux-gnu/gcc-bin/5.3.1/g++ -O2 -c
sparse_product.ii 
markus@x4 build %

[Bug c++/69884] New: [6 Regression] warning: ignoring attributes on template argument

[trippels at gcc dot gnu.org]

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

Bug ID: 69884
   Summary: [6 Regression] warning: ignoring attributes on
template argument
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Running the Eigen testsuite shows many instances of:

markus@x4 build % cat sparse_product.ii
typedef float __m128 __attribute__((__vector_size__(16), __may_alias__));
template  struct A;
template <> struct A<__m128>;

markus@x4 build % clang++ -Wall -Wextra -O2 -c sparse_product.ii
markus@x4 build % icpc -Wall -Wextra -O2 -c sparse_product.ii
markus@x4 build % /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/g++ -Wall -Wextra -O2
-c sparse_product.ii
markus@x4 build % /usr/x86_64-pc-linux-gnu/gcc-bin/5.3.1/g++ -Wall -Wextra -O2
-c sparse_product.ii
markus@x4 build % g++ -O2 -c sparse_product.ii
sparse_product.ii:3:28: warning: ignoring attributes on template argument
‘__m128 {aka __vector(4) float}’
 template <> struct A<__m128>;
^

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Bernd Edlinger from comment #9)
> right now I am trying to boot-strap this:
> 
> Index: c/cstddef
> ===
> --- c/cstddef (revision 233581)
> +++ c/cstddef (working copy)
> @@ -31,10 +31,11 @@
>  
>  #pragma GCC system_header
>  
> -#define __need_size_t
> -#define __need_ptrdiff_t
> -#define __need_NULL
> -#define __need_offsetof
> +#undef __need_wchar_t
> +#undef __need_size_t
> +#undef __need_ptrdiff_t
> +#undef __need_NULL
> +#undef __need_wint_t
>  #include_next 


How do you plan to test this change? Do you have a target that uses this
header?


>  #endif
> Index: c_global/cstddef
> ===
> --- c_global/cstddef  (revision 233581)
> +++ c_global/cstddef  (working copy)
> @@ -41,6 +41,11 @@
>  
>  #pragma GCC system_header
>  
> +#undef __need_wchar_t
> +#undef __need_size_t
> +#undef __need_ptrdiff_t
> +#undef __need_NULL
> +#undef __need_wint_t
>  #include 
>  #include 

This isn't incorrect, but it should not be necessary. This macros are internal
implementation details of the standard library headers, and user code (like
GMP) should not be defining those macros. If GMP wants size_t it should include
 and if it wants std::size_t it should include , and it
should not try to play silly games to only get part of the header.



> Index: c_std/cstddef
> ===
> --- c_std/cstddef (revision 233581)
> +++ c_std/cstddef (working copy)
> @@ -41,6 +41,11 @@
>  
>  #pragma GCC system_header
>  
> +#undef __need_wchar_t
> +#undef __need_size_t
> +#undef __need_ptrdiff_t
> +#undef __need_NULL
> +#undef __need_wint_t
>  #include 
>  #include 

How do you plan to test this?

[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro

[dmalcolm at gcc dot gnu.org]

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

--- Comment #26 from David Malcolm  ---
(In reply to David Malcolm from comment #25)
[...]
> I have a patch that seems to work for this test case; am testing it more
> thoroughly now.
Candidate patch posted here:
  https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01424.html
(see also: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01425.html )

[Bug ada/69883] gcc-6.0 unable to build gcc-4.9 with ada

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger  ---
(In reply to char...@adacore.com from comment #3)
> > I could understand that I can not build something form 1992 with todays
> > tools, but what I do not understand conceptionally, why the host compiler
> > seems to link with the target compiler's runtime, would it work as a
> > cross build then?
> 
> No, for a cross build you need an identical native compiler (same version)
> to start with.
> 
> For native you need an older (or equal) compiler.
> 
> > Could I even get into trouble building gcc4.9 with gcc-5 as host?
> 
> Yes.
> 
> Arno

Hmm, that's pretty awkward, especially as the same gcc-driver
must understand ada and C/C++ at the same time or the build fails
immediately, that forces me to have not only gnat but also C/C++
of the same build date, in binary form.


Bernd.

[Bug ada/69883] gcc-6.0 unable to build gcc-4.9 with ada

[charlet at adacore dot com]

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

--- Comment #3 from charlet at adacore dot com  ---
> I could understand that I can not build something form 1992 with todays
> tools, but what I do not understand conceptionally, why the host compiler
> seems to link with the target compiler's runtime, would it work as a
> cross build then?

No, for a cross build you need an identical native compiler (same version)
to start with.

For native you need an older (or equal) compiler.

> Could I even get into trouble building gcc4.9 with gcc-5 as host?

Yes.

Arno

Re: [Bug ada/69883] gcc-6.0 unable to build gcc-4.9 with ada

[Arnaud Charlet]

> I could understand that I can not build something form 1992 with todays
> tools, but what I do not understand conceptionally, why the host compiler
> seems to link with the target compiler's runtime, would it work as a
> cross build then?

No, for a cross build you need an identical native compiler (same version)
to start with.

For native you need an older (or equal) compiler.

> Could I even get into trouble building gcc4.9 with gcc-5 as host?

Yes.

Arno

[Bug ada/69883] gcc-6.0 unable to build gcc-4.9 with ada

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
(In reply to Arnaud Charlet from comment #1)
> You must use an older (or equal) version of GNAT to build GNAT, using a more
> recent version won't work in general, as shown by this PR, and isn't
> supported.
> 
> Arno

Hi Arno,

I could understand that I can not build something form 1992 with todays
tools, but what I do not understand conceptionally, why the host compiler
seems to link with the target compiler's runtime, would it work as a
cross build then?

Could I even get into trouble building gcc4.9 with gcc-5 as host?


Bernd.

[Bug ada/69883] gcc-6.0 unable to build gcc-4.9 with ada

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||charlet at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Arnaud Charlet  ---
You must use an older (or equal) version of GNAT to build GNAT, using a more
recent version won't work in general, as shown by this PR, and isn't supported.

Arno

[Bug ada/69883] New: gcc-6.0 unable to build gcc-4.9 with ada

[bernd.edlinger at hotmail dot de]

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

Bug ID: 69883
   Summary: gcc-6.0 unable to build gcc-4.9 with ada
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Hi,

I am trying to boot-strap gcc-4.9 with gcc-6 as of today.

gcc-6 is configured as:
../gcc-trunk/configure --prefix=/home/ed/gnu/install
--enable-languages=all,ada,go,obj-c++

gcc-4.9 is configured as:
../gcc-4.9-branch/configure --prefix=/home/ed/gnu/install-4.9
--enable-languages=all,ada,go,obj-c++

The build fails in stage1:
g++ -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++
-static-libgcc  -o gnat1 ada/adadecode.o ada/adaint.o ada/argv.o ada/cio.o
ada/cstreams.o ada/env.o ada/init.o ada/initialize.o ada/raise.o ada/seh_init.o
ada/targext.o ada/cuintp.o ada/decl.o ada/misc.o ada/utils.o ada/utils2.o
ada/trans.o ada/targtyps.o ada/a-charac.o ada/a-chlat1.o ada/a-elchha.o
ada/a-except.o ada/a-ioexce.o ada/ada.o ada/spark_xrefs.o ada/ali.o ada/alloc.o
ada/aspects.o ada/atree.o ada/butil.o ada/casing.o ada/checks.o ada/comperr.o
ada/csets.o ada/cstand.o ada/debug.o ada/debug_a.o ada/einfo.o ada/elists.o
ada/err_vars.o ada/errout.o ada/erroutc.o ada/eval_fat.o ada/exp_aggr.o
ada/exp_spark.o ada/exp_atag.o ada/exp_attr.o ada/exp_cg.o ada/exp_ch11.o
ada/exp_ch12.o ada/exp_ch13.o ada/exp_ch2.o ada/exp_ch3.o ada/exp_ch4.o
ada/exp_ch5.o ada/exp_ch6.o ada/exp_ch7.o ada/exp_ch8.o ada/exp_ch9.o
ada/exp_code.o ada/exp_dbug.o ada/exp_disp.o ada/exp_dist.o ada/exp_fixd.o
ada/exp_imgv.o ada/exp_intr.o ada/exp_pakd.o ada/exp_prag.o ada/exp_sel.o
ada/exp_smem.o ada/exp_strm.o ada/exp_tss.o ada/exp_util.o ada/exp_vfpt.o
ada/expander.o ada/fmap.o ada/fname-uf.o ada/fname.o ada/freeze.o
ada/frontend.o ada/g-byorma.o ada/g-hesora.o ada/g-htable.o ada/g-spchge.o
ada/g-speche.o ada/g-u3spch.o ada/get_spark_xrefs.o ada/get_targ.o ada/gnat.o
ada/gnatvsn.o ada/hostparm.o ada/impunit.o ada/inline.o ada/interfac.o
ada/itypes.o ada/krunch.o ada/layout.o ada/lib-load.o ada/lib-util.o
ada/lib-writ.o ada/lib-xref.o ada/lib.o ada/live.o ada/namet-sp.o ada/namet.o
ada/nlists.o ada/nmake.o ada/opt.o ada/osint-c.o ada/osint.o ada/output.o
ada/par.o ada/par_sco.o ada/prep.o ada/prepcomp.o ada/put_spark_xrefs.o
ada/put_scos.o ada/repinfo.o ada/restrict.o ada/rident.o ada/rtsfind.o
ada/s-addope.o ada/s-assert.o ada/s-bitops.o ada/s-carun8.o ada/s-casuti.o
ada/s-conca2.o ada/s-conca3.o ada/s-conca4.o ada/s-conca5.o ada/s-conca6.o
ada/s-conca7.o ada/s-conca8.o ada/s-conca9.o ada/s-crc32.o ada/s-crtl.o
ada/s-excdeb.o ada/s-except.o ada/s-exctab.o ada/s-htable.o ada/s-imenne.o
ada/s-imgenu.o ada/s-mastop.o ada/s-memory.o ada/s-os_lib.o ada/s-parame.o
ada/s-purexc.o ada/s-restri.o ada/s-secsta.o ada/s-soflin.o ada/s-sopco3.o
ada/s-sopco4.o ada/s-sopco5.o ada/s-stache.o ada/s-stalib.o ada/s-stoele.o
ada/s-strcom.o ada/s-strhas.o ada/s-string.o ada/s-strops.o ada/s-traent.o
ada/s-unstyp.o ada/s-utf_32.o ada/s-valint.o ada/s-valuns.o ada/s-valuti.o
ada/s-wchcnv.o ada/s-wchcon.o ada/s-wchjis.o ada/scans.o ada/scil_ll.o
ada/scn.o ada/scng.o ada/scos.o ada/sdefault.o ada/sem.o ada/sem_aggr.o
ada/sem_attr.o ada/sem_aux.o ada/sem_case.o ada/sem_cat.o ada/sem_ch10.o
ada/sem_ch11.o ada/sem_ch12.o ada/sem_ch13.o ada/sem_ch2.o ada/sem_ch3.o
ada/sem_ch4.o ada/sem_ch5.o ada/sem_ch6.o ada/sem_ch7.o ada/sem_ch8.o
ada/sem_ch9.o ada/sem_dim.o ada/sem_disp.o ada/sem_dist.o ada/sem_elab.o
ada/sem_elim.o ada/sem_eval.o ada/sem_intr.o ada/sem_mech.o ada/sem_prag.o
ada/sem_res.o ada/sem_scil.o ada/sem_smem.o ada/sem_type.o ada/sem_util.o
ada/sem_vfpt.o ada/sem_warn.o ada/set_targ.o ada/sinfo-cn.o ada/sinfo.o
ada/sinput-d.o ada/sinput-l.o ada/sinput.o ada/snames.o ada/sprint.o
ada/stand.o ada/stringt.o ada/style.o ada/styleg.o ada/stylesw.o ada/switch-c.o
ada/switch.o ada/system.o ada/table.o ada/targparm.o ada/tbuild.o
ada/tree_gen.o ada/tree_in.o ada/tree_io.o ada/treepr.o ada/treeprs.o
ada/ttypes.o ada/types.o ada/uintp.o ada/uname.o ada/urealp.o ada/usage.o
ada/validsw.o ada/warnsw.o ada/widechar.o ada/back_end.o ada/gnat1drv.o
ada/b_gnat1.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a attribs.o \
  libcommon-target.a libcommon.a ../libcpp/libcpp.a  
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a   -L/home/ed/gnu/gcc-build2/./cloog/.libs 
-lcloog-isl -L/home/ed/gnu/gcc-build2/./isl/.libs  -lisl
-L/home/ed/gnu/gcc-build2/./gmp/.libs -L/home/ed/gnu/gcc-build2/./mpfr/.libs

[Bug testsuite/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |bernd.edlinger at 
hotmail dot de

--- Comment #14 from vries at gcc dot gnu.org ---
Patch with testcase fix committed to trunk and 5 branch. Testcase not present
in 4.9 branch.

Marking resolved-fixed.

[Bug fortran/52531] [OOP] Compilation fails with polymorphic dummy argument and OpenMP

[dominiq at gcc dot gnu.org]

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

--- Comment #12 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Feb 20 14:10:55 2016
New Revision: 233588

URL: https://gcc.gnu.org/viewcvs?rev=233588=gcc=rev
Log:
2016-02-20  Dominique d'Humieres  

PR fortran/57365
gfortran.dg/allocate_with_source_18.f03: New test.

2016-02-20  Harald Anlauf  

PR fortran/52531
gfortran.dg/gomp/pr52531.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_18.f03
trunk/gcc/testsuite/gfortran.dg/gomp/pr52531.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/57365] [OOP] Sourced allocation fails with unlimited polymorphism

[dominiq at gcc dot gnu.org]

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

--- Comment #5 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Feb 20 14:10:55 2016
New Revision: 233588

URL: https://gcc.gnu.org/viewcvs?rev=233588=gcc=rev
Log:
2016-02-20  Dominique d'Humieres  

PR fortran/57365
gfortran.dg/allocate_with_source_18.f03: New test.

2016-02-20  Harald Anlauf  

PR fortran/52531
gfortran.dg/gomp/pr52531.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_18.f03
trunk/gcc/testsuite/gfortran.dg/gomp/pr52531.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[dominiq at lps dot ens.fr]

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

--- Comment #59 from Dominique d'Humieres  ---
> We already warn about mismatches sizes at LTO link time

Confirmed

[Book15] f90/bug% gfc -c -O2 pr69368_a.f90 -flto
[Book15] f90/bug% gfc -O2 pr69368_a.o pr69368_b.f90 -flto
pr69368_a.f90:3:0: warning: type of 'blk' does not match original declaration
[-Wlto-type-mismatch]
   COMMON /BLK/ K(1)

pr69368_b.f90:3:0: note: 'blk' was previously declared here
   COMMON /BLK/ K(64)

pr69368_b.f90:3:0: note: code may be misoptimized unless -fno-strict-aliasing
is used

and the executable gives the expected output. IMO the second note is bogus
(pr68717).

If I replace

   COMMON /BLK/ K(1)

with

   COMMON /BLK/ K(2)

the executable gives the expected output also for all the compiling options I
have tried.

AFAICT the code (invalid for any value of I and J)

  FUNCTION FOO(I, J)
  COMMON /BLK/ K(1)
  FOO = K(I) + K(J) + K(2*I) + K(2*J)
  END FUNCTION

is optimized as

  FOO = K(I) + K(I) + K(I) + K(I)

Although I know that a compiler can do whatever it deems suitable with invalid
code, I don't understand the rationale of the above "optimization": it is as
invalid as the original code.

Another thing I don't understand is that the following code is not "optimized"
while as invalid as the one above:

  INTEGER FUNCTION FOO(I, J, K)
  INTEGER K(1)
  FOO = K(I) + K(J) + K(2*I) + K(2*J)
  END FUNCTION

  INTEGER FOO
  INTEGER K(64)
  DO I=1,64
  K(I)=I
  END DO
  IF (FOO(5,12,K).NE.51) CALL ABORT
  END

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

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

--- Comment #11 from Bernd Edlinger  ---
(In reply to Jakub Jelinek from comment #10)
> Why should libstdc++ try to workaround a bug in gmp.h?  Just fix gmp.h...

Yes, and probably it is already fixed with gmp-6.1.0, I did not check.

I am trying to bootstrap gcc-4.9 plus the cfns.h patch from yesterday
together with a fixed gmp-4.3.2 which is just what download_prerequisites
installed.

IMHO libstdc++ is just fragile if it lets those __need_-thingies
pass through and then assumes that max_align_t must be defined.

And the free-standing cstdlib is simply not defining offsetof
when it apparently tries to.

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
Why should libstdc++ try to workaround a bug in gmp.h?  Just fix gmp.h...

[Bug tree-optimization/69882] [6 regression] Excessive reduction statements generated by SLP

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-20
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

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

[Bug tree-optimization/69882] New: [6 regression] Excessive reduction statements generated by SLP

[kyukhin at gcc dot gnu.org]

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

Bug ID: 69882
   Summary: [6 regression] Excessive reduction statements
generated by SLP
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyukhin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37743
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37743=edit
Reproducer

Hello,
Attached test case emits wrong reduction statements.

Compile:
$ trunk/64/20160220/bin/gfortran -o repro -static -m64 -Ofast -mavx repro.f90

Execution ABORTs

Works fine when compiled w/ -O0

Extract from vectorizer dump:
  :
  # k_239 = PHI <k.4_11(48), k_266(56)>
  # c_I_lsm.10_241 = PHI <c_I_lsm.10_48(48), M.0_249(56)>
  # c_I_lsm.11_242 = PHI <c_I_lsm.11_3(48), M.0_252(56)>
  # vectp_a.47_406 = PHI <vectp_a.48_402(48), vectp_a.47_407(56)>
  # vect_M.50_410 = PHI <vect_cst__412(48), vect_M.50_411(56)>
  # ivtmp_420 = PHI <0(48), ivtmp_421(56)>
  _245 = (integer(kind=8)) k_239;
  _246 = _245 * 4;
  _247 = _246 + -4;
  _248 = *a_22(D)[_247];
  M.0_249 = MAX_EXPR <_248, c_I_lsm.10_241>;
  _250 = _246 + -3;
  vect__248.49_408 = MEM[(real(kind=8) *)vectp_a.47_406]; <-- SLP
  vectp_a.47_409 = vectp_a.47_406 + 32;
  _251 = *a_22(D)[_250];
  vect_M.50_411 = MAX_EXPR <vect__248.49_408, vect_M.50_410>; <-- SLP
  M.0_252 = MAX_EXPR <_251, c_I_lsm.11_242>;
  k_266 = k_239 + 1;
  vectp_a.47_407 = vectp_a.47_409 + 32; < -- SLP
  ivtmp_421 = ivtmp_420 + 1;
  if (ivtmp_421 >= bnd.44_361)
goto ;
  else
goto ;

  :
  ... # REMAINDER
  k_377 = k_365 + 1;
  if (k_365 == 26)
goto ;
  else
goto ;

  :
  goto ;

  :
  # k_381 = PHI <k_266(49)>
  # c_I_lsm.10_384 = PHI <M.0_249(49)>
  # c_I_lsm.11_386 = PHI <M.0_252(49)>
  # c_I_lsm.13_389 = PHI <c_I_lsm.13_84(49)>
  # c_I_lsm.12_392 = PHI <c_I_lsm.12_13(49)>
  # vect_M.50_413 = PHI <vect_M.50_411(49)>
  stmp_M.51_414 = BIT_FIELD_REF <vect_M.50_413, 64, 0>;
  stmp_M.51_415 = BIT_FIELD_REF <vect_M.50_413, 64, 64>;
  stmp_M.51_416 = BIT_FIELD_REF <vect_M.50_413, 64, 128>;
  stmp_M.51_417 = BIT_FIELD_REF <vect_M.50_413, 64, 192>;
  stmp_M.51_418 = MAX_EXPR <stmp_M.51_414, stmp_M.51_416>;  # <-- WHOT??
  stmp_M.51_419 = MAX_EXPR <stmp_M.51_415, stmp_M.51_417>;  # <-- DITTO.
  _401 = (integer(kind=4)) ratio_mult_vf.45_364;
  tmp.46_400 = k.4_11 + _401;
  if (niters.42_358 == ratio_mult_vf.45_364)
goto ;
  else
goto ;

Those 2 SSA names are then stored to 1st and 2nd array elements

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

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

--- Comment #9 from Bernd Edlinger  ---
right now I am trying to boot-strap this:

Index: c/cstddef
===
--- c/cstddef   (revision 233581)
+++ c/cstddef   (working copy)
@@ -31,10 +31,11 @@

 #pragma GCC system_header

-#define __need_size_t
-#define __need_ptrdiff_t
-#define __need_NULL
-#define __need_offsetof
+#undef __need_wchar_t
+#undef __need_size_t
+#undef __need_ptrdiff_t
+#undef __need_NULL
+#undef __need_wint_t
 #include_next 

 #endif
Index: c_global/cstddef
===
--- c_global/cstddef(revision 233581)
+++ c_global/cstddef(working copy)
@@ -41,6 +41,11 @@

 #pragma GCC system_header

+#undef __need_wchar_t
+#undef __need_size_t
+#undef __need_ptrdiff_t
+#undef __need_NULL
+#undef __need_wint_t
 #include 
 #include 

Index: c_std/cstddef
===
--- c_std/cstddef   (revision 233581)
+++ c_std/cstddef   (working copy)
@@ -41,6 +41,11 @@

 #pragma GCC system_header

+#undef __need_wchar_t
+#undef __need_size_t
+#undef __need_ptrdiff_t
+#undef __need_NULL
+#undef __need_wint_t
 #include 
 #include 

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

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

--- Comment #8 from Bernd Edlinger  ---
BTW:

the free-standing cstddef is also buggy:

#define __need_size_t
#define __need_ptrdiff_t
#define __need_NULL
#define __need_offsetof
#include_next 

but GCC's stddef.h does not implement __need_offsetof.
in the contrary, offsetof is not defined when any of the implemented
__need_XXX macros is set.

$prefix/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/stddef.h:

#ifdef _STDDEF_H

/* Offset of member MEMBER in a struct of type TYPE. */
#define offsetof(TYPE, MEMBER) __builtin_offsetof (TYPE, MEMBER)

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger  ---
Index: include/c_global/cstddef
===
--- include/c_global/cstddef(revision 233581)
+++ include/c_global/cstddef(working copy)
@@ -41,6 +41,12 @@

 #pragma GCC system_header

+#undef __need_wchar_t
+#undef __need_size_t
+#undef __need_ptrdiff_t
+#undef __need_NULL
+#undef __need_wint_t
+
 #include 
 #include 

Index: include/c_std/cstddef
===
--- include/c_std/cstddef   (revision 233581)
+++ include/c_std/cstddef   (working copy)
@@ -41,6 +41,12 @@

 #pragma GCC system_header

+#undef __need_wchar_t
+#undef __need_size_t
+#undef __need_ptrdiff_t
+#undef __need_NULL
+#undef __need_wint_t
+
 #include 
 #include 

like this?

[Bug fortran/64324] Deferred character specific functions not permitted in generic operator interface

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
(In reply to Paul Thomas from comment #3)
> Fixed on trunk. I will wait a few weeks before fixing on 5-branch.
> 
> Paul

This has been on hold awaiting a fix for PR69423 on trunk. It looks as if the
wait is nearly over.

Paul

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger  ---
(In reply to Jonathan Wakely from comment #4)
> The patch seems wrong, your new sections don't add anything to namespace std.

yes.  I think probably cstddef is free to ignore __need_size_t. right?

Then it would be better to #undef all of them, just in case.

cat test.cc
#define __need_size_t
#include 

gcc -c test.cc
In file included from test.cc:2:0:
/home/ed/gnu/install/include/c++/6.0.0/cstddef:51:11: error: '::max_align_t'
has not been declared
   using ::max_align_t;
   ^~~

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Bernd Edlinger from comment #3)
> or 
> 
> #undef all these __need_XXX before including stddef.h,
> after all it is a bit bogus ghat gmp.h does:
> 
> #define __need_size_t  /* tell gcc stddef.h we only want size_t */
> #include  /* for size_t */

That is bogus.

> is cstddef supposed to honor __need_size_t at all?

No.

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
The patch seems wrong, your new sections don't add anything to namespace std.

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
or 

#undef all these __need_XXX before including stddef.h,
after all it is a bit bogus ghat gmp.h does:

#define __need_size_t  /* tell gcc stddef.h we only want size_t */
#include  /* for size_t */

is cstddef supposed to honor __need_size_t at all?

[Bug rtl-optimization/69806] [6 Regression][SH] Combine doesn't see constant

[olegendo at gcc dot gnu.org]

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

--- Comment #10 from Oleg Endo  ---
(In reply to Jakub Jelinek from comment #9)
> Please see PR69671 then, that CSE change is right, so you really need to
> find some solution at the backend side.  Look what fwprop* dumps show etc.

I've checked the before and after pass logs until combine.  The first change in
this case is in cse1.

Before r233133 it would propagate the shift count constant into the shift insn:

(insn 7 6 8 2 (set (reg:SI 169)
(ashift:SI (reg:SI 175 [ x+4 ])
(const_int 30 [0x1e]))) sh_tmp.cpp:34 161 {ashlsi3_d}
 (expr_list:REG_DEAD (reg:SI 175 [ x+4 ])
(expr_list:REG_DEAD (reg:SI 170)
(expr_list:REG_EQUAL (ashift:SI (reg:SI 175 [ x+4 ])
(const_int 30 [0x1e]))
(nil)

Now it doesn't do it and the shift pattern remains as:

(insn 7 6 8 2 (set (reg:SI 169)
(ashift:SI (reg:SI 175 [ x+4 ])
(reg:SI 170))) sh_tmp.cpp:34 161 {ashlsi3_d}
 (expr_list:REG_DEAD (reg:SI 175 [ x+4 ])
(expr_list:REG_DEAD (reg:SI 170)
(expr_list:REG_EQUAL (ashift:SI (reg:SI 175 [ x+4 ])
(const_int 30 [0x1e]))
(nil)


I could fix this in the backend in various ways.  I'll try out a couple of
things.