[Bug c/77328] incorrect caret location in -Wformat calling printf via a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77328 --- Comment #4 from Eric Gallager --- (In reply to Martin Sebor from comment #3) > GCC 8 and 9 output for the test case is slightly different (underlining the > sprintf argument is a nice improvement) but still not what it should be: > > pr77328.c: In function ‘f’: > pr77328.c:7:30: warning: format ‘%i’ expects argument of type ‘int’, but > argument 4 has type ‘double’ [-Wformat=] >__builtin_sprintf (d, "%i %i", 1, 2.0); > ~^ ~~~ > %f > pr77328.c:9:9: warning: format ‘%i’ expects argument of type ‘int’, but > argument 4 has type ‘double’ [-Wformat=] >P (d, "%i %i", 1, 2.0); > ^~~ ~~~ > pr77328.c:5:45: note: in definition of macro ‘P’ > #define P(d, f, a, b) __builtin_sprintf (d, f, a, b) > ^ With gcc 10 it's now: $ /usr/local/bin/gcc -c -S -Wformat 77328.c 77328.c: In function 'f': 77328.c:7:29: warning: format '%i' expects argument of type 'int', but argument 4 has type 'double' [-Wformat=] 7 | __builtin_sprintf (d, "%i %i", 1, 2.0); |~^ ~~~ | | | | intdouble |%f 77328.c:9:8: warning: format '%i' expects argument of type 'int', but argument 4 has type 'double' [-Wformat=] 9 | P (d, "%i %i", 1, 2.0); |^~~ ~~~ || |double 77328.c:5:45: note: in definition of macro 'P' 5 | #define P(d, f, a, b) __builtin_sprintf (d, f, a, b) | ^ 77328.c:9:13: note: format string is defined here 9 | P (d, "%i %i", 1, 2.0); |~^ | | | int |%f $
[Bug c++/84810] [concepts][c++20] constraints of lambdas with explicit template parameters are not checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84810 --- Comment #1 from Jason Merrill --- Author: jason Date: Thu Oct 31 02:31:48 2019 New Revision: 277655 URL: https://gcc.gnu.org/viewcvs?rev=277655=gcc=rev Log: PR c++/84810 - constraints on lambdas Attached is a patch that adds parsing of the optional requires-clause in a lambda-expression and lambda-declarator. Additionally, shorthand constraints from the template-parameter-list are now actually applied and constrain the synthesized operator(). Previously we were not parsing the requires clauses at all and not saving the shorthand constraints in the place expected by grokfndecl. The trailing requires-clause is now also used to suppress synthesis of the conversion to function pointer for non-capturing non-generic lambdas as per expr.prim.lambda.closure/7. This includes a fix to template_class_depth. Previously it was computing the wrong depth for lambdas in the initializer of a static member of a class template, exhibited by the concepts-lambda4 test which currently fails on trunk. The bug was causing grokfndecl to use the constraints from the template class for the lambda. gcc/cp/ 2019-10-30 Jeff Chapman II PR c++/84810 - constraints on lambdas * lambda.c (maybe_add_lambda_conv_op): Do not synthesize conversion if the call operator does not satisfy its constraints. * parser.c (cp_parser_lambda_declarator_opt): Parse requires-clause on generic lambdas; combine with shorthand constraints. Parse trailing requires-clause and attach to the synthesized call operator. * pt.c (template_class_depth): Only inspect LAMBDA_TYPE_EXTRA_SCOPE if it is present. This fixes an incorrect depth calculation for lambdas inside the initializer of a static data member of a template class. gcc/testsuite/ 2019-10-30 Jeff Chapman II PR c++/84810 - constraints on lambdas * g++.dg/cpp2a/concepts-lambda2.C: New test. * g++.dg/cpp2a/concepts-lambda3.C: Ditto. * g++.dg/cpp2a/concepts-lambda4.C: Ditto. * g++.dg/cpp2a/concepts-pr84810.C: Ditto. Added: trunk/gcc/testsuite/g++.dg/cpp2a/concepts-lambda2.C trunk/gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C trunk/gcc/testsuite/g++.dg/cpp2a/concepts-lambda4.C trunk/gcc/testsuite/g++.dg/cpp2a/concepts-pr84810.C Modified: trunk/gcc/cp/lambda.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #10 from Jason Merrill --- Note that I see > FAIL: std/ranges/access/cend.cc (test for excess errors) > FAIL: std/ranges/access/end.cc (test for excess errors) with this patch, because now we properly catch the substitution failure in -> sentinel_for(__t)))>
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 92268, which changed state. Bug 92268 Summary: [concepts] hard error satisfying return-type-requirement https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/92296] [10 Regression] GCC build ICE on MinGW-w64. internal compiler error: Segmentation fault #pragma push_macro("__has_builtin")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296 --- Comment #8 from fdlbxtqi --- (In reply to Andrew Pinski from comment #5) > >Then how can I build a new version of GCC on MinGW? :( > > Wait for the bug to fixed. Bugs happen. Most people compiling the trunk > don't build using mingw. You are the bleading edge with compiling on the > trunk. > > > Every day I have to rebuild the entire compiler since either some features > > fail to work or the compiler fails to compile. > > That is what happens when you are compiling on the trunk of any sources. > You are doing QA. I think I need to inform Martin Sebor He might be able to fix the problem. :)
[Bug c++/92299] The expression X / abs (X) is simplified to 1 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92299 --- Comment #2 from Andrew Pinski --- Where are you getting these testcases from? If they are from a "standards complaincy" test, then I think you need to write to them about being broken.
[Bug c++/92299] The expression X / abs (X) is simplified to 1 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92299 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- 0/0 is undefined.
[Bug modula2/92147] gm2: modula-2 fails to build on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92147 --- Comment #2 from Matthias Klose --- this is not about powerpc64le-linux-gnu(64bit little endian), but powerpc-linux-gnu (32bit, big endian).
[Bug c++/92298] The expression X / X is simplified to 1 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92298 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- 0/0 is undefined.
[Bug c++/92299] New: The expression X / abs (X) is simplified to 1 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92299 Bug ID: 92299 Summary: The expression X / abs (X) is simplified to 1 even when the variable X is 0 Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: disquisitiones at gmail dot com Target Milestone: --- Created attachment 47141 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47141=edit the preprocessed file that triggers the bug This error seems present since GCC 7.1 Output of #g++ -v: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto Thread model: posix gcc version 9.2.0 (GCC) - complete command line that triggers the bug: #g++ -save-temps -o test test.cpp - compiler output: none
[Bug c/92296] [10 Regression] GCC build ICE on MinGW-w64. internal compiler error: Segmentation fault #pragma push_macro("__has_builtin")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296 --- Comment #7 from fdlbxtqi --- (In reply to Andrew Pinski from comment #5) > >Then how can I build a new version of GCC on MinGW? :( > > Wait for the bug to fixed. Bugs happen. Most people compiling the trunk > don't build using mingw. You are the bleading edge with compiling on the > trunk. > > > Every day I have to rebuild the entire compiler since either some features > > fail to work or the compiler fails to compile. > > That is what happens when you are compiling on the trunk of any sources. > You are doing QA. Sounds like gcc is trying to be compatible with clang by adding the new "__has_builtin" macro
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 --- Comment #9 from Jason Merrill --- Author: jason Date: Thu Oct 31 02:01:16 2019 New Revision: 277654 URL: https://gcc.gnu.org/viewcvs?rev=277654=gcc=rev Log: PR c++/92268 - hard error satisfying return-type-requirement Previously we would put the template arguments for the concept-check in a TEMPLATE_ID and then also pass them to constraints_satisfied_p, which meant that we would try to normalize the concept-check with the fully instantiated arguments, leading to sadness. Simply not passing the args to constraints_satisfied_p fixes the problem. I also noticed that we weren't detecting substitution failure in the constraints, but were silently treating it as success. * constraint.cc (type_deducible_p): Check for substitution failure. (diagnose_compound_requirement): Adjust diagnostic. * pt.c (do_auto_deduction): Don't pass cargs to constraints_satisfied_p. Added: trunk/gcc/testsuite/g++.dg/cpp2a/concepts-return-req1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constraint.cc trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/concepts/diagnostic1.C trunk/gcc/testsuite/g++.dg/concepts/placeholder3.C trunk/gcc/testsuite/g++.dg/concepts/placeholder4.C trunk/gcc/testsuite/g++.dg/cpp2a/concepts-pr67178.C trunk/gcc/testsuite/g++.dg/cpp2a/concepts-requires6.C
[Bug c++/92298] New: The expression X / X is simplified to 1 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92298 Bug ID: 92298 Summary: The expression X / X is simplified to 1 even when the variable X is 0 Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: disquisitiones at gmail dot com Target Milestone: --- Created attachment 47140 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47140=edit the preprocessed file that triggers the bug This error seems present since GCC 7.1 Output of #g++ -v: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto Thread model: posix gcc version 9.2.0 (GCC) - complete command line that triggers the bug: #g++ -save-temps -o test test.cpp - compiler output: none
[Bug middle-end/92263] [10 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2087 since r270758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263 --- Comment #6 from Jim Wilson --- Looking at some other targets. ARM has movcc but not 128-bit long double. Aaarch has movcc and 128-bit long double, but has 128-bit load/store so this is only 4 instructions. mips64, powerpc64, and sparc64 have movcc and 128-bit long double, but emit the memcpy inline as 8 instructions. riscv64 meanwhile wants the libcall with -Os as that is 4 instructions instead of 8. For rv32 this would be 16 instructions. I'm not sure offhand if the other targets support 32-bit code and 128-bit long double. Anyways, I tracked the use of BLOCK_OP_NO_LIBCALL in emit_move_complex back to bugzilla 15289, fixed by a patch from Richard Henderson back in Dec 1 2004. I think it is just an oversight that -Os wasn't considered here. I think the correct fix is to only force BLOCK_OP_NO_LIBCALL when optimizing for speed. With this change, I get the 8 instruction sequence with -O2, and the 4 instruction libcall sequence with -Os, which is what the RISC-V backend wants, and this lets the testcase work.
[Bug middle-end/92263] [10 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2087 since r270758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263 Jim Wilson changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot gnu.org --- Comment #7 from Jim Wilson --- Created attachment 47139 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47139=edit untested proposed fix
[Bug c/92296] [10 Regression] GCC build ICE on MinGW-w64. internal compiler error: Segmentation fault #pragma push_macro("__has_builtin")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #6 from fdlbxtqi ---
(In reply to fdlbxtqi from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > Most likely the reduced testcase is just:
> > #pragma push_macro("__has_builtin")
> >
> > --- CUT ---
> > > I did finish compilation with the same script 3 days ago. Now It fails
> >
> > That is because the support for __has_builtin was just added within the last
> > 3 days :).
>
> Then how can I build a new version of GCC on MinGW? :(
>
>
> Every day I have to rebuild the entire compiler since either some features
> fail to work or the compiler fails to compile. Sad :(
>
>
> I have to use the new compiler for compiling my C++20 concepts based IO
> library.
>
>
> https://bitbucket.org/ejsvifq_mabmip/fast_io/src/default/
Compile gcc on linux for twice + MinGW for twice per day. :(
[Bug c/92296] [10 Regression] GCC build ICE on MinGW-w64. internal compiler error: Segmentation fault #pragma push_macro("__has_builtin")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296 --- Comment #5 from Andrew Pinski --- >Then how can I build a new version of GCC on MinGW? :( Wait for the bug to fixed. Bugs happen. Most people compiling the trunk don't build using mingw. You are the bleading edge with compiling on the trunk. > Every day I have to rebuild the entire compiler since either some features > fail to work or the compiler fails to compile. That is what happens when you are compiling on the trunk of any sources. You are doing QA.
[Bug c/92296] [10 Regression] GCC build ICE on MinGW-w64. internal compiler error: Segmentation fault #pragma push_macro("__has_builtin")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #4 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #2)
> Most likely the reduced testcase is just:
> #pragma push_macro("__has_builtin")
>
> --- CUT ---
> > I did finish compilation with the same script 3 days ago. Now It fails
>
> That is because the support for __has_builtin was just added within the last
> 3 days :).
Then how can I build a new version of GCC on MinGW? :(
Every day I have to rebuild the entire compiler since either some features fail
to work or the compiler fails to compile. Sad :(
I have to use the new compiler for compiling my C++20 concepts based IO
library.
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/default/
[Bug c/92296] [10 Regression] GCC build ICE on MinGW-w64. internal compiler error: Segmentation fault #pragma push_macro("__has_builtin")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #3 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #2)
> Most likely the reduced testcase is just:
> #pragma push_macro("__has_builtin")
>
> --- CUT ---
> > I did finish compilation with the same script 3 days ago. Now It fails
>
> That is because the support for __has_builtin was just added within the last
> 3 days :).
Then how can I build a new version of GCC on MinGW? :(
Every day I have to rebuild the entire compiler since either some features fail
to work or the compiler fails to compile.
[Bug c/92296] [10 Regression] GCC build ICE on MinGW-w64. internal compiler error: Segmentation fault #pragma push_macro("__has_builtin")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
Andrew Pinski changed:
What|Removed |Added
Keywords||build, ice-on-valid-code
Target Milestone|--- |10.0
Summary|GCC build ICE on MinGW-w64. |[10 Regression] GCC build
|internal compiler error:|ICE on MinGW-w64. internal
|Segmentation fault #pragma |compiler error:
|push_macro("__has_builtin") |Segmentation fault #pragma
||push_macro("__has_builtin")
--- Comment #2 from Andrew Pinski ---
Most likely the reduced testcase is just:
#pragma push_macro("__has_builtin")
--- CUT ---
> I did finish compilation with the same script 3 days ago. Now It fails
That is because the support for __has_builtin was just added within the last 3
days :).
[Bug c++/92297] The expression 0 / X is simplified to 0 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92297 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- 0 / 0 is undefined so having 0 / X simplify to 0 is a valid thing to do. What were you expecting?
[Bug c++/92297] New: The expression 0 / X is simplified to 0 even when the variable X is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92297 Bug ID: 92297 Summary: The expression 0 / X is simplified to 0 even when the variable X is 0 Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: disquisitiones at gmail dot com Target Milestone: --- Created attachment 47138 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47138=edit the preprocessed file that triggers the bug This error seems present since GCC 7.1, see https://godbolt.org/z/yCP7a7 Output of #g++ -v: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto Thread model: posix gcc version 9.2.0 (GCC) - complete command line that triggers the bug: #g++ -save-temps -o test test.cpp - compiler output: none
[Bug c/92296] GCC build ICE on MinGW-w64. internal compiler error: Segmentation fault #pragma push_macro("__has_builtin")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296 --- Comment #1 from fdlbxtqi --- Here are the patches I am using from msys2. https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/
[Bug c/92296] New: GCC build ICE on MinGW-w64. internal compiler error: Segmentation fault #pragma push_macro("__has_builtin")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
Bug ID: 92296
Summary: GCC build ICE on MinGW-w64. internal compiler error:
Segmentation fault #pragma
push_macro("__has_builtin")
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
/d/mw/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/d/mw/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include -fno-checking -g -march=x86-64
-mtune=generic -O2 -pipe -O2 -I../../../gcc-git/libgcc/../winsup/w32api/include
-g -march=x86-64 -mtune=generic -O2 -pipe -DIN_GCC-W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../.././gcc
-I../../../gcc-git/libgcc -I../../../gcc-git/libgcc/.
-I../../../gcc-git/libgcc/../gcc -I../../../gcc-git/libgcc/../include
-I../../../gcc-git/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -o
_absvsi2.o -MT _absvsi2.o -MD -MP -MF _absvsi2.dep -DL_absvsi2 -c
../../../gcc-git/libgcc/libgcc2.c
/d/mw/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/d/mw/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include -fno-checking -g -march=x86-64
-mtune=generic -O2 -pipe -O2 -I../../../gcc-git/libgcc/../winsup/w32api/include
-g -march=x86-64 -mtune=generic -O2 -pipe -DIN_GCC-W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../.././gcc
-I../../../gcc-git/libgcc -I../../../gcc-git/libgcc/.
-I../../../gcc-git/libgcc/../gcc -I../../../gcc-git/libgcc/../include
-I../../../gcc-git/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -o
_absvdi2.o -MT _absvdi2.o -MD -MP -MF _absvdi2.dep -DL_absvdi2 -c
../../../gcc-git/libgcc/libgcc2.c
In file included from D:/msys64/mingw64/x86_64-w64-mingw32/include/winnt.h:27,
from
D:/msys64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
from D:/msys64/mingw64/x86_64-w64-mingw32/include/windef.h:8,
from
D:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:69,
from ../../../gcc-git/libgcc/libgcc2.c:2183:
D:/msys64/mingw64/x86_64-w64-mingw32/include/psdk_inc/intrin-impl.h:65:9:
internal compiler error: Segmentation fault
65 | #pragma push_macro("__has_builtin")
| ^~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/92289] Worse "control reaches end of non-void function" diagnostic with undefined sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289 Eric Gallager changed: What|Removed |Added Keywords||diagnostic CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- there are some other similar bugs open along these lines; I'll get down their numbers later...
[Bug c/92286] Possible improvement for -Wduplicated-cond warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92286 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=82100 --- Comment #2 from Eric Gallager --- As a user, I don't know if this is really something I'd expect -Wduplicated-cond to warn about; my impression was that that was for when the programmer literally writes the same condition twice, not when the compiler is being smart and figures out conditions are redundant via VRP or whatever... I mean, -Wduplicated-cond prints "previously used here" notes; where would that point in this case? The covered condition is covered by 2 separate previous conditions; would both get notes? I think this warning would make more sense as part of -Wtautological-compare or -Wlogical-op instead, or as part of a revival of -Wunreachable-code, in which case this would be related to (or a dup of) bug 82100
[Bug target/92287] Mismatches in the calling convention for zero sized types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #6 from Segher Boessenkool --- (In reply to Bill Schmidt from comment #5) > For the 32-bit ELF ABI, all structs (regardless of size) are passed using a > pointer allowing for call-by-value semantics. This is the source of ZSTs > requiring a register. So it's clear there is an ABI that requires this > behavior. (Look for the Parameter Passing Register Selection Algorithm in > https://github.com/ryanarn/powerabi/blob/master/chap3-elf32abi.sgml.) > > The 64-bit ABIs (both ELF V1 and ELF V2) pass structures in registers, and > the parameter passing algorithms won't assign registers for size-0 > aggregates. This is intentional. Yup. And everything is identical between LE and BE on all these ABIs. Note that the situation for zero-sized structs isn't very clear in most ABIs, these included. You must have an unusual program if this ever matters ;-)
[Bug target/92295] New: Inefficient vector constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92295
Bug ID: 92295
Summary: Inefficient vector constructor
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-skx-1 microbenchmark]$ cat dup.c
typedef int X __attribute__((vector_size (32)));
X
foo (int x, int z)
{
X y = { x, x, x, x, z, z, z, z };
return y;
}
[hjl@gnu-skx-1 microbenchmark]$ gcc -S -O2 -march=skylake-avx512 dup.c
[hjl@gnu-skx-1 microbenchmark]$ cat dup.s
.file "dup.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
vmovd %esi, %xmm2
vmovd %edi, %xmm3
vpinsrd $1, %esi, %xmm2, %xmm1
vpinsrd $1, %edi, %xmm3, %xmm0
vpunpcklqdq %xmm1, %xmm1, %xmm1
vpunpcklqdq %xmm0, %xmm0, %xmm0
vinserti128 $0x1, %xmm1, %ymm0, %ymm0
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 9.2.1 20190827 (Red Hat 9.2.1-1)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 microbenchmark]$
We can generate:
vpbroadcastd%edi, %xmm0
vpbroadcastd%esi, %xmm1
vinserti128 $1, %xmm1, %ymm0, %ymm0
retq
[Bug modula2/92147] gm2: modula-2 fails to build on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92147 --- Comment #1 from Gaius Mulley --- I've just seen gm2 master branch build successfully on powerpc64le-unknown-linux-gnu (make -j 24). It is currently running the regression tests - looks like it will fail on 15 tests - 6 more than the amd64 (6 tests should fail on every platform). The current master also contains the new coroutine implementation using __gthr.h - which also passes. Just finished the testsuite with: # of expected passes 11247 # of unexpected failures 13 # of unresolved testcases 1 On Fri, 18 Oct 2019 at 11:23, doko at debian dot org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92147 > > Matthias Klose changed: > >What|Removed |Added > > > CC||gaiusmod2 at gmail dot com > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug target/92218] PowerPC indexed insn attribute misses some insns (bswap, atomic, small int float/vector load/store)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92218 Segher Boessenkool changed: What|Removed |Added Target|powerpc64le-gnu-linux, |powerpc* |powerpc64-gnu-linux | Host|powerpc64le-gnu-linux, | |powerpc64-gnu-linux | Build|powerpc64le-gnu-linux, | |powerpc64-gnu-linux | --- Comment #2 from Segher Boessenkool --- The indexed attribute, like most attributes, is mostly used for the scheduling descriptions currently, and isn't set on most insns, only the ones where it makes a difference (and sometimes not those either; patches welcome). If you want to be *sure* what addressing something uses, you already have that available: just look at the RTL itself!
[Bug rtl-optimization/92281] Inconsistent canonicalization of (minus (minus A B) C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- (In reply to Richard Earnshaw from comment #0) > Failed to match this instruction: > (set (reg:SI 125 [+4 ]) > (minus:SI (minus:SI (reg:SI 127) > (reg:SI 121 [ b+4 ])) > (ltu:SI (reg:CC 100 cc) > (const_int 0 [0] > (set (reg:SI 125 [+4 ]) > (minus:SI (minus:SI (reg:SI 127) > (reg:SI 121 [ b+4 ])) > (ltu:SI (reg:CC 100 cc) > (const_int 0 [0] That is (set D (minus (minus A B) (X C 0))) > Successfully matched this instruction: > (set (reg:SI 125 [+4 ]) > (minus:SI (minus:SI (reg:SI 119 [ a+4 ]) > (ltu:SI (reg:CC 100 cc) > (const_int 0 [0]))) > (reg:SI 129))) And this is (set D (minus (minus A (X C 0)) B)) There are no rules for that afaics. > These are mathematically equivalent, but because we do not produce > consistent RTL for them we need two patterns if we are to match both > alternatives. Yes; the same is true for quite a few other unusual combinations. Or not even so very unusual: (ior (ashift X N) (lshiftrt Y M)) vs. (ior (lshiftrt Y M) (ashift X N)) is one nasty example, but also reg+reg+reg where one of the regs is "special" can appear in multiple forms. > I think both should be canonicalized with the LTU inside the inner MINUS > expression, but I wouldn't mind if the other were chosen, as long as we were > consistent. What would the rule become? What targets would it break, and how? What makes combine come up with something else for these two cases?
[Bug c++/83732] wrong warning about non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732 Kenman Tsang changed: What|Removed |Added CC||kentsangkm at gmail dot com --- Comment #6 from Kenman Tsang --- Created attachment 47137 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47137=edit An example error case Sorry for bring this topic back again. But I think there are some inconsistancy with the std::is_pod and the error messages. Refers to my example. A1 is a POD, but the error message said it is "non-POD". Should we either include more detail to the message (like C++98 POD) or to relax the POD checking? I tried the same case with clang. clang successfully compiles and return the correct size. And I cannot found anyway to unify their behavior, hence I cannot have a compiler independent code base Thank you
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 a.h.jaffe at gmail dot com changed: What|Removed |Added CC||a.h.jaffe at gmail dot com --- Comment #17 from a.h.jaffe at gmail dot com --- Jeremy, any information on the ETA of the __OSX_AVAILABLE_STARTING fix? I've got quite a few things I can't compile right now!
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #8 from Jason Merrill --- (In reply to Jason Merrill from comment #6) > But for a constraint with template arguments like, say, same_as, we do, > as we can can run into the same situation as with non-nested requirements: ...except that the draft says — Substitution of template arguments (if any) into the return-type-requirement is performed. This sounds like normal substitution, so we don't need to do normalization at all, just satisfaction.
[Bug bootstrap/92274] 'make' fails when objdir and srcdir paths contain spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92274 --- Comment #4 from joseph at codesourcery dot com --- It's actually generic to anything using make; make is designed around strings that get passed to the shell / split on spaces, rather than having a generic escape mechanism for special characters in target names etc. To the extent there are escape mechanisms, they aren't set up for it to be convenient to escape-for-make whenever some value is passed from shell to make and to escape-for-shell whenever some value is passed in the other direction. Build systems avoiding this issue would probably be ones designed around higher-level structures than strings (when using such build systems, you then e.g. need to pass a list in the appropriate manner if your CC, CXX etc. settings include compiler options, because they don't simply split such settings on spaces).
[Bug c++/91369] Implement P0784R7: constexpr new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369 --- Comment #19 from Jakub Jelinek --- Author: jakub Date: Wed Oct 30 21:55:12 2019 New Revision: 277649 URL: https://gcc.gnu.org/viewcvs?rev=277649=gcc=rev Log: PR c++/91369 - Implement P0784R7: constexpr new * constexpr.c (cxx_replaceable_global_alloc_fn): Don't return true for placement new. (cxx_placement_new_fn, is_std_construct_at): New functions. (cxx_eval_call_expression): Allow placement new in std::construct_at. (potential_constant_expression_1): Likewise. * g++.dg/cpp2a/constexpr-new5.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-new5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/89022] Implement P0202R3 - C++20 Constexpr Modifiers to Functions in and Headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89022 --- Comment #4 from Jonathan Wakely --- Oh, and I removed __cpp_lib_constexpr from today.
[Bug libstdc++/89022] Implement P0202R3 - C++20 Constexpr Modifiers to Functions in and Headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89022 --- Comment #3 from Jonathan Wakely --- (In reply to emsr from comment #2) > I think we're done. > The __cpp_lib_constexpr may not do anything or may not be in the newest > drafts anymore. We should probably kill it. I was very confused as people > were going back and forth about constexpr lib macros. Yeah, it's pretty confusing! > I still owe the patch for misc. constexpr bits. That's not really this PR > though (. It's stuff like pair ctors, insert iterators, etc. I think I did std::pair in r276154 (it was needed for Debug Mode which uses std::pair in some algo checks). I didn't touch the iterators though.
[Bug libstdc++/89022] Implement P0202R3 - C++20 Constexpr Modifiers to Functions in and Headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89022 --- Comment #2 from emsr at gcc dot gnu.org --- I think we're done. The __cpp_lib_constexpr may not do anything or may not be in the newest drafts anymore. We should probably kill it. I was very confused as people were going back and forth about constexpr lib macros. I still owe the patch for misc. constexpr bits. That's not really this PR though (. It's stuff like pair ctors, insert iterators, etc.
[Bug fortran/92284] Subroutine with bind(c) attribute causing varied problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284 Tobias Burnus changed: What|Removed |Added Keywords||wrong-code Status|RESOLVED|NEW Last reconfirmed||2019-10-30 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #5 from Tobias Burnus --- (In reply to José Rui Faustino de Sousa from comment #4) > The new code should ICE 10.0.0, but not 9.1.0, using either the C procedure > or the Fortran bind(c) one. I have now tried (using current GCC trunk + submitted but not committed patch for PR92277): Fortran + C program unmodified: works. BUT: * Leaks memory via _gfortran_gfc_desc_to_cfi_desc (ISO_Fortran_binding.c:100) * valgrind reports "Conditional jump or move depends on uninitialised value(s)" in _gfortran_gfc_desc_to_cfi_desc (ISO_Fortran_binding.c:132)" for the call on the Fortran side (line 50). Hence re-opened. I think one of the recent patches has probably fixed the ICE, it might even the PR92277 patch (which is not yet approved/committed) – See https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02148.html > Using just the "arr_set" procedure with bind(c) set is very likely a > duplicate of PR 92189 like you mention. Presumably – this should be re-checked, once one has a patch for PR 92189. Looking at the memory leakage/mem-access issues: * Memory leak: gfc_desc_to_cfi_desc actually allocates the array descriptor if one has passed a pointer to NULL. That presumably means that one has to undo the the free removal of r277502 for PR91863 – or at least something like that. * The for-loops regarding the bounds should be guarded by "if (GFC_DESCRIPTOR_DATA (s))" – as unallocated/unassociated arrays do not really have array bounds
[Bug sanitizer/92247] ‘__NR_open’ was not declared in this scope libsanitizer/sanitizer_common/sanitizer_linux compilation failed on ubuntu 18.04 WSL2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247 fdlbxtqi changed: What|Removed |Added Resolution|WORKSFORME |INVALID --- Comment #11 from fdlbxtqi --- Not a bug
[Bug sanitizer/92247] ‘__NR_open’ was not declared in this scope libsanitizer/sanitizer_common/sanitizer_linux compilation failed on ubuntu 18.04 WSL2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247 fdlbxtqi changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #10 from fdlbxtqi --- I have found out the reason. I created the incorrect soft link. /usr/include/asm should link to x86_64-linux-gnu/asm/ instead of asm-generic Solution: cd /usr/include sudo rm asm sudo ln -s x86_64-linux-gnu/asm/ asm https://blog.csdn.net/yihui8/article/details/8620914
[Bug c++/92024] crash in check_local_shadow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92024 --- Comment #3 from Bernd Edlinger --- Author: edlinger Date: Wed Oct 30 20:29:21 2019 New Revision: 277643 URL: https://gcc.gnu.org/viewcvs?rev=277643=gcc=rev Log: 2019-10-30 Bernd Edlinger * doc/invoke.texi (-Wshadow, -Wshadow=global -Wshadow=local, -Wshadow=compatible-local): Update documentation. cp: 2019-10-30 Bernd Edlinger PR c++/92024 * name-lookup.c (check_local_shadow): Shadowing TYPE_DECLs is always a -Wshadow=compatible-local warning, unless -Wshadow is used. testsuite: 2019-10-30 Bernd Edlinger PR c++/92024 * g++.dg/parse/crash70.C: New test. * c-c++-common/Wshadow-1.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wshadow-1.c trunk/gcc/testsuite/g++.dg/parse/crash70.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 --- Comment #1 from Jason Merrill --- It would also be helpful to explain for static_assert (!Int);
[Bug fortran/92208] [9/10 Regression] internal compile error, character array of dynamic length returned from function and passed to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92208 --- Comment #4 from Tobias Burnus --- Author: burnus Date: Wed Oct 30 20:01:36 2019 New Revision: 277639 URL: https://gcc.gnu.org/viewcvs?rev=277639=gcc=rev Log: Fortran] PR 92208 don't use function-result dummy variable as actual argument PR fortran/92208 * trans-array.c (gfc_conv_array_parameter): Only copy string-length backend_decl if expression is not a function. PR fortran/92208 * gfortran.dg/pr92208.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pr92208.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug other/92090] [10 regression] ICE in gcc.dg/atomic/c11-atomic-exec-5.c starting with r276469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090 --- Comment #4 from seurer at gcc dot gnu.org --- I retested and the ICE part only occurs on a BE system.
[Bug target/70320] msp430 asm volatile does not accept lower-case register names in clobber list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70320 Jozef Lawrynowicz changed: What|Removed |Added CC||jozefl.gcc at gmail dot com --- Comment #2 from Jozef Lawrynowicz --- This bug is fixed on trunk, I would appreciate if someone would close it for me. Thanks.
[Bug target/92287] Mismatches in the calling convention for zero sized types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287 --- Comment #5 from Bill Schmidt --- For 32-bit big-endian PowerPC (using the 32-bit ELF ABI), the same code generation is provided by GCC and Clang. I.e., here's the code generation for Clang with -O2 -m32 -mbig-endian, using 6.0.0-1ubuntu2: id_foo: # @id_foo .Lfunc_begin0: # %bb.0: mr 3, 4 blr The ABI document used to be posted at power.org, which is defunct. However, the sources are available at github: https://github.com/ryanarn/powerabi For the 32-bit ELF ABI, all structs (regardless of size) are passed using a pointer allowing for call-by-value semantics. This is the source of ZSTs requiring a register. So it's clear there is an ABI that requires this behavior. (Look for the Parameter Passing Register Selection Algorithm in https://github.com/ryanarn/powerabi/blob/master/chap3-elf32abi.sgml.) The 64-bit ABIs (both ELF V1 and ELF V2) pass structures in registers, and the parameter passing algorithms won't assign registers for size-0 aggregates. This is intentional. I hope this is helpful! Bill
[Bug bootstrap/92274] 'make' fails when objdir and srcdir paths contain spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92274 --- Comment #3 from Andrew Pinski --- (In reply to Heiko Eißfeldt from comment #2) > IMHO there are better structured alternatives available (for example the > schily build system from schilytools (sourceforge)). NOTE GCC is not the only issue here but all of the ones which use auto-tools (autoconf, automake, etc.) and that means all of GNU projects really.
[Bug c++/92134] static constinit members incorrectly compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92134 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/92134] static constinit members incorrectly compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92134 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Wed Oct 30 18:49:59 2019 New Revision: 277636 URL: https://gcc.gnu.org/viewcvs?rev=277636=gcc=rev Log: PR c++/92134 - constinit malfunction in static data member. I wasn't properly setting LOOKUP_CONSTINIT in grokfield and so we didn't detect a non-const initializer. * decl2.c (grokfield): Set LOOKUP_CONSTINIT. * g++.dg/cpp2a/constinit14.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/constinit14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/92294] alias attribute generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 Wilco changed: What|Removed |Added Target||aarch64 Target Milestone|--- |10.0
[Bug ipa/92254] [10 regression] ICE LTO in inline_small_functions, at ipa-inline.c:2000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92254 --- Comment #5 from Dmitry G. Dyachenko --- very strange r277625 FAIL for me for testcase from c#1 and for original problem
[Bug rtl-optimization/92294] New: alias attribute generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
Bug ID: 92294
Summary: alias attribute generates incorrect code
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The following example (from gcc.c-torture/execute/alias-2.c) always calls abort
on any AArch64 compiler with -O1 or -O2:
static int a[10];
extern int b[10] __attribute__ ((alias("a")));
int off = 0;
void f(void)
{
b[off]=1;
a[off]=2;
if (b[off]!=2)
__builtin_abort ();
}
Using extern linkage for 'a' avoids the problem, as is doing off = 1 or static
int off = 0. It may only affect targets which use section anchors since
-fno-section-anchors avoids the issue.
[Bug ipa/92278] [10 regression] LTO ICE ipa_get_ith_polymorhic_call_context ipa-prop.h:616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92278 --- Comment #8 from Dmitry G. Dyachenko --- r277625 PASS for me for testcase from c#0 and for original problem. Thank you
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 --- Comment #7 from Jason Merrill --- Created attachment 47136 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47136=edit patch for the simple case This untested patch fixes my testcase and Jon's, though not the more complex case. Not working on this anymore.
[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92206 --- Comment #8 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you! I can confirm that the patch resolved the issue.
[Bug fortran/92284] Subroutine with bind(c) attribute causing varied problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284 --- Comment #4 from José Rui Faustino de Sousa --- Sorry I blooped while trying to simplify the sample code... :-( The new code should ICE 10.0.0, but not 9.1.0, using either the C procedure or the Fortran bind(c) one. Using just the "arr_set" procedure with bind(c) set is very likely a duplicate of PR 92189 like you mention. Sorry for the mishap I hope the code is correct this time around. Thank you very much. Best regards, José Rui
[Bug fortran/92284] Subroutine with bind(c) attribute causing varied problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284 José Rui Faustino de Sousa changed: What|Removed |Added Attachment #47134|0 |1 is obsolete|| --- Comment #3 from José Rui Faustino de Sousa --- Created attachment 47135 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47135=edit Corrected code demonstrating problems.
[Bug fortran/92284] Subroutine with bind(c) attribute causing varied problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284 José Rui Faustino de Sousa changed: What|Removed |Added Attachment #47130|0 |1 is obsolete|| --- Comment #2 from José Rui Faustino de Sousa --- Created attachment 47134 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47134=edit Corrected code demonstrating problems.
[Bug c++/92289] Worse "control reaches end of non-void function" diagnostic with undefined sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289 --- Comment #3 from Jakub Jelinek --- In this particular case, there is instrumentation added because of the -fsanitize=return for the missing return in the function and that affects the warning location.
[Bug c++/92293] New: No reason given for template argument deduction failure with zero-length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92293
Bug ID: 92293
Summary: No reason given for template argument deduction
failure with zero-length array
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
As an extension G++ allows zero-length arrays, but doesn't allow a length of
zero to be deduced:
using size_t = decltype(sizeof(0));
template void f(T(&)[N]) { }
void g()
{
int a[0];
f(a);
}
This prints:
a0.cc: In function 'void g()':
a0.cc:8:6: error: no matching function for call to 'f(int [0])'
8 | f(a);
| ^
a0.cc:3:37: note: candidate: 'template void f(T
(&)[N])'
3 | template void f(T(&)[N]) { }
| ^
a0.cc:3:37: note: template argument deduction/substitution failed:
Note that there is no reason given after the final note.
If you add -pedantic you get a warning on the declaration of the zero-length
array (as expected) and also the reason for deduction failure is shown
(twice!):
a0.cc: In function 'void g()':
a0.cc:7:9: warning: ISO C++ forbids zero-size array 'a' [-Wpedantic]
7 | int a[0];
| ^
a0.cc:8:6: error: no matching function for call to 'f(int [0])'
8 | f(a);
| ^
a0.cc:3:37: note: candidate: 'template void f(T
(&)[N])'
3 | template void f(T(&)[N]) { }
| ^
a0.cc:3:37: note: template argument deduction/substitution failed:
a0.cc: In substitution of 'template void f(T
(&)[N]) [with T = int; long unsigned int N = 0]':
a0.cc:8:6: required from here
a0.cc:3:37: warning: ISO C++ forbids zero-size array [-Wpedantic]
a0.cc:3:39: warning: ISO C++ forbids zero-size array [-Wpedantic]
3 | template void f(T(&)[N]) { }
| ^~~
Should that final pedwarn always be printed when showing the reason for
deduction failure, even without -pedantic?
[Bug c++/92289] Worse "control reaches end of non-void function" diagnostic with undefined sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- If you don't want to see a warning, add [[noreturn]] attribute to throw_sum, -Wreturn-type is an early (front-end) warning, while to find out that throw_sum never returns requires interprocedural analysis which is done much later, at a point where a warning like -Wreturn-type can't be implemented as on the other side a lot of information and potential code paths are lost due to optimizations. Furthermore, -fsanitize= does affect warning diagnostics a lot and there is no way around that in most cases, we don't want to compile everything twice just to give better warnings because not everyone needs that, and you can do that yourself anyway (compile twice, once with -fsanitize=undefined -w and once without sanitization with -Wall -Wextra or whatever you want).
[Bug c/92292] duplicate -Wformat warnings about incorrect printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292 --- Comment #1 from joseph at codesourcery dot com --- This would be an interaction between the built-in function having a printf format attribute and the header having either a gnu_printf or an ms_printf format attribute (depending on feature test macros); as those attributes aren't exact duplicates, both are applied (it's perfectly valid for a function to have multiple format attributes, but I suppose we should special-case this for format attributes for built-in functions with a more specific format attribute in the header declaration).
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
--- Comment #6 from Jason Merrill ---
(In reply to Jason Merrill from comment #5)
> On further thought, I'm not sure normalizing the dependent form is really
> necessary, either here or for nested-requirements, as long as we get the
> proper SFINAE behavior for the requires-expression.
Well...for a simple constraint like this we don't need to do any additional
normalization, as we already have the normal form of forward_iterator.
But for a constraint with template arguments like, say, same_as, we do, as
we can can run into the same situation as with non-nested requirements:
template concept is_void = __is_same_as(Tz, void);
template concept same_as = __is_same_as (Tx, Ty);
template concept void_or_same = is_void || same_as;
template concept foo
= requires { { T() } -> void_or_same; };
template void f() requires foo;
int main() { f(); }
Here, we need to normalize void_or_same and then do satisfaction.
[Bug c/92292] New: duplicate -Wformat warnings about incorrect printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292
Bug ID: 92292
Summary: duplicate -Wformat warnings about incorrect printf
format specifiers
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Target: *-w64-mingw32
Using mingw-w64 the following program gives two warnings. On other target it
only gives one:
#include
int main(void)
{
printf("%lu\n", (long long unsigned)3);
return 0;
}
p.c: In function 'main':
p.c:6:15: warning: format '%lu' expects argument of type 'long unsigned int',
but argument 2 has type 'long long unsigned int' [-Wformat=]
6 | printf("%lu\n", (long long unsigned)3);
| ~~^ ~
| | |
| | long long unsigned int
| long unsigned int
| %I64u
p.c:6:15: warning: format '%lu' expects argument of type 'long unsigned int',
but argument 2 has type 'long long unsigned int' [-Wformat=]
6 | printf("%lu\n", (long long unsigned)3);
| ~~^ ~
| | |
| | long long unsigned int
| long unsigned int
| %I64u
[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #8 from Wilco --- Note gcc.target/aarch64/pr71727.c fails when compiled with -mstrict-align -fno-common -O3: adrpx2, .LC0 adrpx3, .LC1 adrpx1, xarray add x0, x1, :lo12:xarray ldr q1, [x2, #:lo12:.LC0] mov x2, 5 ldr q0, [x3, #:lo12:.LC1] str x2, [x0, 32] str q1, [x1, #:lo12:xarray] str q0, [x0, 16] ret .bss .align 4 .type xarray, %object .size xarray, 5120 xarray: .zero 5120
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 Jason Merrill changed: What|Removed |Added Summary|Constraint normalization|[concepts] hard error |substitutes parameter too |satisfying |early |return-type-requirement --- Comment #5 from Jason Merrill --- On further thought, I'm not sure normalizing the dependent form is really necessary, either here or for nested-requirements, as long as we get the proper SFINAE behavior for the requires-expression.
[Bug c++/88337] Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337
--- Comment #6 from Marek Polacek ---
First steps: this now compiles in c++2a:
struct B {
virtual void baz () {}
};
struct D : B { };
constexpr bool
fn ()
{
bool ok = true;
B b;
B *b1 =
if (D *pd = dynamic_cast(b1))
ok = false;
D d;
B *b2 =
if (D *pd = dynamic_cast(b2))
/*OK*/;
else
ok = false;
return ok;
}
static_assert(fn ());
[Bug ipa/92254] [10 regression] ICE LTO in inline_small_functions, at ipa-inline.c:2000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92254 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Martin Jambor --- This is indeed a duplicate of PR 92278. *** This bug has been marked as a duplicate of bug 92278 ***
[Bug ipa/92278] [10 regression] LTO ICE ipa_get_ith_polymorhic_call_context ipa-prop.h:616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92278 --- Comment #7 from Martin Jambor --- *** Bug 92254 has been marked as a duplicate of this bug. ***
[Bug fortran/92284] Subroutine with bind(c) attribute causing varied problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Depends on||92189 Resolution|--- |INVALID --- Comment #1 from Tobias Burnus --- > The problems reported vary depending on the array having the allocatable or > pointer attributes. In any case, your example is INVALID: Fortran 2018 has in "15.5.2.13 Restrictions on entities associated with dummy arguments": "While an entity is associated with a dummy argument, the following restrictions hold. (1) Action that affects the allocation status of the entity or a subobject thereof shall be taken through the dummy argument. […]" Any your code does: call arr_set(arr) … subroutine arr_set(this) bind(c) integer(kind=c_int), pointer, intent(out) :: this(:) allocate(arr(n)) … do i = 1, size(this) If you fix your code, you might well run into my PR 92189. [There are good reasons why it cannot work with 'pointer' even without bind(C). For allocatable, without 'target' you also break the alias handling. And as soon as the internal representation (array descriptor) w/ and w/o bind(C) is different [as with gfortran] it can also not work – even with 'allocatable, target'.] * * * An ICE is still a bug, but as it is not a regression and does not fail with GCC 10, I still close this PR. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92189 [Bug 92189] Fortran-written bind(C) function with allocatable argument does not update C descriptor on exit
[Bug ipa/92278] [10 regression] LTO ICE ipa_get_ith_polymorhic_call_context ipa-prop.h:616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92278 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Jambor --- Oops, I forgot the letters PR in the ChangeLog. Fixed with: Author: jamborm Date: Wed Oct 30 15:47:29 2019 New Revision: 277627 URL: https://gcc.gnu.org/viewcvs?rev=277627=gcc=rev Log: Edges to interposable calles are possibly_call_in_translation_unit_p 2019-10-30 Martin Jambor ipa/92278 * cgraph.c (cgraph_edge::possibly_call_in_translation_unit_p): Fix availability comparison. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c
[Bug target/92287] Mismatches in the calling convention for zero sized types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287 --- Comment #4 from gnzlbg --- Thanks for chiming in. I see the value in having a simple ABI rule. I guess what confuses me is that the address passed in the calling convention for that struct will never be used for anything or dereferenced.
[Bug target/92291] New: Non-optimal code generated for H8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92291
Bug ID: 92291
Summary: Non-optimal code generated for H8
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mti-1 at tillenius dot com
Target Milestone: ---
I am using a cross compiler for Renesas H8S. In a few places it generates
really bad code. Given the following program:
struct s {
char a, b;
char c[11];
} x[2];
void test(int n)
{
struct s *sp = [n];
sp->a = 1;
sp->b = 1;
}
I would expect that the pointer "sp" is calculated once and reused to access
the fields "a" and "b". But instead the pointer is recalculated for each
access. This generates a lot of extra code, including calls to __mulhi3. I have
tested with gcc 8.2 and 9.2 and with different optimization levels (-O1, -O2,
-Os) all with the same result. With -O0 "sp" is only calculated once and kept
as a variable on the stack but the rest of the code is not as good as it could
be.
---
Using built-in specs.
COLLECT_GCC=h8300-none-elf-gcc
Target: h8300-none-elf
Configured with: /home/mti/abs/arm-none-eabi-gcc/h8/src/gcc-9.2.0/configure
--target=h8300-none-elf --prefix=/usr --with-native-system-header-dir=/include
--libexecdir=/usr/lib --enable-languages=c,c++ --enable-plugins
--disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch
--disable-libstdcxx --disable-nls --disable-shared --disable-threads
--disable-tls --with-gnu-as --with-gnu-ld --with-system-zlib --without-headers
--with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc
--with-isl --with-libelf --enable-gnu-indirect-function
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='Arch Repository' --with-bugurl=https://bugs.archlinux.org/
--with-multilib-list=rmprofile
Thread model: single
gcc version 9.2.0 (Arch Repository)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-S' '-Wall'
/usr/lib/gcc/h8300-none-elf/9.2.0/cc1 -E -quiet -v test.c -Wall -O1
-fpch-preprocess -o test.i
ignoring nonexistent directory
"/usr/lib/gcc/h8300-none-elf/9.2.0/../../../../h8300-none-elf/sys-include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/h8300-none-elf/9.2.0/include
/usr/lib/gcc/h8300-none-elf/9.2.0/include-fixed
/usr/lib/gcc/h8300-none-elf/9.2.0/../../../../h8300-none-elf/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-S' '-Wall'
/usr/lib/gcc/h8300-none-elf/9.2.0/cc1 -fpreprocessed test.i -quiet -dumpbase
test.c -auxbase test -O1 -Wall -version -o test.s
GNU C17 (Arch Repository) version 9.2.0 (h8300-none-elf)
compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (Arch Repository) version 9.2.0 (h8300-none-elf)
compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 67bb4ca8e2b97056926c3ecedb8a3eae
COMPILER_PATH=/usr/lib/gcc/h8300-none-elf/9.2.0/:/usr/lib/gcc/h8300-none-elf/9.2.0/:/usr/lib/gcc/h8300-none-elf/:/usr/lib/gcc/h8300-none-elf/9.2.0/:/usr/lib/gcc/h8300-none-elf/:/usr/lib/gcc/h8300-none-elf/9.2.0/../../../../h8300-none-elf/bin/
LIBRARY_PATH=/usr/lib/gcc/h8300-none-elf/9.2.0/:/usr/lib/gcc/h8300-none-elf/9.2.0/../../../../h8300-none-elf/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-S' '-Wall'
[Bug target/92287] Mismatches in the calling convention for zero sized types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287 --- Comment #3 from Jozef Lawrynowicz --- (In reply to gnzlbg from comment #2) > > I can only speak for msp430, but there's no problem with that generated > > assembly. Structures and unions are always passed by reference. > > I suppose that by this you mean that the current behavior is "by design", is > that correct ? > > If so, could you explain the rationale of this design or point me to the ABI > specification document or rationale for it ? I was just considering from an MSP430 point of view, that if the struct can have an address (it looks like it can, even though it has zero size), then that assembly is correct. I'm afraid I don't have any specific insight into how GCC generically handles zero sized structs beyond that though. The MSP430 ABI is here: http://www.ti.com/lit/an/slaa534/slaa534.pdf Although confusingly that document is wrong regarding passing structures and unions by reference. As I mentioned before, structures and unions are always passed by reference, regardless of size.
[Bug c/92230] Proposal to have builtin underflow detection function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92230 Ariel Torti changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Ariel Torti --- You got it right, I accidentally used the signed version and got confused by the result.
[Bug libstdc++/92272] concepts check failed: std::vector iterator and std::string iterator are not contiguous iterator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92272 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Wed Oct 30 15:48:11 2019 New Revision: 277629 URL: https://gcc.gnu.org/viewcvs?rev=277629=gcc=rev Log: Apply C++20 changes to various iterator types This ensures that __normal_iterator satisfies the contiguous_iterator concept, by defining the iterator_concept member type. Also update vector's iterators, reverse_iterator, istreambuf_iterator and ostreambuf_iterator to meet the C++20 requirements. PR libstdc++/92272 * include/bits/stl_bvector.h (_Bit_iterator::pointer) (_Bit_const_iterator::pointer): Define as void for C++20. * include/bits/stl_iterator.h (reverse_iterator::operator->()): Add constraints for C++20. (__normal_iterator::iterator_concept): Define for C++20. * include/bits/streambuf_iterator.h (istreambuf_iterator::pointer): Define as void for C++20. (ostreambuf_iterator::difference_type): Define as ptrdiff_t for C++20. (ostreambuf_iterator::ostreambuf_iterator()): Add default constructor for C++20. * testsuite/23_containers/vector/bool/iterator_c++20.cc: New test. * testsuite/24_iterators/bidirectional/concept.cc: New test. * testsuite/24_iterators/bidirectional/tag.cc: New test. * testsuite/24_iterators/contiguous/concept.cc: New test. * testsuite/24_iterators/contiguous/tag.cc: New test. * testsuite/24_iterators/forward/concept.cc: New test. * testsuite/24_iterators/forward/tag.cc: New test. * testsuite/24_iterators/input/concept.cc: New test. * testsuite/24_iterators/input/tag.cc: New test. * testsuite/24_iterators/istreambuf_iterator/requirements/typedefs.cc: New test. * testsuite/24_iterators/ostreambuf_iterator/requirements/typedefs.cc: New test. * testsuite/24_iterators/output/concept.cc: New test. * testsuite/24_iterators/output/tag.cc: New test. * testsuite/24_iterators/random_access/concept.cc: New test. * testsuite/24_iterators/random_access/tag.cc: New test. * testsuite/24_iterators/range_operations/advance_debug_neg.cc: New test. * testsuite/24_iterators/random_access_iterator/26020.cc: Move to ... * testsuite/24_iterators/operations/26020.cc: ... here. * testsuite/24_iterators/random_access_iterator/ string_vector_iterators.cc: Move to ... * testsuite/24_iterators/random_access/string_vector_iterators.cc: ... here. Added: trunk/libstdc++-v3/testsuite/23_containers/vector/bool/iterator_c++20.cc - copied, changed from r277628, trunk/libstdc++-v3/testsuite/24_iterators/contiguous/concept.cc trunk/libstdc++-v3/testsuite/24_iterators/bidirectional/ trunk/libstdc++-v3/testsuite/24_iterators/bidirectional/concept.cc trunk/libstdc++-v3/testsuite/24_iterators/bidirectional/tag.cc - copied, changed from r277628, trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/26020.cc trunk/libstdc++-v3/testsuite/24_iterators/forward/ trunk/libstdc++-v3/testsuite/24_iterators/forward/concept.cc trunk/libstdc++-v3/testsuite/24_iterators/forward/tag.cc - copied, changed from r277628, trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/26020.cc trunk/libstdc++-v3/testsuite/24_iterators/input/ trunk/libstdc++-v3/testsuite/24_iterators/input/concept.cc trunk/libstdc++-v3/testsuite/24_iterators/input/tag.cc - copied, changed from r277628, trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/26020.cc trunk/libstdc++-v3/testsuite/24_iterators/operations/26020.cc - copied, changed from r277628, trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/26020.cc trunk/libstdc++-v3/testsuite/24_iterators/output/ trunk/libstdc++-v3/testsuite/24_iterators/output/concept.cc trunk/libstdc++-v3/testsuite/24_iterators/output/tag.cc - copied, changed from r277628, trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/26020.cc trunk/libstdc++-v3/testsuite/24_iterators/random_access/ trunk/libstdc++-v3/testsuite/24_iterators/random_access/concept.cc trunk/libstdc++-v3/testsuite/24_iterators/random_access/string_vector_iterators.cc - copied, changed from r277628, trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/string_vector_iterators.cc trunk/libstdc++-v3/testsuite/24_iterators/random_access/tag.cc - copied, changed from r277628, trunk/libstdc++-v3/testsuite/24_iterators/contiguous/concept.cc trunk/libstdc++-v3/testsuite/24_iterators/range_operations/advance_debug_neg.cc - copied, changed from r277628, trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/26020.cc Removed: trunk/libstdc++-v3/testsuite/24_iterators/random_access_iterator/ Modified: trunk/libstdc++-v3/ChangeLog
[Bug libstdc++/92272] concepts check failed: std::vector iterator and std::string iterator are not contiguous iterator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92272 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|jwakely at redhat dot com | Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Jonathan Wakely --- Fixed.
[Bug bootstrap/92274] 'make' fails when objdir and srcdir paths contain spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92274 --- Comment #2 from Heiko Eißfeldt --- As I see it, there are multiple issues with the current approach. 1. Since absolute paths (as opposed to relative paths) are used, one cannot move the configured source tree to some other location and use it there. 2. Some problematic character [@: ] in the base directory path can screw up the whole setup, so it is a bit fragile. 3. The documentation (https://gcc.gnu.org/install/configure.html) does not mention this requirement. 4. The size of the generated Makefile is well above 900 kilobytes, making an analysis to fix the original issue unnecessary difficult. IMHO there are better structured alternatives available (for example the schily build system from schilytools (sourceforge)). Thanks, Heiko
[Bug target/92287] Mismatches in the calling convention for zero sized types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287 --- Comment #2 from gnzlbg --- > I can only speak for msp430, but there's no problem with that generated > assembly. Structures and unions are always passed by reference. I suppose that by this you mean that the current behavior is "by design", is that correct ? If so, could you explain the rationale of this design or point me to the ABI specification document or rationale for it ?
[Bug c/92290] New: Inconsistent -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92290
Bug ID: 92290
Summary: Inconsistent -Warray-bounds warning
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Created attachment 47133
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47133=edit
testcase
The attached creduced testcases recently started to warn differently in trunk
(9 and earlier don't warn) depending on variable signedness. But I believe the
possible range of the loop counter values should be the same.
int a, b;
unsigned short t1 (void)
{
int j;
unsigned short pu = 0;
unsigned int p[6] = { 0 };
unsigned int v;
for (j = 0; j < 1234; j++)
{
v = a;
if (((v >> 16) & 7) > 0)
{
int i;
b = p[0];
for (i = 0; i < 6 - (int) ((v >> 16) & 0x07); i++)
p[i] = p[i + ((v >> 16) & 0x07)];
}
pu >>= (int) ((v >> 16) & 0x07) * 2;
}
return pu;
}
Compiled with -O2 -Warray-bounds, GCC trunk@277601 warns like this:
testcase.c: In function 't1':
testcase.c:17:14: warning: array subscript 6 is above array bounds of 'unsigned
int[6]' [\-Warray-bounds=\]
17 | p[i] = p[i + ((v >> 16) & 0x07)];
| ~^~~~
testcase.c:7:16: note: while referencing ?p?
7 | unsigned int p[6] = { 0 };
|^
t2() is a slight modification with re-arranged loop condition and gives the
same warning.
t3() uses an unsigned loop variable and doesn't warn, which seems the correct
behaviour to me.
[Bug target/92287] Mismatches in the calling convention for zero sized types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287 Jozef Lawrynowicz changed: What|Removed |Added CC||jozefl.gcc at gmail dot com --- Comment #1 from Jozef Lawrynowicz --- I can only speak for msp430, but there's no problem with that generated assembly. Structures and unions are always passed by reference. R12:R15 are the argument registers, and the return value starts in R12.
[Bug c++/92289] Worse "control reaches end of non-void function" diagnostic with undefined sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289 --- Comment #1 from Tony E Lewis --- Sorry: I should have said... Even the original warning isn't ideal because the compiler has enough information to know that all paths through f() either return a value or throw. So I don't think it should warn at all really. But if it is going to warn, I don't think its diagnostics should degrade when UBSan is enabled.
[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283 --- Comment #6 from Martin Liška --- Created attachment 47132 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47132=edit Debugging patch With the attached patch (and r276645) run succeeds. If you change s/counter < 2/counter < 1/ then it fails. Can you please Richi reproduce that locally?
[Bug c++/92289] New: Worse "control reaches end of non-void function" diagnostic with undefined sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289
Bug ID: 92289
Summary: Worse "control reaches end of non-void function"
diagnostic with undefined sanitizer
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
When I use Godbolt's GCC (9.2 or trunk ("10.0.0 20191022 (experimental)")) to
compile:
~~~
void throw_sum( int a, int b ) { throw a + b; }
#define THROW_WITH_LINE_NUM_ADDED( x ) throw_sum( x, __LINE__ )
bool f( const bool _val ) {
if ( prm_val ) { return true; }
THROW_WITH_LINE_NUM_ADDED( 0 );
}
~~~
...with `-Werror` I get a helpful warning (promoted to error):
~~~
: In function 'bool f(const bool&)':
:9:1: error: control reaches end of non-void function
[-Werror=return-type]
9 | }
| ^
cc1plus: all warnings being treated as errors
Compiler returned: 1
~~~
...but if I turn on UBSan (ie change the options to `-Werror
-fsanitize=undefined`), I get:
~~~
: In function 'bool f(const bool&)':
:3:49: error: control reaches end of non-void function
[-Werror=return-type]
3 | #define THROW_WITH_LINE_NUM_ADDED( x ) throw_sum( x, __LINE__ )
|~^~~
:8:4: note: in expansion of macro 'THROW_WITH_LINE_NUM_ADDED'
8 |THROW_WITH_LINE_NUM_ADDED( 0 );
|^
cc1plus: all warnings being treated as errors
Compiler returned: 1
~~~
...which I think is much less helpful. I don't think that enabling runtime
sanitizer checks should reduce the quality of the compiler's diagnostics.
Thanks very much to all who work on GCC.
[Bug middle-end/92231] [9/10 Regression] ICE in gimple_fold_stmt_to_constant_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92231 --- Comment #2 from Jakub Jelinek --- Created attachment 47131 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47131=edit gcc10-pr92231.patch Untested fix.
[Bug tree-optimization/92288] New: [10 Regression] 502.gcc_r ICE with -O3 -march=skylake -fno-checking since r277621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92288 Bug ID: 92288 Summary: [10 Regression] 502.gcc_r ICE with -O3 -march=skylake -fno-checking since r277621 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Before the revision there was a checking assert (that I disabled with -fno-checking). Can reproduce with test size: runcpu --config=spec2017 --size=test --iterations=1 --no-reportable -I --action=run --tune=peak 502.gcc_r -D Contents of t1.opts-O3_-finline-limit_5.err t1.c:2:5: warning: conflicting types for built-in function 'printf' t1.c: In function 'main': t1.c:9:1: benchmark internal error: in ?, at df-scan.c:1573 The 502.gcc_r benchmark binary 'cpugcc_r' has encountered an internal error. It is possible that there is an error in the benchmark 502.gcc_r source code, but it is more likely that your compiler has mis-optimized or otherwise generated bad code for the benchmark. You might try reducing the optimization level; see your compiler documentation. If you think the error is in the benchmark source code, see www.spec.org/cpu2017/Docs/techsupport.html Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug tree-optimization/92288] [10 Regression] 502.gcc_r ICE with -O3 -march=skylake -fno-checking since r277621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92288 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-30 Known to work||9.2.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug c++/79274] FAIL: g++.dg/tls/pr77285-2.C -std=c++11 scan-assembler _ZTH4var1B3tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79274 --- Comment #2 from dave.anglin at bell dot net --- On 2019-10-30 10:12 a.m., iains at gcc dot gnu.org wrote: > when you say "Think this is a result of emutls." - you mean that hppa is also > (Darwin does) using emuTLS? hppa uses emutls on hpux.
[Bug target/92287] New: Mismatches in the calling convention for zero sized types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
Bug ID: 92287
Summary: Mismatches in the calling convention for zero sized
types
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gonzalobg88 at gmail dot com
Target Milestone: ---
Consider this code:
struct foo {};
int id_foo(struct foo bar, int x) {
return x;
}
int id(int x) {
return x;
}
This link shows the assembly generated for MSP430, MIPS64el, PPC32 and PPC64
(https://godbolt.org/z/yOCJ-z), reproduced here for completeness:
;; MIPS64:
id_foo:
j $31
move$2,$4
id:
j $31
move$2,$4
;; MSP430:
id_foo:
MOV.W R13, R12
RET
id:
RET
;; POWERPC64LE
id_foo:
blr
.long 0
.byte 0,0,0,0,0,0,0,0
id:
blr
.long 0
.byte 0,0,0,0,0,0,0,0
;; POWERPC
id_foo:
mr 3,4
blr
id:
blr
Notice how MSP430 and POWERPC passes ZSTs in the calling convention, while
MIPS64 and POWERPC64LE ignore them.
I can't find an ABI specification document for the MSP430 and POWERPC targets,
so I was wondering whether this is
a bug in the GCC implementation of the ABI for these targets. And if not, then
why do these targets care
about passing zero-sized types in their calling convention? Is this documented
anywhere?
(Note: other targets might be affected as well)
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 92275, which changed state. Bug 92275 Summary: [10 Regression] ICE: error: definition in block 11 does not dominate use in block 15 since r277566 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92275 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/92275] [10 Regression] ICE: error: definition in block 11 does not dominate use in block 15 since r277566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92275 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug ipa/92278] [10 regression] LTO ICE ipa_get_ith_polymorhic_call_context ipa-prop.h:616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92278 --- Comment #5 from Martin Jambor --- See https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02139.html for a possible fix.
[Bug target/89346] Unnecessary EVEX encoding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89346 Peter Cordes changed: What|Removed |Added CC||peter at cordes dot ca --- Comment #1 from Peter Cordes --- Still present in pre10.0.0 trunk 20191022. We pessimize vmovdqu/a in AVX2 intrinsics and autovectorization with -march=skylake-avx512 (and arch=native on such machines) It seems only VMOVDQU/A load/store/register-copy instructions are affected; we get AVX2 VEX vpxor instead of AVX512VL EVEX vpxord for xor-zeroing, and non-zeroing XOR. (And most other instructions have the same mnemonic for VEX and EVEX, like vpaddd. This includes FP moves like VMOVUPS/PD) (https://godbolt.org/z/TEvWiU for example) The good options are: * use VEX whenever possible instead of AVX512VL to save code-size. (2 or 3 byte prefix instead of 4-byte EVEX) * Avoid the need for vzeroupper by using only x/y/zmm16..31. (Still has a max-turbo penalty so -mprefer-vector-width=256 is still appropriate for code that doesn't spend a lot of time in vectorized loops.) This might be appropriate for very simple functions / blocks that only have a few SIMD instructions before the next vzeroupper would be needed. (e.g. copying or zeroing some memory); could be competitive on code-size as well as saving the 4-uop instruction. VEX instructions can't access x/y/zmm16..31 so this forces an EVEX encoding for everything involving the vector (and rules out using AVX2 and earlier instructions, which may be a problem for KNL without AVX512VL unless we narrow to 128-bit in an XMM reg) (citation for not needing vzeroupper if y/zmm0..15 aren't written explicitly: https://stackoverflow.com/questions/58568514/does-skylake-need-vzeroupper-for-turbo-clocks-to-recover-after-a-512-bit-instruc - it's even safe to do vpxor xmm0,xmm0,xmm0 vpcmpeqb k0, zmm0, [rdi] without vzeroupper. Although that will reduce max turbo *temporarily* because it's a 512-bit uop. Or more frequently useful: to zero some memory with vpxor xmm zeroing and YMM stores.
[Bug c++/79274] FAIL: g++.dg/tls/pr77285-2.C -std=c++11 scan-assembler _ZTH4var1B3tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79274 Iain Sandoe changed: What|Removed |Added Target|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11,*-*-d ||arwin* Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-30 CC||iains at gcc dot gnu.org Host|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11,*-*-d ||arwin* Target Milestone|--- |7.5 Ever confirmed|0 |1 --- Comment #1 from Iain Sandoe --- the test was changed to require tls_native (from gcc 9+). I see the same issue on Darwin on gcc8/7 when you say "Think this is a result of emutls." - you mean that hppa is also (Darwin does) using emuTLS? AFAIR, [with emuTLS] there's no proper init of global TLS vars when they are in a different TU from the one referencing - which is what the _ZTH4/_ZTW4var1B3tag symbols are about. (It's on my [very long] TODO to see if there's a way of doing the same thing for emuTLS - that is done for the native case). I'd say we just need to back-port the require native_tls [or xfail] to the earlier branches (if that's permitted).
[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283 --- Comment #5 from Martin Liška --- So the problematic file is results.f. If I use code from the previous revision for the file, there is no miscomparison. Now I'll bisect which loop is causing the miscompilation. Optimized dumps differ quite significantly.
[Bug tree-optimization/92275] [10 Regression] ICE: error: definition in block 11 does not dominate use in block 15 since r277566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92275 --- Comment #4 from Richard Biener --- Author: rguenth Date: Wed Oct 30 13:52:27 2019 New Revision: 277621 URL: https://gcc.gnu.org/viewcvs?rev=277621=gcc=rev Log: 2019-10-30 Richard Biener PR tree-optimization/92275 * tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops): Copy all loop-closed PHIs. * gcc.dg/torture/pr92275.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr92275.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop-manip.c
[Bug ipa/92234] [10 Regression] ICE verify_gimple failed (profiled lto) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92234 --- Comment #4 from Matthias Klose --- --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=yes --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex
[Bug libstdc++/92285] Layout of istreambuf_iterator subobject depends on -std mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92285 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-10-30 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- (In reply to Richard Biener from comment #1) > Ugh. I hope we can keep the "new" ABI for the default std though? That > means > breaking it also for -std=c++98? Yes, see https://gcc.gnu.org/ml/libstdc++/2019-10/msg00129.html for additional discussion of the options and what breaks with each one. As I said there, I would prefer to keep the default std unchanged, even though that breaks c++98. > Or simply document this defect :/ Yes, and I'll be adding it to https://gcc.gnu.org/wiki/Cxx11AbiCompatibility too. > "Works" in 4.6.4 as far as I can see, broken starting with 4.7. Yeah.
