[Bug middle-end/87757] weird underlining and colors in sprintf warnings for unterminated arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87757
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-10-30
Ever confirmed|0 |1
--- Comment #5 from Aldy Hernandez ---
(In reply to David Malcolm from comment #4)
> Aldy: do you remember why the arguments need to have the same location as
> the call itself?
>
> The first case works because during gimplify_arg it's wrapped in a NOP_EXPR
> which is casting from char[] to char *, and it's this NOP_EXPR which gets
> its location modified.
>
> The second case doesn't have the NOP_EXPR.
This looks like an oversight on my part.
In the original patch you mention, there was a now defunct bit that seems
suspicious and my shed light on the problem:
+ /* FIXME diagnostics: This should be the location of the argument,
+not the FNDECL. E.g., for an old-style declaration
+
+ int f10(v) { blah; }
+
+We should use the location of the V, not the F10.
+Unfortunately, the V is an IDENTIFIER_NODE which has no
+location. In the future we need locations for c_arg_info
+entries.
+
+See gcc.dg/Wshadow-3.c for an example of this problem. */
So maybe I was assuming that the problematic line was also dealing with an
IDENTIFIER_NODE which had no place to put a location?
Either way, it looks like some sort of oversight.
Confirmed, BTW.
[Bug tree-optimization/87801] [9 Regression] CPU2006 454.calculix failed to build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87801 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 87785 ***
[Bug tree-optimization/87785] [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87785 Martin Liška changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #7 from Martin Liška --- *** Bug 87801 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/87800] [9 Regression] CPU2006 416.gamess failed to build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87800 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-30 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug other/87802] [9 regression] g++.dg/vect/slp-pr87105.cc fails starting with r265522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87802 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-30 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug target/87793] [8/9 Regression] GCC reports error when compiling with "-fpic -Os -g"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87793 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-30 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to work||7.3.0 Target Milestone|--- |8.3 Summary|GCC reports error when |[8/9 Regression] GCC |compiling with "-fpic -Os |reports error when |-g" |compiling with "-fpic -Os ||-g" Ever confirmed|0 |1 Known to fail||8.2.0, 9.0 --- Comment #1 from Martin Liška --- Confirmed, started with r254025.
[Bug web/87803] GCC 6.5.0 release directory is misnamed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87803 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed.
[Bug web/87803] GCC 6.5.0 release directory is misnamed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87803 --- Comment #2 from Jakub Jelinek --- Unfortunately the GNU ftp uploading directives don't allow to rename a directory. I've mailed the administrator.
[Bug web/87803] GCC 6.5.0 release directory is misnamed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87803 --- Comment #3 from rguenther at suse dot de --- On Tue, 30 Oct 2018, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87803 > > --- Comment #2 from Jakub Jelinek --- > Unfortunately the GNU ftp uploading directives don't allow to rename a > directory. I've mailed the administrator. IIRC I made a mistake myself a few years ago and resorted to delete and re-upload. Delete is possible IIRC.
[Bug web/87803] GCC 6.5.0 release directory is misnamed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87803 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Done that way now.
[Bug fortran/44646] [F08] Implement DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44646 --- Comment #11 from Thomas Koenig --- I've changed the entry in the table to PR78219; the KIND specification in the forall index is still missing. so yellow is appropriate.
[Bug fortran/83064] DO CONCURRENT and auto-parallelization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #30 from Jürgen Reuter --- To me it looks like that after Thomas' commit from April '18 the table of results is now: Unrolled do-loop Options Parallel Correct -Og-ftree-parallelize-loops=2 N Y -O1-ftree-parallelize-loops=2 Y Y -O2-ftree-parallelize-loops=2 Y Y -O3-ftree-parallelize-loops=2 Y Y -Ofast -ftree-parallelize-loops=2 Y Y Modulo inside do-loop, or Indexed via host associated array Options Parallel Correct -Og-ftree-parallelize-loops=2 N Y -O1-ftree-parallelize-loops=2 Y Y -O2-ftree-parallelize-loops=2 Y Y -O3-ftree-parallelize-loops=2 Y Y -Ofast -ftree-parallelize-loops=2 Y Y The first number of PI in the test (the one with 16 digits) is different between the unrolled do-loop and the module inside do-loop/indexed via host association, while the second value (8 digits) is always the same. But all results are consistent and do not change change any more in consecutive runs. So is this fixed now?
[Bug fortran/87804] New: Omp simd loop with sin calls not vectorized when inside omp parallel region and the sin parameter uses value from shared array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87804 Bug ID: 87804 Summary: Omp simd loop with sin calls not vectorized when inside omp parallel region and the sin parameter uses value from shared array Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pavel.ondracka at gmail dot com Target Milestone: --- Created attachment 44926 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44926&action=edit testcase First of all I'm not sure if this is the right component, however selecting fortran fronted for now, since equivalent C code works fine. I need to use vectorized math functions from libmvec (with omp simd) inside an omp parallel region. The omp simd part works (not by default but using the instructions from here: https://gcc.gnu.org/ml/gcc/2017-11/msg00014.html), however when the parameter to the function depends on some value from an shared array it doesn't vectorize. It doesn't matter if the array is declared with constant dimension or allocated on the heap. See the attached minimal testcase. gfortran -O2 -fopenmp -fopt-info-omp-vec-optimized-all test.f03 Analyzing loop at test.f03:23 test.f03:23:0: note: = analyze_loop_nest = test.f03:23:0: note: === vect_analyze_loop_form === test.f03:23:0: note: === get_loop_niters === test.f03:23:0: note: === vect_analyze_data_refs === test.f03:23:0: note: got vectype for stmt: _37 = *.omp_data_i_36(D).b; vector(2) unsigned long test.f03:23:0: note: got vectype for stmt: _38 = *_37.data; vector(2) unsigned long test.f03:23:0: note: not vectorized: not suitable for gather load _38 = *_37.data; test.f03:23:0: note: bad data references. test.f03:19:0: note: vectorized 0 loops in function. If I remove the outer "omp parallel do" the inner loop vectorizes fine. So far the only solution I have found which makes it work together is to place the array on the stack and make it firstprivate in the parallel region. However this IMO should not be needed as I'm using it only for reading inside the loops (and this workaround has some overhead). Gfortran: 8.2.1 Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz This is my first bug report for gcc, so please let me know if more info is needed or if I made some obvious mistake in my testcase.
[Bug c++/87805] New: Incomplete diagnostic for -Wnoexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87805
Bug ID: 87805
Summary: Incomplete diagnostic for -Wnoexcept
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The warning option "-Wnoexcept" produces incomplete diagnostics
for the following testcase:
==
#include
struct Hash
{
char operator()(char) const { return 0; }
};
std::unordered_set x;
==
==
/gcc-8.2.0/include/c++/8.2.0/type_traits: In instantiation of 'constexpr bool
std::__call_is_nt(std::__invoke_other) [with _Fn = const Hash&; _Args = {const
char&}]':
/gcc-8.2.0/include/c++/8.2.0/type_traits:2658:34: required by substitution of
'template using __bool_constant = std::integral_constant
[with bool __v = std::__call_is_nt((std::__result_of_success::__invoke_type{},
std::__result_of_success::__invoke_type()))]'
/gcc-8.2.0/include/c++/8.2.0/type_traits:2656:12: required from 'struct
std::__call_is_nothrow, const
Hash&, const char&>'
/gcc-8.2.0/include/c++/8.2.0/type_traits:131:12: required from 'struct
std::__and_,
std::__call_is_nothrow, const
Hash&, const char&> >'
/gcc-8.2.0/include/c++/8.2.0/type_traits:2668:12: required from 'struct
std::__is_nothrow_invocable'
/gcc-8.2.0/include/c++/8.2.0/type_traits:131:12: required from 'struct
std::__and_, std::__is_nothrow_invocable >'
/gcc-8.2.0/include/c++/8.2.0/type_traits:142:31: required from 'struct
std::__not_,
std::__is_nothrow_invocable > >'
/gcc-8.2.0/include/c++/8.2.0/bits/unordered_set.h:99:63: required from 'class
std::unordered_set'
bug.cc:8:32: required from here
bug.cc:5:8: warning: but 'char Hash::operator()(char) const' does not throw;
perhaps it should be declared 'noexcept' [-Wnoexcept]
char operator()(char) const { return 0; }
^~~~
==
Only with the additional option "-Wsystem-headers" you get the complete
diagnostics:
==
In file included from /gcc-8.2.0/include/c++/8.2.0/unordered_set:38,
from bug.cc:1:
/gcc-8.2.0/include/c++/8.2.0/type_traits: In instantiation of 'constexpr bool
std::__call_is_nt(std::__invoke_other) [with _Fn = const Hash&; _Args = {const
char&}]':
/gcc-8.2.0/include/c++/8.2.0/type_traits:2658:34: required by substitution of
'template using __bool_constant = std::integral_constant
[with bool __v = std::__call_is_nt((std::__result_of_success::__invoke_type{},
std::__result_of_success::__invoke_type()))]'
/gcc-8.2.0/include/c++/8.2.0/type_traits:2656:12: required from 'struct
std::__call_is_nothrow, const
Hash&, const char&>'
/gcc-8.2.0/include/c++/8.2.0/type_traits:131:12: required from 'struct
std::__and_,
std::__call_is_nothrow, const
Hash&, const char&> >'
/gcc-8.2.0/include/c++/8.2.0/type_traits:2668:12: required from 'struct
std::__is_nothrow_invocable'
/gcc-8.2.0/include/c++/8.2.0/type_traits:131:12: required from 'struct
std::__and_, std::__is_nothrow_invocable >'
/gcc-8.2.0/include/c++/8.2.0/type_traits:142:31: required from 'struct
std::__not_,
std::__is_nothrow_invocable > >'
/gcc-8.2.0/include/c++/8.2.0/bits/unordered_set.h:99:63: required from 'class
std::unordered_set'
bug.cc:8:32: required from here
/gcc-8.2.0/include/c++/8.2.0/type_traits:2652:68: warning: noexcept-expression
evaluates to 'false' because of a call to 'char Hash::operator()(char) const'
[-Wnoexcept]
return noexcept(std::declval<_Fn>()(std::declval<_Args>()...));
^
bug.cc:5:8: warning: but 'char Hash::operator()(char) const' does not throw;
perhaps it should be declared 'noexcept' [-Wnoexcept]
char operator()(char) const { return 0; }
^~~~
==
The culprit seems to be the function maybe_noexcept_warning from cp/except.c
where both parts of the warning are emitted as separate warnings.
The first part is (wrongly) suppressed when it is located in a system header:
static void
maybe_noexcept_warning (tree fn)
{
if (TREE_NOTHROW (fn))
{
warning (OPT_Wnoexcept, "noexcept-expression evaluates to % "
"because of a call to %qD", fn);
warning_at (DECL_SOURCE_LOCATION (fn), OPT_Wnoexcept,
"but %qD does not throw; perhaps "
"it should be declared %", fn);
}
}
[Bug c++/87805] Incomplete diagnostic for -Wnoexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87805 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-30 Ever confirmed|0 |1
[Bug c/87806] New: Option -Wall should warn about unused structs, typdefs, enums, etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87806 Bug ID: 87806 Summary: Option -Wall should warn about unused structs, typdefs, enums, etc Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: Ulrich.Windl at rz dot uni-regensburg.de Target Milestone: --- Gcc with -Wall warns about unused static and local variables for a long time, but it does not warn about unused typedefs, enums, structs, etc. I see that there are specific options to enable that, but they are not by default. Is it due to the fact that many #include files define a lot of such (and most of those are not used)? If so, maybe some #pragma to be used in include files could suppress the warning then. Maybe even there are move clever ideas to solve the problem. BTW: With having option -Wmissing-field-initializers I could even imagine to warn about single fields that are never used.
[Bug c/87806] Option -Wall should warn about unused structs, typdefs, enums, etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87806 --- Comment #1 from Ulrich Windl --- This is an enhancement request (cant't set it in Bugzilla)
[Bug target/87807] New: Passing float, double vectors as variadic args fails on sparcv9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87807
Bug ID: 87807
Summary: Passing float, double vectors as variadic args fails
on sparcv9
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
Target Milestone: ---
Target: sparc-sun-solaris2.*
Created attachment 44927
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44927&action=edit
float vector testcase
The attached testcase fails on sparcv9, but works on sparcv7:
$ gcc -m64 va-v2sf.c
$ ./a.out
a = { 1.00, 2.00 }
x = { 0.00, 0.00 }
$ gcc -m32 va-v2sf.c
$ ./a.out
a = { 1.00, 2.00 }
x = { 1.00, 2.00 }
The same happens for the equivalent double testcase, while it works on
i386/amd64.
Of course, the latter has corresponding V2SF/V2DF modes, but still...
[Bug middle-end/65832] Inefficient vector construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65832 Bug 65832 depends on bug 79745, which changed state. Bug 79745 Summary: vec_init<> expander misses V2TImode with AVX and V2OImode and V2TImode with AVX512 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79745 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/79745] vec_init<> expander misses V2TImode with AVX and V2OImode and V2TImode with AVX512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79745 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Testcase in comment#3 is fixed.
[Bug c/87806] Option -Wall should warn about unused structs, typdefs, enums, etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87806 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Jonathan Wakely --- (In reply to Ulrich Windl from comment #0) > Is it due to the fact that many #include files define a lot of such (and > most of those are not used)? Yes. You'd get a warning from every header unless every file that includes the header uses *everything* in that header. It should not be necessary to add pragmas to every header to avoid warnings with -Wall, so this seems like a bad idea.
[Bug c/87806] Option -Wall should warn about unused structs, typdefs, enums, etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87806 --- Comment #3 from Jonathan Wakely --- (In reply to Ulrich Windl from comment #0) > BTW: With having option -Wmissing-field-initializers I could even imagine to > warn about single fields that are never used. Again, this seems like a bad idea. I shouldn't have to use every member of a struct in every file to avoid warnings from -Wall.
[Bug middle-end/65832] Inefficient vector construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65832 Richard Biener changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #9 from Richard Biener --- description and comment#2 and comment#6 still hold. Once you enable -mavx2 things get better, also when avoiding the gpr<->xmm through memory path which we enable with generic tuning.
[Bug jit/87808] New: gcc_lib_dir is missing from libgccjit's search path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87808
Bug ID: 87808
Summary: gcc_lib_dir is missing from libgccjit's search path
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
[forwarded from https://bugs.debian.org/911668]
building an example from the tutorial, then removing the driver and then
running it:
$ ./hello
ld: cannot find crtbeginS.o: No such file or directory
ld: cannot find -lgcc
ld: cannot find -lgcc_s
libgccjit.so: error: error invoking gcc driver
terminate called after throwing an instance of 'gccjit::error'
Aborted (core dumped)
these files are still installed but not found. However when explicitly telling
libgccjit where to look at, it works:
$ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/8 ./hello
hello world
And an strace reveals that this standard path for an installed location is
missing, however it tries to find it many other locations.
access("/home/doko/bin/x86_64-linux-gnu-gcc-8", X_OK) = -1 ENOENT (No such file
or directory)
access("/usr/local/bin/x86_64-linux-gnu-gcc-8", X_OK) = -1 ENOENT (No such file
or directory)
access("/usr/bin/x86_64-linux-gnu-gcc-8", X_OK) = -1 ENOENT (No such file or
directory)
access("/bin/x86_64-linux-gnu-gcc-8", X_OK) = -1 ENOENT (No such file or
directory)
access("/usr/local/games/x86_64-linux-gnu-gcc-8", X_OK) = -1 ENOENT (No such
file or directory)
access("/usr/games/x86_64-linux-gnu-gcc-8", X_OK) = -1 ENOENT (No such file or
directory)
getcwd("/home/doko", 4096) = 11
lstat("/home/doko/x86_64-linux-gnu-gcc-8", 0x7fff0ae9d5c0) = -1 ENOENT (No such
file or directory)
access("/home/doko/bin/x86_64-linux-gnu-gcc-8", X_OK) = -1 ENOENT (No such file
or directory)
access("/usr/local/bin/x86_64-linux-gnu-gcc-8", X_OK) = -1 ENOENT (No such file
or directory)
access("/usr/bin/x86_64-linux-gnu-gcc-8", X_OK) = -1 ENOENT (No such file or
directory)
access("/bin/x86_64-linux-gnu-gcc-8", X_OK) = -1 ENOENT (No such file or
directory)
access("/usr/local/games/x86_64-linux-gnu-gcc-8", X_OK) = -1 ENOENT (No such
file or directory)
access("/usr/games/x86_64-linux-gnu-gcc-8", X_OK) = -1 ENOENT (No such file or
directory)
getcwd("/home/doko", 4096) = 11
lstat("/home/doko/x86_64-linux-gnu-gcc-8", 0x7fff0ae9d5c0) = -1 ENOENT (No such
file or directory)
access("../lib/gcc/x86_64-linux-gnu/8/", X_OK) = -1 ENOENT (No such file or
directory)
access("../lib/gcc/x86_64-linux-gnu/", X_OK) = -1 ENOENT (No such file or
directory)
access("../lib/gcc/", X_OK) = -1 ENOENT (No such file or directory)
access("../lib/", X_OK) = -1 ENOENT (No such file or directory)
access("../lib/gcc/x86_64-linux-gnu/8/", X_OK) = -1 ENOENT (No such file or
directory)
access("../lib/gcc/x86_64-linux-gnu/", X_OK) = -1 ENOENT (No such file or
directory)
access("../lib/gcc/", X_OK) = -1 ENOENT (No such file or directory)
access("../lib/", X_OK) = -1 ENOENT (No such file or directory)
access("../lib/gcc/x86_64-linux-gnu/8/specs", R_OK) = -1 ENOENT (No such file
or directory)
access("../lib/gcc/specs", R_OK)= -1 ENOENT (No such file or directory)
access("../x86_64-linux-gnu/lib/x86_64-linux-gnu/8/specs", R_OK) = -1 ENOENT
(No such file or directory)
access("../x86_64-linux-gnu/lib/specs", R_OK) = -1 ENOENT (No such file or
directory)
access("/usr/lib/gcc/x86_64-linux-gnu/specs", R_OK) = -1 ENOENT (No such file
or directory)
access("../lib/gcc/x86_64-linux-gnu/8/", X_OK) = -1 ENOENT (No such file or
directory)
access("../lib/gcc/x86_64-linux-gnu/", X_OK) = -1 ENOENT (No such file or
directory)
access("../lib/gcc/", X_OK) = -1 ENOENT (No such file or directory)
stat("../lib/gcc/x86_64-linux-gnu/8/lto-wrapper", 0x7fff0ae9e750) = -1 ENOENT
(No such file or directory)
stat("../lib/gcc/x86_64-linux-gnu/lto-wrapper", 0x7fff0ae9e750) = -1 ENOENT (No
such file or directory)
stat("../lib/gcc/lto-wrapper", 0x7fff0ae9e750) = -1 ENOENT (No such file or
directory)
stat("../x86_64-linux-gnu/bin/x86_64-linux-gnu/8/lto-wrapper", 0x7fff0ae9e750)
= -1 ENOENT (No such file or directory)
stat("../x86_64-linux-gnu/bin/x86_64-linux-gnu/lto-wrapper", 0x7fff0ae9e750) =
-1 ENOENT (No such file or directory)
stat("../x86_64-linux-gnu/bin/lto-wrapper", 0x7fff0ae9e750) = -1 ENOENT (No
such file or directory)
openat(AT_FDCWD, "/tmp/ccL9yR72.o", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
stat("../lib/gcc/x86_64-linux-gnu/8/x86_64-linux-gnu-as", 0x7fff0ae9e580) = -1
ENOENT (No such file or directory)
stat("../lib/gcc/x86_64-linux-gnu/8/as", 0x7fff0ae9e5d0) = -1 ENOENT (No such
file or directory)
stat("../lib/gcc/x86_64-linux-gnu/x86_64-linux-gnu-as", 0x7fff0ae9e580) = -1
ENOENT (No such file or directory)
stat("../lib/gcc/x86_64-linux-gnu/as", 0x7fff0ae9e5d0) = -1 ENOENT (No such
file or directory)
stat(
[Bug jit/87808] gcc_lib_dir is missing from libgccjit's search path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87808 --- Comment #1 from Matthias Klose --- it looks like the code can run without the external driver, but it cannot find the needed files in the install location.
[Bug tree-optimization/58497] SLP vectorizes identical operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58497
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #12 from Richard Biener ---
We now generate
g:
.LFB0:
.cfi_startproc
pxor%xmm1, %xmm1
addl$1, %edi
movaps %xmm1, %xmm0
cvtsi2ss%edi, %xmm0
shufps $36, %xmm0, %xmm1
movaps %xmm1, %xmm0
cvtsi2ss%edi, %xmm0
shufps $196, %xmm0, %xmm1
movaps %xmm1, %xmm0
unpcklps%xmm1, %xmm0
cvtsi2ss%edi, %xmm0
shufps $225, %xmm1, %xmm0
cvtsi2ss%edi, %xmm0
ret
or with SSE4
g:
.LFB0:
.cfi_startproc
addl$1, %edi
pxor%xmm1, %xmm1
pxor%xmm0, %xmm0
cvtsi2ss%edi, %xmm1
insertps$48, %xmm1, %xmm0
insertps$32, %xmm1, %xmm0
insertps$16, %xmm1, %xmm0
movss %xmm1, %xmm0
ret
on GIMPLE we end up with
g (int x)
{
float4 W;
int _1;
float _2;
[local count: 1073741824]:
_1 = x_3(D) + 1;
_2 = (float) _1;
W_6 = BIT_INSERT_EXPR ;
W_7 = BIT_INSERT_EXPR ;
W_8 = BIT_INSERT_EXPR ;
W_9 = BIT_INSERT_EXPR ;
return W_9;
so we miss to recognize the splat. The GIMPLE looks like this very early
already (update-address-taken + forwprop). SLP vectorization
doesn't treat a BIT_INSERT_EXPR "reduction" as sink but we could probably
pattern-match a VEC_DUPLICATE_EXPR for the above.
[Bug tree-optimization/85283] Generates 20 lines of assembly while only one assembly instruction is enough.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85283 --- Comment #2 from Richard Biener --- We can vectorize a variant with doubles but that results in awful code because the ABI isn't known. The float variant now looks like the following before vectorization: _1 = a.x; _2 = b.x; _3 = _1 + _2; _4 = a.y; _5 = b.y; _6 = _4 + _5; MEM[(struct *)&D.1915] = _3; MEM[(struct *)&D.1915 + 4B] = _6; return D.1915; here the issue is again that we do not know the ABI details plus MMX is disabled and the vectorizer expects 4 floats for vectorization (that is, it cannot vectorize using partial vector regs - the ABI may specify the upper half of %xmm0 is zero for example).
[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87330 --- Comment #8 from sameerad at gcc dot gnu.org --- Author: sameerad Date: Tue Oct 30 10:59:37 2018 New Revision: 265618 URL: https://gcc.gnu.org/viewcvs?rev=265618&root=gcc&view=rev Log: Fixes bug 87330 by invoking df_note_add_problem to recompute REG_DEAD and REG_UNUSED notes before analysis. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/falkor-tag-collision-avoidance.c
[Bug fortran/87804] Omp simd loop with sin calls not vectorized when inside omp parallel region and the sin parameter uses value from shared array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87804 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-30 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. The issue is two-fold, first the array 'b' has unknown stride because IPA cannot look through __builtin_GOMP_parallel, second dsin () ends up as clobbering memory - you probably have to mark it as pure, then we end up with a vectorized variant: .L4: movdqa .LC2(%rip), %xmm3 movdqa 48(%rsp), %xmm1 addq$32, %r14 paddd %xmm0, %xmm3 paddd %xmm0, %xmm1 movaps %xmm3, (%rsp) cvtdq2pd%xmm1, %xmm0 movaps %xmm1, 32(%rsp) call_ZGVbN2v_sin movdqa 32(%rsp), %xmm1 movaps %xmm0, 16(%rsp) pshufd $238, %xmm1, %xmm0 cvtdq2pd%xmm0, %xmm0 call_ZGVbN2v_sin movapd 16(%rsp), %xmm2 movaps %xmm0, -16(%r14) movdqa (%rsp), %xmm0 movaps %xmm2, -32(%r14) cmpq%r14, %rbx jne .L4 program test interface pure function DSIN(x) bind(C, NAME="sin") use,intrinsic :: iso_c_binding ... Does that fix the issue?
[Bug c++/58372] internal compiler error: ix86_compute_frame_layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372 H.J. Lu changed: What|Removed |Added CC||xuepeng.guo at intel dot com --- Comment #19 from H.J. Lu --- Xuepeng, we investigated stack realignment on Windows when working on stack realignment. Can we take another look?
[Bug tree-optimization/87800] [9 Regression] CPU2006 416.gamess failed to build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87800 --- Comment #3 from Richard Biener --- Author: rguenth Date: Tue Oct 30 11:27:32 2018 New Revision: 265619 URL: https://gcc.gnu.org/viewcvs?rev=265619&root=gcc&view=rev Log: 2018-10-30 Richard Biener PR tree-optimization/87800 * tree-vect-slp.c (vect_build_slp_tree_2): Reject any non-induction or reduction PHIs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug tree-optimization/87800] [9 Regression] CPU2006 416.gamess failed to build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87800 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed.
[Bug fortran/87804] Omp simd loop with sin calls not vectorized when inside omp parallel region and the sin parameter uses value from shared array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87804 --- Comment #2 from Pavel Ondračka --- Wow, yeah that works, thank you so much. It's not very clear from your explanation if this is a bug or not after all... Feel free to close the bug if the omission of pure was a mistake on my end.
[Bug bootstrap/87747] [9 regression] Bootstrap failure if using gcc-4.6 as stage1 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87747 --- Comment #5 from Richard Earnshaw --- Author: rearnsha Date: Tue Oct 30 11:33:24 2018 New Revision: 265620 URL: https://gcc.gnu.org/viewcvs?rev=265620&root=gcc&view=rev Log: Don't allow the pool allocator to be configured to allocate zero-sized objects PR bootstrap/87747 would have been significantly easier to track down if the pool allocator had faulted an attempt to configure it to allocate zero-sized objects. Instead, this slipped through and we later hit memory corruption when the assumed size turned out to be different to the configured size. While, theoretically, there might be a use case for this, it seems unlikely to me that GCC would have such a use. So this patch adds a checking assert that the object size is not zero. * alloc-pool.h (base_pool_allocator ::initialize): Assert that the allocation size is not zero. Modified: trunk/gcc/ChangeLog trunk/gcc/alloc-pool.h
[Bug libstdc++/87809] New: Can't create empty std::optional>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87809
Bug ID: 87809
Summary: Can't create empty std::optional>
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Hello,
Following code snippet:
#include
#include
class Storage;
template
class MyAlloc
{
public:
using value_type = T;
value_type* allocate(size_t n);
void deallocate(value_type* p, size_t n);
MyAlloc(Storage& storage) noexcept;
};
void test()
{
std::optional>> opt;
}
compiles with GCC8, but fails with GCC9 trunk:
In file included from
/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/utility:68,
from
/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/optional:36,
from :1:
/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/bits/stl_vector.h:
In instantiation of 'std::_Vector_base<_Tp,
_Alloc>::_Vector_impl::_Vector_impl() [with _Tp = int; _Alloc = MyAlloc]':
/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/type_traits:925:12:
required from 'struct std::is_constructible >
>'
/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/type_traits:2881:25:
required from 'constexpr const bool std::is_constructible_v > >'
/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/optional:715:66:
required by substitution of 'template >, _Args&&
...>, bool>::type > constexpr std::_Optional_base >, false, false>::_Optional_base(std::in_place_t, _Args&& ...)
[with _Args = {}; typename std::enable_if >, _Args&& ...>, bool>::type = ]'
:20:50: required from here
/opt/compiler-explorer/gcc-trunk-20181028/include/c++/9.0.0/bits/stl_vector.h:128:17:
error: no matching function for call to 'MyAlloc::MyAlloc()'
128 | _Vector_impl() _GLIBCXX_NOEXCEPT_IF( noexcept(_Tp_alloc_type()) )
| ^~~~
:15:3: note: candidate: 'MyAlloc::MyAlloc(Storage&) [with T = int]'
15 | MyAlloc(Storage& storage) noexcept;
| ^~~
:15:3: note: candidate expects 1 argument, 0 provided
:7:7: note: candidate: 'constexpr MyAlloc::MyAlloc(const
MyAlloc&)'
7 | class MyAlloc
| ^~~
:7:7: note: candidate expects 1 argument, 0 provided
:7:7: note: candidate: 'constexpr
MyAlloc::MyAlloc(MyAlloc&&)'
:7:7: note: candidate expects 1 argument, 0 provided
Compiler returned: 1
[Bug c++/58372] internal compiler error: ix86_compute_frame_layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #20 from Uroš Bizjak --- Created attachment 44928 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44928&action=edit Proposed patch It turned out that functions, called directly through emit_library_call (as the above testcase, which builds call to _Unwind_SjLj_Register from sjlj_emit_function_enter) miss a whole lot of stack realignmnet setup. There is an update to crtl->preferred_stack_boundary, but several updates for SUPPORTS_STACK_ALIGNMENT targets are missing, including eventual DRAP setup. Attached patch fixes the path through emit_library_call. Can someone please test the patch on SJLJ target?
[Bug go/87810] New: go-test.exp needs an update for non-existing test exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87810 Bug ID: 87810 Summary: go-test.exp needs an update for non-existing test exceptions Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at debian dot org CC: cmang at google dot com Target Milestone: --- go-test.exp needs an update for non-existing test exceptions, it mentions meny tests/files which don't exist anymore.
[Bug c++/58372] internal compiler error: ix86_compute_frame_layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372 --- Comment #21 from xuepeng guo --- Thanks for fix. I am glad to help to test it out.
[Bug c/87811] New: [9 Regression] ICE with __builtin_expect_with_probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87811
Bug ID: 87811
Summary: [9 Regression] ICE with
__builtin_expect_with_probability
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
void bar (void);
void
foo (int i, double d)
{
if (__builtin_expect_with_probability (i, 0, d))
bar ();
}
ICEs at -O2:
internal compiler error: tree check: expected real_cst, have mult_expr in
expr_expected_value_1, at predict.c:2471
in both C and C++.
Either we need to early (+ in documentation) require that the last argument is
a floating point constant (e.g. in builtins.c folding error on the last arg not
being a REAL_CST), or we need to document what it means if the last argument is
a variable, whether we ignore the hint altogether or what else we do.
[Bug c/87811] [9 Regression] ICE with __builtin_expect_with_probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87811 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-30 Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug other/87802] [9 regression] g++.dg/vect/slp-pr87105.cc fails starting with r265522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87802 --- Comment #2 from Richard Biener --- Bah. Can you please attach preprocessed source and provide command-line flags? A simple cc1plus cross isn't enough it seems and I do not have a cross glibc to build a full cross.
[Bug testsuite/87802] [9 regression] g++.dg/vect/slp-pr87105.cc fails starting with r265522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87802 Richard Biener changed: What|Removed |Added Component|other |testsuite --- Comment #3 from Richard Biener --- Testsuite issue for sure.
[Bug fortran/87804] Omp simd loop with sin calls not vectorized when inside omp parallel region and the sin parameter uses value from shared array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87804 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Richard Biener --- .
[Bug c/87811] [9 Regression] ICE with __builtin_expect_with_probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87811 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Mine.
[Bug libstdc++/87809] [9 Regression] Can't create empty std::optional>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87809 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Known to work||8.2.0 Keywords||rejects-valid Last reconfirmed||2018-10-30 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Summary|Can't create empty |[9 Regression] Can't create |std::optional> |std::optional> Target Milestone|--- |9.0 Known to fail||9.0 --- Comment #1 from Jonathan Wakely --- mine
[Bug libstdc++/87809] [9 Regression] Can't create empty std::optional>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87809
--- Comment #2 from Jonathan Wakely ---
It affects other containers too:
#include
#include
#include
template
struct Alloc
{
using value_type = T;
T* allocate(unsigned n);
void deallocate(T* p, unsigned n);
Alloc(int) { }
template
Alloc(const Alloc&) { }
};
template
bool operator==(Alloc, Alloc) { return true; }
template
bool operator!=(Alloc, Alloc) { return false; }
constexpr bool b
= std::is_default_constructible>>::value;
constexpr bool c
= std::is_default_constructible>>::value;
constexpr bool d
= std::is_default_constructible>>::value;
constexpr bool e
= std::is_default_constructible>>::value;
[Bug libstdc++/87809] [8/9 Regression] Can't create empty std::optional>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87809 Jonathan Wakely changed: What|Removed |Added Known to work|8.2.0 |7.3.0 Target Milestone|9.0 |8.3 Summary|[9 Regression] Can't create |[8/9 Regression] Can't |empty |create empty |std::optional> |nt, CustomAlloc>> Known to fail||8.2.0 --- Comment #3 from Jonathan Wakely --- The vector, list and forward_list cases already fail with GCC 8 as well.
[Bug target/87812] New: X86-64 Vector __m256 return ABI needs clarification (discrepancy between implementations).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87812
Bug ID: 87812
Summary: X86-64 Vector __m256 return ABI needs clarification
(discrepancy between implementations).
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
For a processor that supports SSE, but not AVX.
the following code:
typedef int __attribute__((mode(QI))) qi;
typedef qi __attribute__((vector_size (32))) v32qi;
v32qi foo (int x)
{
v32qi y = {'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f',
'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'};
return y;
}
produces a warning " warning: AVX vector return without AVX enabled changes the
ABI [-Wpsabi]”.
so - the question is what is the resultant ABI in the changed case (since _m256
is supported for such processors)
Looking at the psABI v1.0
* pp24 Returning of Values
The returning of values is done according to the following algorithm:
• Classify the return type with the classification algorithm.
…
• If the class is SSE, the next available vector register of the
sequence %xmm0, %xmm1 is used.
• If the class is SSEUP, the eight byte is returned in the next
available eightbyte chunk of the last used vector register.
...
* classification algorithm : pp20
• Arguments of type __m256 are split into four eightbyte chunks. The
least significant one belongs to class SSE and all the others to class SSEUP.
• Arguments of type __m512 are split into eight eightbyte chunks. The
least significant one belongs to class SSE and all the others to class SSEUP.
* footnote on pp21
12 The post merger clean up described later ensures that, for the processors
that do not support the __m256 type, if the size of an object is larger than
two eightbytes and the first eightbyte is not SSE or any other eightbyte is not
SSEUP, it still has class MEMORY.
This in turn ensures that for processors that do support the __m256 type, if
the size of an object is four eightbytes and the first eightbyte is SSE and all
other eightbytes are SSEUP, it can be passed in a register. This also applies
to the __m512 type. That is for processors that support the __m512 type, if the
size of an object is eight eightbytes and the first eightbyte is SSE and all
other eightbytes are SSEUP, it can be passed in a register, otherwise, it will
be passed in memory.
---
However : the case where the processor does *not* support __m256 but the first
eightbyte *is* SSE and the following eighbytes *are* SSEUP is not clarified.
The intent for SSE seems clear - use a reg
The intent for following SSEUP is less clear.
Nevertheless, it seems to imply that the intent for processors with SSE that
the __m256 (and __m512) returns should be passed in xmm0:1(:3, maybe).
figure 3.4 pp23 does not clarify xmm* use for vector return at all - only
mentioning floating point.
= status
In any event, GCC passes the vec32 return in memory,
LLVM conversely passes it in xmm0:1 (at least for the versions I’ve tried).
which leads to an ABI discrepancy when GCC is used to build code on systems
based on LLVM.
Please could the X86 maintainers clarify the intent (and maybe consider
enhancing the footnote classification notes to make things clearer)?
- and then we can figure out how to deal with the systems that are already
implemented - and how to move forward.
(as an aside, in any event, it seems inefficient to pass through memory when at
least xmm0:1 are already set aside for return value use).
[Bug c++/58372] internal compiler error: ix86_compute_frame_layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372 --- Comment #22 from xuepeng guo --- (In reply to Uroš Bizjak from comment #20) > Created attachment 44928 [details] > Proposed patch > > It turned out that functions, called directly through emit_library_call (as > the above testcase, which builds call to _Unwind_SjLj_Register from > sjlj_emit_function_enter) miss a whole lot of stack realignmnet setup. There > is an update to crtl->preferred_stack_boundary, but several updates for > SUPPORTS_STACK_ALIGNMENT targets are missing, including eventual DRAP setup. > > Attached patch fixes the path through emit_library_call. > > Can someone please test the patch on SJLJ target? On an x86_64 Linux platform, I simply configured gcc with command: ../gcc/configure --enable-sjlj-exceptions Then with Uroš's patch, the gcc bootstrap has no problem and the case can be successfully compiled. I am doing the gcc regression test to make sure there is no regression with Uroš's patch, it will take some time to finish. I am also attempting to cross-build for i686-w64-mingw32 to verify for Comment #14. If I am missing something, please let me know. Thanks very much.
[Bug testsuite/87802] [9 regression] g++.dg/vect/slp-pr87105.cc fails starting with r265522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87802 --- Comment #4 from seurer at gcc dot gnu.org --- Created attachment 44929 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44929&action=edit assembler
[Bug testsuite/87802] [9 regression] g++.dg/vect/slp-pr87105.cc fails starting with r265522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87802 --- Comment #5 from seurer at gcc dot gnu.org --- Created attachment 44930 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44930&action=edit intermediate text
[Bug testsuite/87802] [9 regression] g++.dg/vect/slp-pr87105.cc fails starting with r265522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87802 --- Comment #6 from seurer at gcc dot gnu.org --- Created attachment 44931 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44931&action=edit preprocessed source
[Bug testsuite/87802] [9 regression] g++.dg/vect/slp-pr87105.cc fails starting with r265522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87802 --- Comment #7 from seurer at gcc dot gnu.org --- Various output files attached and here's a run with -v so you can see all the options: seurer@granola:~/gcc/build/gcc-test$ /home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../xg++ -v -B/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/vect/slp-pr87105.cc -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++14 -O2 -ftree-vectorize -fno-vect-cost-model -maltivec -mvsx -mno-allow-movmisalign -fdump-tree-slp-details -ffast-math -E -o ./slp-pr8105.i Reading specs from /home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../specs COLLECT_GCC=/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../xg++ Target: powerpc64-unknown-linux-gnu Configured with: /home/seurer/gcc/gcc-test/configure --prefix=/home/seurer/gcc/install/gcc-test --enable-languages=c,fortran,c++ --with-cpu=power7 --disable-bootstrap --disable-multilib --with-as=/home/seurer/binutils/install/binutils-2.26/bin/as --with-ld=/home/seurer/binutils/install/binutils-2.26/bin/ld Thread model: posix gcc version 9.0.0 20181026 (experimental) [trunk revision 265522] (GCC) COLLECT_GCC_OPTIONS='-fdiagnostics-color=never' '-v' '-B' '/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../' '-fno-diagnostics-show-caret' '-fno-diagnostics-show-line-numbers' '-nostdinc++' '-I' '/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu' '-I' '/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include' '-I' '/home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++' '-I' '/home/seurer/gcc/gcc-test/libstdc++-v3/include/backward' '-I' '/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util' '-fmessage-length=0' '-std=c++14' '-O2' '-ftree-vectorize' '-fvect-cost-model=unlimited' '-maltivec' '-mvsx' '-mno-allow-movmisalign' '-fdump-tree-slp-details' '-ffast-math' '-E' '-o' './slp-pr8105.i' '-shared-libgcc' '-mcpu=power7' /home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../cc1plus -E -quiet -nostdinc++ -v -I /home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I /home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I /home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++ -I /home/seurer/gcc/gcc-test/libstdc++-v3/include/backward -I /home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util -iprefix /home/seurer/gcc/build/gcc-test/gcc/../lib/gcc/powerpc64-unknown-linux-gnu/9.0.0/ -isystem /home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../include -isystem /home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../include-fixed -D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Asystem=linux -Asystem=unix -Asystem=posix /home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/vect/slp-pr87105.cc -o ./slp-pr8105.i -maltivec -mvsx -mno-allow-movmisalign -mcpu=power7 -std=c++14 -fdiagnostics-color=never -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fmessage-length=0 -ftree-vectorize -fvect-cost-model=unlimited -fdump-tree-slp-details -ffast-math -O2 ignoring nonexistent directory "/home/seurer/gcc/build/gcc-test/gcc/../lib/gcc/powerpc64-unknown-linux-gnu/9.0.0/include" ignoring nonexistent directory "/home/seurer/gcc/build/gcc-test/gcc/../lib/gcc/powerpc64-unknown-linux-gnu/9.0.0/include-fixed" ignoring nonexistent directory "/home/seurer/gcc/build/gcc-test/gcc/../lib/gcc/powerpc64-unknown-linux-gnu/9.0.0/../../../../powerpc64-unknown-linux-gnu/include" ignoring nonexistent directory "/home/seurer/gcc/build/gcc-test/gcc/../lib/gcc/../../lib/gcc/powerpc64-unknown-linux-gnu/9.0.0/include" ignoring nonexistent directory "/home/seurer/gcc/build/gcc-test/gcc/../lib/gcc/../../include" ignoring nonexistent directory "/home/seurer/gcc/build/gcc-test/gcc/../lib/gcc/../../lib/gcc/powerpc64-unknown-linux-gnu/9.0.0/include-fixed" ignoring nonexistent directory "/home/seurer/gcc/build/gcc-test/gcc/../lib/gcc/../../lib/gcc/powerpc64-unknown-linux-gnu/9.0.0/../../../../powerpc64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu /home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include /home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++ /home/seurer/gcc/gcc-test/libstdc++-v3/include/backward /home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util /home/seurer/gcc/build/gcc-t
[Bug middle-end/87813] New: sprintf pass calling evrp at -O0 and setting global ranges which affect strnlen expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813
Bug ID: 87813
Summary: sprintf pass calling evrp at -O0 and setting global
ranges which affect strnlen expansion
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
Target Milestone: ---
For gcc.c-torture/execute/builtins/strnlen.c at -Og, the -fprintf-return-value
pass does not change the IL, but is setting global range information, which in
turn, is affecting builtin strnlen expansion.
This is because AFAICT the sprintf pass calls evrp on the entire IL regardless
of its need:
edge
sprintf_dom_walker::before_dom_children (basic_block bb)
{
evrp_range_analyzer.enter (bb);
for (gimple_stmt_iterator si = gsi_start_bb (bb); !gsi_end_p (si); )
{
/* Iterate over statements, looking for function calls. */
gimple *stmt = gsi_stmt (si);
/* First record ranges generated by this statement. */
evrp_range_analyzer.record_ranges_from_stmt (stmt, false);
etc.
For example:
+Visiting statement:
+# USE = anything
+_1 = strnlen ("", r_0_3_17);
Notice this is the sprintf optimization pass, not the strlen pass. Setting
global ranges for these "peeks" into strnlen arguments causes changes in the
behavior of expand_builtin_strnlen():
wide_int min, max;
enum value_range_kind rng = get_range_info (bound, &min, &max);
if (rng != VR_RANGE)
return NULL_RTX;
etc.
This is similar to the discussion I started here, where Martin correctly
pointed out that it wasn't just warnings but printf optimizations which were
touching global range information:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00420.html
Further down thread, Jeff said he'd volunteer to fix this. I'm just
documenting it here, so we don't forget about it.
Meta question-- do we want to be running a full evrp at -O0 (or -Og in this
case)?
Thanks folks.
[Bug middle-end/87813] sprintf pass calling evrp at -O0 and setting global ranges which affect strnlen expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com, ||law at gcc dot gnu.org, ||msebor at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Aldy Hernandez --- Folks, I'm CCing you here as per the discussion started here: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00420.html As usual, thanks for your glorious feedback.
[Bug middle-end/87813] sprintf pass calling evrp at -O0 and setting global ranges which affect strnlen expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-30 CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com Ever confirmed|0 |1 --- Comment #2 from Jeffrey A. Law --- I thought I already had a bug for this... It's a known problem that I plan to fix during the bugfixing stage.
[Bug testsuite/87802] [9 regression] g++.dg/vect/slp-pr87105.cc fails starting with r265522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87802
--- Comment #8 from Richard Biener ---
Ah, ok.
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/vect/slp-pr87105.cc:98:1:
missed: not vectorized: bad data alignment in basic block.
looks like with the flags we do not support unaligned accesses. Removing
the -mno-allow-movmisalign flag fixes this.
Does the following work? If so please go ahead and install it.
Index: gcc/testsuite/g++.dg/vect/slp-pr87105.cc
===
--- gcc/testsuite/g++.dg/vect/slp-pr87105.cc(revision 265619)
+++ gcc/testsuite/g++.dg/vect/slp-pr87105.cc(working copy)
@@ -99,7 +99,7 @@ void quadBoundingBoxA(const Point bez[3]
// We should have if-converted everything down to straight-line code
// { dg-final { scan-tree-dump-times "" 1 "slp2" } }
-// { dg-final { scan-tree-dump-times "basic block part vectorized" 1 "slp2" }
}
+// { dg-final { scan-tree-dump-times "basic block part vectorized" 1 "slp2" {
xfail { { ! vect_element_align } && { ! vect_hw_misalign } } } } }
// It's a bit awkward to detect that all stores were vectorized but the
// following more or less does the trick
-// { dg-final { scan-tree-dump "vect_iftmp\[^\r\m\]* = MIN" "slp2" } }
+// { dg-final { scan-tree-dump "vect_iftmp\[^\r\m\]* = MIN" "slp2" { xfail { {
! vect_element_align } && { ! vect_hw_misalign } } } } }
[Bug middle-end/87813] sprintf pass calling evrp at -O0 and setting global ranges which affect strnlen expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813 --- Comment #3 from Richard Biener --- Why is the sprintf pass (-fprintf-return-value) even enabled at -O0?
[Bug middle-end/87813] sprintf pass calling evrp at -O0 and setting global ranges which affect strnlen expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813 --- Comment #4 from Aldy Hernandez --- (In reply to Richard Biener from comment #3) > Why is the sprintf pass (-fprintf-return-value) even enabled at -O0? Well, at -Og, but isn't that kinda sort-of the same thing?
[Bug testsuite/87802] [9 regression] g++.dg/vect/slp-pr87105.cc fails starting with r265522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87802 --- Comment #9 from seurer at gcc dot gnu.org --- Yes, it works with that patch.
[Bug target/87812] X86-64 Vector __m256 return ABI needs clarification (discrepancy between implementations).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87812 --- Comment #1 from H.J. Lu --- Without AVX, GCC treats typedef qi __attribute__((vector_size (32))) v32qi; as a type of 32 bytes, which is passed in memory. Clang does # clang -S -msse2 x.c -O2 ... movaps .LCPI0_0(%rip), %xmm0 # xmm0 = [48,49,50,51,52,53,54,55,56,57,97,98,99,100,101,102] movaps %xmm0, %xmm1 retq # clang -S -msse2 x.c -O2 -m32 ... movaps .LCPI0_0, %xmm0 # xmm0 = [48,49,50,51,52,53,54,55,56,57,97,98,99,100,101,102] movaps %xmm0, %xmm1 retl They look very odd to me. You either pass it as a vector or you don't. You can't have it both ways.
[Bug libstdc++/87809] [8/9 Regression] Can't create empty std::optional>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87809 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Tue Oct 30 14:49:43 2018 New Revision: 265626 URL: https://gcc.gnu.org/viewcvs?rev=265626&root=gcc&view=rev Log: PR libstdc++/87809 avoid invalid expressions in exception specifications If the allocator isn't default constructible then checking if the default constructor throws in an exception specification makes the declaration invalid. Use the type trait instead. PR libstdc++/87809 * include/bits/forward_list.h (_Fwd_list_impl::_Fwd_list_impl()): Use trait in exception-specification instead of possibly invalid expression. * include/bits/stl_bvector.h (_Bvector_impl::_Bvector_impl()): Likewise. * include/bits/stl_list.h (_List_impl::_List_impl()): Likewise. * include/bits/stl_vector.h (_Vector_impl::_Vector_impl()): Likewise. * testsuite/23_containers/forward_list/cons/87809.cc: New test. * testsuite/23_containers/list/cons/87809.cc: New test. * testsuite/23_containers/vector/bool/cons/87809.cc: New test. * testsuite/23_containers/vector/cons/87809.cc: New test. Added: trunk/libstdc++-v3/testsuite/23_containers/forward_list/cons/87809.cc trunk/libstdc++-v3/testsuite/23_containers/list/cons/87809.cc trunk/libstdc++-v3/testsuite/23_containers/vector/bool/cons/87809.cc trunk/libstdc++-v3/testsuite/23_containers/vector/cons/87809.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/forward_list.h trunk/libstdc++-v3/include/bits/stl_bvector.h trunk/libstdc++-v3/include/bits/stl_list.h trunk/libstdc++-v3/include/bits/stl_vector.h
[Bug libstdc++/87784] A bug in tr2::dynamic_bitset::find_first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87784 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Tue Oct 30 14:49:32 2018 New Revision: 265625 URL: https://gcc.gnu.org/viewcvs?rev=265625&root=gcc&view=rev Log: PR libstdc++/87784 fix dynamic_bitset::push_back Previously the _M_Nb member was incremented before calling _M_unchecked_set which meant that the bit being set was out of bounds. It either set the wrong bit in an allocated word, or accessed beyond the end of the allocated memory in the _M_w vector. The fix for the bug is to update the _M_Nb member after using it as an index. As an optimisation, when a new block needs to be appended the call to _M_unchecked_set can be avoided by appending a block with the least significant bit already set to the desired value. PR libstdc++/87784 * include/tr2/dynamic_bitset (dynamic_bitset::push_back): When there are no unused bits in the last block, append a new block with the right value so the bit doesn't need to be set. Only increment size after setting the new bit, not before. * testsuite/tr2/dynamic_bitset/pr87784.cc: New test. Added: trunk/libstdc++-v3/testsuite/tr2/dynamic_bitset/pr87784.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr2/dynamic_bitset
[Bug libstdc++/87784] A bug in tr2::dynamic_bitset::find_first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87784 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #3 from Jonathan Wakely --- Fixed for GCC 9.
[Bug target/85593] [7/8/9 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 --- Comment #11 from Richard Biener --- So somehow the consensus was that IPA-RA needs to be told what to do about naked functions. IPA-RA is new in GCC 5. I'm not sure whether there already exists a hook for targets to use.
[Bug fortran/85855] [7/8/9 Regression] (Maybe) uninitialized descriptor fields of an allocatable array component of a function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85855 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c/85870] [7/8/9 Regression][LTO1] ICE in linemap_line_start, at libcpp/line-map.c:794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/85925] [7/8/9 regression] Mis-compilation at -02, masking with 257 goes wrong in combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85925 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/86485] [7/8/9 Regression] "anonymous" maybe-uninitialized false positive with ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86485 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Blocks||24639 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug target/86487] [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/86569] [7/8 Regression] -Wnonnull-compare affects code generation since r233684
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86569 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/86575] [7/8/9 Regression] -Wimplicit-fallthrough affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/86669] [7/8/9 regression] Complete object constructor clone omits length for a c++11 braced initialiser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86669 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #2 from Richard Biener --- It sounds like invalid tree sharing.
[Bug c++/86823] [7/8/9 Regression] private member template struct/class is publicly accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86823 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/87812] X86-64 Vector __m256 return ABI needs clarification (discrepancy between implementations).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87812 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-30 Ever confirmed|0 |1 --- Comment #2 from Iain Sandoe --- (In reply to H.J. Lu from comment #1) > Without AVX, GCC treats > > typedef qi __attribute__((vector_size (32))) v32qi; > > as a type of 32 bytes, which is passed in memory. Clang does > > # clang -S -msse2 x.c -O2 > ... > movaps .LCPI0_0(%rip), %xmm0 # xmm0 = > [48,49,50,51,52,53,54,55,56,57,97,98,99,100,101,102] > movaps %xmm0, %xmm1 > retq > # clang -S -msse2 x.c -O2 -m32 > ... > movaps .LCPI0_0, %xmm0 # xmm0 = > [48,49,50,51,52,53,54,55,56,57,97,98,99,100,101,102] > movaps %xmm0, %xmm1 > retl > > They look very odd to me. You either pass it as a vector or you don't. > You can't have it both ways. (when there's no native size support on the hardware) breaking objects into pieces to pass in registers is IMO a reasonable ABI approach. However, I am not here to argue for one or the other - what's needed is a clear statement of the "correct" ABI ad then : * a bug filed against the implementation(s) which don't comply. * a plan to support the mismatch on systems "in the wild". I don't currently have access to icc (or other compilers) so no idea what they do. FWIW clang -mno-sse passes in memory as per the GCC code.
[Bug c++/86905] [7/8/9 Regression] g++ ICE on valid code: verify_cgraph_node failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86905 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/86944] [7/8/9 Regression] ICE in vectorizable_store, at tree-vect-stmts.c:6878 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86944 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/86988] [7 Regression] ICE: tree check: expected integer_cst, have var_decl in get_len, at tree.h:5563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86988 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/87047] [7/8/9 Regression] performance regression because of if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P2
[Bug tree-optimization/86944] [7/8/9 Regression] ICE in vectorizable_store, at tree-vect-stmts.c:6878 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86944 --- Comment #2 from Richard Biener --- I cannot reproduce this on trunk.
[Bug c++/87072] [7 Regression] g++6.2.0 false warning: array subscript is above array bounds, with misleading line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87072 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/87145] [7/8/9 Regression] Implicit conversion to scoped enum fails: "error: taking address of temporary/rvalue"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87145 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libitm/86293] unused variable left over (used in assert) when building with -g0 -DNDEBUG [-Werror=unused-variable]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86293 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #1 from Jeffrey A. Law --- Fixed on the trunk.
[Bug c++/87148] [7/8/9 Regression] backward compatibility issue to take char [] as incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87148 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Richard Biener --- Thus wontfix.
[Bug libstdc++/87809] [8/9 Regression] Can't create empty std::optional>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87809 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Fixed for GCC 8.3 and 9.x --- Comment #6 from Jonathan Wakely --- Author: redi Date: Tue Oct 30 15:15:56 2018 New Revision: 265629 URL: https://gcc.gnu.org/viewcvs?rev=265629&root=gcc&view=rev Log: PR libstdc++/87809 avoid invalid expressions in exception specifications If the allocator isn't default constructible then checking if the default constructor throws in an exception specification makes the declaration invalid. Use the type trait instead. Backport from mainline 2018-10-30 Jonathan Wakely PR libstdc++/87809 * include/bits/forward_list.h (_Fwd_list_impl::_Fwd_list_impl()): Use trait in exception-specification instead of possibly invalid expression. * include/bits/stl_bvector.h (_Bvector_impl::_Bvector_impl()): Likewise. * include/bits/stl_list.h (_List_impl::_List_impl()): Likewise. * testsuite/23_containers/forward_list/cons/87809.cc: New test. * testsuite/23_containers/list/cons/87809.cc: New test. * testsuite/23_containers/vector/bool/cons/87809.cc: New test. * testsuite/23_containers/vector/cons/87809.cc: New test. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/forward_list/cons/87809.cc branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/list/cons/87809.cc branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/vector/bool/cons/87809.cc branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/vector/cons/87809.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/bits/forward_list.h branches/gcc-8-branch/libstdc++-v3/include/bits/stl_bvector.h branches/gcc-8-branch/libstdc++-v3/include/bits/stl_list.h
[Bug libstdc++/87809] [8/9 Regression] Can't create empty std::optional>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87809 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Fixed for GCC 8.3 and 9.x
[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246 Richard Biener changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-30 Known to work||5.5.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed.
[Bug fortran/87430] [7/8/9 Regression] ICE in fortran/trans-types.c:1157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87430 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/87541] [7/8/9 Regression] ICE using a constant decl as an attribute alloc_size argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87541 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/87814] New: [9 Regression] ICE in in tsubst_copy, at cp/pt.c:15962 with range-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87814
Bug ID: 87814
Summary: [9 Regression] ICE in in tsubst_copy, at cp/pt.c:15962
with range-v3
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 44932
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44932&action=edit
Preprocessed repro
This program (preprocessed repro attached as repro.i.gz):
#include
#include
#include
int main() {
using namespace ranges;
auto f = [](int) { return iterator_range(); };
join_view> rng;
(void) rng.begin();
}
ICEs in tsubst_copy while instantiating a variadic inherited constructor
template that performs a "double" pack expansion, defined around line 43341 in
the repro.
[Bug c++/87148] [7/8/9 Regression] backward compatibility issue to take char [] as incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87148 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|NEW Resolution|WONTFIX |--- --- Comment #7 from Jonathan Wakely --- We still reject the example in comment 4, and should accept it. Reopening.
[Bug c++/87542] [7/8/9 Regression] bogus error on attribute format with a named constant argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87542 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/87812] X86-64 Vector __m256 return ABI needs clarification (discrepancy between implementations).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87812
--- Comment #3 from H.J. Lu ---
Without AVX, v32qi should be passed the same way before AVX was
added to compiler. For example,
[hjl@gnu-cfl-1 tmp]$ cat z.c
typedef int __attribute__((mode(SI))) si;
typedef si __attribute__((vector_size (128))) v;
v
foo (int x)
{
v y = {'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f',
'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'};
return y;
}
[hjl@gnu-cfl-1 tmp]$ gcc -S -O2 z.c
[hjl@gnu-cfl-1 tmp]$ cat z.s
.file "z.c"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movq%rdi, %rax
movl$48, (%rdi)
movl$49, 4(%rdi)
movl$50, 8(%rdi)
movl$51, 12(%rdi)
movl$52, 16(%rdi)
movl$53, 20(%rdi)
movl$54, 24(%rdi)
movl$55, 28(%rdi)
movl$56, 32(%rdi)
movl$57, 36(%rdi)
movl$97, 40(%rdi)
movl$98, 44(%rdi)
movl$99, 48(%rdi)
movl$100, 52(%rdi)
movl$101, 56(%rdi)
movl$102, 60(%rdi)
movl$48, 64(%rdi)
movl$49, 68(%rdi)
movl$50, 72(%rdi)
movl$51, 76(%rdi)
movl$52, 80(%rdi)
movl$53, 84(%rdi)
movl$54, 88(%rdi)
movl$55, 92(%rdi)
movl$56, 96(%rdi)
movl$57, 100(%rdi)
movl$97, 104(%rdi)
movl$98, 108(%rdi)
movl$99, 112(%rdi)
movl$100, 116(%rdi)
movl$101, 120(%rdi)
movl$102, 124(%rdi)
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 8.2.1 20181011 (Red Hat 8.2.1-4)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 tmp]$
If there were AVX1024, GCC would pass y in vector register. When AVX1024
were disabled, GCC would pass y in memory and issue an ABI change warning.
So LLVM is wrong.
[Bug middle-end/87647] [7/8 Regression] ICE on valid code in decode_addr_const, at varasm.c:2958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87647 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2 Summary|[7/8/9 Regression] ICE on |[7/8 Regression] ICE on |valid code in |valid code in |decode_addr_const, at |decode_addr_const, at |varasm.c:2958 |varasm.c:2958 --- Comment #5 from Richard Biener --- fixed on trunk
[Bug libstdc++/87787] [9 Regression] runtime error: null pointer passed as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87787 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2018-10-29 00:00:00 |2018-10-30 Ever confirmed|0 |1
[Bug target/87702] [7/8/9 Regression] Segfault in glibc if compiled with -march=amdfam10 -O2 (x86)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87702 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2
[Bug tree-optimization/86944] [7/8/9 Regression] ICE in vectorizable_store, at tree-vect-stmts.c:6878 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86944 Martin Liška changed: What|Removed |Added Keywords||needs-bisection Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Then let me bisect that.
[Bug middle-end/87813] sprintf pass calling evrp at -O0 and setting global ranges which affect strnlen expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813
--- Comment #5 from Martin Sebor ---
The sprintf pass doesn't do any optimization at -O0 but it still runs to
diagnose the subset of mistakes that are detectable even without optimization.
For instance, the buffer overflow due to the off-by-one error in the following
is diagnosed at -O0:
char a[8];
void f (void)
{
sprintf (a, "%s/%s", "dir", "file");
}
[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87330 Ramana Radhakrishnan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #9 from Ramana Radhakrishnan --- Fixed then ?
[Bug target/87812] X86-64 Vector __m256 return ABI needs clarification (discrepancy between implementations).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87812 --- Comment #4 from Iain Sandoe --- (In reply to H.J. Lu from comment #3) > Without AVX, v32qi should be passed the same way before AVX was > added to compiler. For example, > > If there were AVX1024, GCC would pass y in vector register. When AVX1024 > were disabled, GCC would pass y in memory and issue an ABI change warning. > So LLVM is wrong. As an ABI co-author, perhaps you would be kind enough to file a bug there then? --- For current affected systems (at least freeBSD 10+ and Darwin 11+ I'd say) we will have to figure some work-around.
