[Bug target/91135] [9 Regression] __linux__ not defined with -mcall-aixdesc on 9.x and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Alan Modra --- Fixed
[Bug target/91135] [9 Regression] __linux__ not defined with -mcall-aixdesc on 9.x and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135 --- Comment #11 from Alan Modra --- Author: amodra Date: Thu Aug 1 05:57:12 2019 New Revision: 273962 URL: https://gcc.gnu.org/viewcvs?rev=273962=gcc=rev Log: [RS6000] PR91135, __linux__ not defined with -mcall-aixdesc on 9.x and ppc64 This patch makes the obvious fix for PR91135, and deletes extraneous copies of GNU_USER_TARGET_D_OS_VERSIONS that appear in rs6000/linux.h and rs6000/linux64.h. Since all configurations using either of these files also include linux.h there is no need to duplicate the macro. PR target/91135 * config/rs6000/linux.h (GNU_USER_TARGET_D_OS_VERSIONS): Don't define. * config/rs6000/linux64.h (TARGET_OS_CPP_BUILTINS): Invoke GNU_USER_TARGET_OS_CPP_BUILTINS for aixdesc abi. (GNU_USER_TARGET_D_OS_VERSIONS): Don't define. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/rs6000/linux.h branches/gcc-9-branch/gcc/config/rs6000/linux64.h
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #22 from Xiong Hu XS Luo ---
(In reply to Xiong Hu XS Luo from comment #21)
> (In reply to H.J. Lu from comment #19)
> > (In reply to Richard Biener from comment #17)
> > > (In reply to Richard Biener from comment #16)
> > > > (In reply to Richard Biener from comment #15)
> > > > > Honza probably knows where we output the LTO symtab and why we do not
> > > > > put
> > > > > undefs for builtins there.
> > > >
> > > > #include
> > > > double y, z;
> > > > void foo ();
> > > > int main()
> > > > {
> > > > volatile double x = atan2 (y, z);
> > > > foo ();
> > > > }
> > > >
> > > > > gcc-8 -c t.c -flto
> > > > > gcc-nm t.o
> > > > U foo
> > > > T main
> > > > C y
> > > > C z
> > > >
> > > > where's the
> > > >
> > > > U atan2
> > > >
> > > > ?
> > >
> > > For
> > >
> > > double atan2 (double x, double y) { return x + y; }
> > >
> > > it doesn't appear either, this CU has an empty symbol table...
> > >
> > > I do remember quite some "funs" with builtin handling though, so the
> > > current handling may be the least bad of all choices...
> >
> > [hjl@gnu-cfl-1 pr91287]$ cat foo1.c
> > #include
> >
> > float
> > atan2f (float x, float y)
> > {
> > abort ();
> > return x * y;
> > }
> > [hjl@gnu-cfl-1 pr91287]$ cat foo.c
> > float
> > atan2f (float x, float y)
> > {
> > return x * y;
> > }
> > [hjl@gnu-cfl-1 pr91287]$ cat bar.c
> > #include
> >
> > extern float x, y, z;
> >
> > void
> > bar (void)
> > {
> > x = atan2f (y, z);
> > }
> > [hjl@gnu-cfl-1 pr91287]$ cat main.c
> > #include
> >
> > extern void bar (void);
> >
> > float x, y = 1, z =1;
> >
> > int
> > main (void)
> > {
> > x = atan2f (y, z);
> > bar ();
> > return 0;
> > }
> > [hjl@gnu-cfl-1 pr91287]$ make
> > cc -O3 -c -o foo.o foo.c
> > ar rc libfoo.a foo.o
> > cc -O3 -fpic -c -o bar.o bar.c
> > cc -O3 -fpic -c -o foo1.o foo1.c
> > ld -shared -o libfoo1.so foo1.o # --version-script foo1.v
> > ld -shared -o libbar.so bar.o libfoo1.so
> > cc -flto -O3 -o x main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
> > cc -O3 -o y main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
> > ./y
> > ./x
> > make: *** [Makefile:9: all] Aborted
> > [hjl@gnu-cfl-1 pr91287]$
> >
> > Since atan2f isn't referenced in IR, linker doesn't extract atan2f from
> > libfoo.a. atan2f is resolved to definition in libfoo1.so later.
> Thanks for your test case.
> If remove the libfoo1.so when build x, it will link libfoo.a. And run x will
> not abort.
>
> luoxhu@genoa pr91287 $ ~/local/gcc_t/bin/gcc -flto -O3 -o x main.c libfoo.a
> libbar.so -Wl,-R,.
> luoxhu@genoa pr91287 $ ./x
>
> Since x can link the libfoo.a if libfoo1.so not exists, not quite understand
> why "atan2f isn't referenced in IR"?
>
> Acutually my test case shows that binary built with LTO can link libmass.a
> first when use gcc, but failed to link libmass.a if use gfortran(link
> libm.so finally).
>
> PS: My test case (gcc LTO link libmass.a first) doesn't match with your case
> result(gcc LTO link libfoo1.so instead of libfoo.a).
BTW, the link sequence is quite important, switch libbar.so and libfoo.a, then
x will link atan2 in libfoo.a instead of libfoo1.so, which matches my test
case:
~/local/gcc_t/bin/gcc -flto -O3 -o x main.c libbar.so libfoo.a libfoo1.so
-Wl,-R,.
[Bug c++/91317] [7/8/9/10 Regression] false-positive maybe-uninitialized warning in destructor with placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91317 --- Comment #1 from Marc Glisse --- Did you consider exceptions? a() could throw.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #21 from Xiong Hu XS Luo ---
(In reply to H.J. Lu from comment #19)
> (In reply to Richard Biener from comment #17)
> > (In reply to Richard Biener from comment #16)
> > > (In reply to Richard Biener from comment #15)
> > > > Honza probably knows where we output the LTO symtab and why we do not
> > > > put
> > > > undefs for builtins there.
> > >
> > > #include
> > > double y, z;
> > > void foo ();
> > > int main()
> > > {
> > > volatile double x = atan2 (y, z);
> > > foo ();
> > > }
> > >
> > > > gcc-8 -c t.c -flto
> > > > gcc-nm t.o
> > > U foo
> > > T main
> > > C y
> > > C z
> > >
> > > where's the
> > >
> > > U atan2
> > >
> > > ?
> >
> > For
> >
> > double atan2 (double x, double y) { return x + y; }
> >
> > it doesn't appear either, this CU has an empty symbol table...
> >
> > I do remember quite some "funs" with builtin handling though, so the
> > current handling may be the least bad of all choices...
>
> [hjl@gnu-cfl-1 pr91287]$ cat foo1.c
> #include
>
> float
> atan2f (float x, float y)
> {
> abort ();
> return x * y;
> }
> [hjl@gnu-cfl-1 pr91287]$ cat foo.c
> float
> atan2f (float x, float y)
> {
> return x * y;
> }
> [hjl@gnu-cfl-1 pr91287]$ cat bar.c
> #include
>
> extern float x, y, z;
>
> void
> bar (void)
> {
> x = atan2f (y, z);
> }
> [hjl@gnu-cfl-1 pr91287]$ cat main.c
> #include
>
> extern void bar (void);
>
> float x, y = 1, z =1;
>
> int
> main (void)
> {
> x = atan2f (y, z);
> bar ();
> return 0;
> }
> [hjl@gnu-cfl-1 pr91287]$ make
> cc -O3 -c -o foo.o foo.c
> ar rc libfoo.a foo.o
> cc -O3 -fpic -c -o bar.o bar.c
> cc -O3 -fpic -c -o foo1.o foo1.c
> ld -shared -o libfoo1.so foo1.o # --version-script foo1.v
> ld -shared -o libbar.so bar.o libfoo1.so
> cc -flto -O3 -o x main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
> cc -O3 -o y main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
> ./y
> ./x
> make: *** [Makefile:9: all] Aborted
> [hjl@gnu-cfl-1 pr91287]$
>
> Since atan2f isn't referenced in IR, linker doesn't extract atan2f from
> libfoo.a. atan2f is resolved to definition in libfoo1.so later.
Thanks for your test case.
If remove the libfoo1.so when build x, it will link libfoo.a. And run x will
not abort.
luoxhu@genoa pr91287 $ ~/local/gcc_t/bin/gcc -flto -O3 -o x main.c libfoo.a
libbar.so -Wl,-R,.
luoxhu@genoa pr91287 $ ./x
Since x can link the libfoo.a if libfoo1.so not exists, not quite understand
why "atan2f isn't referenced in IR"?
Acutually my test case shows that binary built with LTO can link libmass.a
first when use gcc, but failed to link libmass.a if use gfortran(link libm.so
finally).
PS: My test case (gcc LTO link libmass.a first) doesn't match with your case
result(gcc LTO link libfoo1.so instead of libfoo.a).
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #20 from Xiong Hu XS Luo ---
(In reply to rguent...@suse.de from comment #11)
> On Wed, 31 Jul 2019, wschmidt at linux dot ibm.com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> >
> > --- Comment #10 from wschmidt at linux dot ibm.com ---
> > On 7/31/19 2:25 AM, rguenther at suse dot de wrote:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> > >
> > > --- Comment #9 from rguenther at suse dot de
> > > ---
> > > On Wed, 31 Jul 2019, luoxhu at cn dot ibm.com wrote:
> > >
> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> > >>
> > >> --- Comment #8 from Xiong Hu XS Luo ---
> > >> (In reply to Thomas Koenig from comment #6)
> > >>> (In reply to Xiong Hu XS Luo from comment #4)
> > >>>
> > /tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__':
> > :(.text+0x114): undefined reference to `_gfortran_st_write'
> > :(.text+0x12c): undefined reference to
> > `_gfortran_transfer_character_write'
> > >>> You're not linkging against libgfortran.
> > >>>
> > >>> Either use gfortran as command for compiling or linking, or
> > >>> add the appropriate libraries (-lgfortran -lquadmath) to
> > >>> the linking step.
> > >> Thanks Thomas and Richard. Sorry that I am not familiar with fortran.
> > >> The
> > >> regression was fixed by Martin's new change.
> > >>
> > >> The c code included math.h actually.
> > >>
> > >> cat atan2bashzowie.c
> > >> #include
> > >> #include
> > >> #include
> > >>
> > >> double __attribute__((noinline)) zowie (double x, double y, double z)
> > >> {
> > >> return atan2 (x * y, z);
> > >> }
> > >>
> > >> double __attribute__((noinline)) rand_finite_double (void)
> > >> {
> > >> union {
> > >> double d;
> > >> unsigned char uc[sizeof(double)];
> > >> } u;
> > >> do {
> > >> for (unsigned i = 0; i < sizeof u.uc; i++) {
> > >> u.uc[i] = (unsigned char) rand();
> > >> }
> > >> } while (!isfinite(u.d));
> > >> return u.d;
> > >> }
> > >>
> > >> int main ()
> > >> {
> > >> double a = rand_finite_double ();
> > >> printf ("%lf\n", zowie (a, 4.5, 2.2));
> > >> return 0;
> > >> }
> > >> cat build.sh
> > >> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> > >> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -lmass_simdp8 -lmassv -lmassvp8
> > >> -o a.out
> > >> nm a.out | grep atan2
> > >> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> > >> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv
> > >> -lmassvp8 -o
> > >> a.out
> > >> nm a.out | grep atan2
> > >> ./build.sh
> > >> 1700 T atan2
> > >> 1700 T _atan2
> > >> 17e0 T atan2
> > >> 17e0 T _atan2
> > > Err, but [_]atan2 are surely not vector variants. Also is massv a static
> > > library here? It looks more like you are not getting the code vectorized
> > > with -flto but without and both variants end up using massv (the -flto
> > > variant using the scalar atan2)?
> > >
> > > That said, you have to do more detailed analysis of what actually
> > > happens and what you _want_ to happen. The bugreport summary
> > > doesn't really match what you show.
> > >
> > Agree that there's some unnecessary confusion here. I think the
> > temporary ICE and the build issues obscured the original intent of the bug.
> >
> > There are two libraries provided with the MASS project. libmass
> > provides scalar replacements for corresponding libm scalar math
> > functions. libmassv provides the vectorized versions of those
> > functions. For this bug we are only concerned about libmass and scalar
> > math functions.
>
> OK, so -mveclibabi=mass isn't needed to reproduce the issue, nor is
> linking -lmassv or -lmass_smidp8 then I guess.
>
> > With the C version of the code, we correctly generate symbols atan2 and
> > _atan2 that will be satisfied by libmass. With the Fortran version of
> > the code and without -flto, we again generate symbols atan2f and _atan2f
> > that will be satisfied by libmass. When we add -flto to the Fortran
> > version of the code, we instead generate symbols for atan2f@@GLIBC_2.17,
> > disallowing libmass from satisfying them.
> >
> > We see different behavior in the "visibility" LTO pass between the C and
> > Fortran versions, which seems to be a clue.
>
> I see (on x86) atan2f being used for the fortran testcase since
> you are calling atan2 with real() arguments. If you do not use
> -fdefault-real-8 you are then comparing apples and oranges.
>
> Maybe MASS doesn't have any float variants?
update the fortran case to use real*8 to call atan2 instead of atan2f,
-mveclibabi=mass and -lmassv are unnecessary to reproduce it:
luoxhu@genoa lto $ cat hellofortran.f90
recursive subroutine square_cube(i,isquare,icube)
REAL*8 j
REAL*8, DIMENSION(0:1):: vector
integer, intent(in) :: i ! input
integer, intent(out) :: isquare,icube !
[Bug fortran/42546] ALLOCATED statement typo in the docs and for scalar variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42546 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #4 from kargl at gcc dot gnu.org --- I have a patch except for the doc fixes, which I'll nick from Tobias' 10 year old patch.
[Bug tree-optimization/91183] strlen of a strcpy result with a conditional source not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91183 --- Comment #7 from Martin Sebor --- Patch to handle the issue discussed in comment #6: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg0.html
[Bug tree-optimization/91315] missing strlen lower bound of a string known to be at least N characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91315 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg0.html
[Bug tree-optimization/91294] [10 Regression] wrong strlen result of a conditional with an offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91294 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg0.html
[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109 --- Comment #5 from Bernd Edlinger --- Created attachment 46654 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46654=edit untested patch It looks like update_scratch_ops creates a copy of the original scratch register, but the new scratch register has no working live range info. I don't know a correct solution for the underlying problem, but removing the assignment to reg_renumber seems to fix the test case.
[Bug c++/91317] New: [7/8/9/10 Regression] false-positive maybe-uninitialized warning in destructor with placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91317
Bug ID: 91317
Summary: [7/8/9/10 Regression] false-positive
maybe-uninitialized warning in destructor with
placement new
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: martindorey at gmail dot com
Target Milestone: ---
Sorry if this is already raised somewhere. I did try to search various ways.
$ cat D139927.cpp
#include
void* operator new(size_t, void* p) {
return p;
}
int a();
void d(int p);
struct U {
int p;
U()
: p(a()) {
}
~U() {
d(p);
}
};
void f() {
U lhs;
new () U;
}
$ g++-8 -c D139927.cpp -Wmaybe-uninitialized -O1
D139927.cpp: In function ‘void f()’:
D139927.cpp:18:10: warning: ‘lhs.U::p’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
d(p);
~^~~
$
Increasing -O, as suggested in one of the bugs I found, doesn't help.
godbolt.org's Compiler Explorer suggests it was a regression between 6.4 and
7.1 and abides in 9 and the latest trunk available over there. Sorry about the
#include but it gave me a portable size_t for the placement new, which I failed
to simplify away.
[Bug target/91189] 20% binary size regression in avr-gcc 9.1.0 from 8.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91189 --- Comment #2 from Georg-Johann Lay --- How did you conclude it's a target issue? Would you pinpoint where in the avr backend the problem is?
[Bug fortran/91316] New: Derived type finalization failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91316 Bug ID: 91316 Summary: Derived type finalization failing Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at hotmail dot com Target Milestone: --- Created attachment 46653 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46653=edit Code exhibiting behavior Some situations where derived type finalization is not working Tested with gfortran 5.4.0 and 9.1.0 Commented output: enter main DESTROY: -1 enter final_s1 DESTROY: -1 f1:1 DESTROY:1 exit final_s1 enter final_s2 DESTROY: -1 f2:2 DESTROY:2 exit final_s2 enter final_s3 *** * Expected initial finalization of the assignment target * Expected finalization of any temporaries created *** f3:3 DESTROY:3 exit final_s3 enter final_s4 f4:4 *** * Finalization does not get called at all *** exit final_s4 f0:0 DESTROY:0 exit main Thank you all for a great compiler! Best regards, José Rui
[Bug lto/91313] [10 regression] r273908 breaks lto on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91313 --- Comment #3 from Steve Kargl --- On Wed, Jul 31, 2019 at 10:04:17PM +, kargl at gcc dot gnu.org wrote: > This change appears to break FreeBSD as well. See > > https://gcc.gnu.org/ml/gcc-testresults/2019-07/msg03699.html > Yep, Verified with 'svn merge -r 273908:273907 .' and a rebuild of the tree.
[Bug lto/91313] [10 regression] r273908 breaks lto on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91313 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- This change appears to break FreeBSD as well. See https://gcc.gnu.org/ml/gcc-testresults/2019-07/msg03699.html
[Bug c/91312] -Wconversion warning with += operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91312 --- Comment #3 from Kostas Sotiropoulos --- (In reply to Andrew Pinski from comment #2) > THis is not a bug, In C, "i += MACRO;" is equivant to: > i = i + MACRO. > And since you are using a type smaller than int, it is prompted to int. > > NOTE there might be another bug associated with this one. 1)In order to remove the warning we should only do the following: i = (unsigned char)(i + MACRO)? 2)Why if we want to cast like this: i += (unsigned char)MACRO, i on the right side of expression is not also casted to unsigned char (I mean the second i of expanded expression i = i + MACRO? 3)What do you mean with your NOTE can you please elaborate a bit more? 4) If we expand and cast the expression we will probably have not so optimized produced code by the compiler, should we? Thank you, Kostas
[Bug libstdc++/51333] [7/8 Regression] cxxabi.h incompatible with -fkeep-inline-functions at link time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51333 Jonathan Wakely changed: What|Removed |Added Summary|[7/8/9 Regression] cxxabi.h |[7/8 Regression] cxxabi.h |incompatible with |incompatible with |-fkeep-inline-functions at |-fkeep-inline-functions at |link time |link time --- Comment #11 from Jonathan Wakely --- Also fixed for 9.2
[Bug libstdc++/91308] [7/8/9 Regression] unique_ptr assignment fails with different deleters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91308 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Wed Jul 31 19:56:08 2019 New Revision: 273947 URL: https://gcc.gnu.org/viewcvs?rev=273947=gcc=rev Log: PR libstdc++/91308 fix constraints on unique_ptr assignment Backport from mainline 2019-07-31 Jonathan Wakely PR libstdc++/91308 * include/bits/unique_ptr.h (unique_ptr::__safe_conversion_up): Remove constraints on deleter that should only apply to the constructor. (unique_ptr::__safe_conversion_up): Likewise. (unique_ptr::unique_ptr(unique_ptr&&)): Restore constraints on deleter here. * testsuite/20_util/unique_ptr/assign/91308.cc: New test. Added: branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/unique_ptr/assign/91308.cc Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/include/bits/unique_ptr.h
[Bug libstdc++/51333] [7/8/9 Regression] cxxabi.h incompatible with -fkeep-inline-functions at link time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51333 --- Comment #10 from Jonathan Wakely --- Author: redi Date: Wed Jul 31 19:56:04 2019 New Revision: 273946 URL: https://gcc.gnu.org/viewcvs?rev=273946=gcc=rev Log: PR libstdc++/51333 Define recursive_init_error constructor non-inline The recursive_init_error class is defined in a header, with an inline constructor, but the definition of the vtable and destructor are not exported from the shared library. With -fkeep-inline-functions the constructor gets emitted in user code, and requires the (non-exported) vtable. This fails to link. As far as I can tell, the recursive_init_error class definition was moved into so it could be documented with Doxygen, not for any technical reason. But now it's there (and documented), somebody could be relying on it, by catching that type and possibly performing derived-to-base conversions to the std::exception base class. So the conservative fix is to leave the class definition in the header but make the constructor non-inline. This still allows the type to be caught and still defines its base class. Backport from mainline 2019-07-29 Jonathan Wakely PR libstdc++/51333 * libsupc++/cxxabi.h (__gnu_cxx::recursive_init_error): Do not define constructor inline. * libsupc++/guard_error.cc (__gnu_cxx::recursive_init_error): Define constructor. * testsuite/18_support/51333.cc: New test. Added: branches/gcc-9-branch/libstdc++-v3/testsuite/18_support/51333.cc Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/libsupc++/cxxabi.h branches/gcc-9-branch/libstdc++-v3/libsupc++/guard_error.cc
[Bug tree-optimization/91315] missing strlen lower bound of a string known to be at least N characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91315 Martin Sebor changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-07-31 Blocks||83819 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- I have a simple patch. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 [Bug 83819] [meta-bug] missing strlen optimizations
[Bug tree-optimization/91315] New: missing strlen lower bound of a string known to be at least N characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91315
Bug ID: 91315
Summary: missing strlen lower bound of a string known to be at
least N characters
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In the program below the strlen pass tracks the (minimum) length of the string
formed by each of the functions, yet it doesn't expose that information to
downstream passes that could fold each of the tests to false on that basis.
$ cat z.c && gcc -O2 -Wall -S -fdump-tree-optimized=/dev/stdout z.c
char a[8];
void f0 (void)
{
a[0] = '1';
a[1] = '2';
if (__builtin_strlen (a) < 2)
__builtin_abort ();
}
void f1 (void)
{
__builtin_memcpy (a, "123", 3);
if (__builtin_strlen (a) < 3)
__builtin_abort ();
}
void f2 (void)
{
*__builtin_stpcpy (a, "123") = '4';
if (__builtin_strlen (a) < 4)
__builtin_abort ();
}
;; Function f0 (f0, funcdef_no=0, decl_uid=1909, cgraph_uid=1, symbol_order=1)
f0 ()
{
long unsigned int _1;
[local count: 1073741824]:
MEM [(char *)] = 12849;
_1 = __builtin_strlen ();
if (_1 <= 1)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return;
}
;; Function f1 (f1, funcdef_no=1, decl_uid=1912, cgraph_uid=2, symbol_order=2)
f1 ()
{
long unsigned int _1;
[local count: 1073741824]:
__builtin_memcpy (, "123", 3);
_1 = __builtin_strlen ();
if (_1 <= 2)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return;
}
;; Function f2 (f2, funcdef_no=2, decl_uid=1915, cgraph_uid=3, symbol_order=3)
f2 ()
{
long unsigned int _1;
[local count: 1073741824]:
__builtin_memcpy (, "123", 3);
MEM[(char *) + 3B] = 52;
_1 = __builtin_strlen ();
if (_1 <= 3)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return;
}
[Bug c++/91314] New: Confusing warning refers to nonexistent comma operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91314
Bug ID: 91314
Summary: Confusing warning refers to nonexistent comma operator
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
Test case:
int main() {
int a;
&(a=0);
}
Demonstration:
$ g++ -c -Wunused-value confusing_warning.cpp
confusing_warning.cpp: In function ‘int main()’:
confusing_warning.cpp:3:7: warning: right operand of comma operator has no
effect [-Wunused-value]
3 | &(a=0);
| ^
The problem: The warning refers to a comma operator that does not
exist in the source.
Speculation (please ignore this if it's not useful):
The compiler internally generates some internal data structure that's
similar to a comma operator (something like `(a=0), `) and the
warning message is based on that.
I've reproduced this problem with all versions of g++ I have access
to, from 4.1.2 to 10.0.0 20190718 (experimental).
This problem was originally reported by Stefan Ram
on comp.lang.c++, 2019-07-24, thread "why can't I apply a bitwise modifier
directly in a function call?".
[Bug c++/91264] modifying const-qual object in constexpr context not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91264 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #4 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01914.html
[Bug target/89746] powerpc-none-eabi-gcc emits code using stfiwx to misaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Segher Boessenkool --- It's not a regression, so I won't backport it to GCC 8 (and older).
[Bug lto/91313] [10 regression] r273908 breaks lto on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91313 --- Comment #1 from seurer at gcc dot gnu.org --- I tried this on a different power7 system and it worked OK there. The failing system is running Fedora 28. The one that worked Red hat 6.10. Maybe it is distro related? I will try a couple of others.
[Bug c++/90538] [9/10 Regression] Redeclaration error when expanding parameter pack multiple times in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90538 --- Comment #2 from Jason Merrill --- Author: jason Date: Wed Jul 31 18:50:00 2019 New Revision: 273944 URL: https://gcc.gnu.org/viewcvs?rev=273944=gcc=rev Log: PR c++/90538 - multiple expansions of capture packs Previously, with init-capture the type of the closure field was a DECLTYPE_TYPE of the initializer. But since each time we tsubst a lambda we get a different lambda, that meant that if the initializer is a lambda, we'd end up with different closure types in the field and initializer after substitution (PR 87322). We dealt with this by remembering the lambda instantiation within each pack expansion element, using local_specialization_stack to separate the elements. But that broke this testcase, because it lost lambda capture proxies that also use local_specializations. So, this patch removes the local_specializations changes from that patch and fixes 87322 differently, by giving init-capture fields 'auto' type and doing deduction later. There's a bit of a kludge to get the right number of fields by pretending that 'auto...' uses the parameter packs from the initializer, but it does the trick. * cp-tree.h (DECLTYPE_FOR_INIT_CAPTURE): Remove. * lambda.c (add_capture): Copy parameter packs from init. (lambda_capture_field_type): Always use auto for init-capture. * pt.c (uses_parameter_packs): Return tree. (tsubst) [DECLTYPE_TYPE]: Remove init-capture handling. (gen_elem_of_pack_expansion_instantiation): Don't push local_specialization_stack. (prepend_one_capture): New. (tsubst_lambda_expr): Use it. Don't touch local_specializations. (do_auto_deduction): Avoid redundant error. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/lambda.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/cpp0x/range-for19.C trunk/gcc/testsuite/g++.dg/cpp1y/lambda-init16.C
[Bug lto/91313] [10 regression] r273908 breaks lto on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91313 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-07-31 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug rtl-optimization/88233] combine fails to merge insns leaving unneeded reg copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88233 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Segher Boessenkool --- Fixed on trunk; no backports planned.
[Bug lto/91313] New: [10 regression] r273908 breaks lto on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91313 Bug ID: 91313 Summary: [10 regression] r273908 breaks lto on power 7 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- r273908 | marxin | 2019-07-30 08:45:11 -0500 (Tue, 30 Jul 2019) | 11 lines Deduce automatically number of cores for -flto option. 2019-07-30 Martin Liska * doc/invoke.texi: Document new behavior. * lto-wrapper.c (cpuset_popcount): New function is a copy of libgomp/config/linux/proc.c. (init_num_threads): Likewise. (run_gcc): Automatically detect core count for -flto. (jobserver_active_p): New function. Maybe the automatic core detection isn't working right on power 7? Note that it seems to work OK on power 8 and 9. The errors all look like this: Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ c_lto_2008_0.o c_lto_2008_1.o -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin -o gcc-dg-lto-2008-21.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ c_lto_2008_0.o c_lto_2008_1.o -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin -o gcc-dg-lto-2008-21.exe make[4]: *** write jobserver: Bad file descriptor. Stop. make[4]: *** Waiting for unfinished jobs make[4]: *** write jobserver: Bad file descriptor. Stop. lto-wrapper: fatal error: make returned 2 exit status compilation terminated. collect2: fatal error: lto-wrapper returned 1 exit status compilation terminated. compiler exited with status 1 FAIL: gcc.dg/lto/2008 c_lto_2008_0.o-c_lto_2008_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20090213 c_lto_20090213_0.o-c_lto_20090213_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20081222 c_lto_20081222_0.o-c_lto_20081222_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20081125 c_lto_20081125_0.o-c_lto_20081125_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gfortran.dg/lto/20091015-1 f_lto_20091015-1_0.o-f_lto_20091015-1_2.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20090213 c_lto_20090213_0.o-c_lto_20090213_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20081222 c_lto_20081222_0.o-c_lto_20081222_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20090812 c_lto_20090812_0.o-c_lto_20090812_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20081125 c_lto_20081125_0.o-c_lto_20081125_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gfortran.dg/lto/20091015-1 f_lto_20091015-1_0.o-f_lto_20091015-1_2.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20090812 c_lto_20090812_0.o-c_lto_20090812_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20091017-1 c_lto_20091017-1_0.o-c_lto_20091017-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081127 cp_lto_20081127_0.o-cp_lto_20081127_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20091017-1 c_lto_20091017-1_0.o-c_lto_20091017-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20090218-1 c_lto_20090218-1_0.o-c_lto_20090218-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20100227-1 c_lto_20100227-1_0.o-c_lto_20100227-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20090218-1 c_lto_20090218-1_0.o-c_lto_20090218-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/2008 c_lto_2008_0.o-c_lto_2008_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gcc.dg/lto/20100227-1 c_lto_20100227-1_0.o-c_lto_20100227-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: gfortran.dg/lto/pr40724 f_lto_pr40724_0.o-f_lto_pr40724_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL:
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 Peter Bergner changed: What|Removed |Added Status|NEW |RESOLVED URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-07/msg01899.ht ||ml Resolution|--- |FIXED --- Comment #16 from Peter Bergner --- Fixed.
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 --- Comment #15 from Peter Bergner --- Author: bergner Date: Wed Jul 31 17:18:40 2019 New Revision: 273941 URL: https://gcc.gnu.org/viewcvs?rev=273941=gcc=rev Log: PR target/91050 * config/rs6000/rs6000.opt (mdejagnu-cpu=): Delete option. * config/rs6000/rs6000.c (rs6000_option_override_internal): Remove use of deleted rs6000_dejagnu_cpu_index variable. * config/rs6000/rs6000.h (DRIVER_SELF_SPECS): Define. (SUBTARGET_DRIVER_SELF_SPECS): Likewise. * config/darwin.h (DRIVER_SELF_SPECS): Rename from this ... (SUBTARGET_DRIVER_SELF_SPECS): ...to this. * config/i386/i386.h (DRIVER_SELF_SPECS): Define. (SUBTARGET_DRIVER_SELF_SPECS): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h trunk/gcc/config/i386/i386.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h trunk/gcc/config/rs6000/rs6000.opt
[Bug c/91312] -Wconversion warning with += operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91312 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #2 from Andrew Pinski --- THis is not a bug, In C, "i += MACRO;" is equivant to: i = i + MACRO. And since you are using a type smaller than int, it is prompted to int. NOTE there might be another bug associated with this one.
[Bug c/91312] -Wconversion warning with += operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91312
--- Comment #1 from Kostas Sotiropoulos ---
Hi,
When compiling the following code snippet with gcc 8.3.0
with -Werror=conversion option:
#include
#define MACRO 1
int main(void)
{
unsigned char i;
i += MACRO;
return i;
}
the following warning which is treated as an error is reported:
test.c:3:15: error: conversion from ‘int’ to ‘unsigned char’ may change value
[-Werror=conversion]
#define MACRO 1
^
test.c:9:7: note: in expansion of macro ‘MACRO’
i += MACRO;
^
cc1: some warnings being treated as errors
Should this happen?
From what is described about -Wconversion under the following link:
https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc.pdf I am not convinced
that even with casting the right hand of expression this problem should
still appear on this case. Please check this statement:
"Do not warn for explicit casts likeabs ((int) x)andui= (unsigned) -1,
or if the value is not changed by the conversion like inabs(2.0)."
The only solution to this issue is to expand += and then cast to unsigned
char i.e. i = (unsigned char) (i + MACRO)? Should not we be more flexible
on cases of MACRO's even here that integer promotion takes place?
Thank you,
Kostas
[Bug c/91312] New: -Wconversion warning with += operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91312 Bug ID: 91312 Summary: -Wconversion warning with += operator Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kosotiro at yahoo dot gr Target Milestone: ---
[Bug ada/91169] [10 regression] cd2a31a FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91169 --- Comment #8 from Eric Botcazou --- The patch totally overlooks that the index can wrap around during the traversal of the CONSTRUCTOR: if (index_type) index = wi::ext (index, TYPE_PRECISION (index_type), TYPE_SIGN (index_type)); so the new comparison code cannot reasonably work...
[Bug ada/87100] FAIL: gnat.dg/config_pragma1.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87100 John David Anglin changed: What|Removed |Added Last reconfirmed|2019-03-10 00:00:00 |2019-7-31 CC||helge.deller at sap dot com --- Comment #2 from John David Anglin --- On linux, this message is seen on console: mmap: config_pragma1. (14628): VmData 1018527744 exceed data ulimit 524288000. Update limits or use boot option ignore_rlimit_data. Nominally, ulimit says unlimited. So, I'm not sure where the limit comes from.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #19 from H.J. Lu ---
(In reply to Richard Biener from comment #17)
> (In reply to Richard Biener from comment #16)
> > (In reply to Richard Biener from comment #15)
> > > Honza probably knows where we output the LTO symtab and why we do not put
> > > undefs for builtins there.
> >
> > #include
> > double y, z;
> > void foo ();
> > int main()
> > {
> > volatile double x = atan2 (y, z);
> > foo ();
> > }
> >
> > > gcc-8 -c t.c -flto
> > > gcc-nm t.o
> > U foo
> > T main
> > C y
> > C z
> >
> > where's the
> >
> > U atan2
> >
> > ?
>
> For
>
> double atan2 (double x, double y) { return x + y; }
>
> it doesn't appear either, this CU has an empty symbol table...
>
> I do remember quite some "funs" with builtin handling though, so the
> current handling may be the least bad of all choices...
[hjl@gnu-cfl-1 pr91287]$ cat foo1.c
#include
float
atan2f (float x, float y)
{
abort ();
return x * y;
}
[hjl@gnu-cfl-1 pr91287]$ cat foo.c
float
atan2f (float x, float y)
{
return x * y;
}
[hjl@gnu-cfl-1 pr91287]$ cat bar.c
#include
extern float x, y, z;
void
bar (void)
{
x = atan2f (y, z);
}
[hjl@gnu-cfl-1 pr91287]$ cat main.c
#include
extern void bar (void);
float x, y = 1, z =1;
int
main (void)
{
x = atan2f (y, z);
bar ();
return 0;
}
[hjl@gnu-cfl-1 pr91287]$ make
cc -O3 -c -o foo.o foo.c
ar rc libfoo.a foo.o
cc -O3 -fpic -c -o bar.o bar.c
cc -O3 -fpic -c -o foo1.o foo1.c
ld -shared -o libfoo1.so foo1.o # --version-script foo1.v
ld -shared -o libbar.so bar.o libfoo1.so
cc -flto -O3 -o x main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
cc -O3 -o y main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
./y
./x
make: *** [Makefile:9: all] Aborted
[hjl@gnu-cfl-1 pr91287]$
Since atan2f isn't referenced in IR, linker doesn't extract atan2f from
libfoo.a. atan2f is resolved to definition in libfoo1.so later.
[Bug sanitizer/91311] __attribute__ ((aligned (128))) results in stack-use-after-scope and stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91311 --- Comment #1 from Konstantin Kharlamov --- Created attachment 46652 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46652=edit rr record for the testcase, results in stack-use-after-scope I'm also attaching the `rr` record for the testcase resulting in `stack-use-after-scope`. To run it, unpack the directory, and execute: rr replay asan_testcase-0 gdb prompt gonna appear, just type `continue`.
[Bug tree-optimization/91145] [9 Regression] ICE: in vect_build_slp_tree_2, at tree-vect-slp.c:1143 with -march=skylake-avx512 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91145 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.1.1 Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/91162] [7/8 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:86 (error: invalid 'PHI' argument)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91162 Richard Biener changed: What|Removed |Added Known to work||9.1.1 Target Milestone|9.2 |7.5 Summary|[9 Regression] ICE: tree|[7/8 Regression] ICE: tree |check: expected class |check: expected class |'type', have 'exceptional' |'type', have 'exceptional' |(error_mark) in |(error_mark) in |useless_type_conversion_p, |useless_type_conversion_p, |at gimple-expr.c:86 (error: |at gimple-expr.c:86 (error: |invalid 'PHI' argument) |invalid 'PHI' argument) --- Comment #7 from Richard Biener --- Latent, so exploring further backport.
[Bug tree-optimization/91162] [9 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:86 (error: invalid 'PHI' argument)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91162 --- Comment #6 from Richard Biener --- Author: rguenth Date: Wed Jul 31 15:40:36 2019 New Revision: 273939 URL: https://gcc.gnu.org/viewcvs?rev=273939=gcc=rev Log: 2019-07-31 Richard Biener Backport from mainline 2019-07-19 Richard Biener PR tree-optimization/91200 * tree-ssa-phiopt.c (cond_store_replacement): Check we have no PHI nodes in middle-bb. * gcc.dg/torture/pr91200.c: New testcase. 2019-07-15 Richard Biener PR middle-end/91162 * tree-cfg.c (move_block_to_fn): When releasing a virtual PHI node make sure to replace all uses with something valid. * gcc.dg/autopar/pr91162.c: New testcase. 2019-07-12 Richard Biener PR tree-optimization/91145 * tree-vect-slp.c (vect_build_slp_tree_2): Fix reduction chain check. * gcc.dg/torture/pr91145.c: New testcase. 2019-07-11 Richard Biener PR middle-end/91131 * gimplify.c (gimplify_compound_literal_expr): Force a temporary when the object is volatile and we have not cleared it even though there are no nonzero elements. * gcc.target/i386/pr91131.c: New testcase. 2019-07-10 Richard Biener PR tree-optimization/91126 * tree-ssa-sccvn.c (n_walk_cb_data::push_partial_def): Adjust native encoding offset for BYTES_BIG_ENDIAN. (vn_reference_lookup_3): Likewise. * gcc.dg/torture/pr91126.c: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91126.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91145.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91200.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr91131.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/gimplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-cfg.c branches/gcc-9-branch/gcc/tree-ssa-phiopt.c branches/gcc-9-branch/gcc/tree-ssa-sccvn.c branches/gcc-9-branch/gcc/tree-vect-slp.c
[Bug tree-optimization/91145] [9 Regression] ICE: in vect_build_slp_tree_2, at tree-vect-slp.c:1143 with -march=skylake-avx512 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91145 --- Comment #4 from Richard Biener --- Author: rguenth Date: Wed Jul 31 15:40:36 2019 New Revision: 273939 URL: https://gcc.gnu.org/viewcvs?rev=273939=gcc=rev Log: 2019-07-31 Richard Biener Backport from mainline 2019-07-19 Richard Biener PR tree-optimization/91200 * tree-ssa-phiopt.c (cond_store_replacement): Check we have no PHI nodes in middle-bb. * gcc.dg/torture/pr91200.c: New testcase. 2019-07-15 Richard Biener PR middle-end/91162 * tree-cfg.c (move_block_to_fn): When releasing a virtual PHI node make sure to replace all uses with something valid. * gcc.dg/autopar/pr91162.c: New testcase. 2019-07-12 Richard Biener PR tree-optimization/91145 * tree-vect-slp.c (vect_build_slp_tree_2): Fix reduction chain check. * gcc.dg/torture/pr91145.c: New testcase. 2019-07-11 Richard Biener PR middle-end/91131 * gimplify.c (gimplify_compound_literal_expr): Force a temporary when the object is volatile and we have not cleared it even though there are no nonzero elements. * gcc.target/i386/pr91131.c: New testcase. 2019-07-10 Richard Biener PR tree-optimization/91126 * tree-ssa-sccvn.c (n_walk_cb_data::push_partial_def): Adjust native encoding offset for BYTES_BIG_ENDIAN. (vn_reference_lookup_3): Likewise. * gcc.dg/torture/pr91126.c: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91126.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91145.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91200.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr91131.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/gimplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-cfg.c branches/gcc-9-branch/gcc/tree-ssa-phiopt.c branches/gcc-9-branch/gcc/tree-ssa-sccvn.c branches/gcc-9-branch/gcc/tree-vect-slp.c
[Bug tree-optimization/91200] ICE on valid code at -O1: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91200 --- Comment #4 from Richard Biener --- Author: rguenth Date: Wed Jul 31 15:40:36 2019 New Revision: 273939 URL: https://gcc.gnu.org/viewcvs?rev=273939=gcc=rev Log: 2019-07-31 Richard Biener Backport from mainline 2019-07-19 Richard Biener PR tree-optimization/91200 * tree-ssa-phiopt.c (cond_store_replacement): Check we have no PHI nodes in middle-bb. * gcc.dg/torture/pr91200.c: New testcase. 2019-07-15 Richard Biener PR middle-end/91162 * tree-cfg.c (move_block_to_fn): When releasing a virtual PHI node make sure to replace all uses with something valid. * gcc.dg/autopar/pr91162.c: New testcase. 2019-07-12 Richard Biener PR tree-optimization/91145 * tree-vect-slp.c (vect_build_slp_tree_2): Fix reduction chain check. * gcc.dg/torture/pr91145.c: New testcase. 2019-07-11 Richard Biener PR middle-end/91131 * gimplify.c (gimplify_compound_literal_expr): Force a temporary when the object is volatile and we have not cleared it even though there are no nonzero elements. * gcc.target/i386/pr91131.c: New testcase. 2019-07-10 Richard Biener PR tree-optimization/91126 * tree-ssa-sccvn.c (n_walk_cb_data::push_partial_def): Adjust native encoding offset for BYTES_BIG_ENDIAN. (vn_reference_lookup_3): Likewise. * gcc.dg/torture/pr91126.c: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91126.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91145.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91200.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr91131.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/gimplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-cfg.c branches/gcc-9-branch/gcc/tree-ssa-phiopt.c branches/gcc-9-branch/gcc/tree-ssa-sccvn.c branches/gcc-9-branch/gcc/tree-vect-slp.c
[Bug tree-optimization/91126] [7/8/9 regression] Incorrect constant propagation of BIT_FIELD_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91126 --- Comment #10 from Richard Biener --- Author: rguenth Date: Wed Jul 31 15:40:36 2019 New Revision: 273939 URL: https://gcc.gnu.org/viewcvs?rev=273939=gcc=rev Log: 2019-07-31 Richard Biener Backport from mainline 2019-07-19 Richard Biener PR tree-optimization/91200 * tree-ssa-phiopt.c (cond_store_replacement): Check we have no PHI nodes in middle-bb. * gcc.dg/torture/pr91200.c: New testcase. 2019-07-15 Richard Biener PR middle-end/91162 * tree-cfg.c (move_block_to_fn): When releasing a virtual PHI node make sure to replace all uses with something valid. * gcc.dg/autopar/pr91162.c: New testcase. 2019-07-12 Richard Biener PR tree-optimization/91145 * tree-vect-slp.c (vect_build_slp_tree_2): Fix reduction chain check. * gcc.dg/torture/pr91145.c: New testcase. 2019-07-11 Richard Biener PR middle-end/91131 * gimplify.c (gimplify_compound_literal_expr): Force a temporary when the object is volatile and we have not cleared it even though there are no nonzero elements. * gcc.target/i386/pr91131.c: New testcase. 2019-07-10 Richard Biener PR tree-optimization/91126 * tree-ssa-sccvn.c (n_walk_cb_data::push_partial_def): Adjust native encoding offset for BYTES_BIG_ENDIAN. (vn_reference_lookup_3): Likewise. * gcc.dg/torture/pr91126.c: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91126.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91145.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91200.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr91131.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/gimplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-cfg.c branches/gcc-9-branch/gcc/tree-ssa-phiopt.c branches/gcc-9-branch/gcc/tree-ssa-sccvn.c branches/gcc-9-branch/gcc/tree-vect-slp.c
[Bug middle-end/91131] Bad bitfield coalescing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131 --- Comment #13 from Richard Biener --- Author: rguenth Date: Wed Jul 31 15:40:36 2019 New Revision: 273939 URL: https://gcc.gnu.org/viewcvs?rev=273939=gcc=rev Log: 2019-07-31 Richard Biener Backport from mainline 2019-07-19 Richard Biener PR tree-optimization/91200 * tree-ssa-phiopt.c (cond_store_replacement): Check we have no PHI nodes in middle-bb. * gcc.dg/torture/pr91200.c: New testcase. 2019-07-15 Richard Biener PR middle-end/91162 * tree-cfg.c (move_block_to_fn): When releasing a virtual PHI node make sure to replace all uses with something valid. * gcc.dg/autopar/pr91162.c: New testcase. 2019-07-12 Richard Biener PR tree-optimization/91145 * tree-vect-slp.c (vect_build_slp_tree_2): Fix reduction chain check. * gcc.dg/torture/pr91145.c: New testcase. 2019-07-11 Richard Biener PR middle-end/91131 * gimplify.c (gimplify_compound_literal_expr): Force a temporary when the object is volatile and we have not cleared it even though there are no nonzero elements. * gcc.target/i386/pr91131.c: New testcase. 2019-07-10 Richard Biener PR tree-optimization/91126 * tree-ssa-sccvn.c (n_walk_cb_data::push_partial_def): Adjust native encoding offset for BYTES_BIG_ENDIAN. (vn_reference_lookup_3): Likewise. * gcc.dg/torture/pr91126.c: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/autopar/pr91162.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91126.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91145.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91200.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr91131.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/gimplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-cfg.c branches/gcc-9-branch/gcc/tree-ssa-phiopt.c branches/gcc-9-branch/gcc/tree-ssa-sccvn.c branches/gcc-9-branch/gcc/tree-vect-slp.c
[Bug sanitizer/91311] New: __attribute__ ((aligned (128))) results in stack-use-after-scope and stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91311
Bug ID: 91311
Summary: __attribute__ ((aligned (128))) results in
stack-use-after-scope and stack-buffer-overflow
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
This is sporadically (as in, ≈6/10) reproducible on 8.3.0, and not reproducible
on 7.4.0 and 9.1.0. Running the testcase sometimes results in
stack-buffer-overflow sanitizer report, othertimes it's stack-use-after-scope,
and sometimes code passes with no crashes and warnings.
This code is not so small (58 lines) because removing anything from it, or
trying to merge functions, results in getting less crashes or none at all.
Removing the `__attribute__ ((aligned (128)))` results in no crashes from 100
runs; and it's the only odd line of this code, so I suspect this is the
culprit.
Doing `export ASAN_OPTIONS=detect_stack_use_after_return=1` also seems to fix
that.
Despite the testcase being specific to 8.3.0, it seems likely that some similar
problem is present in at least older GCC versions as well. In a project I'm
working on, another developer, with 7.x.x GCC version, also had its share of
odd sanitizer crashes. It's possible, there's the same root reason.
Any suggestions or ideas for how to debug it are welcome.
# Steps to reproduce (in terms of terminal commands)
$ cat asan_testcase.c
#include
#include
#include
struct MyStruct1 {
uint64_t ptr1;
char a;
uint64_t ptr2;
char b;
};
typedef struct {
const uint8_t *raw;
uint64_t err_off;
} MyStruct2 __attribute__ ((aligned (128)));
void test_func() {
struct MyStruct1 test;
char* foo = (char*)
for (size_t i = 0; i < sizeof(struct MyStruct1); ++i)
foo[i] = 0;
printf("test addr: %p", );
struct MyStruct1 test2 = {0};
printf("test addr: %p", );
exit(0);
}
void my_bson_destroy(void *foo) {
}
void my_bson_iter_init_find(MyStruct2 *foo, void *bar, const void* p) {
}
void* my_bson_new_from_json(const void* p, int a, int b) {
return 0;
}
static void test_func3() {
void *bson_param = my_bson_new_from_json((const uint8_t*)"{}", -1, 0);
do {
MyStruct2 it;
my_bson_iter_init_find(, bson_param, "");
} while(0);
my_bson_destroy(bson_param);
}
static void test_func2(const char* json_params) {
test_func3();
fputs("### rpc_operation_cud_obj called!\n", stderr);
test_func();
}
static void test_func4() { test_func2(0); }
static void* test_func5(void *arg) { test_func4(); abort(); }
int main() {
test_func5(0);
}
$ gcc -fsanitize=address -g3 -O0 -o asan_testcase asan_testcase.c
$ for i in {1..100}; do ./asan_testcase; done
## Expected
Only output from the app, bunch of lines like:
### rpc_operation_cud_obj called!
test addr: 0x7ffe31c987d0test addr: 0x7ffe31c98810%
## Actual
Aborts by address sanitizer: sometimes it's a stack-buffer-overflow:
=
==819==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff118a9010 at pc 0x564fb240f2f6 bp 0x7fff118a8fd0 sp 0x7fff118a8fc0
WRITE of size 1 at 0x7fff118a9010 thread T0
#0 0x564fb240f2f5 in test_func ../iscsi/asan_testcase.c:23
#1 0x564fb240f55c in test_func2 ../iscsi/asan_testcase.c:50
#2 0x564fb240f56d in test_func4 ../iscsi/asan_testcase.c:53
#3 0x564fb240f586 in test_func5 ../iscsi/asan_testcase.c:54
#4 0x564fb240f59e in main ../iscsi/asan_testcase.c:57
#5 0x7f1d87092ce2 in __libc_start_main (/usr/lib/libc.so.6+0x23ce2)
#6 0x564fb240f13d in _start (/tmp/asan_testcase+0x113d)
Address 0x7fff118a9010 is located in stack of thread T0 at offset 32 in
frame
#0 0x564fb240f218 in test_func ../iscsi/asan_testcase.c:19
This frame has 2 object(s):
[32, 64) 'test' <== Memory access at offset 32 is inside this variable
[96, 128) 'test2'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
../iscsi/asan_testcase.c:23 in test_func
Shadow bytes around the buggy address:
0x10006230d1b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006230d1c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006230d1d0:
[Bug lto/91299] LTO inlines a weak definition in presence of a non-weak definition from an ELF file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299 --- Comment #6 from H.J. Lu --- (In reply to Martin Liška from comment #5) > (In reply to Richard Biener from comment #4) > > You want to look at the output of the linker resolution file (compile with > > -v -save-temps and look for -fresolution=). The linker probably > > tells > > GCC that its "weak" foo() definition is prevailing. This either makes it > > a non-bug or a binutils bug then. > > $ cat weakdef.res > 1 > weakdef.o 2 > 199 b48787268b6fb34e PREEMPTED_REG foo > 202 b48787268b6fb34e PREVAILING_DEF main -O0 and -O1 work. -O2 and above fail. It looks like a GCC bug.
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307
Martin Liška changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #7 from Martin Liška ---
Can anything as simple as this resolve it:
diff --git a/gcc/tree.c b/gcc/tree.c
index 8cf75f0..56c0fd450f1 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -9817,12 +9817,17 @@ get_file_function_name (const char *type)
|| (strncmp (type, "sub_", 4) == 0
&& (type[4] == 'I' || type[4] == 'D')))
{
- const char *file = main_input_filename;
- if (! file)
- file = LOCATION_FILE (input_location);
- /* Just use the file's basename, because the full pathname
-might be quite long. */
- p = q = ASTRDUP (lbasename (file));
+ if (flag_wpa)
+ p = q = ASTRDUP ("wpa");
+ else
+ {
+ const char *file = main_input_filename;
+ if (! file)
+ file = LOCATION_FILE (input_location);
+ /* Just use the file's basename, because the full pathname
+might be quite long. */
+ p = q = ASTRDUP (lbasename (file));
+ }
}
else
{
?
[Bug fortran/91310] Read overflow generated by character array assignment to self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310 --- Comment #4 from Fritz Reese --- Created attachment 46651 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46651=edit intermediate code for test case 2 You can see the central loop described in the original report from lines 18-25. The bounds of the loop are problematic, as iterations 509-511 will overflow the source buffer. The optimized version is able to detect the overflow and issue a warning.
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307 --- Comment #6 from Martin Liška --- The name to function is given here: get_file_function_name Breakpoint 1, get_file_function_name (type=0x7fffd670 "I_65535_0") at /home/marxin/Programming/gcc/gcc/tree.c:9809 9809 if (first_global_object_name) (gdb) bt #0 get_file_function_name (type=0x7fffd670 "I_65535_0") at /home/marxin/Programming/gcc/gcc/tree.c:9809 #1 0x00ab7c9b in cgraph_build_static_cdtor_1 (which=, body=0x778958e0, priority=65535, final=, optimization=0x77895880, target=0x7789c558) at /home/marxin/Programming/gcc/gcc/ipa.c:845 #2 0x00ab830b in build_cdtor (ctor_p=true, cdtors=...) at /home/marxin/Programming/gcc/gcc/tree.h:3258 #3 0x00ab877d in build_cdtor_fns (dtors=0x7fffd7d0, ctors=0x7fffd720) at /home/marxin/Programming/gcc/gcc/ipa.c:1064 #4 ipa_cdtor_merge () at /home/marxin/Programming/gcc/gcc/ipa.c:1093 #5 0x00bb9f1a in execute_one_pass (pass=0x2263e60) at /home/marxin/Programming/gcc/gcc/passes.c:2474 #6 0x00bbb927 in execute_ipa_pass_list (pass=0x2263e60) at /home/marxin/Programming/gcc/gcc/passes.c:2914 #7 0x007e1e51 in do_whole_program_analysis () at /home/marxin/Programming/gcc/gcc/context.h:48 #8 lto_main () at /home/marxin/Programming/gcc/gcc/lto/lto.c:628 #9 0x00c8c900 in compile_file () at /home/marxin/Programming/gcc/gcc/toplev.c:456 #10 0x007ba21b in do_compile () at /home/marxin/Programming/gcc/gcc/toplev.c:2190 #11 toplev::main (this=this@entry=0x7fffda6e, argc=, argc@entry=19, argv=, argv@entry=0x7fffdb68) at /home/marxin/Programming/gcc/gcc/toplev.c:2325 #12 0x007bdd2f in main (argc=19, argv=0x7fffdb68) at /home/marxin/Programming/gcc/gcc/main.c:39 So when one uses --save-temps: gcc -flto pr91307-*.c -o a.out --save-temps && objdump -S a.out | grep GLOBAL generating: _GLOBAL__I_65535_0_pr91307_1.o We can probably give a better name in WPA.
[Bug libstdc++/91308] [7/8/9/10 Regression] unique_ptr assignment fails with different deleters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91308 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Wed Jul 31 14:38:26 2019 New Revision: 273937 URL: https://gcc.gnu.org/viewcvs?rev=273937=gcc=rev Log: PR libstdc++/91308 fix constraints on unique_ptr assignment PR libstdc++/91308 * include/bits/unique_ptr.h (unique_ptr::__safe_conversion_up): Remove constraints on deleter that should only apply to the constructor. (unique_ptr::__safe_conversion_up): Likewise. (unique_ptr::unique_ptr(unique_ptr&&)): Restore constraints on deleter here. * testsuite/20_util/unique_ptr/assign/91308.cc: New test. Added: trunk/libstdc++-v3/testsuite/20_util/unique_ptr/assign/91308.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/unique_ptr.h
[Bug fortran/91310] Read overflow generated by character array assignment to self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310
--- Comment #3 from Fritz Reese ---
Created attachment 46650
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46650=edit
intermediate code for test case 1
You can see the central condition described in the original report from lines
17-25, and the problematic __builtin_memmove on line 24, which in the optimized
version of the tree causes the warning.
> __builtin_memmove ((void *) , (void *) [D.3853]{lb: 1 sz: 1}, 512);
[Bug tree-optimization/91280] [8/9 Regression] ICE in get_constraint_for_component_ref, at tree-ssa-structalias.c:3259 since r260354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91280 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |get_constraint_for_componen |get_constraint_for_componen |t_ref, at |t_ref, at |tree-ssa-structalias.c:3259 |tree-ssa-structalias.c:3259 |since r260354 |since r260354 Known to fail|10.0| --- Comment #5 from Richard Biener --- Fixed on trunk.
[Bug tree-optimization/91280] [8/9/10 Regression] ICE in get_constraint_for_component_ref, at tree-ssa-structalias.c:3259 since r260354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91280 --- Comment #4 from Richard Biener --- Author: rguenth Date: Wed Jul 31 14:38:21 2019 New Revision: 273936 URL: https://gcc.gnu.org/viewcvs?rev=273936=gcc=rev Log: 2019-07-31 Richard Biener PR tree-optimization/91280 * tree-ssa-structalias.c (get_constraint_for_component_ref): Decompose MEM_REF manually for offset handling. * g++.dg/torture/pr91280.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr91280.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug c/91192] [9 regression] non-deterministic ICE on invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91192 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 regression] |[9 regression] |non-deterministic ICE on|non-deterministic ICE on |invalid |invalid --- Comment #3 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c/91192] [9/10 regression] non-deterministic ICE on invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91192 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Jul 31 14:32:24 2019 New Revision: 273935 URL: https://gcc.gnu.org/viewcvs?rev=273935=gcc=rev Log: PR c/91192 * c-parser.c (c_parser_sizeof_expression): Call set_c_expr_source_range even if finish is UNKNOWN_LOCATION, just use start as finish in that case. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c
[Bug fortran/91310] Read overflow generated by character array assignment to self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310 --- Comment #2 from Fritz Reese --- Created attachment 46649 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46649=edit test case 2
[Bug fortran/91310] Read overflow generated by character array assignment to self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310 --- Comment #1 from Fritz Reese --- Created attachment 46648 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46648=edit test case 1
[Bug fortran/91310] New: Read overflow generated by character array assignment to self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91310
Bug ID: 91310
Summary: Read overflow generated by character array assignment
to self
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: foreese at gcc dot gnu.org
Target Milestone: ---
The following simple test cases read_overflow1.for and read_overflow2.for
generate warnings when compiled with -O2 (in gfortran 9.1.0) which allude to
the bug which is a read overflow generated from a character array assignment
within a single variable where the bounds of the LHS and RHS are known.
> $ cat read_overflow1.for
> subroutine s(len)
> implicit none
> character str*512
> integer(4) :: offset
> integer(4), intent(in) :: len
>
> offset = 4
> str(1:) = str(offset:len+3)
> print *, str
> end subroutine
> $ diff read_overflow1.for read_overflow2.for
> 3c3
> < character str*512
> ---
> > character str(512)
> $ gfortran -c -O0 read_overflow1.for # no warning
> $ gfortran -c -O2 read_overflow1.for
> read_overflow1.for:9:0:
>
> 9 | str(1:) = str(offset:len+3)
> |
> Warning: ‘__builtin_memmove’ reading 512 bytes from a region of size 509
> [-Wstringop-overflow=]
> $ gfortran -c -O0 read_overflow2.for # no warning
> $ gfortran -c -O2 read_overflow2.for
> read_overflow2.for:9:0:
>
> 9 | str(1:) = str(offset:len+3)
> |
> Warning: iteration 509 invokes undefined behavior
> [-Waggressive-loop-optimizations]
> read_overflow2.for:9:0: note: within this loop
The issue can be seen in the trees dumped by -fdump-tree-original and
-fdump-tree-optimized, both at -O0 and -O2 for both test cases. The
intermediate code generated is equivalent for both optimization levels. For
read_overflow1.for it boils down to the following:
> _read_length = len - 3;
> if (_read_length < 512) {
> __builtin_memmove(, +3, _read_length);
> __builtin_memset(, ' ', 512 - _read_length);
> } else {
> __builtin_memmove(, +3, 512);
> }
The trees for read_overflow2.for are similar but are expanded into a loop
equivalent to the following:
> idx = 0;
> while (idx < 512) {
> str[idx][1] = str[idx + 3][1];
> ++idx;
> }
Clearly, code is generated to avoid overflow when _writing_ to str, but there
is no code generated to avoid overflow when _reading_ from str, though both the
source and destination sizes are known. In fact if len is > 509, the last three
characters would result in a read overflow of the str character array and
garbage would be written to the end of the array.
The warnings are only issued in -O2 because the intermediate code is simplified
enough for the overflow to be obvious.
A workaround from the user perspective is to replace the assignment with two
explicitly bounded assignments:
> s(1:len) = s(offset:len+3)
> s(len+1:) = ' '
In this case no overflow can occur from the generated code.
AFAICT the standard does not specify what to do when an assignment occurs among
array sections of differing sizes, so it is up to the compiler to be sensible.
One might argue it is not against the standard to ignore the source size and
always write the destination size -- however, I rather think of it as blatant
negligence on the compiler's part in this case, since the bounds of both are
known and it already tries to avoid overflow of one operation (write) but not
the other (read). If the behavior is intentional and the code _should_ result
in an overflow, then a consistent and obvious warning should be issued for all
optimization levels - but I don't think that it should.
[Bug tree-optimization/91293] [8/9 Regression] Wrong code with -O3 -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91293 --- Comment #6 from Richard Biener --- Author: rguenth Date: Wed Jul 31 14:15:37 2019 New Revision: 273934 URL: https://gcc.gnu.org/viewcvs?rev=273934=gcc=rev Log: 2019-07-31 Richard Biener PR tree-optimization/91293 * tree-vect-slp.c (vect_build_slp_tree_2): Do not swap operands of reduction stmts. * gcc.dg/vect/pr91293-1.c: New testcase. * gcc.dg/vect/pr91293-2.c: Likewise. * gcc.dg/vect/pr91293-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/vect/pr91293-1.c trunk/gcc/testsuite/gcc.dg/vect/pr91293-2.c trunk/gcc/testsuite/gcc.dg/vect/pr91293-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307 --- Comment #5 from Martin Liška --- Confirmed: $ marxin@marxinbox:/tmp> gcc -flto pr91307-*.c -o a.out && objdump -S a.out | grep GLOBAL 00401109 <_GLOBAL__I_65535_0_ccIH3dv1.o.4348>: marxin@marxinbox:/tmp> gcc -flto pr91307-*.c -o a.out && objdump -S a.out | grep GLOBAL 00401109 <_GLOBAL__I_65535_0_ccrEZiHf.o.4348>:
[Bug tree-optimization/91293] [8/9 Regression] Wrong code with -O3 -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91293 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[8/9/10 Regression] Wrong |[8/9 Regression] Wrong code |code with -O3 -mavx2|with -O3 -mavx2 Known to fail|10.0| --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug c++/91309] New: Fails to compile when initializing template argument with immediately-invoked lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91309
Bug ID: 91309
Summary: Fails to compile when initializing template argument
with immediately-invoked lambda
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: beachboy44 at me dot com
Target Milestone: ---
https://godbolt.org/z/8O-ItF
The following code fails to compile:
template
struct S {};
template
using T = S< []{ return 0; }() >;
template
using U = T;
using V = U<0>;
error: 'U' does not name a type
However, it compiles when you specify an integer literal as the template
argument to T:
template
using U = T<0>;
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307
--- Comment #4 from Richard Biener ---
A simple two-file testcase like
static void init(void) __attribute__((constructor));
static void init()
{
static volatile int i = 0;
}
int main() { return 0; }
static void init2(void) __attribute__((constructor));
static void init2()
{
static volatile int i = 0;
}
reproduces this. Having two ctors (in different CUs) is important.
[Bug libstdc++/91308] [7/8/9/10 Regression] unique_ptr assignment fails with different deleters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91308 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.5
[Bug target/91303] powerpc-rtems compile error libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91303 --- Comment #3 from Joel Sherrill --- Pursuing the assumption that the e500 files shouldn't be build, I decided to remove them from the t-savresfgpr files. With this patch, powerpc-rtems5 builds again: diff --git a/libgcc/config/rs6000/t-savresfgpr b/libgcc/config/rs6000/t-savresfg index a8455ae..e252cc8 100644 --- a/libgcc/config/rs6000/t-savresfgpr +++ b/libgcc/config/rs6000/t-savresfgpr @@ -7,17 +7,4 @@ LIB2ADD_ST += \ $(srcdir)/config/rs6000/crtresxfpr.S \ $(srcdir)/config/rs6000/crtresxgpr.S \ $(srcdir)/config/rs6000/crtsavevr.S \ - $(srcdir)/config/rs6000/crtrestvr.S \ - $(srcdir)/config/rs6000/e500crtres32gpr.S \ - $(srcdir)/config/rs6000/e500crtres64gpr.S \ - $(srcdir)/config/rs6000/e500crtres64gprctr.S \ - $(srcdir)/config/rs6000/e500crtrest32gpr.S \ - $(srcdir)/config/rs6000/e500crtrest64gpr.S \ - $(srcdir)/config/rs6000/e500crtresx32gpr.S \ - $(srcdir)/config/rs6000/e500crtresx64gpr.S \ - $(srcdir)/config/rs6000/e500crtsav32gpr.S \ - $(srcdir)/config/rs6000/e500crtsav64gpr.S \ - $(srcdir)/config/rs6000/e500crtsav64gprctr.S \ - $(srcdir)/config/rs6000/e500crtsavg32gpr.S \ - $(srcdir)/config/rs6000/e500crtsavg64gpr.S \ - $(srcdir)/config/rs6000/e500crtsavg64gprctr.S + $(srcdir)/config/rs6000/crtrestvr.S
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Richard Biener changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #18 from Richard Biener --- So the linker issue would be that during computing of the resolution when the linker decides a whole archive isn't necessary it doesn't re-consider it for the final actual link (which is where GCC exposes the atan2 UNDEF). Instead it happily resolves it to libm which libgfortran drags in? For C and without -lm it doesn't find it and thus _does_ re-consider the previously unused -lmass. I would have expected the link to fail with an unresolved symbol - so the behavior is at least inconsistent.
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307
--- Comment #3 from Bernhard M. Wiedemann ---
It seems to be triggered by nvme-cli/cmd_handler.h
#define PLUGIN(name, cmds) \
static struct plugin plugin = { \
name\
.commands = commands\
}; \
\
static void init(void) __attribute__((constructor));\
static void init(void) \
{ \
register_extension();\
}
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-07-31
Ever confirmed|0 |1
--- Comment #17 from Richard Biener ---
(In reply to Richard Biener from comment #16)
> (In reply to Richard Biener from comment #15)
> > Honza probably knows where we output the LTO symtab and why we do not put
> > undefs for builtins there.
>
> #include
> double y, z;
> void foo ();
> int main()
> {
> volatile double x = atan2 (y, z);
> foo ();
> }
>
> > gcc-8 -c t.c -flto
> > gcc-nm t.o
> U foo
> T main
> C y
> C z
>
> where's the
>
> U atan2
>
> ?
For
double atan2 (double x, double y) { return x + y; }
it doesn't appear either, this CU has an empty symbol table...
I do remember quite some "funs" with builtin handling though, so the
current handling may be the least bad of all choices...
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #16 from Richard Biener ---
(In reply to Richard Biener from comment #15)
> Honza probably knows where we output the LTO symtab and why we do not put
> undefs for builtins there.
#include
double y, z;
void foo ();
int main()
{
volatile double x = atan2 (y, z);
foo ();
}
> gcc-8 -c t.c -flto
> gcc-nm t.o
U foo
T main
C y
C z
where's the
U atan2
?
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-07-31 CC|mliska at suse dot cz | Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #15 from Richard Biener --- Honza probably knows where we output the LTO symtab and why we do not put undefs for builtins there.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #14 from rguenther at suse dot de --- On Wed, 31 Jul 2019, wschmidt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 > > Bill Schmidt changed: > >What|Removed |Added > > Known to fail||10.0, 8.3.0, 9.1.0 > > --- Comment #13 from Bill Schmidt --- > It dates back to at least 2018-04-12, when it was reported internally on a > SPEC > test. I'll mark known-to-fail for GCC 8 going forward. Note it can also be a binutils issue, there used to be issues with static library handling and builtins eventually not appearing in the LTO symbol table. Indeed for the fortran example I see 1 t.o 8 334 a12b0c6fed53f76a PREVAILING_DEF_IRONLY square_cube_ 348 a12b0c6fed53f76a PREVAILING_DEF main 363 a12b0c6fed53f76a RESOLVED_DYN _gfortran_st_write_done 372 a12b0c6fed53f76a RESOLVED_DYN _gfortran_transfer_integer_write 381 a12b0c6fed53f76a RESOLVED_DYN _gfortran_transfer_character_write 383 a12b0c6fed53f76a RESOLVED_DYN _gfortran_st_write 391 a12b0c6fed53f76a RESOLVED_DYN _gfortran_set_options 396 a12b0c6fed53f76a RESOLVED_DYN _gfortran_set_args and for a corresponding C testcase 1 t.o 3 198 af89597965b857af PREVAILING_DEF main 211 af89597965b857af PREVAILING_DEF_IRONLY z 213 af89597965b857af PREVAILING_DEF_IRONLY y so no atan2 but an external function foo appears. So the linker probably decides MASS is not needed at all and in the end atan2 comes in via libgfortran linking to libm.
[Bug tree-optimization/91201] [7/8/9/10 Regression] SIMD not generated for horizontal sum of bytes in array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Wed Jul 31 13:49:26 2019 New Revision: 273932 URL: https://gcc.gnu.org/viewcvs?rev=273932=gcc=rev Log: PR tree-optimization/91201 * config/i386/mmx.md (reduc_plus_scal_v8qi): New expander. * gcc.target/i386/sse2-pr91201-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/sse2-pr91201-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/mmx.md trunk/gcc/testsuite/ChangeLog
[Bug target/91303] powerpc-rtems compile error libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91303 --- Comment #2 from Joel Sherrill --- I admit to being completely confused by the multitude of PwerPC variants but if the e500 was deleted, why does libgcc/config.host still include libgcc/config/rs6000/t-savresfgpr for multiple powerpc targets and t-savresfgpr still list files which have e500 in the name?
[Bug lto/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307 Andrew Pinski changed: What|Removed |Added CC||marxin at gcc dot gnu.org Component|c |lto --- Comment #2 from Andrew Pinski --- So it is a global constructor which is picking up the name of the object file.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Bill Schmidt changed: What|Removed |Added Known to fail||10.0, 8.3.0, 9.1.0 --- Comment #13 from Bill Schmidt --- It dates back to at least 2018-04-12, when it was reported internally on a SPEC test. I'll mark known-to-fail for GCC 8 going forward.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #12 from Bill Schmidt --- (In reply to rguent...@suse.de from comment #11) > On Wed, 31 Jul 2019, wschmidt at linux dot ibm.com wrote: > > OK, so -mveclibabi=mass isn't needed to reproduce the issue, nor is > linking -lmassv or -lmass_smidp8 then I guess. That's correct. That was just our standard set of flags for linking with MASS/MASSV. It was confusing. > > > With the C version of the code, we correctly generate symbols atan2 and > > _atan2 that will be satisfied by libmass. With the Fortran version of > > the code and without -flto, we again generate symbols atan2f and _atan2f > > that will be satisfied by libmass. When we add -flto to the Fortran > > version of the code, we instead generate symbols for atan2f@@GLIBC_2.17, > > disallowing libmass from satisfying them. > > > > We see different behavior in the "visibility" LTO pass between the C and > > Fortran versions, which seems to be a clue. > > I see (on x86) atan2f being used for the fortran testcase since > you are calling atan2 with real() arguments. If you do not use > -fdefault-real-8 you are then comparing apples and oranges. > > Maybe MASS doesn't have any float variants? No, this used to work. It looks like this started happening a couple of releases ago. We need to drill down on that.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #11 from rguenther at suse dot de ---
On Wed, 31 Jul 2019, wschmidt at linux dot ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
> --- Comment #10 from wschmidt at linux dot ibm.com ---
> On 7/31/19 2:25 AM, rguenther at suse dot de wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> >
> > --- Comment #9 from rguenther at suse dot de ---
> > On Wed, 31 Jul 2019, luoxhu at cn dot ibm.com wrote:
> >
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> >>
> >> --- Comment #8 from Xiong Hu XS Luo ---
> >> (In reply to Thomas Koenig from comment #6)
> >>> (In reply to Xiong Hu XS Luo from comment #4)
> >>>
> /tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__':
> :(.text+0x114): undefined reference to `_gfortran_st_write'
> :(.text+0x12c): undefined reference to
> `_gfortran_transfer_character_write'
> >>> You're not linkging against libgfortran.
> >>>
> >>> Either use gfortran as command for compiling or linking, or
> >>> add the appropriate libraries (-lgfortran -lquadmath) to
> >>> the linking step.
> >> Thanks Thomas and Richard. Sorry that I am not familiar with fortran. The
> >> regression was fixed by Martin's new change.
> >>
> >> The c code included math.h actually.
> >>
> >> cat atan2bashzowie.c
> >> #include
> >> #include
> >> #include
> >>
> >> double __attribute__((noinline)) zowie (double x, double y, double z)
> >> {
> >> return atan2 (x * y, z);
> >> }
> >>
> >> double __attribute__((noinline)) rand_finite_double (void)
> >> {
> >> union {
> >> double d;
> >> unsigned char uc[sizeof(double)];
> >> } u;
> >> do {
> >> for (unsigned i = 0; i < sizeof u.uc; i++) {
> >> u.uc[i] = (unsigned char) rand();
> >> }
> >> } while (!isfinite(u.d));
> >> return u.d;
> >> }
> >>
> >> int main ()
> >> {
> >> double a = rand_finite_double ();
> >> printf ("%lf\n", zowie (a, 4.5, 2.2));
> >> return 0;
> >> }
> >> cat build.sh
> >> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> >> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -lmass_simdp8 -lmassv -lmassvp8 -o
> >> a.out
> >> nm a.out | grep atan2
> >> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> >> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv
> >> -lmassvp8 -o
> >> a.out
> >> nm a.out | grep atan2
> >> ./build.sh
> >> 1700 T atan2
> >> 1700 T _atan2
> >> 17e0 T atan2
> >> 17e0 T _atan2
> > Err, but [_]atan2 are surely not vector variants. Also is massv a static
> > library here? It looks more like you are not getting the code vectorized
> > with -flto but without and both variants end up using massv (the -flto
> > variant using the scalar atan2)?
> >
> > That said, you have to do more detailed analysis of what actually
> > happens and what you _want_ to happen. The bugreport summary
> > doesn't really match what you show.
> >
> Agree that there's some unnecessary confusion here. I think the
> temporary ICE and the build issues obscured the original intent of the bug.
>
> There are two libraries provided with the MASS project. libmass
> provides scalar replacements for corresponding libm scalar math
> functions. libmassv provides the vectorized versions of those
> functions. For this bug we are only concerned about libmass and scalar
> math functions.
OK, so -mveclibabi=mass isn't needed to reproduce the issue, nor is
linking -lmassv or -lmass_smidp8 then I guess.
> With the C version of the code, we correctly generate symbols atan2 and
> _atan2 that will be satisfied by libmass. With the Fortran version of
> the code and without -flto, we again generate symbols atan2f and _atan2f
> that will be satisfied by libmass. When we add -flto to the Fortran
> version of the code, we instead generate symbols for atan2f@@GLIBC_2.17,
> disallowing libmass from satisfying them.
>
> We see different behavior in the "visibility" LTO pass between the C and
> Fortran versions, which seems to be a clue.
I see (on x86) atan2f being used for the fortran testcase since
you are calling atan2 with real() arguments. If you do not use
-fdefault-real-8 you are then comparing apples and oranges.
Maybe MASS doesn't have any float variants?
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #10 from wschmidt at linux dot ibm.com ---
On 7/31/19 2:25 AM, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
> --- Comment #9 from rguenther at suse dot de ---
> On Wed, 31 Jul 2019, luoxhu at cn dot ibm.com wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>>
>> --- Comment #8 from Xiong Hu XS Luo ---
>> (In reply to Thomas Koenig from comment #6)
>>> (In reply to Xiong Hu XS Luo from comment #4)
>>>
/tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__':
:(.text+0x114): undefined reference to `_gfortran_st_write'
:(.text+0x12c): undefined reference to
`_gfortran_transfer_character_write'
>>> You're not linkging against libgfortran.
>>>
>>> Either use gfortran as command for compiling or linking, or
>>> add the appropriate libraries (-lgfortran -lquadmath) to
>>> the linking step.
>> Thanks Thomas and Richard. Sorry that I am not familiar with fortran. The
>> regression was fixed by Martin's new change.
>>
>> The c code included math.h actually.
>>
>> cat atan2bashzowie.c
>> #include
>> #include
>> #include
>>
>> double __attribute__((noinline)) zowie (double x, double y, double z)
>> {
>> return atan2 (x * y, z);
>> }
>>
>> double __attribute__((noinline)) rand_finite_double (void)
>> {
>> union {
>> double d;
>> unsigned char uc[sizeof(double)];
>> } u;
>> do {
>> for (unsigned i = 0; i < sizeof u.uc; i++) {
>> u.uc[i] = (unsigned char) rand();
>> }
>> } while (!isfinite(u.d));
>> return u.d;
>> }
>>
>> int main ()
>> {
>> double a = rand_finite_double ();
>> printf ("%lf\n", zowie (a, 4.5, 2.2));
>> return 0;
>> }
>> cat build.sh
>> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
>> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -lmass_simdp8 -lmassv -lmassvp8 -o
>> a.out
>> nm a.out | grep atan2
>> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
>> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv -lmassvp8
>> -o
>> a.out
>> nm a.out | grep atan2
>> ./build.sh
>> 1700 T atan2
>> 1700 T _atan2
>> 17e0 T atan2
>> 17e0 T _atan2
> Err, but [_]atan2 are surely not vector variants. Also is massv a static
> library here? It looks more like you are not getting the code vectorized
> with -flto but without and both variants end up using massv (the -flto
> variant using the scalar atan2)?
>
> That said, you have to do more detailed analysis of what actually
> happens and what you _want_ to happen. The bugreport summary
> doesn't really match what you show.
>
Agree that there's some unnecessary confusion here. I think the
temporary ICE and the build issues obscured the original intent of the bug.
There are two libraries provided with the MASS project. libmass
provides scalar replacements for corresponding libm scalar math
functions. libmassv provides the vectorized versions of those
functions. For this bug we are only concerned about libmass and scalar
math functions.
With the C version of the code, we correctly generate symbols atan2 and
_atan2 that will be satisfied by libmass. With the Fortran version of
the code and without -flto, we again generate symbols atan2f and _atan2f
that will be satisfied by libmass. When we add -flto to the Fortran
version of the code, we instead generate symbols for atan2f@@GLIBC_2.17,
disallowing libmass from satisfying them.
We see different behavior in the "visibility" LTO pass between the C and
Fortran versions, which seems to be a clue.
[Bug c++/91304] maybe_unused attribute ignored on variable declared in if declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91304 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-31 Ever confirmed|0 |1
[Bug libstdc++/91308] [7/8/9/10 Regression] unique_ptr assignment fails with different deleters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91308 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-07-31 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/91308] New: [7/8/9/10 Regression] unique_ptr assignment fails with different deleters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91308
Bug ID: 91308
Summary: [7/8/9/10 Regression] unique_ptr assignment fails with
different deleters
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
As reported at https://gcc.gnu.org/ml/libstdc++/2019-07/msg00088.html this
fails to compile:
#include
struct D1
{
void operator()(int* p) const noexcept { }
};
struct D2 : D1
{
D2& operator=(D1&&) noexcept { return *this; }
};
void
test01()
{
std::unique_ptr d1;
std::unique_ptr d2;
d2 = std::move(d1);
}
void
test02()
{
std::unique_ptr d1;
std::unique_ptr d2;
d2 = std::move(d1);
}
The constraints on the converting assignment operators incorrectly include this
constraint from the converting constructor:
— either D is a reference type and E is the same type as D, or D is not a
reference type and E is implicitly convertible to D.
This used to compile with GCC 5, until r226733.
[Bug tree-optimization/91293] [8/9/10 Regression] Wrong code with -O3 -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91293
--- Comment #4 from Richard Biener ---
Equivalent testcase that doesn't run into the operator swapping and thus works:
long long a;
unsigned b, c;
int d = 62;
void e(long long *f, int p2) { *f = p2; }
int xx = 5, yy = 4;
int main()
{
for (int g = 2; g <= d; g++)
{
c += xx - g;
b += yy + g;
}
e(, b);
if (a != 2196)
__builtin_abort ();
return 0;
}
swapping operands confuses reduction code-generation. It would probably
be "easiest" to not swap operands in this case. This results in no longer
vectorizing this in an optimal way but is probably the way to go for release
branches.
[Bug c/91307] -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307 --- Comment #1 from Simon Schricker --- We also tried building with -pipe, but the observed behavior didn't change.
[Bug ipa/69678] Missed function specialization + partial devirtualization opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69678 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-31 Ever confirmed|0 |1 --- Comment #1 from Bill Schmidt --- COnfirmed...
[Bug c/91307] New: -flto causes binary to vary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307 Bug ID: 91307 Summary: -flto causes binary to vary Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gccbmw at lsmod dot de CC: mliska at suse dot cz Target Milestone: --- When building openSUSE:Factory nvme-cli with -flto=2 it causes a variation in the resulting nvme binary that is not there without -flto /usr/sbin/nvme differs in assembler output @@ -433,7 +433,7 @@ Disassembly of section .text: -_GLOBAL__I_65535_0_cc6lpCUH.o.10070: +_GLOBAL__I_65535_0_cckZcJmg.o.10070: sub$something,%rsp leaoffset(%rip),%rdi# callq strace shows that ["cc", "-D_GNU_SOURCE", "-D__CHECK_ENDIAN__", "-O2", "-Wall", "-D_FORTIFY_SOURCE=2", "-fstack-protector-strong", "-funwind-tables", "-fasynchronous-unwind-tables", "-fstack-clash-protection", "-Werror=return-type", "-flto=2", "-I.", "-std=gnu99", "-I.", "-DLIBUUID", "-DNVME_VERSION=\"1.8.1+git135.9bab71e\"", "nvme.c", "-o", "nvme", "argconfig.o", "suffix.o", "parser.o", "nvme-print.o", "nvme-ioctl.o", "nvme-lightnvm.o", "fabrics.o", "json.o", "nvme-models.o", "plugin.o", "nvme-status.o", "plugins/intel/intel-nvme.o", "plugins/lnvm/lnvm-nvme.o", "plugins/memblaze/memblaze-nvme.o", "plugins/wdc/wdc-nvme.o", "plugins/wdc/wdc-utils.o", "plugins/huawei/huawei-nvme.o", "plugins/netapp/netapp-nvme.o", "plugins/toshiba/toshiba-nvme.o", "plugins/micron/micron-nvme.o", "plugins/seagate/seagate-nvme.o", "plugins/virtium/virtium-nvme.o", "plugins/shannon/shannon-nvme.o", "-luuid"] calls ["/usr/lib64/gcc/x86_64-suse-linux/9/collect2", "-plugin", "/usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so", "-plugin-opt=/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper", "-plugin-opt=-fresolution=/tmp/ccQNkgLE.res", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_s", "-plugin-opt=-pass-through=-lc", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_s", "-flto=2", "--build-id", "--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-pie", "-o", "nvme", "/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/Scrt1.o", "/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/crti.o", "/usr/lib64/gcc/x86_64-suse-linux/9/crtbeginS.o", "-L/usr/lib64/gcc/x86_64-suse-linux/9", "-L/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64", "-L/lib/../lib64", "-L/usr/lib/../lib64", "-L/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/lib", "-L/usr/lib64/gcc/x86_64-suse-linux/9/../../..", "/tmp/cchuJoLU.o", "argconfig.o", "suffix.o", "parser.o", "nvme-print.o", "nvme-ioctl.o", "nvme-lightnvm.o", "fabrics.o", "json.o", "nvme-models.o", "plugin.o", "nvme-status.o", "plugins/intel/intel-nvme.o", "plugins/lnvm/lnvm-nvme.o", "plugins/memblaze/memblaze-nvme.o", "plugins/wdc/wdc-nvme.o", "plugins/wdc/wdc-utils.o", "plugins/huawei/huawei-nvme.o", "plugins/netapp/netapp-nvme.o", "plugins/toshiba/toshiba-nvme.o", "plugins/micron/micron-nvme.o", "plugins/seagate/seagate-nvme.o", "plugins/virtium/virtium-nvme.o", "plugins/shannon/shannon-nvme.o", "-luuid", "-lgcc", "--push-state", "--as-needed", "-lgcc_s", "--pop-state", "-lc", "-lgcc", "--push-state", "--as-needed", "-lgcc_s", "--pop-state", "/usr/lib64/gcc/x86_64-suse-linux/9/crtendS.o", "/usr/lib64/gcc/x86_64-suse-linux/9/../../../../lib64/crtn.o"] Without -flto the collect2 call also gets the random tmp file passed, but the name is not embedded in the result.
[Bug target/91289] powerpc-eabi: Usage of -fstack-limit-symbol leads to internal compiler error during RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289 --- Comment #2 from Philipp Spilger --- Only reverting the "elf_low" insn changes of this commit leads to no encounter of the problem, i.e. the following diff "resolves" the problem on gcc-9_1_0-release. diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md index ad80592765d0..f797008eac9b 100644 --- a/gcc/config/rs6000/rs6000.md +++ b/gcc/config/rs6000/rs6000.md @@ -10138,11 +10138,13 @@ "lis %0,%1@ha") (define_insn "elf_low" - [(set (match_operand:SI 0 "gpc_reg_operand" "=r") - (lo_sum:SI (match_operand:SI 1 "gpc_reg_operand" "b") + [(set (match_operand:SI 0 "gpc_reg_operand" "=r,r") + (lo_sum:SI (match_operand:SI 1 "gpc_reg_operand" "b,!*r") (match_operand 2 "" "")))] "TARGET_ELF && !TARGET_64BIT && !flag_pic" - "la %0,%2@l(%1)") + "@ +la %0,%2@l(%1) +addic %0,%1,%K2") (define_insn "*pltseq_tocsave_" [(set (match_operand:P 0 "memory_operand" "=m")
[Bug target/91289] powerpc-eabi: Usage of -fstack-limit-symbol leads to internal compiler error during RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
Eric Müller changed:
What|Removed |Added
CC||mueller at kip dot
uni-heidelberg.
||de
--- Comment #1 from Eric Müller ---
We did a quick search for changes to the "elf_low" insn which is mentioned in
the error message and found commit 55a56a6f323e876a0368f268f2bf85a5739c7498
("PR target/64180", 2014-12-10 by segher).
After reverting this commit (based on "gcc-9_1_0-release") we do not encounter
the problem anymore; the generated assembly looks okay.
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 --- Comment #2 from zed.three at gmail dot com --- Forgive me, but what is stupid here? The perceived wisdom is that it is best practice to always use `stat` with `allocate`, and the addition of `errmsg` now gives us something portable to hopefully get a sensible error message. Unfortunately, the error message is not correct here. If you mean trying to allocate a 1D array that is huge(1) -- this is just a large enough value that it's likely to fail due to not enough memory on most machines, as it's about 17GB. A 5D array of real64s of size 64x64x64x64x64 is 8GB, which is definitely not an unrealistic size. That's only 2x10^9 points. I'm certainly not saying this is a show-stopper, but I don't think it's at all stupid to expect useful error messages.
[Bug libgcc/91306] New: [MSP430] libgcc/crtstuff.c: Alignment of frame_dummy .init_array entry is too big
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91306
Bug ID: 91306
Summary: [MSP430] libgcc/crtstuff.c: Alignment of frame_dummy
.init_array entry is too big
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: jozefl.gcc at gmail dot com
Target Milestone: ---
In libgcc/crtstuff.c, an alignment of "sizeof (void *)" (i.e. pointer size)
is enforced for the frame_dummy() init_array entry. For msp430-elf in the
large memory model (-mlarge), pointer size is 4 bytes, but the expected
alignment of a pointer is 2 bytes.
So when .init_array is constructed, there could be padding added at the
beginning or between entries, since the structure itself is only aligned to
2 bytes but this entry is aligned to 4 bytes.
The padding causes incorrect execution since the code to run through
.init_array does not expect any gaps between entries since pointers only need
to be 2 byte aligned.
I see this alignment of "sizeof (void *)" was added to fix a mips64 bootstrap
failure in r182066 (https://gcc.gnu.org/ml/gcc-patches/2011-12/msg00393.html),
but this alignment isn't appropriate for msp430.
In crtstuff.c, the type of the init_array entry for frame_dummy is specified
to be "void *", so why must the alignment also be specified?
I don't have access to a mips platform, but shouldn't the entry have the
correct alignment for the type?
Was the addition of the aligned attribute in the 2011 commit a workaround for a
GCC bug? Can it be removed now?
For the following code, GCC generates the the correct alignment without using
the "aligned" attribute on x86, x86_64 and msp430-elf/-mlarge.
static void * entry[]
__attribute__ ((used, section(".init_array"))) = { foo };
x86_64-pc-linux-gnu -m32:
> .section.init_array,"aw"
> .align 4
> .type entry, @object
> .size entry, 4
>entry:
> .long foo
x86_64-pc-linux-gnu -m64:
> .section.init_array,"aw"
> .align 8
> .type entry, @object
> .size entry, 8
>entry:
> .quad foo
msp430-elf -mlarge:
> .section.init_array,"aw"
> .balign 2
> .type entry, @object
> .size entry, 4
>entry:
> .long foo
[Bug tree-optimization/91178] [9 Regression] Infinite recursion in split_constant_offset in slp after r260289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91178 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[9/10 Regression] Infinite |[9 Regression] Infinite |recursion in|recursion in |split_constant_offset in|split_constant_offset in |slp after r260289 |slp after r260289 Known to fail|10.0| --- Comment #11 from Richard Biener --- Fixed again.
[Bug tree-optimization/91178] [9 Regression] Infinite recursion in split_constant_offset in slp after r260289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91178 --- Comment #12 from Richard Biener --- Author: rguenth Date: Wed Jul 31 09:46:18 2019 New Revision: 273928 URL: https://gcc.gnu.org/viewcvs?rev=273928=gcc=rev Log: 2019-07-31 Richard Biener PR tree-optimization/91178 * tree-ssa-sccvn.c (vn_reference_maybe_forwprop_address): Use tail-recursion. * gcc.dg/torture/pr91178-2.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr91178-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/91257] Compile-time and memory-hog hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257 Richard Biener changed: What|Removed |Added Target Milestone|7.5 |--- Summary|[7/8/9/10 Regression] |Compile-time and memory-hog |Compile-time and memory-hog |hog |hog | --- Comment #11 from Richard Biener --- On the reduced testcase GCC 6.5 takes 48s and 1.2GB peak rss for -O3 so it's a regression on the memory-use side but not compile-time. We have ICF since GCC 5 but have since expanded the early pre-IPA pipeline which may explain the regression seen for the larger testcase. With -O3 -fno-ipa-icf compile-time and memory-usage with GCC 6.5 sky-rockets to 275s and 4.3GB so there isn't really much of a regression besides that we added new passes so GCC is expected to get slower. Removing the regression marker.
[Bug tree-optimization/90579] [8/9/10 Regression] Huge store forward stall due to vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579 --- Comment #8 from rguenther at suse dot de --- On Wed, 31 Jul 2019, crazylht at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579 > > --- Comment #7 from Hongtao.liu --- > Transform second loop as > > diff --git a/loop.c b/loop.c > index feea9ea..81a3ea6 100644 > --- a/loop.c > +++ b/loop.c > @@ -9,6 +9,6 @@ loop (int k, double x) >for (i=0;i<6;i++) > r[i] = x * a[i + k]; >for (i=0;i<6;i++) > -t+=r[5-i]; > +t+=r[i]; using ascending order, align with former loop. >return t; > } > } > > Can avoid store forward stalls. > > Before loop transform: > > loop_avx256: 3710992 > loop : 671995 > loop_avx128: 650882 > > After loop transform: > > loop_avx256: 661386 > loop : 652932 > loop_avx128: 568710 Since the loop is probably unrolled this would be a task for reassociation which should try to make data dependences in a way the scheduler can then order memory accesses in advancing order without increasing register pressure (would also help using pre/post-inc addressing modes on some targets). Currently operand rank for memory accesses is determined by looking at the rank of SSA uses (which there may be none) only.
[Bug ipa/91305] ICF compile-time issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91305 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-07-31 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/91275] __builtin_crypto_vpmsumd gives different results -O[123] vs -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275 --- Comment #1 from Lauri Kasanen --- clang 7.0.0 outputs the expected values, aka the gcc -O0 ones, at all optimization levels. (it calls the builtin __builtin_altivec_crypto_vpmsumd, but no other changes)
[Bug tree-optimization/90579] [8/9/10 Regression] Huge store forward stall due to vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579 --- Comment #7 from Hongtao.liu --- Transform second loop as diff --git a/loop.c b/loop.c index feea9ea..81a3ea6 100644 --- a/loop.c +++ b/loop.c @@ -9,6 +9,6 @@ loop (int k, double x) for (i=0;i<6;i++) r[i] = x * a[i + k]; for (i=0;i<6;i++) -t+=r[5-i]; +t+=r[i]; using ascending order, align with former loop. return t; } } Can avoid store forward stalls. Before loop transform: loop_avx256: 3710992 loop : 671995 loop_avx128: 650882 After loop transform: loop_avx256: 661386 loop : 652932 loop_avx128: 568710
[Bug ipa/91305] New: ICF compile-time issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91305 Bug ID: 91305 Summary: ICF compile-time issues Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- The testcase for PR91257 (https://gcc.gnu.org/bugzilla/attachment.cgi?id=46627) shows 5% compile-time is spent in IPA ICF (it does unify 6 identical large functions down to 1 so overall compile-time wise it's a clear win).
