[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Target Milestone|--- |8.4 --- Comment #17 from Iain Sandoe --- I have a patch series to fix this - but it's not really appropriate this late in stage 4. So plan is to fix in early 10 stage 1 and back port. (you can try my pending patch series from https://github.com/iains/gcc-8-branch, I don't expect to make too much change from that). the key patch for this is - https://github.com/iains/gcc-8-branch/commit/85d8544e8cfab2e89198e83373b169b29c429777 but it probably won't apply cleanly without the preceding ones.
[Bug tree-optimization/90021] [9 Regression] ICE in index_in_loop_nest, at tree-data-ref.h:587 since r270203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90021 --- Comment #5 from bin cheng --- (In reply to Jakub Jelinek from comment #4) > From what I can see, a fix for this has been acked 11 days ago: > https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00413.html > Bin, are you going to commit it? I just commit it. There was a typo in PR number of ChangeLog entry, so this PR is not update. For the record, it's https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=270499
[Bug tree-optimization/90078] [7/8/9 Regression] ICE with deep templates caused by overflow [PATCH]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078 --- Comment #9 from bin cheng --- Author: amker Date: Tue Apr 23 04:07:46 2019 New Revision: 270500 URL: https://gcc.gnu.org/viewcvs?rev=270500&root=gcc&view=rev Log: PR tree-optimization/90078 * tree-ssa-loop-ivopts.c (comp_cost::operator +,-,+=,-+,/=,*=): Add checks for infinite_cost overflow. gcc/testsuite * gcc/testsuite/g++.dg/tree-ssa/pr90078.C: New test. Also fix typo in ChangeLog entry for revision 270499. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr90078.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug c/89774] Add flag to force single precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #10 from JunMa ---
(In reply to Segher Boessenkool from comment #9)
> We currently only do it for trivial cases, as the example in comment 6 shows
> as well. This is done during expand, which is the wrong place for it.
>
> PR90070 is asking for better optimisation of this: do the operation in single
> precision, and use single-precision constants, if this does not change the
> result (or there is some -ffast-math option).
>
> PR22326 is also closely related. I don't think we can close any of these PRs
> as a dup of another, they are all asking for slightly different things :-)
clang can do this optimization in instcombine pass. see this case:
float f4( float x ) {double t = x + 2.0; return t; }
float f5( float x ) {return x + 2.0; }
compiled with -O2 -march=native, GCC gives:
f4:
vcvtss2sd%xmm0, %xmm0, %xmm0
vaddsd .LC1(%rip), %xmm0, %xmm0
vcvtsd2ss%xmm0, %xmm0, %xmm0
ret
f5:
vaddss .LC3(%rip), %xmm0, %xmm0
ret
while clang always emits vaddss instruction.
[Bug libstdc++/90192] std::vector::resize() requires more than it should (CopyInsertable)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90192 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-22 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- The requirements were altered by https://wg21.link/lwg2033 (and then simplified by https://wg21.link/lwg2323 to remove some redundancy). Looks like we never implemented 2033. I think we need to stop using _M_fill_insert for resize.
[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205 --- Comment #4 from Jonathan Wakely --- (In reply to Jonny Grant from comment #2) > The 'argument' is float, within the printf it arrives as a 'parameter' of > type double after the promotion before the call. Yes, it seems more correct to say "but argument 2 has type 'float'"
[Bug fortran/90166] Compiler Fails at Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90166 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on trunk.
[Bug fortran/90166] Compiler Fails at Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90166 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Apr 22 21:00:40 2019 New Revision: 270495 URL: https://gcc.gnu.org/viewcvs?rev=270495&root=gcc&view=rev Log: 2019-04-19 Steven G. Kargl PR fortran/90166 * decl.c (in_module_or_interface): New function to check that the current state is in a module, submodule, or interface. (gfc_match_prefix): Use it. 2019-04-19 Steven G. Kargl PR fortran/90166 * gfortran.dg/submodule_22.f08: Add additional dg-error comments. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/submodule_22.f08
[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205
--- Comment #3 from Jonny Grant ---
A clang++ example, doing it as I expected, showing the type before automatic
promotion. I did with char, as I couldn't find a -Wformat-signedness for the
original example code in clang++
#include
int main()
{
char b = 'b';
printf("%f", b);
}
#1 with x86-64 clang (trunk)
:5:18: warning: format specifies type 'double' but the argument has
type 'char' [-Wformat]
printf("%f", b);
~~ ^
%c
1 warning generated.
Compiler returned: 0
[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205
--- Comment #2 from Jonny Grant ---
(In reply to Andreas Schwab from comment #1)
> %f is correct for double.
Yes, the float was promoted to double via the ellipsis ... as I understand it
(default type promotion - I am sure you know a lot more about this than I do),
but the message should say 'float' like the following I thought?
The 'argument' is float, within the printf it arrives as a 'parameter' of type
double after the promotion before the call.
I guess what I am saying, is the message should state the type before the
promotion? Clang does it as I expect
I expected:
:5:14: warning: format '%d' expects argument of type 'int', but
argument 2 has type 'float' [-Wformat=]
5 | printf("%d", i);
| ~^ ~
| | |
| int float
| %f
[Bug c++/90173] [9 Regression] ICE: Segmentation fault (in strip_declarator_types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90173 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-22 CC||paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- I believe we can cut it short and simply do (passes testing): Index: decl.c === --- decl.c (revision 270483) +++ decl.c (working copy) @@ -10973,6 +10973,7 @@ grokdeclarator (const cp_declarator *declarator, error_at (typespec_loc, "template placeholder type %qT must be followed " "by a simple declarator-id", type); inform (DECL_SOURCE_LOCATION (tmpl), "%qD declared here", tmpl); + return error_mark_node; } staticp = 0;
[Bug tree-optimization/89847] Simplify subexpressions of % constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89847
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-04-22
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool ---
They didn't test the right targets ;-)
While for x86_64 you get
movl%edi, %eax
sall$5, %eax
subl%edi, %eax
addl$27961, %eax
andl$15, %eax
ret
and for aarch64 you get
lsl w1, w0, 5
sub w0, w1, w0
mov w1, 27961
add w0, w0, w1
and w0, w0, 15
ret
for sparc{,64} you get
sethi %hi(27648), %g1
or %g1, 313, %g1
sub %g1, %o0, %o0
jmp %o7+8
and%o0, 15, %o0
(the mul-by-31 was optimised away by combine).
While for 32-bit powerpc you get
mulli 3,3,31
addi 3,3,27961
rlwinm 3,3,0,28,31
blr
(if you don't set a modern -mcpu=, anyway), for powerpc64 you get
subfic 3,3,9
rldicl 3,3,0,60
blr
This again is done by combine:
Trying 10, 11 -> 12:
10: r129:SI=r128:SI-r132:DI#4
REG_DEAD r132:DI
REG_DEAD r128:SI
11: r130:SI=r129:SI+0x6d39
REG_DEAD r129:SI
12: r125:SI=r130:SI&0xf
REG_DEAD r130:SI
Failed to match this instruction:
(set (reg:SI 125)
(and:SI (minus:SI (const_int 9 [0x9])
(subreg:SI (reg:DI 132) 4))
(const_int 15 [0xf])))
Successfully matched this instruction:
(set (reg:SI 130)
(minus:SI (const_int 9 [0x9])
(subreg:SI (reg:DI 132) 4)))
Successfully matched this instruction:
(set (reg:SI 125)
(and:SI (reg:SI 130)
(const_int 15 [0xf])))
Ideally this would be done in gimple already, of course. Combine cannot
handle this in general.
[Bug inline-asm/90181] Feature request: provide a way to explicitly select specific named registers in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181 --- Comment #6 from nfxjfg at googlemail dot com --- Yes, it's clear that that the constraint can't be _just_ the register name, since they'll clash with builtin constraints now or with future architectures (which may add arbitrary register names). The proposed "*registername" is pretty nice, though. Having this would be great. I didn't find a RISC-V builtin for ecall (maybe I looked in the wrong place). That wouldbn't be sufficient anyway. Another situation where I wanted to specify many fixed register constraints was a piece of inline code that did some syscalls without touching the stack (it needed all inputs as registers, and in specific registers, and have some registers for free use by the asm code itself). Throwing macros at the problem does help to reduce the duplication, but I think this proposed extension would solve this in a better way.
[Bug fortran/90207] Debugging generated tree code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90207 Thomas Koenig changed: What|Removed |Added Keywords||internal-improvement Target Milestone|--- |10.0
[Bug fortran/90207] New: Debugging generated tree code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90207 Bug ID: 90207 Summary: Debugging generated tree code Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Fortran statements are translated into trees (as seen with -fdump-tree-original). I would help if there was a flag which allowed inspecting values of individual variables and stepping through the generated vs. the original source code. This could also be implemented by a transformation of what -fdump-tree-original produces into a valid C program, using data structures from libgfortran.
[Bug c++/88256] [7/8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn), C++ FE missing DECL_EXPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 --- Comment #8 from Jason Merrill --- *** Bug 89910 has been marked as a duplicate of this bug. ***
[Bug c++/89910] [7/8/9 Regression] ICE in make_ssa_name_fn with VLA cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89910 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jason Merrill --- Yes. *** This bug has been marked as a duplicate of bug 88256 ***
[Bug c++/87366] [7/8/9 Regression] SFINAE trait as template parameter causes incorrect application of trait to other areas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87366 --- Comment #2 from Jason Merrill --- Author: jason Date: Mon Apr 22 19:16:46 2019 New Revision: 270494 URL: https://gcc.gnu.org/viewcvs?rev=270494&root=gcc&view=rev Log: PR c++/87366 - wrong error with alias template. With this testcase the code in template_args_equal to treat aliases as distinct wasn't sufficient, because it only looked at the top level, whereas here we have a reference to the alias. So let's also handle treating them as distinct in structural_comptypes. For GCC 10 I have a more comprehensive patch, but for GCC 9 let's go with this smaller change. * typeck.c (structural_comptypes): When comparing_specializations, aliases are unequal. (comptypes): When comparing_specializations, do structural comparison. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-66.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c
[Bug c++/90201] -Werror=useless-cast in move constructir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90201 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-22 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- N.B. This is a warning, not an error. Reporting that you get an error because you turned it into an error doesn't change that is a warning :-)
[Bug ada/90206] GNAT gcc ada function out argument not support with -gnat12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90206 --- Comment #5 from Leonard Kramer --- Created attachment 46227 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46227&action=edit Makefile to demonstrate bug
[Bug ada/90206] GNAT gcc ada function out argument not support with -gnat12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90206 --- Comment #4 from Leonard Kramer --- The issue is that Ada2012 supports functions with arguments qualified with an "out" or "in out" keyword. (Originally, Ada did not support functions that permitted modifying arguments.) When I attempt to create a generic package, passing a function "access" type, the compiler fails complaining that 'functions can only have "in" parameters'
[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-22 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1
[Bug ada/90206] GNAT gcc ada function out argument not support with -gnat12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90206 --- Comment #3 from Leonard Kramer --- Created attachment 46226 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46226&action=edit .adb body of generic function exhibiting the bug. Body of generic function that exhibits the bug.
[Bug ada/90206] GNAT gcc ada function out argument not support with -gnat12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90206 --- Comment #2 from Leonard Kramer --- Created attachment 46225 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46225&action=edit .ads specification code. Spec for generic function that exhibits the bug.
[Bug ada/90206] GNAT gcc ada function out argument not support with -gnat12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90206 --- Comment #1 from Leonard Kramer --- Created attachment 46224 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46224&action=edit Main package body Package program that exhibits the bug.
[Bug target/89736] New test pr87532-mc.c fails on compiler not defaulting to VSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89736 --- Comment #6 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Mon Apr 22 16:09:13 2019 New Revision: 270493 URL: https://gcc.gnu.org/viewcvs?rev=270493&root=gcc&view=rev Log: gcc/ChangeLog: 2019-04-22 Kelvin Nilsen Backport from mainline 2019-03-15 Kelvin Nilsen PR target/87532 * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): When handling vec_extract, use modular arithmetic to allow constant selectors greater than vector length. * config/rs6000/rs6000.c (rs6000_expand_vector_extract): Allow V1TImode vectors to have constant selector values greater than 0. Use modular arithmetic to compute vector index. (rs6000_split_vec_extract_var): Use modular arithmetic to compute index for in-memory vectors. Correct code generation for in-register vectors. Use inner mode of vector rather than mode of destination for move instruction. (altivec_expand_vec_ext_builtin): Use modular arithmetic to compute index. 2019-04-12 Kelvin Nilsen PR target/87532 * config/rs6000/vsx.md (*vsx_extract__mode_var): Use QI inner mode with V16QI vector mode. gcc/testsuite/ChangeLog: 2019-04-22 Kelvin Nilsen Backport from mainline 2019-03-15 Kelvin Nilsen PR target/87532 * gcc.target/powerpc/pr87532-mc.c: New test. * gcc.target/powerpc/pr87532.c: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2.h: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2a.c: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2b.c: New test. * gcc.target/powerpc/vsx-builtin-10a.c: New test. * gcc.target/powerpc/vsx-builtin-10b.c: New test. * gcc.target/powerpc/vsx-builtin-11a.c: New test. * gcc.target/powerpc/vsx-builtin-11b.c: New test. * gcc.target/powerpc/vsx-builtin-12a.c: New test. * gcc.target/powerpc/vsx-builtin-12b.c: New test. * gcc.target/powerpc/vsx-builtin-13a.c: New test. * gcc.target/powerpc/vsx-builtin-13b.c: New test. * gcc.target/powerpc/vsx-builtin-14a.c: New test. * gcc.target/powerpc/vsx-builtin-14b.c: New test. * gcc.target/powerpc/vsx-builtin-15a.c: New test. * gcc.target/powerpc/vsx-builtin-15b.c: New test. * gcc.target/powerpc/vsx-builtin-16a.c: New test. * gcc.target/powerpc/vsx-builtin-16b.c: New test. * gcc.target/powerpc/vsx-builtin-17a.c: New test. * gcc.target/powerpc/vsx-builtin-17b.c: New test. * gcc.target/powerpc/vsx-builtin-18a.c: New test. * gcc.target/powerpc/vsx-builtin-18b.c: New test. * gcc.target/powerpc/vsx-builtin-19a.c: New test. * gcc.target/powerpc/vsx-builtin-19b.c: New test. * gcc.target/powerpc/vsx-builtin-20a.c: New test. * gcc.target/powerpc/vsx-builtin-20b.c: New test. * gcc.target/powerpc/vsx-builtin-9a.c: New test. * gcc.target/powerpc/vsx-builtin-9b.c: New test. 2019-03-19 Kelvin Nilsen PR target/89736 * gcc.target/powerpc/pr87532-mc.c: Modify dejagnu directives to restrict this test to vsx targets. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr87532-mc.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr87532.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2.h branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-buil
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532 --- Comment #19 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Mon Apr 22 16:09:13 2019 New Revision: 270493 URL: https://gcc.gnu.org/viewcvs?rev=270493&root=gcc&view=rev Log: gcc/ChangeLog: 2019-04-22 Kelvin Nilsen Backport from mainline 2019-03-15 Kelvin Nilsen PR target/87532 * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): When handling vec_extract, use modular arithmetic to allow constant selectors greater than vector length. * config/rs6000/rs6000.c (rs6000_expand_vector_extract): Allow V1TImode vectors to have constant selector values greater than 0. Use modular arithmetic to compute vector index. (rs6000_split_vec_extract_var): Use modular arithmetic to compute index for in-memory vectors. Correct code generation for in-register vectors. Use inner mode of vector rather than mode of destination for move instruction. (altivec_expand_vec_ext_builtin): Use modular arithmetic to compute index. 2019-04-12 Kelvin Nilsen PR target/87532 * config/rs6000/vsx.md (*vsx_extract__mode_var): Use QI inner mode with V16QI vector mode. gcc/testsuite/ChangeLog: 2019-04-22 Kelvin Nilsen Backport from mainline 2019-03-15 Kelvin Nilsen PR target/87532 * gcc.target/powerpc/pr87532-mc.c: New test. * gcc.target/powerpc/pr87532.c: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2.h: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2a.c: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2b.c: New test. * gcc.target/powerpc/vsx-builtin-10a.c: New test. * gcc.target/powerpc/vsx-builtin-10b.c: New test. * gcc.target/powerpc/vsx-builtin-11a.c: New test. * gcc.target/powerpc/vsx-builtin-11b.c: New test. * gcc.target/powerpc/vsx-builtin-12a.c: New test. * gcc.target/powerpc/vsx-builtin-12b.c: New test. * gcc.target/powerpc/vsx-builtin-13a.c: New test. * gcc.target/powerpc/vsx-builtin-13b.c: New test. * gcc.target/powerpc/vsx-builtin-14a.c: New test. * gcc.target/powerpc/vsx-builtin-14b.c: New test. * gcc.target/powerpc/vsx-builtin-15a.c: New test. * gcc.target/powerpc/vsx-builtin-15b.c: New test. * gcc.target/powerpc/vsx-builtin-16a.c: New test. * gcc.target/powerpc/vsx-builtin-16b.c: New test. * gcc.target/powerpc/vsx-builtin-17a.c: New test. * gcc.target/powerpc/vsx-builtin-17b.c: New test. * gcc.target/powerpc/vsx-builtin-18a.c: New test. * gcc.target/powerpc/vsx-builtin-18b.c: New test. * gcc.target/powerpc/vsx-builtin-19a.c: New test. * gcc.target/powerpc/vsx-builtin-19b.c: New test. * gcc.target/powerpc/vsx-builtin-20a.c: New test. * gcc.target/powerpc/vsx-builtin-20b.c: New test. * gcc.target/powerpc/vsx-builtin-9a.c: New test. * gcc.target/powerpc/vsx-builtin-9b.c: New test. 2019-03-19 Kelvin Nilsen PR target/89736 * gcc.target/powerpc/pr87532-mc.c: Modify dejagnu directives to restrict this test to vsx targets. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr87532-mc.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr87532.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2.h branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-bui
[Bug ada/90206] New: GNAT gcc ada function out argument not support with -gnat12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90206 Bug ID: 90206 Summary: GNAT gcc ada function out argument not support with -gnat12 Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: leonard.kramer at boeing dot com Target Milestone: --- Created attachment 46223 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46223&action=edit Verbose output from gcc -v -save-temps -gnat12 Using ada with -gnat12 switch, function access type passed to generic package does not support "out" qualified arguments contrary to ada 2012 specification.
[Bug target/88474] Inline built-in hypot for -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88474
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||segher at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #4 from Segher Boessenkool ---
It isn't implemented for any other targets yet. When I use __builtin_hypot
with -ffast-math (I tried on powerpc64-linux) I get a call to __hypot_finite,
instead of just three machine instructions, like e.g.
fmul 2,2,2
fmadd 1,1,1,2
fsqrt 1,1
which is what you get for
double hypot(double x, double y) { return __builtin_sqrt(x*x + y*y); }
Reopened. (Or do you want this PR to be just for x87? If so, why?)
[Bug target/90193] [8/9 Regression] asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90193 --- Comment #11 from Mathieu Desnoyers --- The proposed fix "gcc9-pr90193.patch" applied on top of gcc-8.3.0 fixes the issue for both x86-64 and for x86-32 (-m32) from a 64-bit x86 gcc.
[Bug tree-optimization/90021] [9 Regression] ICE in index_in_loop_nest, at tree-data-ref.h:587 since r270203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90021 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- From what I can see, a fix for this has been acked 11 days ago: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00413.html Bin, are you going to commit it?
[Bug target/90193] [8/9 Regression] asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90193 --- Comment #10 from Jakub Jelinek --- Created attachment 46222 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46222&action=edit gcc9-pr90193.patch Untested fix.
[Bug target/90193] [8/9 Regression] asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90193 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Looks like missing asm goto support in classify_insn to me.
[Bug libstdc++/90203] Can't compare "const std::pair" with "std::pair"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90203 --- Comment #4 from Shreyans Doshi --- Yeah, I checked that scenario as well. Logically both are same, but compiler doesn't agree to that. But as pointed out by other members, it is not just the compiler, surprisingly it is not present in the standard itself. So, I guess I'll have to propose it C++ std committee. Thanks for looking into it anyways. Regards Shreyans On Mon, Apr 22, 2019 at 6:34 PM redi at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90203 > > --- Comment #3 from Jonathan Wakely --- > (In reply to Shreyans Doshi from comment #0) > > > > Surprisingly, const pair and pair are not > > comparable, which it should be in such cases. Ideally, if a container is > > const, it should imply that all the underlying members are also const. > > > > const pair does imply the members are const, but it's still not the > same > type as pair, and so isn't comparable. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug.
[Bug libstdc++/90203] Can't compare "const std::pair" with "std::pair"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90203 --- Comment #3 from Jonathan Wakely --- (In reply to Shreyans Doshi from comment #0) > > Surprisingly, const pair and pair are not > comparable, which it should be in such cases. Ideally, if a container is > const, it should imply that all the underlying members are also const. > const pair does imply the members are const, but it's still not the same type as pair, and so isn't comparable.
[Bug libstdc++/90203] Can't compare "const std::pair" with "std::pair"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90203 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- Not a bug, this is how the standard requires it to behave.
[Bug tree-optimization/89811] uint32_t load is not recognized if shifts are done in a fixed-size loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89811 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #2 from Segher Boessenkool --- On PowerPC, for "bad" we get addi 9,3,2 lbz 0,1(3) lbz 3,0(3) lhbrx 10,0,9 rlwimi 0,10,8,0,31-8 rlwimi 3,0,8,0,31-8 rldicl 3,3,0,32 blr (BE -m64); it managed to recognise the top two bytes as a byte-reverse load, but not the lower two. (And yup, "loop" uses no byte-reverse at all.)
[Bug tree-optimization/89804] optimization opportunity: move variable from stack to register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89804 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #4 from Segher Boessenkool --- That sounds not too hard to fix, no? Expand should expand and not do all kinds of other things. Also, doing this optimisation in RTL is much harder to do than in gimple, I think.
[Bug fortran/80467] Function Without Arguments Fails to Generate Error When Declared Later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80467 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Dominique d'Humieres --- Duplicate of pr50974. *** This bug has been marked as a duplicate of bug 50974 ***
[Bug fortran/50974] ICE on invalid on function used as variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50974 Dominique d'Humieres changed: What|Removed |Added CC||jeffrey.armstrong@approxima ||trix.com --- Comment #5 from Dominique d'Humieres --- *** Bug 80467 has been marked as a duplicate of this bug. ***
[Bug fortran/88099] ICE in maybe_legitimize_operand, at optabs.c:7170
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88099 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|NEW |WAITING See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80467 --- Comment #3 from Dominique d'Humieres --- Related to/duplicate of pr80467.
[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205 --- Comment #1 from Andreas Schwab --- %f is correct for double.
[Bug fortran/80467] Function Without Arguments Fails to Generate Error When Declared Later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80467 Dominique d'Humieres changed: What|Removed |Added CC||g.granda at irya dot unam.mx --- Comment #9 from Dominique d'Humieres --- *** Bug 90198 has been marked as a duplicate of this bug. ***
[Bug fortran/90198] internal compiler error: in convert_move, at expr.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90198 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Dominique d'Humieres --- This is a duplicate of pr80467. *** This bug has been marked as a duplicate of bug 80467 ***
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 --- Comment #12 from Nathan Sidwell --- Richard, I have no idea. AFAICT all the dump_tu stuff is in the C++ FE.
[Bug fortran/90198] internal compiler error: in convert_move, at expr.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90198 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-22 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Confirmed from at least 4.8 up to trunk (9.0). The ICE reported in comment 0 is emitted for compilers configured with --enable-checking=release. For those configures with --enable-checking=yes the ICE is pr90198.f90:24:0: 24 | real function l_t_field(temp,nh) | Error: type mismatch in binary expression real(kind=4) real(kind=4) real(kind=4) (*) (void) _4 = rho_0 * heat_function_field; pr90198.f90:24:0: internal compiler error: verify_gimple failed
[Bug c++/90205] New: Wformat-signedness detects %d and suggests %d fixit hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205
Bug ID: 90205
Summary: Wformat-signedness detects %d and suggests %d fixit
hint
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
C++ trunk suggests '%d' when I '%u' is what is needed
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:5:14: warning: format '%d' expects argument of type 'int', but
argument 2 has type 'unsigned int' [-Wformat=]
5 | printf("%d", i);
| ~^ ~
| | |
| int unsigned int
| %d
Compiler returned: 0
#include
int main()
{
unsigned int i = 0;
printf("%d", i);
}
Another is %f is suggested, but the message states 'double' instead of 'float'
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:5:14: warning: format '%d' expects argument of type 'int', but
argument 2 has type 'double' [-Wformat=]
5 | printf("%d", i);
| ~^ ~
| | |
| int double
| %f
Compiler returned: 0
#include
int main()
{
float i = 0;
printf("%d", i);
}
[Bug target/90202] AVX-512 instructions not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90202 --- Comment #2 from Antony Polukhin --- Then I'm fine with the current codegen. However with -mavx512f it produces a few additional instructions for rbp register test(v, v): push rbp ; not necessary mov rax, rdi mov rbp, rsp ; not necessary vmovdqu32 zmm1, ZMMWORD PTR [rbp+16]; could use rsp directly vpaddd zmm0, zmm1, ZMMWORD PTR [rbp+80] ; could use rsp directly vmovdqu32 ZMMWORD PTR [rdi], zmm0 vzeroupper pop rbp ; not necessary ret
[Bug libstdc++/90203] Can't compare "const std::pair" with "std::pair"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90203 Marc Glisse changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Marc Glisse --- There is usually a reason when all compilers agree: that's what the standard dictates. You probably need to present a proposal to the standardization committee explaining the extension you want. (It would seem sensible to me to be able to compare pair < pair as long as one can do A<=>C (or A
[Bug c/89774] Add flag to force single precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774 Segher Boessenkool changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2019-04-22 CC||segher at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90070, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=22326 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #9 from Segher Boessenkool --- We currently only do it for trivial cases, as the example in comment 6 shows as well. This is done during expand, which is the wrong place for it. PR90070 is asking for better optimisation of this: do the operation in single precision, and use single-precision constants, if this does not change the result (or there is some -ffast-math option). PR22326 is also closely related. I don't think we can close any of these PRs as a dup of another, they are all asking for slightly different things :-)
[Bug target/90202] AVX-512 instructions not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90202 --- Comment #1 from Marc Glisse --- IIRC this is a tuning decision made on purpose. If you use just -mavx512f instead of the -march, you get the code you expected.
[Bug c/90204] New: [8 Regression] C code is optimized worse than C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204
Bug ID: 90204
Summary: [8 Regression] C code is optimized worse than C++
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the example:
struct v {
int val[16];
};
struct v test(struct v a, struct v b) {
struct v res;
for (int i = 0; i < 16; i++)
res.val[i] = a.val[i] + b.val[i];
return res;
}
Compiling that snippet with `g++ -O3 -march=skylake-avx512` gives a short
assembly:
test(v, v):
push rbp
mov rax, rdi
mov rbp, rsp
vmovdqu32 ymm1, YMMWORD PTR [rbp+16]
vmovdqu32 ymm2, YMMWORD PTR [rbp+48]
vpaddd ymm0, ymm1, YMMWORD PTR [rbp+80]
vmovdqu32 YMMWORD PTR [rdi], ymm0
vpaddd ymm0, ymm2, YMMWORD PTR [rbp+112]
vmovdqu32 YMMWORD PTR [rdi+32], ymm0
vzeroupper
pop rbp
ret
Compiling the same sample with the C compiler and same flags produces a ~150
lines of assembly with a lot of jumps and comparisons. The regression appeared
after GCC-7.3
[Bug c++/90203] New: Can't compare "const std::pair" with "std::pair"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90203
Bug ID: 90203
Summary: Can't compare "const std::pair" with
"std::pair"
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: shreyans.doshi94 at gmail dot com
Target Milestone: ---
Created attachment 46221
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46221&action=edit
Complete error message
The following code works fine:
#include
#include
#include
using namespace std;
int main()
{
map a = {{1, 2}, {3, 4}};
pair x = {1, 2};
cout << count(a.begin(), a.end(), x); // Outputs 1
return 0;
}
But when I do the same thing inside count function using make_pair, it doesn't
work:
#include
#include
#include
using namespace std;
int main()
{
map a = {{1, 2}, {3, 4}};
cout << count(a.begin(), a.end(), make_pair(1, 2)); //
Compilation error
return 0;
}
Exact error message:
/usr/include/c++/7/bits/predefined_ops.h:241:17: error: no match for
‘operator==’ (operand types are ‘std::pair’ and ‘const
std::pair’)
{ return *__it == _M_value; }
~~^~~
I've attached complete error message in a file with Description "Complete error
message" for reference. But I believe the issues is easy to reproduce on local
machine as well
Surprisingly, const pair and pair are not comparable,
which it should be in such cases. Ideally, if a container is const, it should
imply that all the underlying members are also const.
To play around a little bit, I also tried to keep the type of x in the first
snippet to be "pair" and it starts giving similar error
that it can't compare "pair" with "pair".
Although this should have worked, but logically thinking, the case above where
the whole pair is const should be more likely to work in my opinion.
Although the error message I've given is from gcc7, I've tried the same thing
on gcc8.3, clang8 and even MSVC19.20 to see if any other compiler has the same
issue and it turns out that all of them are giving me same error.
Compilation flag: -g3 -std=c++17 -O3
I've also tried adding "-Wall -Werror -Wpedantic" and it gives me same error.
I'll be happy to give any more info if required by anyone.
[Bug target/90202] New: AVX-512 instructions not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90202
Bug ID: 90202
Summary: AVX-512 instructions not used
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the following test program:
struct v {
int val[16];
};
v test(v a, v b) {
v res;
for (int i = 0; i < 16; i++)
res.val[i] = a.val[i] + b.val[i];
return res;
}
When compiled with `g++ -O3 -march=skylake-avx512` the following assembly is
produced:
test(v, v):
push rbp
mov rax, rdi
mov rbp, rsp
vmovdqu32 ymm1, YMMWORD PTR [rbp+16]
vmovdqu32 ymm2, YMMWORD PTR [rbp+48]
vpaddd ymm0, ymm1, YMMWORD PTR [rbp+80]
vmovdqu32 YMMWORD PTR [rdi], ymm0
vpaddd ymm0, ymm2, YMMWORD PTR [rbp+112]
vmovdqu32 YMMWORD PTR [rdi+32], ymm0
vzeroupper
pop rbp
ret
it seems suboptimal, as the 512 registers are available and a better assembly
is possible:
test(v, v):
vmovdqu32 zmm0, zmmword ptr [rsp + 72]
vpaddd zmm0, zmm0, zmmword ptr [rsp + 8]
vmovdqu32 zmmword ptr [rdi], zmm0
mov rax, rdi
vzeroupper
ret
[Bug ada/90051] Error in spec comments - g-caliio.ads (%Z)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90051 simon at pushface dot org changed: What|Removed |Added CC||simon at pushface dot org --- Comment #1 from simon at pushface dot org --- That would be g-catiio. Still no %Z in gcc version 9.0.1 20190323 (experimental) (GCC); %Z results in GNAT.CALENDAR.TIME_IO.PICTURE_ERROR.
[Bug preprocessor/90034] gcc hangs on wait4 after vfork after opening tmp file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90034 Akim Demaille changed: What|Removed |Added CC||akim.demaille at gmail dot com --- Comment #8 from Akim Demaille --- (In reply to Richard Biener from comment #2) > That said, bison should be fixed to not emit this kind of line directives... Hi Richard, I maintain Bison. Bison is emitting two types of #lines: right before emitting code coming from the input file, something like (1) #line "parse.y" 42 and once we are done with the input, and back to generated code, something like (2) #line "parse.tab.c" 1024 What is special here is the way Bison and GCC were invoked: bison -o /dev/stdout parser.y | gcc -xc - So "of course", because the output file is /dev/stdout, we emit this for (2) #line "/dev/stdout" 1024 and if someone were to call bison with bison -o /dev/stdout /dev/stdin no doubt that (1) will become #line "/dev/stdin" 42 Back your comment: > That said, bison should be fixed to not emit this kind of line directives... Well, I don't think we should decide whether or not to emit the #lines based on how magic the input files, but if the consensus here differs, I will change that. I personally do not understand the point of not generating the output file and sending the output directly to stdout. Especially in the case of Bison which also might generate other files based on the base name of the output file (/dev/stdout.h, /dev/stdout.output, etc.). If you do think we should detect special input and output files and not emit #line in their case, what kind of check would you recommend? That being said, since we also have caret-diagnostics, and we also support #line in the input, we also have to get robust to users/generators putting special file names in the #lines inside parser.y... Cheers!
[Bug ada/89556] error when using "with Priority"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89556 simon at pushface dot org changed: What|Removed |Added CC||simon at pushface dot org --- Comment #1 from simon at pushface dot org --- Ignoring the GPR file (which references nonexistent directories) and just compiling the source files, GNAT CE 2018 does indeed result in this ICE. However gcc version 9.0.1 20190323 (experimental) (GCC) does NOT.
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 Jakub Jelinek changed: What|Removed |Added Attachment #46205|0 |1 is obsolete|| --- Comment #77 from Jakub Jelinek --- Created attachment 46220 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46220&action=edit gcc9-pr89093.patch The above patch passed bootstrap, but there is a regression: +FAIL: compiler driver --help=target option(s): "^ +-.*[^:.]\$" absent from output: " -mgeneral-regs-only Generate code which uses the cor e registers only(r0-r14)" because there is no full stop at the end of description. Fixed in this patch (I've also added a space before (. I've also seen +FAIL: TestAbort +FAIL: TestBreakpoint +FAIL: TestCgoCrashHandler +FAIL: TestCgoSignalDeadlock +FAIL: TestSelectStackAdjust regressions, but 1) not sure if they are reproducible or not, go has usually lots of random intermitent failures 2) even if yes, the libgo part of the patch I believe can't be committed together with the rest, as libgo has a different upstream and will need to guard it on being compiled with gcc 9+, because it can be built with other compilers too.
[Bug c++/90201] New: -Werror=useless-cast in move constructir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90201
Bug ID: 90201
Summary: -Werror=useless-cast in move constructir
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: prokofjev.d at gmail dot com
Target Milestone: ---
Compiler options:
$ gcc kill_me.cpp -Wall -Wextra -std=c++17 "-Werror=useless-cast"
Code:
class foo
{
void bar(foo&& f)
{
foo(static_cast(f));
//foo(std::move(f));
}
};
int main()
{
}
Error:
with static_cast:
kill_me.cpp:5:30: error: useless cast to type ‘foo’ [-Werror=useless-cast]
foo(static_cast(f));
with std::move:
kill_me.cpp:7:21: error: useless cast to type ‘foo’ [-Werror=useless-cast]
foo(std::move(f));
^
