[Bug ada/68345] New: gnat build broken on dragonfly due to omission of r229342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68345 Bug ID: 68345 Summary: gnat build broken on dragonfly due to omission of r229342 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: gnugcc at marino dot st Target Milestone: --- Due to waiting on big locale patch, I haven't been testing gcc regularly. I just did today and gnat files to build on dragonfly: s-taprop.adb:326:32: ambiguous operand in conversion s-taprop.adb:326:32: possible interpretation at s-osinte.ads:333 s-taprop.adb:326:32: possible interpretation at s-osinte.ads:334 s-taprop.adb:981:52: ambiguous operand in conversion s-taprop.adb:981:52: possible interpretation at s-osinte.ads:333 s-taprop.adb:981:52: possible interpretation at s-osinte.ads:334 ../gcc-interface/Makefile:311: recipe for target 's-taprop.o' failed gmake[8]: *** [s-taprop.o] Error 1 the reason is that Get_Page_Size was changed to return an int, and this was done for a number of systems except dragonfly: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=229342 The same change done on s-osinte-freebsd.ads by r229342 needs to be done on s-osinte-dragonfly.ads DragonFly is an officially (and well) supported system on GCC! It should not be omitted like this.
[Bug ada/68345] gnat build broken on dragonfly due to omission of r229342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68345 Arnaud Charlet changed: What|Removed |Added CC||charlet at gcc dot gnu.org --- Comment #1 from Arnaud Charlet --- Can you please submit a patch on gcc-patches@ ?
[Bug ada/68345] gnat build broken on dragonfly due to omission of r229342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68345 --- Comment #2 from Arnaud Charlet --- Author: charlet Date: Sat Nov 14 09:09:01 2015 New Revision: 230373 URL: https://gcc.gnu.org/viewcvs?rev=230373&root=gcc&view=rev Log: 2015-11-13 Arnaud Charlet PR ada/68345 * s-osinte-dragonfly.ads (Get_Page_Size): C function returns an int. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-osinte-dragonfly.ads
[Bug ada/68345] gnat build broken on dragonfly due to omission of r229342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68345 Arnaud Charlet changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Arnaud Charlet --- I applied a change blindly, let me know how it goes. Arno
[Bug bootstrap/68346] New: [6 Regression] Bootstrap failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68346 Bug ID: 68346 Summary: [6 Regression] Bootstrap failure on i686-linux Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- Most likely since the c++ delayed folding merge, but I admit I've bootstrapped trunk on i686-linux 8 days ago, so the window is larger, trunk no longer bootstraps on i686-linux: ../../gcc/gimple-fold.c: In function ‘bool gimple_fold_builtin_printf(gimple_stmt_iterator*, tree, tree, built_in_function)’: ../../gcc/gimple-fold.c:2621:30: error: self-comparison always evaluates to true [-Werror=tautological-compare] && (size_t) (int) len == len ^~ This code is not new in there, but supposedly before that we either have not been folding the arguments for -Wtautological-compare, or not so aggressively. I'd say it is quite common idiom to cast a variable to some other type and compare to itself, with the intent that if the type is the same, it is a no-op check, but if the type is narrower or has different signedness, it filters out some undesirable values.
[Bug bootstrap/68346] [6 Regression] Bootstrap failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68346 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0
[Bug bootstrap/68346] [6 Regression] Bootstrap failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68346 --- Comment #1 from Jakub Jelinek --- Note one even can't work around this warning through say: && (sizeof (int) >= sizeof (size_t) ? 1 : (size_t) (int) len == len)
[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808 --- Comment #27 from Anthony Brandon --- Created attachment 36706 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36706&action=edit First version of patch for PR19808 This is the current version of my patch. It still needs some work. The Wuninitialized part should be combined with the Winit_self part, and it should be made to detect multiple uninitialized values in a single initializer.
[Bug libfortran/68347] New: Multiple build errors in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347 Bug ID: 68347 Summary: Multiple build errors in libgfortran Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: alexey.a.rychkov at gmail dot com Target Milestone: --- There are multiple bogus symbols in files (stray \33, etc): libgfortran/kinds.h libgfortran/kinds.inc libgfortran/fpu-target.inc libgfortran/c99_protos.inc which lead to multiple compilation errors. The gcc source code was downloaded from ftp://ftp.gwdg.de/pub/misc/gcc/releases/gcc-5.2.0/gcc-5.2.0.tar.bz2
[Bug ada/68345] gnat build broken on dragonfly due to omission of r229342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68345 --- Comment #4 from John Marino --- Hi Arno, I made the same exact change internally. It built and the full testsuite was run afterwards: === acats Summary === # of expected passes2320 # of unexpected failures0 Native configuration is x86_64-test-dragonfly4.3 === g++ tests === Running target unix === gnat Summary === # of expected passes2467 # of expected failures 21 # of unsupported tests 5 /build/home/marino-huge/gcc-test-area/build/gcc/gnatmake version 6.0.0 20151114 (experimental) === objc tests === I think it would be okay to just "blindly" make the same changes to DragonFly that you do for FreeBSD in the future. It will almost always be the correct thing, and if it isn't I'll still catch it with regular build checks. Thanks for the quick fix, john
[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808 --- Comment #28 from Manuel López-Ibáñez --- Hi Anthony, adding testcases to the patch will help clarify what is working and what you expect to work but it isn't: https://gcc.gnu.org/wiki/HowToPrepareATestcase
[Bug libfortran/68347] Multiple build errors in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-11-14 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- > There are multiple bogus symbols in files (stray \33, etc): > > libgfortran/kinds.h > libgfortran/kinds.inc > libgfortran/fpu-target.inc > libgfortran/c99_protos.inc > > which lead to multiple compilation errors. AFAICT these files are generated during bootstrap. On which platform do you see this? Can you give some examples of the faulty lines? Have you ever successfully bootstrapped 5.2? grep "\x33" ../5_build/x86_64-apple-darwin14.5.0/libgfortran/* does not return anything on x86_64-apple-darwin14 for gcc version 5.2.1 revision r230040 (or trunk 6.0).
[Bug libfortran/68347] Multiple build errors in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347 --- Comment #2 from Alexey Rychkov --- #define GFC_REAL_4_HUGE ^[[01;31m^[[K^[[m^[[K 3.40282347e38f #define GFC_REAL_4_LITERAL_SUFFIX f #define GFC_REAL_4_LITERAL(X) (X ## f) #define GFC_REAL_4_DIGITS ^[[01;31m^[[K^[[m^[[K 24 #define GFC_REAL_4_RADIX ^[[01;31m^[[K^[[m^[[K 2 ^[[01;31m^[[K#^[[m^[[Kifndef C99_PROTOS_H ^[[01;31m^[[K#^[[m^[[Kdefine C99_PROTOS_H 1 ^[[01;31m^[[K#^[[m^[[Kifndef HAVE_ACOSF ^[[01;31m^[[K#^[[m^[[Kdefine HAVE_ACOSF 1 ^[[01;31m^[[K#^[[m^[[Kendif The system is CentOS release 6.7 I did just this: cd gcc-5.2.0 mkdir build && cd build ../configure --disable-multilib make I'm not sure if this can affect something, but I was using tmux on top of ssh session...
[Bug libfortran/68347] Multiple build errors in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347 --- Comment #3 from Dominique d'Humieres --- > I'm not sure if this can affect something, but I was using tmux on top > of ssh session... Can you try again without tmx? I am not that familiar with sequences such as "^[[01;31m^[[K^[[m^[[K", but I associate them to output "styles" to the terminal. The file kind.h is generated by /bin/sh ../../../work/libgfortran/mk-kinds-h.sh '/opt/gcc/build_w/./gcc/gfortran -B/opt/gcc/build_w/./gcc/ -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/bin/ -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/lib/ -isystem /opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/include -isystem /opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/sys-include-I . -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring -g -O2' > kinds.h || rm kinds.h where /opt/gcc/build_w , /opt/gcc/work, and /opt/gcc/gcc6w are respectively my build, source, and install directories. What is the output of /bin/sh /opt/gcc/work/libgfortran/mk-kinds-h.sh '/opt/gcc/build_w/gcc/gfortran -B/opt/gcc/build_w/gcc/ -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/bin/ -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/lib/ -I/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libgfortran -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring -g -O2' (with suitable replacements of /opt/gcc/work/ and /opt/gcc/build_w).
[Bug libfortran/68347] Multiple build errors in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347 --- Comment #4 from Andreas Schwab --- Did you set GREP_OPTIONS?
[Bug fortran/61450] ICE in gfc_global_used()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61450 --- Comment #1 from Dominique d'Humieres --- With the updated patch below the ICE is now replaced with pr61450.f90:6:15: integer i1 2 bind(c,name="foo") :: i1 end module subroutine truc() bind(c,name="foo") 1 Error: Global binding name 'foo' at (1) is already being used at (2) Any reason why the original patch has been delayed for more than a year? If it helps, I can take care of the packaging. Dominique --- ../_clean/gcc/fortran/parse.c 2015-11-11 15:23:35.0 +0100 +++ gcc/fortran/parse.c 2015-11-14 12:49:41.0 +0100 @@ -5237,33 +5237,32 @@ gfc_global_used (gfc_gsymbol *sym, locus switch(sym->type) { case GSYM_PROGRAM: - name = "PROGRAM"; + name = "as a PROGRAM "; break; case GSYM_FUNCTION: - name = "FUNCTION"; + name = "as a FUNCTION "; break; case GSYM_SUBROUTINE: - name = "SUBROUTINE"; + name = "as a SUBROUTINE "; break; case GSYM_COMMON: - name = "COMMON"; + name = "as a COMMON "; break; case GSYM_BLOCK_DATA: - name = "BLOCK DATA"; + name = "as a BLOCK DATA "; break; case GSYM_MODULE: - name = "MODULE"; + name = "as a MODULE "; break; default: - gfc_internal_error ("gfc_global_used(): Bad type"); - name = NULL; + name = ""; } if (sym->binding_label) -gfc_error ("Global binding name %qs at %L is already being used as a %s " +gfc_error ("Global binding name %qs at %L is already being used %s" "at %L", sym->binding_label, where, name, &sym->where); else -gfc_error ("Global name %qs at %L is already being used as a %s at %L", +gfc_error ("Global name %qs at %L is already being used %sat %L", sym->name, where, name, &sym->where); }
[Bug libfortran/68347] Multiple build errors in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin --- according to https://gcc.gnu.org/install/configure.html: > building where objdir is a subdirectory of srcdir is unsupported. this: (In reply to Alexey Rychkov from comment #2) > cd gcc-5.2.0 > mkdir build && cd build > ../configure --disable-multilib is unsupported.
[Bug libfortran/68347] Multiple build errors in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347 --- Comment #6 from Alexey Rychkov --- (In reply to Andreas Schwab from comment #4) > Did you set GREP_OPTIONS? Yes, GREP_OPTIONS='--color=always'
[Bug libfortran/68347] Multiple build errors in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347 --- Comment #7 from Alexey Rychkov --- (In reply to Dominique d'Humieres from comment #3) > > I'm not sure if this can affect something, but I was using tmux on top > > of ssh session... > > Can you try again without tmx? I am not that familiar with sequences such as > "^[[01;31m^[[K^[[m^[[K", but I associate them to output "styles" to the > terminal. > > The file kind.h is generated by > > /bin/sh ../../../work/libgfortran/mk-kinds-h.sh > '/opt/gcc/build_w/./gcc/gfortran -B/opt/gcc/build_w/./gcc/ > -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/bin/ > -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/lib/ -isystem > /opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/include -isystem > /opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/sys-include-I . -Wall -Werror > -fimplicit-none -fno-repack-arrays -fno-underscoring -g -O2' > kinds.h || > rm kinds.h > > where /opt/gcc/build_w , /opt/gcc/work, and /opt/gcc/gcc6w are respectively > my build, source, and install directories. > > What is the output of > > /bin/sh /opt/gcc/work/libgfortran/mk-kinds-h.sh > '/opt/gcc/build_w/gcc/gfortran -B/opt/gcc/build_w/gcc/ > -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/bin/ > -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/lib/ > -I/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libgfortran -Wall -Werror > -fimplicit-none -fno-repack-arrays -fno-underscoring -g -O2' > > (with suitable replacements of /opt/gcc/work/ and /opt/gcc/build_w). Executing /bin/sh ../libgfortran/mk-kinds-h.sh './gcc/gfortran -B/home/arychkov/gcc-5.2.0/build/gcc/ -I/home/arychkov/gcc-5.2.0/libgfortran -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring -g -O2' results in valid output.
[Bug libfortran/68347] Multiple build errors in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347 --- Comment #8 from Dominique d'Humieres --- > ... results in valid output. So Mikael probably got the point: don't buil in the source directory. Instead of > cd gcc-5.2.0 > mkdir build && cd build > ../configure --disable-multilib > make do cd gcc-5.2.0 mkdir ../build && cd ../build ../gcc-5.2.0/configure --disable-multilib make (or similar!-).
[Bug libfortran/68347] Multiple build errors in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347 --- Comment #9 from Alexey Rychkov --- (In reply to Dominique d'Humieres from comment #8) > > ... results in valid output. > > So Mikael probably got the point: don't buil in the source directory. > Instead of > > > cd gcc-5.2.0 > > mkdir build && cd build > > ../configure --disable-multilib > > make > > do > > cd gcc-5.2.0 > mkdir ../build && cd ../build > ../gcc-5.2.0/configure --disable-multilib > make > > (or similar!-). Are you sure that problem is not in GREP_OPTIONS='--color=always' which according to man results in color output using default color scheme '01;31'?
[Bug libfortran/68347] Multiple build errors in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347 --- Comment #10 from Dominique d'Humieres --- > Are you sure that problem is not in GREP_OPTIONS='--color=always' which > according to man results in color output using default color scheme '01;31'? No! but you can do the test by unsetting GREP_OPTIONS. What I am sure is that building in the source directory is not supported.
[Bug libfortran/68347] Multiple build errors in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68347 Alexey Rychkov changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #11 from Alexey Rychkov --- Now it is compiles without any problems. The reason of the problem was in --color=always which results in special chars controlling color of output of grep to be generated even when using with pipe.
[Bug rtl-optimization/68328] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68328 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- I can't reproduce on x86_64-linux with ether gcc-6 r230377, gcc-5 r230369, or gcc-4.9 r230368.
[Bug c++/68348] New: ice in cxx_eval_constant_expression at cp/constexpr.c:3172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68348 Bug ID: 68348 Summary: ice in cxx_eval_constant_expression at cp/constexpr.c:3172 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 36707 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36707&action=edit gzipped C++ source code I used gcc trunk dated 20151114 to compile the attached C++ code. The compiler said ../../analitzaplot/plotter2d.cpp: In member function ‘QRectF Analitza::Plotter2D ::normalizeUserViewport(QRectF)’: ../../analitzaplot/plotter2d.cpp:944:41: in constexpr expansion of ‘#‘result_d ecl’ not supported by dump_expr#.QRectF::width()’ ../../analitzaplot/plotter2d.cpp:968:1: internal compiler error: Segmentation fa ult 0xd6ab3f crash_signal ../../src/trunk/gcc/toplev.c:336 0x7f3d12 cxx_eval_constant_expression ../../src/trunk/gcc/cp/constexpr.c:3172 0x7f5d5a cxx_eval_indirect_ref ../../src/trunk/gcc/cp/constexpr.c:2609 0x7f2dbf cxx_eval_constant_expression ../../src/trunk/gcc/cp/constexpr.c:3363
[Bug c/68349] New: ice in decompose_normal_address with -O2 at tlanal.c:6086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68349 Bug ID: 68349 Summary: ice in decompose_normal_address with -O2 at tlanal.c:6086 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 36708 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36708&action=edit C source code I used gcc trunk dated 20151114 to compile the attached C code. The compiler said $ ../results/bin/gcc -c -O2 bug245.c findhyphen.c: In function ‘DoHyphens’: findhyphen.c:291:1: internal compiler error: in decompose_normal_address, at rtlanal.c:6086 0xaeec83 decompose_normal_address ../../src/trunk/gcc/rtlanal.c:6086 0xaeec83 decompose_address(address_info*, rtx_def**, machine_mode, unsigned char, rtx_code) ../../src/trunk/gcc/rtlanal.c:6163 0x9b8355 process_address_1 ../../src/trunk/gcc/lra-constraints.c:2874 0x9b8355 process_address ../../src/trunk/gcc/lra-constraints.c:3133
[Bug rtl-optimization/68349] ;ice in decompose_normal_address with -O2 at rtlanal.c:6086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68349 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-14 CC||trippels at gcc dot gnu.org Summary|ice in |;ice in |decompose_normal_address|decompose_normal_address |with -O2 at rtlanal.c:6086 |with -O2 at rtlanal.c:6086 Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- int a, b; unsigned long strlen(); typedef struct sHyphenNode { char sepcnts[0]; struct sHyphenNode *Daughters[]; } * PHyphenNode; int GetIndex(); PHyphenNode c; void DoHyphens_Field_1() { char d[300], e[300]; int z, f, l = strlen(); for (; z;) ; for (; l; z++) { f = z; for (; f < l; f++) { c = c->Daughters[GetIndex(d[f])]; a = 0; for (; a <= f - z; a++) if (e[z + a]) e[z] = c->sepcnts[a]; } } if (e[z]) b = 1; }
[Bug libstdc++/68350] New: std::uninitialized_copy overly restrictive for trivially_copyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350 Bug ID: 68350 Summary: std::uninitialized_copy overly restrictive for trivially_copyable types Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: philipp.ochsendorf+gcc at gmail dot com Target Milestone: --- I think the following decision is too restrictive: return std::__uninitialized_copy<__is_trivial(_ValueType1) && __is_trivial(_ValueType2) && __assignable>:: __uninit_copy(__first, __last, __result); (cf. stl_uninitialized.h:123ff). The following should be sufficient: return std::__uninitialized_copy:: __uninit_copy(__first, __last, __result); Found this in 5.2.0 and 6.0. Probably it's in versions prior to 5.2.0 as well.
[Bug c++/68348] [6 regression] ICE: segfault in cxx_eval_constant_expression at cp/constexpr.c:3172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68348 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-14 CC||trippels at gcc dot gnu.org Summary|ice in |[6 regression] ICE: |cxx_eval_constant_expressio |segfault in |n at cp/constexpr.c:3172|cxx_eval_constant_expressio ||n at cp/constexpr.c:3172 Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- typedef double qreal; class QRectF { public: constexpr QRectF() : xp(), yp(), w(), h() {} constexpr qreal width() const noexcept; double xp; double yp; double w; double h; }; constexpr qreal QRectF::width() const noexcept { return w; } QRectF normalizeUserViewport() { QRectF normalizeduvp; normalizeduvp.width(); return normalizeduvp; }
[Bug fortran/67803] ICE on concatenating wrong character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67803 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Nov 14 17:31:16 2015 New Revision: 230379 URL: https://gcc.gnu.org/viewcvs?rev=230379&root=gcc&view=rev Log: 2015-11-14 Steven G. Kargl PR fortran/67803 * array.c (gfc_match_array_constructor): If array constructor included a CHARACTER typespec, check array elements for compatible type. 2015-11-14 Steven G. Kargl PR fortran/67803 * gfortran.dg/pr67803.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr67803.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/68298] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68298 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- I can't reproduce this SEGV on x86_64-linux with current gcc-5 or gcc-6.
[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-14 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Yes, G++ didn't support is_trivially_copyable when that condition was written.
[Bug fortran/67803] ICE on concatenating wrong character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67803 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Nov 14 17:43:15 2015 New Revision: 230380 URL: https://gcc.gnu.org/viewcvs?rev=230380&root=gcc&view=rev Log: 2015-11-14 Steven G. Kargl PR fortran/67803 * array.c (gfc_match_array_constructor): If array constructor included a CHARACTER typespec, check array elements for compatible type. 2015-11-14 Steven G. Kargl PR fortran/67803 * gfortran.dg/pr67803.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67803.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/array.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/67803] ICE on concatenating wrong character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67803 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug bootstrap/68346] [6 Regression] Bootstrap failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68346 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-14 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/68344] No warning for old-style function declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68344 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #1 from Eric Gallager --- I think -Wstrict-prototypes does what you're looking for here: $ /usr/local/bin/gcc -Wold-style-declaration -Wold-style-definition -Wstrict-prototypes -Wmissing-parameter-type -Wmissing-prototypes -std=c11 -pedantic -c pr68344.c pr68344.c:1:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes] int a(); ^
[Bug c/68344] No warning for old-style function declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68344 --- Comment #2 from i.hamsa at gmail dot com --- Indeed. I somehow missed that option. It probably would be logical for -Wold-style-declaration to imply -Wstrict-prototypes, but this is a minor issue.
[Bug bootstrap/68346] [6 Regression] Bootstrap failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68346 --- Comment #2 from Jason Merrill --- Author: jason Date: Sat Nov 14 18:54:16 2015 New Revision: 230382 URL: https://gcc.gnu.org/viewcvs?rev=230382&root=gcc&view=rev Log: PR bootstrap/68346 * call.c (build_new_op_1): Don't fold arguments to warn_tautological_cmp. Added: trunk/gcc/testsuite/g++.dg/warn/Wtautological-compare.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/68351] New: ICE in ssl.h with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68351 Bug ID: 68351 Summary: ICE in ssl.h with -g Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: guille at cal dot berkeley.edu Target Milestone: --- Created attachment 36709 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36709&action=edit this is the OSX 10.9.5 /usr/include/openssl/ssl.h t.c: #include int main() { return 0; } # c++-6.0.0 -g t.c In file included from /usr/include/openssl/asn1.h:76:0, from /usr/include/openssl/objects.h:962, from /usr/include/openssl/evp.h:100, from /usr/include/openssl/x509.h:75, from /usr/include/openssl/ssl.h:185, from t.c:1: /usr/include/openssl/bn.h:335:3: error: TYPE_CANONICAL is not compatible { ^ asm_written public unsigned DI size unit size align 64 symtab 31264032 alias set -1 canonical type 0x1434272a0 pointer_to_this > decl_3 VOID file /usr/include/openssl/bn.h line 333 col 8 align 1 offset_align 1 context chain decl_3 VOID file /usr/include/openssl/bn.h line 332 col 15 align 1 offset_align 1 context chain >> context full-name "struct bn_gencb_st" n_parents=0 use_template=0 interface-unknown pointer_to_this chain > full-name "BN_GENCB" n_parents=0 use_template=0 interface-unknown pointer_to_this chain > /usr/include/openssl/bn.h:335:3: internal compiler error: verify_type failed /usr/include/openssl/bn.h:335:3: internal compiler error: Abort trap: 6 c++-6.0.0: internal compiler error: Abort trap: 6 (program cc1plus)
[Bug c++/68351] ICE in ssl.h with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68351 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-11-14 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Please attach the preprocessed file. See: http://gcc.gnu.org/bugs/
[Bug c++/68351] ICE in ssl.h with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68351 --- Comment #2 from Guille --- Created attachment 36710 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36710&action=edit This is the preprocessed file.
[Bug bootstrap/68346] [6 Regression] Bootstrap failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68346 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug c++/68351] ICE in ssl.h with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68351 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Markus Trippelsdorf --- Thanks. dup. *** This bug has been marked as a duplicate of bug 66214 ***
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 Markus Trippelsdorf changed: What|Removed |Added CC||guille at cal dot berkeley.edu --- Comment #17 from Markus Trippelsdorf --- *** Bug 68351 has been marked as a duplicate of this bug. ***
[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239 H.J. Lu changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #16 from H.J. Lu --- It was triggered by r222305. It may be a latent bug.
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 --- Comment #18 from Guille --- I may be missing something: I could build latest openssl no problem, but '#include \int main(){return 0;}' ICEs on my system's installed openssl (OSX 10.9.5). (In reply to Magnus Fromreide from comment #16) > Should the importance of this bug be raised? > It is a bit embarrasing that the program > > #include > > ice's
[Bug c++/68352] New: [Cygwin] internal compiler error: Segmentation fault max() _GLIBCXX_USE_NOEXCEPT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68352 Bug ID: 68352 Summary: [Cygwin] internal compiler error: Segmentation fault max() _GLIBCXX_USE_NOEXCEPT Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: daspamster at gmail dot com Target Milestone: --- My toy code won't compile on Cygwin when a simple "Hello world' will. I'm including one big file, with everything but the first 62 lines being the contents of "permute.cpp", my one source file.
[Bug c++/68352] [Cygwin] internal compiler error: Segmentation fault max() _GLIBCXX_USE_NOEXCEPT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68352 --- Comment #1 from Ben Kane --- Created attachment 36711 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36711&action=edit all except permute.ii (attaching separately)
[Bug c++/68352] [Cygwin] internal compiler error: Segmentation fault max() _GLIBCXX_USE_NOEXCEPT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68352 --- Comment #2 from Ben Kane --- Created attachment 36712 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36712&action=edit permute.ii (1.5 MB) I uploaded it to Wikisend because of the file size. It disappears in 90 days :)
[Bug tree-optimization/66974] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- (In reply to Ganesh Ajjanagadde from comment #2) For what it's worth, telling gcc that the argument is constrained to the limited range of values either by converting it like so: order = ((struct { unsigned order: 2; }){ order }).order; or by declaring the function to take an argument of that type eliminates the warnings and results in far simpler object code.
[Bug libstdc++/68353] New: [6 Regression] libstdc++-v3/include/bits/basic_string. h:5524:31: error: 'wcstoll' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68353 Bug ID: 68353 Summary: [6 Regression] libstdc++-v3/include/bits/basic_string. h:5524:31: error: 'wcstoll' is not a member of 'std' Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa*-*-hpux* Target: hppa*-*-hpux* Build: hppa*-*-hpux* Created attachment 36713 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36713&action=edit Preprocessed source In stage1, we have: make[4]: Entering directory `/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++- v3' Making all in includemake[5]: Entering directory `/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include' mkdir -p ./hppa64-hp-hpux11.11/bits/stdc++.h.gch/test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/test/gnu/gcc/objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/sys-include-x c++-header -nostdinc++ -g -O2 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /test/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h \ -o hppa64-hp-hpux11.11/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/string:52:0, from /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/locale_classes.h:40, from /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/ios_base.h:41, from /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ios:42, from /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/istream:38, from /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/sstream:38, from /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:45, from /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ccomplex:38, from /test/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h:52: /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h: In function 'long long int std::__cxx11::stoll(const wstring&, std::size_t*, int)': /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:5524:31: error: 'wcstoll' is not a member of 'std' { return __gnu_cxx::__stoa(&std::wcstoll, "stoll", __str.c_str(), ^~~ /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h: In function 'long long unsigned int std::__cxx11::stoull(const wstring&, std::size_t*, int)': /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:5529:31: error: 'wcstoull' is not a member of 'std' { return __gnu_cxx::__stoa(&std::wcstoull, "stoull", __str.c_str(), ^~~ /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h: In function 'float std::__cxx11::stof(const wstring&, std::size_t*)': /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:5535:31: error: 'wcstof' is not a member of 'std' { return __gnu_cxx::__stoa(&std::wcstof, "stof", __str.c_str(), __idx); } ^~~ /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h: In function 'long double std::__cxx11::stold(const wstring&, std::size_t*)': /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:5543:31: error: 'wcstold' is not a member of 'std' { return __gnu_cxx::__stoa(&std::wcstold, "stold", __str.c_str(), __idx); } ^~~ make[5]: *** [hppa64-hp-hpux11.11/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1 make[5]: Leaving directory `/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include' make[4]: *** [all-recursive] Error 1
[Bug tree-optimization/66974] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974 --- Comment #5 from Ganesh Ajjanagadde --- That I do not consider a readable or scalable solution. Furthermore, this is a bug, and the FFmpeg codebase gets compiled across a wide array of compilers. We can't insert hacks for specific GCC versions. Thanks for pointing it out nonetheless.
[Bug c++/68354] New: -Warray-bounds on a flexible array member in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68354 Bug ID: 68354 Summary: -Warray-bounds on a flexible array member in C++ Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- In C++ mode (but not in C mode), g++ silently (without -Wpedantic) accepts both a definition of a struct with a flexible array member and an object of such a type without an initializer but issues a warning for accesses to the array (see below). Debugging reveals that unlike the C front end, the C++ front end sets the bounds on flexible arrays to [0, SIZE_MAX]. The code in check_array_ref in tree-vrp.c then trips up on such an array because it first assumes that flexible arrays have no bounds, and further assumes that no array has an upper bound of SIZE_MAX when adding one to the bound. When the computation wraps around to zero, the function incorrectly deduces that the array is empty and issues a warning. It seems wrong for the C++ front end to set the upper bound to SIZE_MAX for any array. First, because GCC itself assumes that no object is larger than SIZE_MAX / 2. Second, when the size of the array element is greater than 1 as in the case below, even the most permissive upper bound cannot be SIZE_MAX. $ cat u.cpp && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -O2 -S -Wall -Wextra -o/dev/null u.cpp struct S { int n; int a[]; } s; int i; void f () { i = s.a [0]; } u.cpp: In function ‘void f()’: u.cpp:10:15: warning: array subscript is above array bounds [-Warray-bounds] i = s.a [0]; ^
[Bug c++/68354] -Warray-bounds on a flexible array member in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68354 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-15 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Working on a patch.
[Bug target/68332] [6 Regression] ICE: in rs6000_is_valid_mask, at config/rs6000/rs6000.c:17052 with __sync_and_and_fetch() @ powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68332 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-15 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- Whoops, I forgot about this. Mine.
[Bug libstdc++/68353] [6 Regression] libstdc++-v3/include/bits/basic_string. h:5524:31: error: 'wcstoll' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68353 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-15 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1
[Bug rtl-optimization/68328] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68328 --- Comment #2 from Zhendong Su --- (In reply to Mikael Pettersson from comment #1) > I can't reproduce on x86_64-linux with ether gcc-6 r230377, gcc-5 r230369, > or gcc-4.9 r230368. Mikael, not sure why you can't reproduce the miscompilation. I can still reproduce it with r230832 as shown below: $ 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 20151114 (experimental) [trunk revision 230382] (GCC) $ $ gcc-trunk -O2 pr68328.c $ ./a.out 0 $ gcc-trunk -Os pr68328.c $ ./a.out $
[Bug rtl-optimization/68298] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68298 --- Comment #2 from Zhendong Su --- (In reply to Mikael Pettersson from comment #1) > I can't reproduce this SEGV on x86_64-linux with current gcc-5 or gcc-6. Mikael, I can still reproduce it with r230382 as shown below: $ 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 20151114 (experimental) [trunk revision 230382] (GCC) $ $ gcc-trunk -m64 -O3 pr68298.c $ ./a.out Segmentation fault (core dumped) $ $ gcc-trunk -m64 -O2 pr68298.c $ ./a.out 0 $
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #8 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #7) > (In reply to Kazumoto Kojima from comment #6) > I've changed the predicate of the 2nd operand to arith_operand instead > of const_int_operand in your patch and run testsuite. Yes, of course, sorry. > There is one new failure: > > FAIL: gfortran.dg/pr65450.f90 -O3 -g execution test > > which is > > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > > Weird. I'm afraid that even my first patch makes wrong codes silently, > though it doesn't fail for the above test. With that test and the patch I see one difference: before: dt r11 add r7,r12 mov.w .L65,r7<<< add r1,r7 after: dt r11 add r7,r12 mov r1,r7 <<< add r1,r7 The insn in .reload is: (note 133 132 747 9 [bb 9] NOTE_INSN_BASIC_BLOCK) (insn 747 133 134 9 (set (reg:SI 7 r7) (const_int 4000 [0xfa0])) 256 {movsi_ie} (nil)) (insn 134 747 135 9 (parallel [ (set (reg:SI 12 r12 [orig:295 ivtmp.165 ] [295]) (plus:SI (reg:SI 12 r12 [orig:295 ivtmp.165 ] [295]) (reg:SI 7 r7))) (clobber (scratch:SI)) ]) 65 {addsi3_scr} (nil)) (insn 135 134 748 9 (parallel [ (set (reg:SI 7 r7 [orig:298 ivtmp.172 ] [298]) (plus:SI (reg:SI 1 r1 [orig:280 ivtmp.135 ] [280]) (const_int 4000 [0xfa0]))) (clobber (reg:SI 0 r0)) ]) 65 {addsi3_scr} (nil)) addsi_scr will convert this to something like mov.w #4000, r7 add r1,r7 but then .postreload sees the previous same constant load in insn 747, removes it and changes the add insn to: (insn 135 134 748 9 (set (reg:SI 7 r7 [orig:298 ivtmp.172 ] [298]) (plus:SI (reg:SI 1 r1 [orig:280 ivtmp.135 ] [280]) (reg:SI 7 r7))) 66 {*addsi3} (nil)) so we get overlapping regs for operands[0] and operands[2] which is not checked. In fact, the very same bug is hidden in the addsi3_scr pattern which we have added recently, but it seems it hasn't been triggered (yet). The patch below is a bit of a hammer, but hopefully it works as intended. CSiBE code size change is +- 0 everywhere, but there are some differences in the generated code. Postreload is able to remove some redundant constant loads. I've checked that gfortran.dg/pr65450.f90 and attachment 36686 look OK with this patch. Could you please give it another test run? Index: gcc/config/sh/sh.md === --- gcc/config/sh/sh.md (revision 230158) +++ gcc/config/sh/sh.md (working copy) @@ -2232,11 +2232,51 @@ } } else if (!reg_overlap_mentioned_p (operands[0], operands[1])) -emit_move_insn (operands[0], operands[1]); +{ + if (!reg_overlap_mentioned_p (operands[0], operands[2])) + emit_move_insn (operands[0], operands[1]); + else + operands[2] = operands[1]; +} } [(set_attr "type" "arith")]) +;; Old reload might generate add insns directly (not through the expander) for +;; the memory address of complex insns like atomic insns when reloading. (define_insn_and_split "*addsi3" + [(set (match_operand:SI 0 "arith_reg_dest" "=r") + (plus:SI (match_operand:SI 1 "arith_reg_operand" "r") +(match_operand:SI 2 "arith_or_int_operand" "rn")))] + "TARGET_SH1 && !sh_lra_p () + && reload_completed + && !reg_overlap_mentioned_p (operands[0], operands[1])" + "#" + "&& 1" + [(set (match_dup 0) (plus:SI (match_dup 0) (match_dup 2)))] +{ + if (operands[2] == const0_rtx) +{ + emit_move_insn (operands[0], operands[1]); + DONE; +} + + if (CONST_INT_P (operands[2])) +{ + if (satisfies_constraint_I08 (operands[2])) + emit_move_insn (operands[0], operands[1]); + else + { + emit_move_insn (operands[0], operands[2]); + operands[2] = operands[1]; + } +} + else if (!reg_overlap_mentioned_p (operands[0], operands[2])) +emit_move_insn (operands[0], operands[1]); + else +operands[2] = operands[1]; +}) + +(define_insn_and_split "*addsi3" [(set (match_operand:SI 0 "arith_reg_dest" "=r,r") (plus:SI (match_operand:SI 1 "arith_reg_operand" "%0,r") (match_operand:SI 2 "arith_operand" "rI08,Z")))]
[Bug target/68355] New: Constant byte is passed on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68355 Bug ID: 68355 Summary: Constant byte is passed on stack Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: ubizjak at gmail dot com Target Milestone: --- Target: x86-64 [hjl@gnu-tools-1 pr67239]$ cat foo.ii template struct integral_constant { static constexpr _Tp value = __v; typedef _Tp value_type; typedef integral_constant<_Tp, __v> type; constexpr operator value_type() const { return value; } }; typedef integral_constant true_type; extern void xxx (true_type c); extern true_type y; void yyy () { xxx (y); } [hjl@gnu-tools-1 pr67239]$ gcc -S -std=gnu++11 -S -O2 foo.ii [hjl@gnu-tools-1 pr67239]$ cat foo.s .file "foo.ii" .section.text.unlikely,"ax",@progbits .LCOLDB0: .text .LHOTB0: .p2align 4,,15 .globl _Z3yyyv .type _Z3yyyv, @function _Z3yyyv: .LFB1: .cfi_startproc subq$16, %rsp .cfi_def_cfa_offset 24 pushq $0 .cfi_def_cfa_offset 32 call_Z3xxx17integral_constantIbLb1EE addq$24, %rsp .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE1: .size _Z3yyyv, .-_Z3yyyv .section.text.unlikely .LCOLDE0: .text .LHOTE0: .ident "GCC: (GNU) 5.2.1 20150929 (Red Hat 5.2.1-3)" .section.note.GNU-stack,"",@progbits [hjl@gnu-tools-1 pr67239]$ It causes PR 67329 due to DW_CFA_GNU_args_size generated by "push $0", which is ignored by callee.
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #9 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #6) > I think that that trial and AMS show the backend like SH requires > something even for the old reload, though I'm not sure that > the 2nd postreload_cse is the right thing for that. The 2nd postreload might be a wallpapering work around. But it would allow us to switch to LRA by default without regressing code size / performance, if I understand correctly. Of course the proper fix would be having AMS and constant optimization and R0 pre-alloc and 2-operand-optimizations (the ones we've been fighting with the addsi3 patterns) and ... At the current (lack of) pace I don't know when all of that will be done. So my idea was to at least reduce the R0 problem for users by making LRA the default in GCC 6. If we have to add the 2nd postreload temporarily, so be it. When the other solutions become more mature and stable, we can remove the 2nd postreload thing again.
[Bug target/68355] Constant byte is passed on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68355 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-15 Blocks||67239 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It is PR 67239. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239 [Bug 67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test