[Bug c++/58045] gcc 4.8 produces an undefined reference to an inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58045 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 61214. *** This bug has been marked as a duplicate of bug 61214 ***
[Bug c++/61214] [4.9/5 regression] Weird interaction between -fvisibility-inlines-hidden, inline virtuals and devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61214 Andrew Pinski changed: What|Removed |Added CC||rafael at espindo dot la --- Comment #10 from Andrew Pinski --- *** Bug 58045 has been marked as a duplicate of this bug. ***
[Bug ipa/62051] [9/10/11/12 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051 --- Comment #26 from Andrew Pinski --- Is this even valid? That is Base and Derived in the shared library and the main program are considered two different classes because of -fvisibility=hidden and the classes are not marked as visibility default.
[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #21 from rguenther at suse dot de ---
On Thu, 9 Sep 2021, seurer at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
>
> --- Comment #19 from seurer at gcc dot gnu.org ---
> This also prevents gcc from being built if it includes go on powerpc LE:
>
> libtool: compile: /home/seurer/gcc/git/build/gcc-test/./gcc/gccgo
> -B/home/seurer/gcc/git/build/gcc-test/./gcc/
> -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
> -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
> -isystem
> /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
> -isystem
> /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
> -O2 -g -I . -c -fgo-pkgpath=strconv
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atob.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoc.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoi.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/bytealg.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ctoa.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/decimal.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/doc.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/eisel_lemire.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoa.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoaryu.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/isprint.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/itoa.go
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/quote.go -fPIC -o
> .libs/strconv.o
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go: In function
> 'strconv.parseFloatPrefix':
> /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error:
> unrecognizable insn:
> 704 | func parseFloatPrefix(s string, bitSize int) (float64, int, error) {
> | ^
> (insn 351 350 352 35 (set (reg:SF 219 [ SR.5776 ])
> (subreg:SF (reg:DI 237 [ GOTMP.360 ]) 0))
Btw, I think this is a subreg that would be reasonable to handle.
It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI
..) 0).
[Bug c++/67650] undef reference with -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67650 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |9.0 Resolution|--- |FIXED --- Comment #36 from Andrew Pinski --- Fixed for GCC 9 by the patch for PR 80916. Tested even on the original testcase.
[Bug gcov-profile/90364] 521.wrf_r is 8-17% slower with PGO at -Ofast and native march/mtune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90364 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |12.0
[Bug c++/102261] [12 Regression] ICE: Segmentation fault (in build_this_conversion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102261
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-09-10
Ever confirmed|0 |1
Target Milestone|--- |12.0
Known to work||11.2.1
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener ---
Confirmed.
2289 conversion *t = implicit_conversion (parmtype, argtype, arg,
2290 /*c_cast_p=*/false, flags,
complain);
2291 t->this_p = this_p;
2292 return t;
2293}
2294
2295/* Create an overload candidate for the function or method FN called
(gdb) p t
$1 = (conversion *) 0x0
note I'm not sure the particular error is very helpful. Why do we even
support asm("...") on aggregate types?
[Bug c++/102263] Requesting enhanced warning on returning pointer/reference to local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102263 Richard Biener changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic
[Bug target/102264] Macro Intrinsics fail to use all the registers on the machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Component|inline-asm |target --- Comment #3 from Richard Biener --- Maybe 'x' is simply the wrong constraint? Try 'y'.
[Bug c++/102261] [12 Regression] ICE: Segmentation fault (in build_this_conversion) since r12-3346-g47543e5f9d1fc502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102261 Martin Liška changed: What|Removed |Added Summary|[12 Regression] ICE:|[12 Regression] ICE: |Segmentation fault (in |Segmentation fault (in |build_this_conversion) |build_this_conversion) ||since ||r12-3346-g47543e5f9d1fc502 CC||marxin at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r12-3346-g47543e5f9d1fc502, it was rejected before the revision.
[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #22 from Hongtao.liu ---
(In reply to rguent...@suse.de from comment #21)
> On Thu, 9 Sep 2021, seurer at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
> >
> > --- Comment #19 from seurer at gcc dot gnu.org ---
> > This also prevents gcc from being built if it includes go on powerpc LE:
> >
> > libtool: compile: /home/seurer/gcc/git/build/gcc-test/./gcc/gccgo
> > -B/home/seurer/gcc/git/build/gcc-test/./gcc/
> > -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
> > -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
> > -isystem
> > /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
> > -isystem
> > /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
> > -O2 -g -I . -c -fgo-pkgpath=strconv
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atob.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoc.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoi.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/bytealg.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ctoa.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/decimal.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/doc.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/eisel_lemire.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoa.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoaryu.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/isprint.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/itoa.go
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/quote.go -fPIC -o
> > .libs/strconv.o
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go: In function
> > 'strconv.parseFloatPrefix':
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error:
> > unrecognizable insn:
> > 704 | func parseFloatPrefix(s string, bitSize int) (float64, int, error) {
> > | ^
> > (insn 351 350 352 35 (set (reg:SF 219 [ SR.5776 ])
> > (subreg:SF (reg:DI 237 [ GOTMP.360 ]) 0))
>
> Btw, I think this is a subreg that would be reasonable to handle.
> It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI
> ..) 0).
Yes, LRA/reload can handle it correctly, like i tried in #c10.
[Bug c/102268] Wrong code with aliasing union pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102268 Richard Biener changed: What|Removed |Added Version|unknown |11.2.1 CC||rguenth at gcc dot gnu.org Last reconfirmed||2021-09-10 Known to fail||11.2.1 Ever confirmed|0 |1 Depends on||101641 Status|UNCONFIRMED |NEW --- Comment #2 from Richard Biener --- Without doing detailed analysis this smells like a duplicate of PR101641 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101641 [Bug 101641] Bogus redundant store removal
[Bug tree-optimization/82224] Strict-aliasing not noticing valid aliasing of two unions with active members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82224 --- Comment #14 from Richard Biener --- Oh, and related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82224
[Bug tree-optimization/102269] New: [12 Regression] ICE in verify_gimple_stmt since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102269
Bug ID: 102269
Summary: [12 Regression] ICE in verify_gimple_stmt since
r12-3433-ga25e0b5e6ac8a77a
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: qing.zhao at oracle dot com
Target Milestone: ---
The following crashes:
$ cat auto-var.c
void fn() { int a[0]; }
$ gcc auto-var.c -c -ftrivial-auto-var-init=zero -fdump-tree-all
auto-var.c: In function ‘fn’:
auto-var.c:1:6: internal compiler error: Segmentation fault
1 | void fn() { int a[0]; }
| ^~
0x14615f8 crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:328
0x7786239f ???
../sysdeps/unix/sysv/linux/sigaction.c:10
0x14c1ffc verify_gimple_call
/home/marxin/Programming/gcc/gcc/tree-cfg.c:3466
0x14c8d13 verify_gimple_stmt
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5032
0x14c92f4 verify_gimple_in_seq_2
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5188
0x14c91e3 verify_gimple_in_seq_2
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5161
0x14c941c verify_gimple_in_seq(gimple*)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5227
0x1028655 gimplify_body(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/gimplify.c:15746
0x1028922 gimplify_function_tree(tree_node*)
/home/marxin/Programming/gcc/gcc/gimplify.c:15817
0xd543d0 cgraph_node::analyze()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:670
0xd5671d analyze_functions
/home/marxin/Programming/gcc/gcc/cgraphunit.c:1234
0xd59e59 symbol_table::finalize_compilation_unit()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2508
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/102269] [12 Regression] ICE in verify_gimple_stmt since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102269 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |12.0 Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-10
[Bug c/102268] Wrong code with aliasing union pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102268 --- Comment #3 from Richard Biener --- Oh, and related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82224
[Bug c/102268] Wrong code with aliasing union pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102268 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Richard Biener --- Indeed. +Deleted redundant store p3_9(D)->v2.x = t2$x_25; +Deleted redundant store p3_9(D)->v1.x = t1$x_2; @@ -227,12 +157,8 @@ : temp_10 = p3_9(D)->v1.x; - t2$x_25 = temp_10; - p3_9(D)->v2.x = t2$x_25; MEM[(struct s2 *)p2_13(D)].x = 1234; temp_15 = p3_9(D)->v2.x; - t1$x_2 = temp_15; - p3_9(D)->v1.x = t1$x_2; : _23 = MEM[(struct s1 *)p1_6(D)].x; that leaves us with the store via S2 that is not found when looking up the load via S1 but instead we find the originally loaded value. *** This bug has been marked as a duplicate of bug 101641 ***
[Bug tree-optimization/101641] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101641 Richard Biener changed: What|Removed |Added CC||davmac at davmac dot org --- Comment #6 from Richard Biener --- *** Bug 102268 has been marked as a duplicate of this bug. ***
[Bug libstdc++/102270] New: std::tuple<>::swap missing constexpr specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270
Bug ID: 102270
Summary: std::tuple<>::swap missing constexpr specifier
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
constexpr bool b = [] {
std::tuple<> x, y;
x.swap(y);
return true;
}();
https://godbolt.org/z/Gac17hjen
[Bug target/18216] Different results when an array is statically/dynamically allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18216 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski --- I get no difference between statically allocated V or dynamically allocated. I do get a difference with -m32 and -m32 -msse2 -mfpmath=sse (which is exactly the difference between ICC and GCC).
[Bug tree-optimization/102269] [12 Regression] ICE in verify_gimple_stmt since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102269 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- The issue is that we elide assigns of zero size.
[Bug tree-optimization/102271] New: [12 Regression] ICE in make_decl_rtl, at varasm.c:1446 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102271
Bug ID: 102271
Summary: [12 Regression] ICE in make_decl_rtl, at varasm.c:1446
since r12-3433-ga25e0b5e6ac8a77a
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: qing.zhao at oracle dot com
Target Milestone: ---
Since the revision, the following fails:
$ cat lambda.C
struct A {};
int main() {
A a;
auto lam4 = [a] {};
lam4();
}
$ g++ lambda.C -ftrivial-auto-var-init=pattern -c
during RTL pass: expand
lambda.C: In lambda function:
lambda.C:5:17: internal compiler error: in make_decl_rtl, at varasm.c:1446
5 | auto lam4 = [a] {};
| ^
0x1d73737 make_decl_rtl(tree_node*)
/home/marxin/Programming/gcc/gcc/varasm.c:1446
0x12fe256 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:10547
0x12f5b2c expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:8733
0x12d16aa expand_expr
/home/marxin/Programming/gcc/gcc/expr.h:301
0x12f49ed expand_expr_addr_expr_1
/home/marxin/Programming/gcc/gcc/expr.c:8424
0x12f5432 expand_expr_addr_expr
/home/marxin/Programming/gcc/gcc/expr.c:8545
0x1304a76 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:11761
0x12f5b2c expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:8733
0x12d16aa expand_expr
/home/marxin/Programming/gcc/gcc/expr.h:301
0x1300257 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:10907
0x12f5b2c expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:8733
0x12d16aa expand_expr
/home/marxin/Programming/gcc/gcc/expr.h:301
0x12e80a5 expand_assignment(tree_node*, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/expr.c:5752
0x11217f7 expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3942
0x1121c34 expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:4040
0x112a625 expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6082
0x112cec5 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/102271] [12 Regression] ICE in make_decl_rtl, at varasm.c:1446 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102271 Martin Liška changed: What|Removed |Added Target Milestone|--- |12.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102269
[Bug target/102264] Macro Intrinsics fail to use all the registers on the machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264 --- Comment #4 from Andrew Pinski --- (In reply to Richard Biener from comment #3) > Maybe 'x' is simply the wrong constraint? Try 'y'. It is 'v': v Any EVEX encodable SSE register (%xmm0-%xmm31).
[Bug libstdc++/102270] std::tuple<>::swap missing constexpr specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270 --- Comment #1 from 康桓瑋 --- This is missing from r278331.
[Bug c++/102272] New: rejects-valid: VLA captured in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102272
Bug ID: 102272
Summary: rejects-valid: VLA captured in generic lambda
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: simon.giesecke at snowflake dot com
Target Milestone: ---
gcc rejects the following code:
```
int bar();
void foo() {
char data[bar()];
[&](auto *ptr) { data; };
}
```
saying:
```
: In function 'void foo()':
:6:3: error: use of deleted function
'foo()~()'
6 | [&](auto *ptr) { data; };
| ^~~~
:6:5: note: 'foo()~()' is implicitly
deleted because the default definition would be ill-formed:
6 | [&](auto *ptr) { data; };
| ^
```
This happens in trunk and in various versions back to 8.x I tried.
With a non-generic lambda, this works.
Interestingly, it also works if the length of the VLA doesn't depend on the
result of a function call, but on a parameter of the function.
While this isn't standard C++, gcc supports VLA in C++ code generally, so I
think this should also work.
[Bug c/102268] Wrong code with aliasing union pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102268 --- Comment #5 from Davin McCall --- Hi Richard, I think you marked as a duplicate of the wrong bug. It is indeed a duplicate of 82224 - sorry, I didn't realise that there was already a bug filed, also this test case is "fixed" by version 8.1 and then regresses again in 10.1 (but I assume that is coincidental rather than the underlying issue was fixed).
[Bug libstdc++/102270] std::tuple<>::swap missing constexpr specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-09-10 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug target/102264] [9/10/11/12 Regression] extra spilling when using inline-asm and all registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to work||4.9.4 Last reconfirmed||2021-09-10 Summary|Macro Intrinsics fail to|[9/10/11/12 Regression] |use all the registers on|extra spilling when using |the machine |inline-asm and all ||registers Known to fail||5.1.0 --- Comment #5 from Andrew Pinski --- Using the 'v' constraint, there is still a register allocation issue but almost all of the extra moves are gone. The register allocation issue looks to be a regression from GCC 4.9.
[Bug tree-optimization/102271] [12 Regression] ICE in make_decl_rtl, at varasm.c:1446 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102271 --- Comment #1 from Richard Biener --- Can't reproduce with the pending patch for PR102269.
[Bug tree-optimization/102271] ICE in make_decl_rtl with -ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102271 Andrew Pinski changed: What|Removed |Added Target Milestone|12.0|--- Summary|[12 Regression] ICE in |ICE in make_decl_rtl with |make_decl_rtl, at |-ftrivial-auto-var-init=pat |varasm.c:1446 since |tern |r12-3433-ga25e0b5e6ac8a77a | --- Comment #2 from Andrew Pinski --- How is this a regression when ftrivial-auto-var-init is a new feature?
[Bug tree-optimization/102269] ICE in verify_gimple_stmt and -ftrivial-auto-var-init=zero and zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102269 Andrew Pinski changed: What|Removed |Added Summary|[12 Regression] ICE in |ICE in verify_gimple_stmt |verify_gimple_stmt since|and |r12-3433-ga25e0b5e6ac8a77a |-ftrivial-auto-var-init=zer ||o and zero size array Target Milestone|12.0|---
[Bug libstdc++/102259] ifstream::read(…, count) fails when count >= 2^31 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259 --- Comment #2 from Michel Morin --- Whoa, darwin's (and FreeBSD's too?) `read(…, …, nbyte)` fails when nbyte >= 2^31! This is the culprit, I think. I also found the following description in FreeBSD's manpage of read (https://www.unix.com/man-page/FreeBSD/2/read/): ERRORS [EINVAL] The value nbytes is greater than INT_MAX. Given that the testcase works file when compiled with Clang, libcxx would have some workround for it.
[Bug tree-optimization/102269] ICE in verify_gimple_stmt and -ftrivial-auto-var-init=zero and zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102269 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1dae802b685937b1dc52e49d0641c75f3186ba14 commit r12-3445-g1dae802b685937b1dc52e49d0641c75f3186ba14 Author: Richard Biener Date: Fri Sep 10 10:17:24 2021 +0200 middle-end/102269 - avoid auto-init of empty types This avoids initializing empty types for which we'll eventually leave a .DEFERRED_INIT call without a LHS. 2021-09-10 Richard Biener PR middle-end/102269 * gimplify.c (is_var_need_auto_init): Empty types do not need initialization. * gcc.dg/pr102269.c: New testcase.
[Bug tree-optimization/102269] ICE in verify_gimple_stmt and -ftrivial-auto-var-init=zero and zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102269 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #23 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #21)
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error:
> > unrecognizable insn:
> > 704 | func parseFloatPrefix(s string, bitSize int) (float64, int, error) {
> > | ^
> > (insn 351 350 352 35 (set (reg:SF 219 [ SR.5776 ])
> > (subreg:SF (reg:DI 237 [ GOTMP.360 ]) 0))
>
> Btw, I think this is a subreg that would be reasonable to handle.
> It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI
> ..) 0).
And it is more than reasonable for backends to *not* have to handle such
constructs. Most targets have no use for such surprising things.
The expander should never create such code in the first place, it is premature
optimisation! At expand time this should be separate statements, first taking
a SI out of a DI, and then converting it to an SF.
[Bug c/102268] Wrong code with aliasing union pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102268 --- Comment #6 from rguenther at suse dot de --- On Fri, 10 Sep 2021, davmac at davmac dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102268 > > --- Comment #5 from Davin McCall --- > Hi Richard, > I think you marked as a duplicate of the wrong bug. It is indeed a duplicate > of > 82224 - sorry, I didn't realise that there was already a bug filed, also this > test case is "fixed" by version 8.1 and then regresses again in 10.1 (but I > assume that is coincidental rather than the underlying issue was fixed). The bug now happens / resurfaced because of 101641, I have not checked the only slightly different testcases in 82224 (but that bug as a quite big audit-trail with multiple testcases). There have been multiple fixes in this area in the last years but the situation in PR101641 now persists where we lose track of a change of the active union member because we elide a store into it as redundant (writing the same bit pattern into the same location).
[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #24 from rguenther at suse dot de ---
On Fri, 10 Sep 2021, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
>
> --- Comment #23 from Segher Boessenkool ---
> (In reply to rguent...@suse.de from comment #21)
> > > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error:
> > > unrecognizable insn:
> > > 704 | func parseFloatPrefix(s string, bitSize int) (float64, int,
> > > error) {
> > > | ^
> > > (insn 351 350 352 35 (set (reg:SF 219 [ SR.5776 ])
> > > (subreg:SF (reg:DI 237 [ GOTMP.360 ]) 0))
> >
> > Btw, I think this is a subreg that would be reasonable to handle.
> > It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI
> > ..) 0).
>
> And it is more than reasonable for backends to *not* have to handle such
> constructs. Most targets have no use for such surprising things.
>
> The expander should never create such code in the first place, it is premature
> optimisation! At expand time this should be separate statements, first taking
> a SI out of a DI, and then converting it to an SF.
Fair enough - but extract_bit_field doesn't do this and forcing it to do
it regresses things (that was my first preferential treatment...).
I realize that the situation around subregs is fragile and there's
unlikely going to be a solution that doesn't need fixes in other targets.
[Bug tree-optimization/102273] New: ICE in expand_DEFERRED_INIT, at internal-fn.c:3024 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102273
Bug ID: 102273
Summary: ICE in expand_DEFERRED_INIT, at internal-fn.c:3024
since r12-3433-ga25e0b5e6ac8a77a
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: qing.zhao at oracle dot com
Target Milestone: ---
The following fails:
$ cat debug.c
void bar();
struct A {
char d; }
foo() {
struct A e;
void baz() { bar(e); }
}
$ gcc debug.c -ftrivial-auto-var-init=zero -c
during RTL pass: expand
debug.c: In function ‘foo’:
debug.c:6:12: internal compiler error: in expand_DEFERRED_INIT, at
internal-fn.c:3024
6 | struct A e;
|^
0x1046342 expand_DEFERRED_INIT
/home/marxin/Programming/gcc/gcc/internal-fn.c:3024
0x104cfd8 expand_internal_call(internal_fn, gcall*)
/home/marxin/Programming/gcc/gcc/internal-fn.c:4193
0x104d007 expand_internal_call(gcall*)
/home/marxin/Programming/gcc/gcc/internal-fn.c:4201
0xcc2fa6 expand_call_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2749
0xcc7434 expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3876
0xcc7b3c expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:4040
0xcd052d expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6082
0xcd2dcd execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/102273] ICE in expand_DEFERRED_INIT, at internal-fn.c:3024 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102273 Martin Liška changed: What|Removed |Added Target Milestone|--- |12.0 CC||rguenth at gcc dot gnu.org
[Bug tree-optimization/102273] ICE in expand_DEFERRED_INIT, at internal-fn.c:3024 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102273
--- Comment #1 from Martin Liška ---
This one is about nested functions:
optimized dump looks like:
;; Function foo (foo, funcdef_no=0, decl_uid=1980, cgraph_uid=2,
symbol_order=1)
struct A foo ()
{
struct FRAME.foo FRAME.0;
struct A e [value-expr: FRAME.0.e];
void * D.1990;
void * _3;
:
_3 = __builtin_dwarf_cfa (0);
FRAME.0.FRAME_BASE.PARENT = _3;
FRAME.0.e = .DEFERRED_INIT (1, 2, 0);
GIMPLE_NOP
return;
}
[Bug tree-optimization/102273] ICE in expand_DEFERRED_INIT, at internal-fn.c:3024 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102273 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-10 Ever confirmed|0 |1
[Bug tree-optimization/102271] ICE in make_decl_rtl with -ftrivial-auto-var-init=pattern and empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102271 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Martin Liška --- Fixed now. *** This bug has been marked as a duplicate of bug 102269 ***
[Bug tree-optimization/102269] ICE in verify_gimple_stmt and -ftrivial-auto-var-init=zero and zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102269 --- Comment #4 from Martin Liška --- *** Bug 102271 has been marked as a duplicate of this bug. ***
[Bug libstdc++/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427 --- Comment #5 from cqwrteur --- actually a lot of dlls are not copied correctly. libstdc++-6.dll libatomic.dll libquadmath.dll libssp.dll are all copied with 32 bit dlls. And libgcc_seh.dll is not copied. I think the copy to bin behavior should be removed. It should be just like normal linux distribution. 64 bit dlls in lib. 32 bit dlls in lib32.
[Bug tree-optimization/102273] ICE in expand_DEFERRED_INIT, at internal-fn.c:3024 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102273 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Richard Biener --- I have a patch.
[Bug libgcc/101655] canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101655 --- Comment #13 from cqwrteur --- Created attachment 51432 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51432&action=edit i see the bug again here are the logs
[Bug libgcc/101655] canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101655 --- Comment #14 from cqwrteur --- Created attachment 51433 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51433&action=edit config file
[Bug libgcc/101655] canadian compile of libgcc uses native cc as the compiler instead of the target cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101655 cqwrteur changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED --- Comment #15 from cqwrteur --- Is that if --build == --target, even --target is not true host name, it still uses cc?? cc should never ever happen tbh.
[Bug target/95285] AArch64:aarch64 medium code model proposal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285 --- Comment #17 from Wilco --- Here is the current medium code model proposal: https://github.com/ARM-software/abi-aa/pull/107/files
[Bug tree-optimization/102183] sccvn compare predicated result issue in vn_nary_op_insert_into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102183 Di Zhao changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Di Zhao --- commit 7285f394558980d1c7211f83c62b692af3c094eb
[Bug tree-optimization/101667] GNAT bug detected in op1_range in range-op.cc during GIMPLE pass evrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101667 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.2 Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org --- Comment #5 from Eric Botcazou --- 2021-06-03 Eric Botcazou * range-op.cc (get_bool_state): Adjust head comment. (operator_not_equal::op1_range): Fix comment. (operator_bitwise_xor::op1_range): Remove call to gcc_unreachable.
[Bug ada/70867] [9/10/11/12 regression] access discriminant in return aggregate wrongly detected as dangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70867 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|9.5 |11.0 --- Comment #15 from Eric Botcazou --- .
[Bug target/102274] New: aarch64: ICE (unrecognizable insn) with __builtin_aarch64_fmlal_highv2sf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102274
Bug ID: 102274
Summary: aarch64: ICE (unrecognizable insn) with
__builtin_aarch64_fmlal_highv2sf
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat t.c
typedef __Float16x4_t float16x4_t;
typedef __Float32x2_t float32x2_t;
float32x2_t a;
float16x4_t b;
float16x4_t c;
void f(void) {
__builtin_aarch64_fmlal_highv2sf(a,b,c);
}
$ gcc/xgcc -B gcc -c t.c
t.c: In function ‘f’:
t.c:8:1: error: unrecognizable insn:
8 | }
| ^
(insn 14 13 0 2 (set (reg:V2SF 101)
(fma:V2SF (float_extend:V2SF (vec_select:V2HF (reg:V4HF 93 [ b.1_2 ])
(parallel:V4HF [
(const_int 2 [0x2])
(const_int 3 [0x3])
])))
(float_extend:V2SF (vec_select:V2HF (reg:V4HF 94 [ c.2_3 ])
(parallel:V4HF [
(const_int 2 [0x2])
(const_int 3 [0x3])
])))
(reg:V2SF 92 [ a.0_1 ]))) "t.c":7:3 -1
(nil))
during RTL pass: vregs
t.c:8:1: internal compiler error: in extract_insn, at recog.c:2769
0x68e4b3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:108
0x68e4df _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:116
0xd8245b extract_insn(rtx_insn*)
/home/alecop01/toolchain/src/gcc/gcc/recog.c:2769
0xa884ef instantiate_virtual_regs_in_insn
/home/alecop01/toolchain/src/gcc/gcc/function.c:1611
0xa884ef instantiate_virtual_regs
/home/alecop01/toolchain/src/gcc/gcc/function.c:1985
0xa884ef execute
/home/alecop01/toolchain/src/gcc/gcc/function.c:2034
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/102273] ICE in expand_DEFERRED_INIT, at internal-fn.c:3024 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102273 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:79f488de3036a4a4be08df2a782e6eb02419db19 commit r12-3447-g79f488de3036a4a4be08df2a782e6eb02419db19 Author: Richard Biener Date: Fri Sep 10 12:28:09 2021 +0200 middle-end/102273 - avoid ICE with auto-init and nested functions This refactors expansion to consider non-decl LHS. I suspect the is_val argument is not needed. 2021-09-10 Richard Biener PR middle-end/102273 * internal-fn.c (expand_DEFERRED_INIT): Always expand non-SSA vars. * gcc.dg/pr102273.c: New testcase.
[Bug tree-optimization/102273] ICE in expand_DEFERRED_INIT, at internal-fn.c:3024 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102273 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug other/101711] Error when gcc cross compile libvtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101711 --- Comment #11 from bootmgr at 163 dot com --- (In reply to ctice from comment #10) > I have been trying off-and-on for the last 3 weeks to build a ming64 GCC > cross-compiler, on my x86_64 linux ELF system, and I have not been able to > do it. This is without enabling libvtv. The instructions referenced on > https://sourceforge.net/p/mingw-w64/wiki2/ > Cross%20Win32%20and%20Win64%20compiler/ are at least 8 years out of date, > and I have not been able to make them work. > > Until I can get a set of instructions that works, I cannot reproduce the > problem, and without reproducing it I cannot debug/fix it. I am sorry about > this, but I really have tried. Can you give me your error messages?
[Bug tree-optimization/97352] gcc.dg/vect/bb-slp-pr78205.c fails to vectorize all opportunities with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97352 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug fortran/102275] New: Assumed rank, unlimited polymorphic pointer gives incorrect behavious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102275 Bug ID: 102275 Summary: Assumed rank, unlimited polymorphic pointer gives incorrect behavious Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: paal at levold dot net Target Milestone: --- Created attachment 51434 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51434&action=edit Source code reproducing the issue Possibly related to bug 100097. Environment: GCC 11.2.0 Docker image from https://hub.docker.com/_/gcc. The attached code uses a unlimited polymorphic pointer with assumed rank. When running it produces the following output: This is correct: rank 0 rank 1 T T ptr0 = 123 ptr1 =1 2 3 This is NOT correct: rank 0 rank 0 F T uptr1 = 123 The latter part is incorrect, it should be: rank 0 rank 1 T T uptr0 = 123 uptr1 =1 2 3
[Bug middle-end/102276] New: -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
Bug ID: 102276
Summary: -ftrivial-auto-var-init fails to initialize a
variable, causes a spurious warning
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
int g(int *);
int f1()
{
switch (0) {
int x;
default:
return g(&x);
}
}
int f2()
{
goto L;
{
int x;
L:
return g(&x);
}
}
Compiling with -O2 -ftrivial-auto-var-init=pattern causes spurious
warning: statement will never be executed [-Wswitch-unreachable]
5 | int x;
| ^
In both f1 and f2, resulting assembly does not in fact initialize 'x':
f1:
subq$24, %rsp
leaq12(%rsp), %rdi
callg
addq$24, %rsp
ret
f2:
subq$24, %rsp
leaq12(%rsp), %rdi
callg
addq$24, %rsp
ret
[Bug tree-optimization/102269] ICE in verify_gimple_stmt and -ftrivial-auto-var-init=zero and zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102269 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #5 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) > Fixed. thanks a lot for fixing this. Qing
[Bug ipa/62051] [9/10/11/12 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051 --- Comment #27 from Jason Merrill --- (In reply to Andrew Pinski from comment #26) > That is Base and Derived in the shared library and the main program are > considered two different classes because of -fvisibility=hidden and the > classes are not marked as visibility default. Symbol visibility is outside the language, and doesn't affect mangling, so I don't think it's accurate to say they are considered two different classes. It seems to me they are the same classes, with controlled access to the implementation.
[Bug bootstrap/102277] New: hppa2.0w-hp-hpux11.23 bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102277 Bug ID: 102277 Summary: hppa2.0w-hp-hpux11.23 bootstrap comparison failure Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: me at larbob dot org Target Milestone: --- Building gcc-12-20210905 seems to result in a bootstrap comparison failure between stages 2 and 3 on hppa2.0w-hp-hpux11.*. Comparing stages 2 and 3 warning: hppa2.0w-hp-hpux11.23/libgcc/lib2funcs_s.o differs warning: hppa2.0w-hp-hpux11.23/libgcc/lib2funcs.o differs Bootstrap comparison failure! gcc/cp/module.o differs make[2]: *** [Makefile:22059: compare] Error 1 Compiled with gcc 11.1.
[Bug libgcc/102278] New: Fails to build on powerpc-unknown-freebsd since 20210801 snapshot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102278 Bug ID: 102278 Summary: Fails to build on powerpc-unknown-freebsd since 20210801 snapshot Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: pkubaj at anongoth dot pl Target Milestone: --- 20210725 was the last snapshot that built. 20210801 fails with: /wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210801/gcc/lra-constraints.c: In function 'bool curr_insn_transform(bool)': /wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210801/gcc/lra-constraints.c:4367:21: error: suggest parentheses around assignment used as truth value [-Werror=parentheses] 4367 | (c = *constraint) && c != ',' && c != '#'; After that, build fails with: during GIMPLE pass: ldist /wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210808/libgcc/libgcov-interface.c: In function '__gcov_execl': /wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210808/libgcc/libgcov-interface.c:201:1: internal compiler error: Segmentation fault 201 | __gcov_execl (const char *path, char *arg, ...) | ^~~~ I build on FreeBSD 13.0-RELEASE using LLVM 11.0.1.
[Bug tree-optimization/102273] ICE in expand_DEFERRED_INIT, at internal-fn.c:3024 since r12-3433-ga25e0b5e6ac8a77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102273 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #5 from qinzhao at gcc dot gnu.org --- (In reply to CVS Commits from comment #3) > The master branch has been updated by Richard Biener : > > middle-end/102273 - avoid ICE with auto-init and nested functions > > This refactors expansion to consider non-decl LHS. I suspect > the is_val argument is not needed. > Thank you for fixing this. I will double check whether the IS_VLA argument is really needed or not. and will delete it if we don't need it.
[Bug libstdc++/102270] std::tuple<>::swap missing constexpr specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270
--- Comment #2 from 康桓瑋 ---
In addition, the uses-allocator construction version also missing constexpr
specifier, but I don't know if this is intentional.
#include
#include
struct O {
using allocator_type = std::allocator;
O() = default;
constexpr O(const allocator_type&) {}
};
constexpr std::allocator a;
constexpr std::tuple t(std::allocator_arg, a);
https://godbolt.org/z/ba61nWhYx
[Bug c/102279] New: Bad codegen with ILP32, packed struct field pointer, static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102279
Bug ID: 102279
Summary: Bad codegen with ILP32, packed struct field pointer,
static variable
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nyphbl8d at gmail dot com
Target Milestone: ---
Created attachment 51435
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51435&action=edit
preprocessed source
When using a packed struct with AArch64 ILP32, -O2, and packed struct field
manipulation by pointer, gcc can produce bad assembly output.
The preprocessed Linux-native test case source is attached.
The original test case was compiled with:
aarch64-rtems6-gcc (GCC) 10.3.1 20210409 (RTEMS 6, RSB
d162b7de619779d29a27b95bfd10a2441c2e5dca-modified, Newlib 4f81149)
aarch64-rtems6-gcc -c -o align_test.o -D__rtems__ -D_GNU_SOURCE -O2 -g -Wall
-I../new-install/aarch64-rtems6/xilinx_zynqmp_ilp32_zu3eg/lib/include
-mcpu=cortex-a53 -mabi=ilp32 -ffunction-sections -fdata-sections align_test.c
The Linux-native test case was compiled with:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads
aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
10.3-2021.07 (arm-10.29)) 10.3.1 20210621
./gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc
align_test.linux.c -o align_test.linux.o -c -mabi=ilp32 -O2 -mcpu=cortex-a53
-Wall -ffunction-sections -fdata-sections --save-temps
This code should produce 0x12341234, but instead produces 0x1234abcd under
RTEMS running under QEMU and on hardware. I was not able to run the code under
Linux on an ARM64 machine, but the assembly looks equally broken based on my
reading and understanding.
Linux-native source align_test.linux.c:
#include
#include
#pragma pack(1)
struct S
{
uint32_t field1;
uint16_t field2;
};
#pragma pack()
int main() {
static int static_int = 0;
uint16_t *word_ptr;
struct S m;
m.field1 = 0x1234ABCD + static_int;
word_ptr = (uint16_t *) &(m.field1);
word_ptr[0] = word_ptr[1];
printf("0x%x\n", m.field1);
static_int++;
return 0;
}
I'm happy to provide any other information required and I have source, object
files, and disassembly ready to share if necessary.
These resolve the problem:
* Removing the pack pragmas
* Changing -O2 to -O0 (-Os still displays bad codegen)
* Switching the data manipulation to bitshifting
* Removing "static_int++"
* Removing field2
* Adding "uint16_t field3;" after field2
[Bug c/102279] Bad codegen with ILP32, packed struct field pointer, static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102279 --- Comment #1 from Richard Earnshaw --- Looks to me like this code violates the aliasing rules. Compiling with -fno-strict-aliasing looks generate what your are expecting (although your expectations are wrong by the C standard). Oddly, -Wstrict-aliasing does not pick this case up, perhaps because of the packed attribute.
[Bug middle-end/40505] hppa: ICE: in expand_expr_addr_expr_1, at expr.c:6830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40505 --- Comment #10 from dave.anglin at bell dot net --- The ICE doesn't occur with g++-8, g++-9, g++-10 or g++-11, so I think this bug can be closed.
[Bug c/102279] Bad codegen with ILP32, packed struct field pointer, static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102279 Will changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Will --- Thanks(In reply to Richard Earnshaw from comment #1) > Looks to me like this code violates the aliasing rules. Compiling with > -fno-strict-aliasing looks generate what your are expecting (although your > expectations are wrong by the C standard). > > Oddly, -Wstrict-aliasing does not pick this case up, perhaps because of the > packed attribute. Thanks Richard! This is obviously a gap in my knowledge I need to fill in.
[Bug c/102279] Bad codegen with ILP32, packed struct field pointer, static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102279 --- Comment #3 from Richard Earnshaw --- (In reply to Will from comment #2) > Thanks Richard! This is obviously a gap in my knowledge I need to fill in. The aliasing rules say (in essence) that a pointer to an object of type T1 cannot point to an object of type T2, unless one of the types is derived from char. It's defined so that the compiler can safely move loads and stores to different types around when optimizing in order to generate more efficient code.
[Bug c++/102280] New: span'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102280 Bug ID: 102280 Summary: span' Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: joeloser93 at gmail dot com Target Milestone: ---
[Bug c++/102280] span's range deduction guide is missing contiguous_iterator constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102280 --- Comment #1 from Joe Loser --- `span` has a range deduction guide, but it is not properly constrained for ranges satisfying `contiguous_iterator` concept only at https://github.com/gcc-mirror/gcc/blob/01b5038718056b024b370b74a874fbd92c5bbab3/libstdc%2B%2B-v3/include/std/span#L412 per 22.7.3.3 in the working draft.
[Bug c++/102280] span's range deduction guide is missing ranges::contiguous_range constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102280 --- Comment #2 from Joe Loser --- Sorry, typo in previous comment. The `span` range deduction guide should constrain on `ranges::contiguous_range`, not `contiguous_iterator` concept -- sorry. This is from P1394 (https://wg21.link/p1394).
[Bug c++/102281] New: -ftrivial-auto-var-init=zero causes ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
Bug ID: 102281
Summary: -ftrivial-auto-var-init=zero causes ice
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ code:
long _mm_set_epi64x___q0;
__attribute__((__vector_size__(2 * sizeof(long long long _mm_set_epi64x() {
return (__attribute__((__vector_size__(2 * sizeof(long long long){
_mm_set_epi64x___q0};
}
compiled by recent gcc and compiler flag -ftrivial-auto-var-init=zero,
does this:
$ /home/dcb/gcc/results/bin/gcc -ftrivial-auto-var-init=zero bug756.cc
bug756.cc: In function ‘__vector(2) long long int _mm_set_epi64x()’:
bug756.cc:2:62: error: invalid operand in return statement
2 | _attribute__((__vector_size__(2 * sizeof(long long long
_mm_set_epi64x() {
|
^~
D.2371
return D.2371;
bug756.cc:2:62: internal compiler error: ‘verify_gimple’ failed
0x105dc3a verify_gimple_in_seq(gimple*)
../../trunk.git/gcc/tree-cfg.c:5228
Taking the new flag off causes the code to compile ok:
$ /home/dcb/gcc/results/bin/gcc -c bug756.cc
$
[Bug testsuite/102282] New: New test cases in r12-3320 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102282 Bug ID: 102282 Summary: New test cases in r12-3320 fail Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:cb17b5054118ec0f727956fd6e034b577b5e261c, r12-3320 Some issue with how they are configured maybe? UNRESOLVED: gfortran.dg/c-interop/cf-descriptor-5.f90 -O0 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/cf-descriptor-5.f90 -O1 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/cf-descriptor-5.f90 -O2 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/cf-descriptor-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/cf-descriptor-5.f90 -O3 -g compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/cf-descriptor-5.f90 -Os compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/cf-out-descriptor-5.f90 -O0 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/cf-out-descriptor-5.f90 -O1 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/cf-out-descriptor-5.f90 -O2 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/cf-out-descriptor-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/cf-out-descriptor-5.f90 -O3 -g compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/cf-out-descriptor-5.f90 -Os compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/fc-descriptor-5.f90 -O0 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/fc-descriptor-5.f90 -O1 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/fc-descriptor-5.f90 -O2 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/fc-descriptor-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/fc-descriptor-5.f90 -O3 -g compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/fc-descriptor-5.f90 -Os compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/fc-out-descriptor-5.f90 -O0 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/fc-out-descriptor-5.f90 -O1 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/fc-out-descriptor-5.f90 -O2 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/fc-out-descriptor-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/fc-out-descriptor-5.f90 -O3 -g compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/fc-out-descriptor-5.f90 -Os compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/ff-descriptor-5.f90 -O0 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/ff-descriptor-5.f90 -O1 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/ff-descriptor-5.f90 -O2 compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/ff-descriptor-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/ff-descriptor-5.f90 -O3 -g compilation failed to produce executable UNRESOLVED: gfortran.dg/c-interop/ff-descriptor-5.f90 -Os compilation failed to produce executable commit cb17b5054118ec0f727956fd6e034b577b5e261c (HEAD) Author: Sandra Loosemore Date: Wed Jun 30 20:03:27 2021 -0700 Fortran: TS 29113 testsuite Add tests to exercise features added to Fortran via TS 29113, "Further Interoperability of Fortran with C":
[Bug c++/102283] New: Inconsistent/wrong overload resolution when using an initializer list and a defaulted template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102283
Bug ID: 102283
Summary: Inconsistent/wrong overload resolution when using an
initializer list and a defaulted template parameter
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hello,
The following testcase has an "inconsistent" overload resolution:
template
struct helper {};
struct data {};
template
struct S
{
template
void f(T2 &&); // #1
template
void f(const helper &); // #2
};
int main() {
S s1;
S s2;
s1.f({});
s2.f({});
}
https://gcc.godbolt.org/z/nsj48M7af
On GCC 11, the the first call to f() resolves to #1, but the second call
resolves to #2. I cannot find any reason for this inconsistency in the ranking
of the overloads; no warnings are emitted under -Wall -Wextra.
Clang and MSVC both always call #1.
[Bug fortran/100110] Parameterized Derived Types, problems with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100110 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:714b85f6fce0448b9d4d5e5d21152a3478b27422 commit r10-10106-g714b85f6fce0448b9d4d5e5d21152a3478b27422 Author: Paul Thomas Date: Tue Apr 20 07:30:07 2021 +0100 Fortran: Fix host associated PDT entity initialization 2021-04-20 Paul Thomas gcc/fortran PR fortran/100110 * trans-decl.c (gfc_get_symbol_decl): Replace test for host association with a check that the current and symbol namespaces are the same. gcc/testsuite/ PR fortran/100110 * gfortran.dg/pdt_31.f03: New test. * gfortran.dg/pdt_26.f03: Reduce 'builtin_malloc' count from 9 to 8. (cherry picked from commit 67378cd63d62bf0c69e966d1d202a1e586550a68)
[Bug bootstrap/102278] [12 regression] Bootstrap fails with LLVM 11.0.1 on powerpc-unknown-freebsd: libgcov-interface.c:201:1: internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102278 --- Comment #1 from Piotr Kubaj --- The full error with the command line executed is: /wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/xgcc -B/wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/ -B/usr/local/powerpc-portbld-freebsd13.0/bin/ -B/usr/local/powerpc-portbld-freebsd13.0/lib/ -isystem /usr/local/powerpc-portbld-freebsd13.0/include -isystem /usr/local/powerpc-portbld-freebsd13.0/sys-include -fno-checking -g -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -O2 -g -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DIN_GCC -fPIC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem ./include -fPIC -pthread -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread -I. -I. -I../.././gcc -I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc -I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc/. -I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc/../gcc -I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc/../include -DHAVE_CC_TLS -o _gcov_execl.o -MT _gcov_execl.o -MD -MP -MF _gcov_execl.dep -DL_gcov_execl -c /wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc/libgcov-interface.c during GIMPLE pass: ldist /wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc/libgcov-interface.c: In function '__gcov_execl': /wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20210829/libgcc/libgcov-interface.c:201:1: internal compiler error: Segmentation fault 201 | __gcov_execl (const char *path, char *arg, ...)
[Bug fortran/100110] Parameterized Derived Types, problems with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100110 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f692856517393d60f745f20306173919e18fc71a commit r9-9718-gf692856517393d60f745f20306173919e18fc71a Author: Paul Thomas Date: Tue Apr 20 07:30:07 2021 +0100 Fortran: Fix host associated PDT entity initialization 2021-04-20 Paul Thomas gcc/fortran PR fortran/100110 * trans-decl.c (gfc_get_symbol_decl): Replace test for host association with a check that the current and symbol namespaces are the same. gcc/testsuite/ PR fortran/100110 * gfortran.dg/pdt_31.f03: New test. * gfortran.dg/pdt_26.f03: Reduce 'builtin_malloc' count from 9 to 8. (cherry picked from commit 67378cd63d62bf0c69e966d1d202a1e586550a68)
[Bug fortran/100110] Parameterized Derived Types, problems with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100110 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Backported Paul's fix to remaining open branches. Closing. Thanks to everybody!
[Bug bootstrap/102278] [12 regression] Bootstrap fails with LLVM 11.0.1 on powerpc-unknown-freebsd: libgcov-interface.c:201:1: internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102278 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Keywords||build Last reconfirmed||2021-09-10 --- Comment #2 from Andrew Pinski --- A couple of things: How did you configure GCC? Do you have any env variables set that could influence the bootstrap e.g. CXXFLAGS or STAGE1_CXXFLAGS, etc.? I am trying to check to see if LLVM is not miscompiling GCC here (it could be). Also can you attach the full build log? What stage is the building failing, stage 1 or stage2 or stage 3?
[Bug fortran/98472] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:7352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98472 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:0a79a5457a1a982dd05b8ae33e1320d040a20ccd commit r10-10107-g0a79a5457a1a982dd05b8ae33e1320d040a20ccd Author: Paul Thomas Date: Wed Jan 27 09:12:16 2021 + Fortran: Fix ICE due to elemental procedure pointers [PR98472]. 2021-01-27 Paul Thomas gcc/fortran PR fortran/98472 * trans-array.c (gfc_conv_expr_descriptor): Include elemental procedure pointers in the assert under the comment 'elemental function' and eliminate the second, spurious assert. gcc/testsuite/ PR fortran/98472 * gfortran.dg/elemental_function_5.f90 : New test. (cherry picked from commit 003f0414291d595d2126e6d2e24b281f38f3448f)
[Bug fortran/98472] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:7352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98472 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c101105e7852a940f967137f6b9e0a97d7f2c3c3 commit r9-9719-gc101105e7852a940f967137f6b9e0a97d7f2c3c3 Author: Paul Thomas Date: Wed Jan 27 09:12:16 2021 + Fortran: Fix ICE due to elemental procedure pointers [PR98472]. 2021-01-27 Paul Thomas gcc/fortran PR fortran/98472 * trans-array.c (gfc_conv_expr_descriptor): Include elemental procedure pointers in the assert under the comment 'elemental function' and eliminate the second, spurious assert. gcc/testsuite/ PR fortran/98472 * gfortran.dg/elemental_function_5.f90 : New test. (cherry picked from commit 003f0414291d595d2126e6d2e24b281f38f3448f)
[Bug fortran/98472] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:7352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98472 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- Backported to remaining open branches after verifying that it works. Closing. Thanks to everybody involved!
[Bug fortran/93701] ICE on associate of wrongly accessed array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93701 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:56defe319186a21dc37e50db8d71185bce332506 commit r10-10108-g56defe319186a21dc37e50db8d71185bce332506 Author: Paul Thomas Date: Thu Jan 7 17:34:49 2021 + Fortran: Improve resolution of associate variables. [PR93701]. 2021-01-07 Paul Thomas gcc/fortran PR fortran/93701 * resolve.c (find_array_spec): Put static prototype for resolve_assoc_var before this function and call for associate variables. gcc/testsuite/ PR fortran/93701 * gfortran.dg/associate_54.f90: New test. * gfortran.dg/associate_55.f90: New test. * gfortran.dg/associate_56.f90: New test. (cherry picked from commit 85fb1d7d5f44a81a52015d58ebe67765faabfd35)
[Bug c++/96184] [11/12 Regression] GCC treats "use of local variable with automatic storage from containing function" differently in versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96184 Jason Merrill changed: What|Removed |Added Priority|P3 |P2 Target Milestone|9.5 |11.0 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Summary|[9/10 Regression] GCC |[11/12 Regression] GCC |treats "use of local|treats "use of local |variable with automatic |variable with automatic |storage from containing |storage from containing |function" differently in|function" differently in |versions|versions --- Comment #4 from Jason Merrill --- I think it's ill-formed, because the use of 'a' is in a function parameter scope, rather than in 'main'. The changes in whether we accepted this testcase were indeed by accident, as the way we handled 'this' injection changed whether parsing_nsdmi() returned true.
[Bug fortran/93701] ICE on associate of wrongly accessed array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93701 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:acfdc0b662e8ed7d850ef42215b2436df720ca5f commit r9-9720-gacfdc0b662e8ed7d850ef42215b2436df720ca5f Author: Paul Thomas Date: Thu Jan 7 17:34:49 2021 + Fortran: Improve resolution of associate variables. [PR93701]. 2021-01-07 Paul Thomas gcc/fortran PR fortran/93701 * resolve.c (find_array_spec): Put static prototype for resolve_assoc_var before this function and call for associate variables. gcc/testsuite/ PR fortran/93701 * gfortran.dg/associate_54.f90: New test. * gfortran.dg/associate_55.f90: New test. * gfortran.dg/associate_56.f90: New test. (cherry picked from commit 85fb1d7d5f44a81a52015d58ebe67765faabfd35)
[Bug fortran/93701] ICE on associate of wrongly accessed array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93701 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Backported to remaining open branches after verifying that the fix works. Closing. Thanks to all!
[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 Bug 87477 depends on bug 93701, which changed state. Bug 93701 Summary: ICE on associate of wrongly accessed array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93701 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/97723] type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:25d45b5dd41a9ab005a5ae8ee8e54be17f2467a2 commit r10-10109-g25d45b5dd41a9ab005a5ae8ee8e54be17f2467a2 Author: Paul Thomas Date: Sun Dec 27 14:59:38 2020 + Fortran: Fix some select rank issues [PR97694 and 97723]. 2020-12-27 Paul Thomas gcc/fortran PR fortran/97694 PR fortran/97723 * check.c (allocatable_check): Select rank temporaries are permitted even though they are treated as associate variables. * resolve.c (gfc_resolve_code): Break on select rank as well as select type so that the block os resolved. * trans-stmt.c (trans_associate_var): Class associate variables that are optional dummies must use the backend_decl. gcc/testsuite/ PR fortran/97694 PR fortran/97723 * gfortran.dg/select_rank_5.f90: New test. (cherry picked from commit c4a678981572c12d158709ace0d3f23dd04cf217)
[Bug fortran/97694] ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:25d45b5dd41a9ab005a5ae8ee8e54be17f2467a2 commit r10-10109-g25d45b5dd41a9ab005a5ae8ee8e54be17f2467a2 Author: Paul Thomas Date: Sun Dec 27 14:59:38 2020 + Fortran: Fix some select rank issues [PR97694 and 97723]. 2020-12-27 Paul Thomas gcc/fortran PR fortran/97694 PR fortran/97723 * check.c (allocatable_check): Select rank temporaries are permitted even though they are treated as associate variables. * resolve.c (gfc_resolve_code): Break on select rank as well as select type so that the block os resolved. * trans-stmt.c (trans_associate_var): Class associate variables that are optional dummies must use the backend_decl. gcc/testsuite/ PR fortran/97694 PR fortran/97723 * gfortran.dg/select_rank_5.f90: New test. (cherry picked from commit c4a678981572c12d158709ace0d3f23dd04cf217)
[Bug fortran/97723] type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||anlauf at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Backported Paul's fix to 10-branch after verifying that it does the job. The backport to 9-branch would require more work, thus not done. Closing.
[Bug fortran/97694] ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org --- Comment #10 from anlauf at gcc dot gnu.org --- Backported Paul's fix to 10-branch after verifying that it does the job. The backport to 9-branch would require more work, thus not done. Closing.
[Bug libstdc++/102259] ifstream::read(…, count) fails when count >= 2^31 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259 --- Comment #3 from Andrew Pinski --- (In reply to Michel Morin from comment #2) > Whoa, darwin's (and FreeBSD's too?) `read(…, …, nbyte)` fails when nbyte >= > 2^31! This is the culprit, I think. > > I also found the following description in FreeBSD's manpage of read > (https://www.unix.com/man-page/FreeBSD/2/read/): > > ERRORS > [EINVAL] The value nbytes is greater than INT_MAX. > > Given that the testcase works file when compiled with Clang, libcxx would > have some workround for it. Maybe they do a loop around the read for sizes >= INT_MAX. I don't know if that is the correct thing to do or not.
[Bug fortran/98565] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98565 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:5bb6119070a7aab95dad3bcf3cdf8ac2bc818488 commit r9-9721-g5bb6119070a7aab95dad3bcf3cdf8ac2bc818488 Author: Paul Thomas Date: Fri Jan 22 17:11:06 2021 + Fortran: Fix for class functions as associated target [PR98565]. 2021-01-22 Paul Thomas gcc/fortran PR fortran/98565 * trans-intrinsic.c (gfc_conv_associated): Do not add a _data component for scalar class function targets. Instead, fix the function result and access the _data from that. gcc/testsuite/ PR fortran/98565 * gfortran.dg/associated_target_7.f90 : New test. (cherry picked from commit bf8ee9e4eed6ba1a6d77b4cf168df480e1f954da)
[Bug fortran/98565] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98565 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Backported Paul's fix to remaining open branches after verifying that it does the job. Closing. Thanks to all!
[Bug fortran/98565] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98565 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:755299ea93dd064ab5ec1027a34f30ca2d908f4c commit r10-10110-g755299ea93dd064ab5ec1027a34f30ca2d908f4c Author: Paul Thomas Date: Fri Jan 22 17:11:06 2021 + Fortran: Fix for class functions as associated target [PR98565]. 2021-01-22 Paul Thomas gcc/fortran PR fortran/98565 * trans-intrinsic.c (gfc_conv_associated): Do not add a _data component for scalar class function targets. Instead, fix the function result and access the _data from that. gcc/testsuite/ PR fortran/98565 * gfortran.dg/associated_target_7.f90 : New test. (cherry picked from commit bf8ee9e4eed6ba1a6d77b4cf168df480e1f954da)
[Bug fortran/97612] [F08] Structure constructor of type with nested allocatable array components fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97612 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:80b1492b2de153f4850a32cafcd8f4d37c2c84fc commit r10-10111-g80b1492b2de153f4850a32cafcd8f4d37c2c84fc Author: Paul Thomas Date: Tue Dec 29 17:44:48 2020 + Fortran: Correct missing structure constructor comps. [PR97612]. 2020-12-29 Paul Thomas gcc/fortran PR fortran/97612 * primary.c (build_actual_constructor): Missing allocatable components are set unallocated using EXPR_NULL. Then missing components are tested for a default initializer. gcc/testsuite/ PR fortran/97612 * gfortran.dg/structure_constructor_17.f90: New test. (cherry picked from commit eeb145317b42d5203056851435457d9189a7303d)
[Bug fortran/97612] [F08] Structure constructor of type with nested allocatable array components fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97612 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:19f2f22d59f4a3a7e246d09be11a727cffb8badc commit r9-9722-g19f2f22d59f4a3a7e246d09be11a727cffb8badc Author: Paul Thomas Date: Tue Dec 29 17:44:48 2020 + Fortran: Correct missing structure constructor comps. [PR97612]. 2020-12-29 Paul Thomas gcc/fortran PR fortran/97612 * primary.c (build_actual_constructor): Missing allocatable components are set unallocated using EXPR_NULL. Then missing components are tested for a default initializer. gcc/testsuite/ PR fortran/97612 * gfortran.dg/structure_constructor_17.f90: New test. (cherry picked from commit eeb145317b42d5203056851435457d9189a7303d)
