[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 68694, which changed state. Bug 68694 Summary: SLP loads should be permuted until supported if possible https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68694 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/68694] SLP loads should be permuted until supported if possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68694 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- I think it was fixed with r12-1329 instead (also when you associate in source). But yes, r10-1321 makes it less likely to happen for well-written user code.
[Bug tree-optimization/95084] [11/12 Regression] code sinking prevents if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95084 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #2 from Richard Biener --- Note the issue is older but there are some cases where sink didn't do its job that have been fixed meanwhile. For GCC 12 we have an additional (albeit quite late) sinking pass, so one option might be to tame down early sinking for possibly trapping operations in loops that look like they could be vectorized (similar how we tame PRE). I think the only loop pass affected by not sinking might be unswitching which could get less favorable costs due to the need to duplicate the not sunk stmts. At least I cannot think of a way to preserve the conditional non-trappingness on the ref after sinking it.
[Bug target/103771] [12 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #33 from Andrew Pinski --- Oh yes I remember why factor_out_conditional_conversion is not doing it. it is because we have two bb but the current code does not handle that case. That is we have: if (x.1_1 > 255) goto ; [INV] else goto ; [INV] : _2 = -x_5(D); _3 = _2 >> 31; iftmp.0_7 = (uint8_t) _3; goto ; [INV] : iftmp.0_6 = (uint8_t) x_5(D); : # iftmp.0_4 = PHI While the correct code only handles the case where the one of the bb4 does not exist. Yes I am working on this for GCC 13.
[Bug d/102765] [11 Regression] GDC11 stopped inlining library functions and lambdas used by a binary search one-liner code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102765 --- Comment #4 from Siarhei Siamashka --- First of all, it's my own fault for not just bisecting the GDC code from the day one to figure out all the relevant details many months earlier. The code is large and takes a lot of time to compile, so I was lazy. And I apologise for this. Now comments from https://forum.dlang.org/thread/sspkdp$1m4n$1...@digitalmars.com provided some missing bits of important information. I may be still wrong, so please correct me if necessary, but the root cause of this performance regression appears to be an attempt to fix the actual problem PR104317 in GDC11 via some excessively invasive PR99914 that ended up evolving GDC in a wrong direction. Just imagine someone encountering something like the examples from https://stackoverflow.com/questions/3691835/why-uninitialized-global-variable-is-weak-symbol and then suddenly making a strange conclusion that all template functions should be non-inlineable in a C++ compiler (unless LTO is enabled). Looks like that's exactly what happened to GDC. The D language standard documentation is incomplete and this isn't helping. But the developers of the other D compilers seem to have an opinion that inlining template functions is okay (due to the same or at least similar ODR rules as in C++).
[Bug d/104317] D language: rt.config module doesn't work as expected in GDC 9/10 (multiple definition linker error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104317
Siarhei Siamashka changed:
What|Removed |Added
CC||siarhei.siamashka at gmail dot
com
--- Comment #2 from Siarhei Siamashka ---
Created attachment 52322
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52322&action=edit
proof of concept patch for gdc10
The attached proof of concept patch for GDC10 fixes the problem in a much less
invasive way. The idea is to just use weak attributes for global variables in
druntime instead of enclosing them in a "template {}" block.
A preliminary pull request for upstream druntime is tracked here:
https://github.com/dlang/druntime/pull/3716
The same simple fix also works fine for GDC11 if we undo PR99914:
https://gist.github.com/ssvb/d8a67fb445e96f9e66d0516a3ba62475
I first tried to toggle "flag_weak_templates" in "gcc/d/lang.opt" from 1 to 0
in GDC11 instead of reverting PR99914, but the resulting toolchain was unable
to compile and link even the most simple applications due to missing symbols
from Phobos.
The part preventing undesirable removal of cmdline arguments is cherry picked
from:
https://github.com/dlang/druntime/commit/ae9581c1e4b96de6707c71eb45dcc9c10dd4d402
[Bug c++/104319] better error message for parsing error when >= ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Summary|"parse error of template|better error message for
|argument list" due to |parsing error when >= ends
|missing space in ">==", a |a template variable.
|better error message should |
|be given|
Ever confirmed|0 |1
Last reconfirmed||2022-02-01
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed here is a simplified reduced testcase:
template int Zero;
void f(void)
{
Zero=0;
}
--- CUT
GCC currently produces:
: In function 'void f()':
:4:3: error: parse error in template argument list
4 | Zero=0;
| ^~~
Clang gives:
:4:11: error: a space is required between a right angle bracket and an
equals sign (use '> =')
Zero=0;
^~
> =
While MSVC gives:
(4): error C2947: expecting '>' to terminate template-argument-list,
found '>='
ICC gives:
(4): error: expected a ">"
Zero=0;
^
All three are better than GCC's really.
[Bug c++/104319] New: "parse error of template argument list" due to missing space in ">==", a better error message should be given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319
Bug ID: 104319
Summary: "parse error of template argument list" due to missing
space in ">==", a better error message should be given
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
consider following code (https://www.godbolt.org/z/4drb17Pqn):
template
struct A{
constexpr static int value=0;
};
template
constexpr int Zero=A::value;
static_assert(Zero==0);
:8:15: error: parse error in template argument list
8 | static_assert(Zero==0);
| ^~~~
:8:15: error: template argument 1 is invalid
Compiler returned: 1
clang gives much clear reason:
error: a space is required between a right angle bracket and an equals sign
(use '> =')
static_assert(Zero==0);
^~
> =
clearly "Zero" can be considered template id to avoid template argument
list error message.
[Bug d/104317] D language: rt.config module doesn't work as expected in GDC 9/10 (multiple definition linker error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104317 --- Comment #1 from Siarhei Siamashka --- An attempted fix for the linker error had been introduced in GDC11 via: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99914 But it made function templates non-inlineable as a side effect: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102765 Also cmdline arguments with "--DRT-" prefix are still incorrectly filtered out: $ gdc-11.2.0 test.d && ./a.out --DRT-this-cmdline-argument-should-not-be-filtered-out ["./a.out"] It would be useful to have a better fix for this problem.
[Bug c++/104318] New: [modules] ICE tsubst_copy, at cp/pt.c:16621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104318
Bug ID: 104318
Summary: [modules] ICE tsubst_copy, at cp/pt.c:16621
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wentam42 at gmail dot com
Target Milestone: ---
Reproducible here with both 11.2 and trunk.
foo_interface.ii=
# 0 ""
# 1 "foo2.ipp"
module ;
# 1 "include1.h" 1
template void h(int a) { a; }
template struct d { virtual void e() { h; } };
extern template struct d;
template struct c;
template > struct b { d f; };
template <> struct c { void g() { b f; } };
# 3 "foo2.ipp" 2
export module mod;
b a;
foo_implementation.ii===
# 0 ""
# 1 "foo2.cpp"
module ;
# 1 "include2.h" 1
template void h(int);
template struct c { int static b; };
void b() { c::b; }
# 3 "foo2.cpp" 2
module mod;
build
g++ -std=c++20 -fmodules-ts -c foo_interface.ii
g++ -std=c++20 -fmodules-ts -c foo_implementation.ii
output
In file included from foo2.ipp:2,
of module mod, imported at foo2.cpp:3:
include1.h: In instantiation of ‘void h(int) [with =
int]’:
include1.h:2:51: required from ‘void d@mod< >::e()
[with = int]’
include1.h:2:45: required from here
include1.h:1:37: internal compiler error: in tsubst_copy, at cp/pt.c:16621
1 | template void h(int a) { a; }
| ^
0x1724b67 internal_error(char const*, ...)
???:0
0x66b62d fancy_abort(char const*, int, char const*)
???:0
0x7d05ff instantiate_decl(tree_node*, bool, bool)
???:0
0x7ec25b instantiate_pending_templates(int)
???:0
0x6fe518 c_parse_final_cleanups()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug d/104317] New: D language: rt.config module doesn't work as expected in GDC 9/10 (multiple definition linker error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104317
Bug ID: 104317
Summary: D language: rt.config module doesn't work as expected
in GDC 9/10 (multiple definition linker error)
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: siarhei.siamashka at gmail dot com
Target Milestone: ---
The rt.config module provides a set of configuration variables with various
ways to override them as documented here:
https://dlang.org/phobos/rt_config.html
The following small application can be used to test it:
import std.stdio;
extern(C) __gshared bool rt_cmdline_enabled = false;
void main(string[] args) { writeln(args); }
== Expected correct result: ==
$ gdc test.d && ./a.out --DRT-this-cmdline-argument-should-not-be-filtered-out
["./a.out", "--DRT-this-cmdline-argument-should-not-be-filtered-out"]
== Got: ==
$ gdc-9.3.0 test.d
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libgdruntime.a(lt8-config.o):/var/tmp/portage/sys-devel/gcc-9.3.0-r1/work/gcc-9.3.0/libphobos/libdruntime/rt/config.d:48:
multiple definition of `rt_cmdline_enabled'; /tmp/ccvDzGs7.o:(.bss+0x0): first
defined here
collect2: error: ld returned 1 exit status
$ gdc-12.0.1 test.d && ./a.out
--DRT-this-cmdline-argument-should-not-be-filtered-out
["./a.out", "--DRT-this-cmdline-argument-should-not-be-filtered-out"]
[Bug c++/104302] [12 Regression] ICE Segmentation fault since r12-6825-g2da90ad39bf8fa9e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104302
--- Comment #1 from Andrew Pinski ---
Reduced further:
struct ss {};
static ss ff(void* const v);
template
void f1(void) {
int mem[mem_size];
ss StateRegs[] = {
ff(mem)
};
}
CUT ---
mem's array size needs to be value dependent.
[Bug c++/104300] [12 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2977 since r12-6326-ge948436eab818c52
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104300
--- Comment #1 from Andrew Pinski ---
Reduced a little further:
struct ss {
char r;
ss();
};
struct a {
ss e[6];
};
a vv;
void ff() { vv = {}; }
[Bug fortran/104309] Elemental character function should not return array of character variables of different lengths.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104309 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #1) > I don't think the wording of g95 is explaining what is wrong. > > Browsing F2018 I saw: > > C15103 In the specification-expr that specifies a type parameter value of > the result of an elemental function, an object designator with a dummy > argument of the function as the base object shall appear only as the > subject of a specification inquiry (10.1.11), ... > > And 10.1.11 has: > > A specification inquiry is a reference to > > (1) an intrinsic inquiry function other than PRESENT, > (2) a type parameter inquiry (9.4.5), > (3) ... > > TRIM and LEN_TRIM are not intrinsic inquiry functions. Harald, your're analysis is correct for F2008 and F2018. The g95 error message is correct for Fortran 95 and 2003. >From F95, page 213, the relevant constraint is Constraint: A dummy argument, or a subobject thereof, shall not appear in a specification-expr except as the argument to one of the intrinsic functions BIT_SIZE, KIND, LEN, or the numeric inquiry functions (13.11.8). Note, this constraint applies to the entire specification expression. F2018 C15103 is restricted to a "type parameter values" portion of a specification expression.
[Bug tree-optimization/104316] RSO is not used when doing assignment rather than initialization and address taken afterwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104316 Andrew Pinski changed: What|Removed |Added Depends on||23384 --- Comment #3 from Andrew Pinski --- Yes PR 23384. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384 [Bug 23384] escaped set should be flow sensitive
[Bug tree-optimization/104316] RSO is not used when doing assignment rather than initialization and address taken afterwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104316
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-01-31
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
NRV has:
static bool
dest_safe_for_nrv_p (gcall *call)
{
tree dest = gimple_call_lhs (call);
dest = get_base_address (dest);
if (! dest)
return false;
if (TREE_CODE (dest) == SSA_NAME)
return true;
if (call_may_clobber_ref_p (call, dest, false)
|| ref_maybe_used_by_stmt_p (call, dest, false))
return false;
return true;
}
Which is fine, the problem is the clobber list is not exactly flow senative, I
think there is another bug about that.
[Bug target/88798] AVX512BW code does not use bit-operations that work on mask registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88798 --- Comment #6 from Wojciech Mula --- Hongtao, thank you for your patch and for pinging back! I checked the code from this issue against version 11.2.0 (Debian 11.2.0-14), but still, there are KMOVQs before performing any bit ops. Here is the output from `gcc -O3 -march=icelake-server -S` vpcmpub $0, .LC0(%rip), %zmm0, %k0 vpcmpub $0, .LC1(%rip), %zmm0, %k1 vpcmpub $0, .LC2(%rip), %zmm0, %k2 kmovq %k0, %rcx kmovq %k1, %rax orq %rcx, %rax kmovq %k2, %rdx orq %rdx, %rax ret
[Bug tree-optimization/104316] RSO is not used when doing assignment rather than initialization and address taken afterwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104316 --- Comment #1 from Andrew Pinski --- return slot optimization
[Bug tree-optimization/104316] RSO is not used when doing assignment rather than initialization and address taken afterwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104316 Andrew Pinski changed: What|Removed |Added Summary|Missing optimization for|RSO is not used when doing |uninitialized local struct |assignment rather than |variable|initialization and address ||taken afterwards Keywords||missed-optimization Severity|normal |enhancement Component|c |tree-optimization
[Bug tree-optimization/104288] [11/12 Regression] EVRP null pointer check removal for strcmp (and maybe others) is not flow senative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104288
--- Comment #7 from Andrew Macleod ---
its a bit more tightly intertwined than that unfortunately. I had plans to
replace the current non-null processing with a range_after_stmt side-effect API
which would work in conjunction with dominator walks, but never got to it in
this release.
So ranger makes the assumption currently that if the non-null property is found
anywhere in the BB, it applies to the entire BB, unless
can_throw_non_call_exceptions is true, then it just bails.
The unfortunate side effect of this is we can no longer determine the
difference between this test case and (vrp111.c):
void foo (void *p) __attribute__((nonnull(1)));
void bar (void *p)
{
foo (p);
if (!p)
__builtin_abort ();
}
where the use determining non-null happens first, and then we can eliminate
branches safely. ie,so a problematic test case would be a combination:
void h(int result)
{
if (result)
__builtin_exit(0);
}
void foo (void *p) __attribute__((nonnull(1)));
void bar (void *p)
{
h(p == 0);// can't eliminate this
foo (p); // this makes p non=null
if (!p) // should be able to eliminate this
__builtin_abort ();
}
I'm contemplating the situation. The trick is to find something with minimal
change that is functionally acceptable. I think the goal for this release
would be to continue to get vrp111.c, and simply not get it in the problematic
case.. ie, if the first use in the block is unknown and then LATER in the
block we figure out that it is non-null, we will miss that case through-out
the block for now.
Effectively: if no dominator block contains non-null then whatever the first
use in a block determines will apply to the whole block, for the duration of
the block.. but upon exit to the block, if it was non-null anywhere, then all
following blocks get that knowledge.
I think this could be done reasonably efficiently with a minimum of risk/churn.
At least that is what I'M currently trying. would this be OK?
And for GCC 11 it is not much of an issue. Since it runs in hybrid mode, I can
simply switch ranger to be more pessimistic and deal with just dominators if
they are available, EVRP picks up the slack, and it still pass all the
testsuite cases.
[Bug c/104316] New: Missing optimization for uninitialized local struct variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104316
Bug ID: 104316
Summary: Missing optimization for uninitialized local struct
variable
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
~~~c
#include
typedef struct Buffer {
char *buf;
size_t len;
size_t cap;
} Buffer;
Buffer Buffer_Init_Return(void);
void Buffer_Init_Ref(Buffer *buf);
void Buffer_Add(Buffer *buf, const char *);
void
Use_Buffers(void)
{
Buffer buf1 = Buffer_Init_Return();
Buffer buf2;
buf2 = Buffer_Init_Return();
Buffer_Add(&buf1, "1");
Buffer_Add(&buf2, "2");
}
~~~
https://godbolt.org/z/qTz36qP9r
The code snippets for initializing buf1 and buf2 are almost the same. From an
as-if perspective, they are identical.
GCC 12 generates several copy instructions when initializing buf2, while Clang
and ICC generate the straight-forward code.
Would it be difficult to tell GCC to optimize the above initialization for
buf2, for the case that buf2 is not accessed between the declaration and the
assignment?
[Bug target/104315] [AArch64] Failure to optimize 8-bit bitreverse pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104315 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-01-31 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Severity|normal |enhancement See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=50481 --- Comment #2 from Andrew Pinski --- Part of it is because GCC does not have a builtin to do bit reversal (PR 50481). Confirmed otherwise.
[Bug target/104315] [AArch64] Failure to optimize 8-bit bitreverse pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104315
--- Comment #1 from Gabriel Ravier ---
PS: I've just stumbled upon the more generic case, which would be this code:
unsigned int stb_bitreverse(unsigned int n)
{
n = ((n & 0x) >> 1) | ((n & 0x) << 1);
n = ((n & 0x) >> 2) | ((n & 0x) << 2);
n = ((n & 0xF0F0F0F0) >> 4) | ((n & 0x0F0F0F0F) << 4);
n = ((n & 0xFF00FF00) >> 8) | ((n & 0x00FF00FF) << 8);
return (n >> 16) | (n << 16);
}
which GCC optimizes to this:
stb_bitreverse(unsigned int):
lsl w2, w0, 1
lsr w1, w0, 1
and w0, w1, 1431655765
and w1, w2, -1431655766
orr w0, w0, w1
lsr w1, w0, 2
lsl w0, w0, 2
and w0, w0, -858993460
and w1, w1, 858993459
orr w1, w1, w0
lsr w0, w1, 4
lsl w1, w1, 4
and w1, w1, -252645136
and w0, w0, 252645135
orr w0, w0, w1
rev w0, w0
ret
and LLVM to this:
stb_bitreverse(unsigned int):
rbit w0, w0
ret
[Bug target/104315] New: [AArch64] Failure to optimize 8-bit bitreverse pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104315
Bug ID: 104315
Summary: [AArch64] Failure to optimize 8-bit bitreverse pattern
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
unsigned int stb_bitreverse8(unsigned char n)
{
n = ((n & 0xAA) >> 1) + ((n & 0x55) << 1);
n = ((n & 0xCC) >> 2) + ((n & 0x33) << 2);
return (unsigned char) ((n >> 4) + (n << 4));
}
On AArch64, with -O3, GCC currently outputs this:
stb_bitreverse8(unsigned char):
mov w2, 170
mov w1, 85
and w1, w1, w0, lsr 1
and w0, w2, w0, lsl 1
orr w0, w1, w0
mov w1, -52
mov w2, 51
and w1, w1, w0, lsl 2
and w0, w2, w0, lsr 2
and w1, w1, 255
orr w0, w0, w1
lsr w1, w0, 4
orr w0, w1, w0, lsl 4
and w0, w0, 255
ret
LLVM instead outputs this:
stb_bitreverse8(unsigned char):
rbit w8, w0
lsr w0, w8, #24
ret
This optimization should be faster and quite useful, especially as there does
not seem to be any way to use `rbit` manually with intrinsics in GCC.
[Bug tree-optimization/104279] [12 Regregression] ICE on valid code at -O1 and above on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104279 Andrew Pinski changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 104310 has been marked as a duplicate of this bug. ***
[Bug c/104310] ice in forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104310 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Already fixed. *** This bug has been marked as a duplicate of bug 104279 ***
[Bug fortran/104309] Elemental character function should not return array of character variables of different lengths.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104309 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P4 Last reconfirmed||2022-01-31 Version|fortran-dev |12.0 --- Comment #1 from anlauf at gcc dot gnu.org --- I don't think the wording of g95 is explaining what is wrong. Browsing F2018 I saw: C15103 In the specification-expr that specifies a type parameter value of the result of an elemental function, an object designator with a dummy argument of the function as the base object shall appear only as the subject of a specification inquiry (10.1.11), ... And 10.1.11 has: A specification inquiry is a reference to (1) an intrinsic inquiry function other than PRESENT, (2) a type parameter inquiry (9.4.5), (3) ... TRIM and LEN_TRIM are not intrinsic inquiry functions.
[Bug fortran/104314] ICE in deferred_op_assign, at fortran/resolve.cc:11794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104314 --- Comment #2 from Steve Kargl --- On Mon, Jan 31, 2022 at 08:14:39PM +, kargl at gcc dot gnu.org wrote: > > --- Comment #1 from kargl at gcc dot gnu.org --- > Untested patch. > Seems to pass regression testing.
[Bug tree-optimization/95084] [11/12 Regression] code sinking prevents if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95084 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.3 Blocks||26163 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug c++/88378] notes for template deduction errors mention "[with U = U]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88378 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c++/88378] notes for template deduction errors mention "[with U = U]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88378 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100716 --- Comment #4 from Andrew Pinski --- The patch was explicitly fixing this case: "skip output of irrelevant & confusing "[with T = T]" in dump_substitution."
[Bug debug/55641] debug info for the type of a reference declared with a typedef has spurious 'const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=61755 CC||sijun.liu at oracle dot com --- Comment #14 from Andrew Pinski --- *** Bug 61755 has been marked as a duplicate of this bug. ***
[Bug c++/61755] Reference to function is parsed as const reference to function in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61755 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=55641 Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 55641 (g++.dg/debug/dwarf2/ref-1.C is close enough being the same testcase as that one I did even). *** This bug has been marked as a duplicate of bug 55641 ***
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-01-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P4 --- Comment #2 from anlauf at gcc dot gnu.org --- We could limit the size of the resulting array constructor, using e.g. flag_max_array_constructor.
[Bug tree-optimization/68694] SLP loads should be permuted until supported if possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68694 --- Comment #3 from Andrew Pinski --- (In reply to Martin Liška from comment #2) > Fixed with r10-1321-g332d6c4189218b06. So just made a latent I think really.
[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #4) > Created attachment 52311 [details] > Patch that regtests ok. While playing some more with variations of the testcase, I figured that this patch is not complete. It does not fix cases where a call tree consists of procedures with and without the bind(c) attribute. So more work is needed.
[Bug c++/84939] [9/10/11/12 Regression] internal compiler error: in gimplify_expr, at gimplify.c:12382
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84939 Andrew Pinski changed: What|Removed |Added Target Milestone|9.5 |11.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93314 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Andrew Pinski --- Fixed in GCC 11 by the patch which fixed PR 93314, the testcase added g++.dg/parse/uneval1.C is very similar to the original testcase here.
[Bug c++/102434] [11/12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514 since r11-4547-g6fb7e3c29188ab7c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102434 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Marek Polacek --- Fixed.
[Bug c++/102414] [12 Regression] ICE in unify_array_domain, at cp/pt.c:23442 since r12-1933-ge66d0b7b87d105d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102414 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug c++/16994] [meta-bug] VLA and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 Bug 16994 depends on bug 101874, which changed state. Bug 101874 Summary: [12 Regression] ICE with auto specifier for VLAs since r12-1933-ge66d0b7b87d105d2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101874 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/101874] [12 Regression] ICE with auto specifier for VLAs since r12-1933-ge66d0b7b87d105d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101874 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/102414] [12 Regression] ICE in unify_array_domain, at cp/pt.c:23442 since r12-1933-ge66d0b7b87d105d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102414 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:874ad5d6745bf3bbe4aa138cef09c669b3fb9b07 commit r12-6952-g874ad5d6745bf3bbe4aa138cef09c669b3fb9b07 Author: Marek Polacek Date: Thu Jan 27 18:11:03 2022 -0500 c++: ICE with auto[] and VLA [PR102414] Here we ICE in unify_array_domain when we're trying to deduce the type of an array, as in auto(*p)[i] = (int(*)[i])0; but unify_array_domain doesn't arbitrarily complex bounds. Another test is, e.g., auto (*b)[0/0] = &a; where the type of the array is <<< Unknown tree: template_type_parm >>>[0:(sizetype) ((ssizetype) (0 / 0) - 1)] It seems to me that we need not handle these. PR c++/102414 PR c++/101874 gcc/cp/ChangeLog: * decl.cc (create_array_type_for_decl): Use template_placeholder_p. Sorry on a variable-length array of auto. gcc/testsuite/ChangeLog: * g++.dg/cpp23/auto-array3.C: New test. * g++.dg/cpp23/auto-array4.C: New test.
[Bug c++/101874] [12 Regression] ICE with auto specifier for VLAs since r12-1933-ge66d0b7b87d105d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101874 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:874ad5d6745bf3bbe4aa138cef09c669b3fb9b07 commit r12-6952-g874ad5d6745bf3bbe4aa138cef09c669b3fb9b07 Author: Marek Polacek Date: Thu Jan 27 18:11:03 2022 -0500 c++: ICE with auto[] and VLA [PR102414] Here we ICE in unify_array_domain when we're trying to deduce the type of an array, as in auto(*p)[i] = (int(*)[i])0; but unify_array_domain doesn't arbitrarily complex bounds. Another test is, e.g., auto (*b)[0/0] = &a; where the type of the array is <<< Unknown tree: template_type_parm >>>[0:(sizetype) ((ssizetype) (0 / 0) - 1)] It seems to me that we need not handle these. PR c++/102414 PR c++/101874 gcc/cp/ChangeLog: * decl.cc (create_array_type_for_decl): Use template_placeholder_p. Sorry on a variable-length array of auto. gcc/testsuite/ChangeLog: * g++.dg/cpp23/auto-array3.C: New test. * g++.dg/cpp23/auto-array4.C: New test.
[Bug c++/102434] [11/12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514 since r11-4547-g6fb7e3c29188ab7c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102434 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:b1a8b92f8f78536a00012e2e53a0d12ddbe6836d commit r12-6951-gb1a8b92f8f78536a00012e2e53a0d12ddbe6836d Author: Marek Polacek Date: Fri Jan 28 20:01:06 2022 -0500 c++: Reject union std::initializer_list [PR102434] Weird things are going to happen if you define your std::initializer_list as a union. In this case, we crash in output_constructor_regular_field. Let's not allow such a definition in the first place. PR c++/102434 gcc/cp/ChangeLog: * class.cc (finish_struct): Don't allow union initializer_list. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist128.C: New test.
[Bug target/83220] modification of a global register variable while the function only reads from it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83220 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91957 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Fixed, the patch included a testcase which covers this case, g++.target/i386/pr97054.C so closing as fixed.
[Bug c++/104294] ICE: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst_pack_expansion, at cp/pt.cc:13130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104294 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 --- Comment #5 from Patrick Palka --- Fixed.
[Bug c++/104294] ICE: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst_pack_expansion, at cp/pt.cc:13130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104294
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:76dc465aaf1b74bf92143510b6db5671e1c053d6
commit r12-6950-g76dc465aaf1b74bf92143510b6db5671e1c053d6
Author: Patrick Palka
Date: Mon Jan 31 15:27:58 2022 -0500
c++: CTAD for class tmpl defined inside partial spec [PR104294]
Here during deduction guide generation for the nested class template
B::C, the computation of outer_args yields the template
arguments relative to the primary template for B (i.e. {char(int)})
but what we really want is those relative to C's enclosing scope, the
partial specialization of B (i.e. {char, int}).
PR c++/104294
gcc/cp/ChangeLog:
* pt.cc (ctor_deduction_guides_for): Correct computation of
outer_args.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/class-deduction106.C: New test.
[Bug fortran/104314] ICE in deferred_op_assign, at fortran/resolve.cc:11794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104314 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||kargl at gcc dot gnu.org Priority|P3 |P4 Ever confirmed|0 |1 Last reconfirmed||2022-01-31 --- Comment #1 from kargl at gcc dot gnu.org --- Untested patch. diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index 835a4783718..d18404da09d 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc @@ -11784,6 +11784,9 @@ deferred_op_assign (gfc_code **code, gfc_namespace *ns) if (gfc_expr_attr ((*code)->expr1).pointer) return false; + if ((*code)->expr1->ts.type != (*code)->expr2->ts.type) +return false; + tmp_expr = get_temp_from_expr ((*code)->expr1, ns); tmp_expr->where = (*code)->loc;
[Bug fortran/104314] New: ICE in deferred_op_assign, at fortran/resolve.cc:11794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104314 Bug ID: 104314 Summary: ICE in deferred_op_assign, at fortran/resolve.cc:11794 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p character(:), allocatable :: c(:) c = ['123'] c = c == c end $ gfortran-12-20220130 -c z1.f90 z1.f90:4:7: 4 |c = c == c | 1 Error: Cannot convert LOGICAL(4) to CHARACTER(0) at (1) f951: internal compiler error: Segmentation fault 0xe6e49f crash_signal ../../gcc/toplev.cc:322 0x7a979c deferred_op_assign ../../gcc/fortran/resolve.cc:11794 0x7a979c gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:12063 0x7a98e7 resolve_codes ../../gcc/fortran/resolve.cc:17537 0x7a99ae gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17572 0x791cd4 resolve_all_program_units ../../gcc/fortran/parse.cc:6586 0x791cd4 gfc_parse_file() ../../gcc/fortran/parse.cc:6842 0x7dff7f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug fortran/104313] New: [9/10/11/12 Regression] ICE verify_gimple failed with -ff2c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104313 Bug ID: 104313 Summary: [9/10/11/12 Regression] ICE verify_gimple failed with -ff2c Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r9, changed between 20190728 and 20190811 : $ cat z1.f90 function f(a) return end $ gfortran-12-20220130 -c z1.f90 -ff2c z1.f90:1:0: 1 | function f(a) | Error: non-trivial conversion in 'var_decl' real(kind=8) real(kind=4) D.4216 = __result_f; z1.f90:1:0: internal compiler error: 'verify_gimple' failed 0xeba38d verify_gimple_in_seq(gimple*) ../../gcc/tree-cfg.cc:5211 0xb40ea1 gimplify_body(tree_node*, bool) ../../gcc/gimplify.cc:16292 0xb41147 gimplify_function_tree(tree_node*) ../../gcc/gimplify.cc:16363 0x952b17 cgraph_node::analyze() ../../gcc/cgraphunit.cc:675 0x955dc6 analyze_functions ../../gcc/cgraphunit.cc:1240 0x956f9d symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.cc:2500
[Bug fortran/104312] New: ICE with -ff2c in fold_convert_loc, at fold-const.cc:2451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104312 Bug ID: 104312 Summary: ICE with -ff2c in fold_convert_loc, at fold-const.cc:2451 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 function f() real, pointer :: f, e entry e() end $ gfortran-12-20220130 -c z1.f90 $ $ gfortran-12-20220130 -c z1.f90 -ff2c z1.f90:1:0: 1 | function f() | internal compiler error: in fold_convert_loc, at fold-const.cc:2451 0x9b68e7 fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc/fold-const.cc:2450 0xa3130d gimplify_modify_expr ../../gcc/gimplify.cc:5918 0xa2901a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.cc:14963 0xa2bb48 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.cc:7035 0xa29306 gimplify_and_add(tree_node*, gimple**) ../../gcc/gimplify.cc:495 0xa29306 gimplify_return_expr ../../gcc/gimplify.cc:1677 0xa29306 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.cc:15225 0xa2bb48 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.cc:7035 0xa2c0a1 gimplify_bind_expr ../../gcc/gimplify.cc:1427 0xa2948a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.cc:15164 0xa2bb48 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.cc:7035 0xa2cbcb gimplify_body(tree_node*, bool) ../../gcc/gimplify.cc:16209 0xa2d01f gimplify_function_tree(tree_node*) ../../gcc/gimplify.cc:16363 0x8b3147 cgraph_node::analyze() ../../gcc/cgraphunit.cc:675 0x8b5af7 analyze_functions ../../gcc/cgraphunit.cc:1240 0x8b64bd symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.cc:2500
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 G. Steinmetz changed: What|Removed |Added Target||x86_64-pc-linux-gnu Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- And for completeness : $ cat z2.f90 program p type t end type type(t) :: x(2) print *, transfer(1, x, huge(1)) end
[Bug fortran/104311] New: [9/10/11/12 Regression] ICE out of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 Bug ID: 104311 Summary: [9/10/11/12 Regression] ICE out of memory Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to r8, changed between 20190208 and 20190308 : (follow-up of pr104227) $ cat z1.f90 program p type t end type type(t) :: x(2) x = transfer(1, x, huge(1)) end $ gfortran-7 -c z1.f90 z1.f90:5:3: x = transfer(1, x, huge(1)) 1 Error: Different shape for array assignment at (1) on dimension 1 (2 and 2147483647) $ gfortran-12-20220130 -c z1.f90 GNU MP: Cannot allocate memory (size=8) f951: out of memory allocating 139 bytes after a total of 1499426816 bytes
[Bug c++/104230] Non-type template arguments of reference and pointer type fail when initialized by pointer to member operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104230 --- Comment #2 from anton at socialhacker dot com --- Hmm, sorry, still learning the bugzilla UI. I thought that patch would be attached to my next comment. I don't believe that patch is a solution to the problem. It was just a way I was able to make progress debugging the issue. I followed that patch with one that allowed GCC to mangle the resulting POINTER_PLUS_EXPR. But the end result was that the two template instantiations were not considered the same (as far as __is_same was concerned). I'm pretty sure that the problem is upstream instead of downstream from the location where the diagnostic is generated (in invalid_tparm_referent_p). And I've been working my way backwards into the parser, but it's much slower going for me. I've found where the two different parse trees are generated for the two different version of the template parameters. But they happen in such different portions of the parser I'm not sure at all how to have them generate the same tree eventually, which is I'm guessing the right answer to the problem. That is, instead of generating a COMPONENT_REF for the accepted form, and a POINTER_PLUS_EXPR for the rejected form, GCC should probably be generating COMPONENT_REF for both. But I think it's forgotten the required information to do that conversion from POINTER_PLUS_EXPR by the time it's needed. I'm guessing someone who knows the parser side well might have a better chance at seeing how that should be done.
[Bug c++/104230] Non-type template arguments of reference and pointer type fail when initialized by pointer to member operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104230 --- Comment #1 from anton at socialhacker dot com --- Created attachment 52321 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52321&action=edit Patch to get member references via pointers accepted as template arguments
[Bug c++/104291] [12 Regression] gcc accepts template argument involves template parameter(s)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104291 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Patrick Palka --- Fixed.
[Bug c++/104291] [12 Regression] gcc accepts template argument involves template parameter(s)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104291 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0eb06ee9a40a09d2f492461289d69aa39f757e66 commit r12-6949-g0eb06ee9a40a09d2f492461289d69aa39f757e66 Author: Patrick Palka Date: Mon Jan 31 14:15:01 2022 -0500 c++: CONSTRUCTORs are non-deduced contexts [PR104291] PR c++/104291 gcc/cp/ChangeLog: * pt.cc (for_each_template_parm_r) : Clear walk_subtrees if !include_nondeduced_p. Simplify given that cp_walk_subtrees already walks TYPE_PTRMEMFUNC_FN_TYPE_RAW. gcc/testsuite/ChangeLog: * g++.dg/template/partial20.C: New test.
[Bug target/104298] [12 Regression] Broken cross compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104298 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2cbe5dd54f15e88e0b42567319aa9c8e7bad7946 commit r12-6948-g2cbe5dd54f15e88e0b42567319aa9c8e7bad7946 Author: Jakub Jelinek Date: Mon Jan 31 20:08:18 2022 +0100 rs6000: Fix up build of non-glibc/aix/darwin powerpc* targets [PR104298] As reported by Martin, while David has added OPTION_GLIBC define to aix and Iain to darwin, all the other non-linux targets now fail because rs6000.md macro isn't defined. One possibility is to define this macro in option-defaults.h which on rs6000 targets is included last, then we don't need to define it in aix/darwin headers and for targets using linux.h or linux64.h it will DTRT too. The other option is the first 2 hunks + changing the 3 if (!OPTION_GLIBC) FAIL; cases in rs6000.md to e.g. #ifdef OPTION_GLIBC if (!OPTION_GLIBC) #endif FAIL; or to: #ifdef OPTION_GLIBC if (!OPTION_GLIBC) #else if (true) #endif FAIL; (the latter case if Richi wants to push the -Wunreachable-code changes for GCC 13). 2022-01-31 Jakub Jelinek PR target/104298 * config/rs6000/aix.h (OPTION_GLIBC): Remove. * config/rs6000/darwin.h (OPTION_GLIBC): Likewise. * config/rs6000/option-defaults.h (OPTION_GLIBC): Define to 0 if not already defined.
[Bug middle-end/104075] bogus/missing -Wuse-after-free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075 Bug 104075 depends on bug 104232, which changed state. Bug 104232 Summary: [12 Regression] spurious -Wuse-after-free after conditional free https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104232 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/104232] [12 Regression] spurious -Wuse-after-free after conditional free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104232 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Martin Sebor --- Fixed in r12-6947.
[Bug middle-end/104232] [12 Regression] spurious -Wuse-after-free after conditional free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104232 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:48d3191e7bd6245bd2df625731f1ad9207a26655 commit r12-6947-g48d3191e7bd6245bd2df625731f1ad9207a26655 Author: Martin Sebor Date: Mon Jan 31 12:04:55 2022 -0700 Constrain PHI handling in -Wuse-after-free [PR104232]. Resolves: PR middle-end/104232 - spurious -Wuse-after-free after conditional free gcc/ChangeLog: PR middle-end/104232 * gimple-ssa-warn-access.cc (pointers_related_p): Add argument. Handle PHIs. Add a synonymous overload. (pass_waccess::check_pointer_uses): Call pointers_related_p. gcc/testsuite/ChangeLog: PR middle-end/104232 * g++.dg/warn/Wuse-after-free4.C: New test. * gcc.dg/Wuse-after-free-2.c: New test. * gcc.dg/Wuse-after-free-3.c: New test.
[Bug target/102952] New code-gen options for retpolines and straight line speculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952 --- Comment #39 from H.J. Lu --- The GCC 11 backport is posted at https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589527.html
[Bug target/104253] libgcc missing __floatdiif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253 --- Comment #11 from Michael Meissner --- The patch has been posted, I'm awaiting approval. https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589469.html BTW, the copy_to_mode_reg bug I mentioned earlier goes away with the patch.
[Bug rtl-optimization/104153] [12 Regression] ICE due to recent ifcvt changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153 --- Comment #7 from Jeffrey A. Law --- Sorry, I wasn't able to debug those additional failures until the weekend. They ultimately turned out to be a bug in some recent newlib refactoring. I got clean or1k builds once I applied your patch and fixed up newlib. Are you going to submit the patch officially?
[Bug rtl-optimization/104153] [12 Regression] ICE due to recent ifcvt changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153 --- Comment #6 from rdapp at linux dot ibm.com --- One thing wrong with the previous snippet is that cc_cmp and rev_cc_cmp can be NULL. This can also be the reason for your failures as seen on SPARC.
[Bug c/104310] ice in forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104310 --- Comment #3 from Jakub Jelinek --- r12-6931-ga1544878966020d1f7a640b35d1f7a5f0e055624 should fix that.
[Bug c/104310] ice in forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104310
--- Comment #2 from David Binderman ---
The code I gave crashes in fre. This code crashes in forwprop:
int i_5;
void func_3() {
int *ptr_11;
unsigned int ui_15;
ptr_11 = &ui_15;
(ui_15 = 0 >= 0) / i_5 << 1;
}
My apologies for getting the reduction wrong.
[Bug c/104310] ice in forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104310 --- Comment #1 from Andrew Pinski --- I think this was already fixed.
[Bug c/104310] New: ice in forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104310
Bug ID: 104310
Summary: ice in forwprop
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:
$ more bug792.c
int i_5;
unsigned int func_3_ui_15;
void func_3()
{
(func_3_ui_15 = 0 >= 0) / i_5 << 1;
}
compiled by recent gcc trunk, does this:
$ /home/dcb/gcc/results.20220129//bin/gcc -c -O1 bug792.c
bug792.c: In function ‘func_3’:
bug792.c:6:1: error: bogus comparison result type
6 | }
| ^
unsigned int
_4 = i_5.1_2 == 1;
during GIMPLE pass: fre
bug792.c:6:1: internal compiler error: verify_gimple failed
0xde241a verify_gimple_in_cfg(function*, bool)
../../trunk.git/gcc/tree-cfg.cc:5559
The bug first seems to occur sometime between git hash b51fb28ed294cdf1
and f6f2d6cfec1c2fe9, a range of 28 commits.
[Bug middle-end/104307] [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104307 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 52320 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52320&action=edit gcc12-pr104307.patch Untested fix. Just the first part of the hunk is needed for this bug, I'm actually not 100% sure about the rhs2/rhs3 case, but it feels it isn't right (it would e.g. try to expand_vector_condition the same stmt multiple times). I must say I don't understand the pushing of all uses into a vector, wouldn't it make more sense to push there just the VEC_COND_EXPRs with such lhs? Then we e.g. wouldn't need to do any expand_vector_condition calls if we have 1000 VEC_COND_EXPR uses and then a different use.
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
--- Comment #4 from David Malcolm ---
Yes; using -fdump-ipa-analyzer=stderr shows that the memmove becomes:
_1 = &s + 1;
_3 = MEM [(char * {ref-all})_1];
MEM [(char * {ref-all})&s] = _3;
where the first and third stmts in the gimple-ssa IR above have this location:
foo.c:2:25: note:
2 | int main() { char s[5]; memmove(s, s + 1, 2); }
| ^~~~
but the middle stmt ("_3 = ...") has unknown location.
[Bug c++/104291] [12 Regression] gcc accepts template argument involves template parameter(s)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104291 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug middle-end/104307] [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104307 --- Comment #2 from Jakub Jelinek --- Started with r11-2577-g229752afe3156a3990dacaedb94c76846cebf132 but I think the real bug is caused by r11-2362-g55c9695cbe91c406805ac0cd342949f32f13b779
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308 Kamil Dudka changed: What|Removed |Added CC||kdudka at redhat dot com --- Comment #3 from Kamil Dudka --- Thank you for having a look! I was curious where (short unsigned int *) came from but it seems to be a result of inlined memmove(). The report goes away when the code is compiled with -fno-builtin-memmove.
[Bug target/104307] [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104307 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-31 Priority|P3 |P2 Target Milestone|--- |11.3 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/86345] Likely false warning with -Wstringop-overflow and memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86345 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- The original test-case is fixed with r9-2639-gbb79aba479cf2288.
[Bug c++/86703] template auto fails deduction, where template int succeeds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86703 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed with r9-4044-g7d119905abdf28f5.
[Bug c++/103341] [11 Regression] ICE type of variable instantiation constrained on template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103341 --- Comment #7 from Patrick Palka --- (In reply to Arseny Solokha from comment #6) > g++ 12.0.1 20220130 snapshot (g:baf98320ac6cd56da0c0b460fb94e3b87a79220d) > still ICEs on the testcase in comment 3. Looks like that one requires a different fix, so I just reopened PR103706.
[Bug c++/103706] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2503
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103706 Patrick Palka changed: What|Removed |Added Target Milestone|--- |11.3
[Bug c++/103706] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2503
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103706 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Known to work||10.3.0 Resolution|DUPLICATE |--- Status|RESOLVED|NEW Known to fail||11.2.0, 12.0 --- Comment #5 from Patrick Palka --- Reopening since this PR is concerning constrained lambdas and PR103341 is about constrained variable templates, and we still ICE on the testcase here even after r12-6919. Started with r11-7454.
[Bug middle-end/101913] -Wstrict-overflow -O3 false alarm on tzdb localtime.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101913 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||aldyh at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- Fixed with r12-3903-g0288527f47cec669.
[Bug c++/84939] [9/10/11/12 Regression] internal compiler error: in gimplify_expr, at gimplify.c:12382
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84939 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Keywords|needs-bisection | --- Comment #10 from Martin Liška --- Fixed with r11-8181-g9b53edc796d284b6.
[Bug target/83220] modification of a global register variable while the function only reads from it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83220 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Keywords|needs-bisection | --- Comment #3 from Martin Liška --- Fixed with r11-3285-g3c7c5f1d4a4b8328.
[Bug c++/86143] ICE capturing constexpr chrono duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86143 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Martin Liška --- Fixed with r9-960-g57ea03ad4a0dde98.
[Bug c++/88378] notes for template deduction errors mention "[with U = U]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88378 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||marxin at gcc dot gnu.org, ||mkretz at gcc dot gnu.org --- Comment #3 from Martin Liška --- Fixed with r12-1100-gc33ec196aa713c62.
[Bug c++/61755] Reference to function is parsed as const reference to function in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61755 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Keywords|needs-bisection | --- Comment #3 from Martin Liška --- Fixed with r7-2599-g71e1a6a4c799e27b.
[Bug libitm/61594] ICE (assertion failure) in trans-mem.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||marxin at gcc dot gnu.org --- Comment #9 from Martin Liška --- Changed with r8-835-gb7cb2251a32e7af5.
[Bug tree-optimization/68694] SLP loads should be permuted until supported if possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68694 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Martin Liška --- Fixed with r10-1321-g332d6c4189218b06.
[Bug c/59485] may_alias attribute ignored in internal references while defining aggregate types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59485 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Fixed with r7-1272-g5545a9071573a58e.
[Bug c++/82980] [9/10/11/12 Regression] template keyword should not be required for captured decl of the "base" type since r6-6866-gff2faafcf689b6c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82980 Martin Liška changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11/12 Regression] |template keyword should not |template keyword should not |be required for captured|be required for captured |decl of the "base" type |decl of the "base" type ||since ||r6-6866-gff2faafcf689b6c2 Keywords|needs-bisection | CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Started with r6-6866-gff2faafcf689b6c2.
[Bug c++/101717] [9/10/11/12 Regression] ICE capturing static member within stateless generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101717 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Keywords|needs-bisection | --- Comment #6 from Martin Liška --- Started with r9-279-g86cf10840b6cfbfe.
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308 --- Comment #2 from David Malcolm --- Sorry, link should have been: https://godbolt.org/z/ecWYnE73T
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2022-01-31
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from David Malcolm ---
Thanks for filing this bug; confirmed.
-Wanalyzer-use-of-uninitialized-value is new as of gcc 12.
Current trunk gives me:
https://godbolt.org/z/4bfE1TW61
In function ‘main’:
cc1: warning: use of uninitialized value ‘*(short unsigned int *)&s + 1’
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
‘main’: event 1
|
|foo.c:2:19:
|2 | int main() { char s[5]; memmove(s, s + 1, 2); }
| | ^
| | |
| | (1) region created on stack here
|
‘main’: event 2
|
|cc1:
| (2): use of uninitialized value ‘*(short unsigned int *)&s + 1’ here
|
where event (1) has a location, but (2) doesn't.
[Bug c/97986] [9/10/11/12 Regression] ICE in force_constant_size when applying va_arg to VLA type since r6-91-gf8e89441bc5518f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97986 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||vries at gcc dot gnu.org Summary|[9/10/11/12 Regression] ICE |[9/10/11/12 Regression] ICE |in force_constant_size when |in force_constant_size when |applying va_arg to VLA type |applying va_arg to VLA type ||since ||r6-91-gf8e89441bc5518f4 Keywords|needs-bisection | --- Comment #3 from Martin Liška --- Started with r6-91-gf8e89441bc5518f4.
[Bug middle-end/104232] [12 Regression] spurious -Wuse-after-free after conditional free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104232 --- Comment #4 from Martin Sebor --- The full link to the patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589366.html
[Bug middle-end/104075] bogus/missing -Wuse-after-free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075 Bug 104075 depends on bug 104269, which changed state. Bug 104269 Summary: [12 Regression] Bogus -Wuse-after-free seen in xen https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104269 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/104232] [12 Regression] spurious -Wuse-after-free after conditional free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104232 --- Comment #3 from Martin Sebor --- *** Bug 104269 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/104269] [12 Regression] Bogus -Wuse-after-free seen in xen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104269 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Martin Sebor --- The problem is the same as pr104232. *** This bug has been marked as a duplicate of bug 104232 ***
[Bug target/102952] New code-gen options for retpolines and straight line speculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952 --- Comment #38 from H.J. Lu --- (In reply to H.J. Lu from comment #37) > (In reply to Richard Biener from comment #36) > > HJ, does it make sense to backport these to branches since AFAIU they also > > address possible security issues? > > Yes, Linux kernel needs it. I will work on it. I am testing GCC 11 backport on users/hjl/pr102952/gcc-11 branch: https://gitlab.com/x86-gcc/gcc/-/commits/users/hjl/pr102952/gcc-11
[Bug middle-end/104232] [12 Regression] spurious -Wuse-after-free after conditional free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104232 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/
