[Bug fortran/105152] [9/10/11/12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.cc:5647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105152 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.5
[Bug sanitizer/105155] -fsanitize=signed-integer-overflow failed to check an overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105155
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-04-05
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
We fold this already before gimplification to
;; Function foo (null)
;; enabled by -tree-original
{
return a > 0 ? -2147483648(OVF) : 2147483646;
}
[Bug c/105156] No diagnostic for `enum { toobig = UINT_MAX }`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105156 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-05 Ever confirmed|0 |1
[Bug c/105151] [12 Regression] ICE in gimple_range_global with invalid "gimple" language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105151
--- Comment #2 from Aldy Hernandez ---
(In reply to Richard Biener from comment #1)
> going down passes after errors is always tricky - we do stop but it seems
> the diagnostic passes are still run because they are part of "lowering"
> (why is pass_walloca not in pass_build_ssa_passes like
> pass_warn_{printf,nonnull_compare,access}?). In particular it seems to look
> at ranger but we are not even in SSA form!?
Yeah, that looks like an oversight.
>
> ranger "support" was added with r12-1078-gfe9a499cb8775c which should have
> moved the pass to a place where we are in SSA form or the ranger use
> restricted to the late pass.
>
> I'm testing moving of the pass.
Thanks.
[Bug c/105149] [9/10/11/12 Regression] ICE in verify_ssa, at tree-ssa.cc:1211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105149
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |c
CC||jsm28 at gcc dot gnu.org
Keywords||accepts-invalid,
||ice-on-invalid-code
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Status|ASSIGNED|NEW
--- Comment #3 from Richard Biener ---
The odd thing is that we parse
d = va_arg (ap, typeof(d)()) ();
as function call, gimplifying it as
_1 = .VA_ARG (&ap(address-taken), 0B, 0B);
D.1987(address-taken) = _1;
D.1987(address-taken) ();
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x766793f0 context
chain >
side-effects
arg:0
used read BLK t.c:4:13 size unit-size
align:8 warn_if_not_align:0 context
chain
addressable used read BLK t.c:5:11
size
unit-size
align:64 warn_if_not_align:0 context >>
arg:1
side-effects
fn
side-effects
arg:0
side-effects
arg:0
arg:0 >
t.c:6:7 start: t.c:6:7 finish: t.c:6:7>
t.c:6:7 start: t.c:6:7 finish: t.c:6:7>
t.c:6:7 start: t.c:6:7 finish: t.c:6:33>
t.c:6:5 start: t.c:6:3 finish: t.c:6:33>
I _think_ we fail to decay the function type in va_arg to a pointer type
or we fail to reject this testcase.
Somewhat reduced testcase:
#include
typedef struct {} D;
void foo (int size, ...)
{
va_list ap;
va_arg (ap, D()) ();
}
C17/7.16.1.1 isn't sufficiently clear as to whether this is valid, but
at least "The parameter type shall be a type name specified such that
the type of a pointer to an object that has the specified type can be
obtained simply by postfixing a * to type" isn't fulfilled here since
the corresponding pointer type would be D(*)(), not D()*.
clang rejects this with
t.c:6:15: error: second argument to 'va_arg' is of non-POD type 'D ()'
[-Wnon-pod-varargs]
va_arg (ap, D()) ();
^~~
but not sure if "POD" is a thing to use in C language diagnostics.
Anyway, defering to C frontend maintainers.
[Bug c/105149] [9/10/11/12 Regression] ICE in verify_ssa, at tree-ssa.cc:1211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105149 --- Comment #4 from Richard Biener --- It looks like c_build_va_arg could be amended to reject FUNCTION_TYPE type. But as said, not sure if this is valid or not.
[Bug c/105149] [9/10/11/12 Regression] ICE in verify_ssa, at tree-ssa.cc:1211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105149 --- Comment #5 from Richard Biener --- The C++ frontend accepts this and diagnoses In file included from t.c:1: t.c: In function 'void foo(int, ...)': t.c:6:15: warning: 'D()' is promoted to 'D (*)()' when passed through '...' 6 | va_arg (ap, D()) (); and produces the following GENERIC, decaying the "loaded function": unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76681348 fields public abstract external autoinline decl_3 QI t.c:2:19 align:16 warn_if_not_align:0 context full-name "D::~D() noexcept ()" not-really-extern chain > context full-name "struct D" X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown pointer_to_this chain > side-effects fn unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76681690> side-effects arg:0 side-effects arg:0 arg:0 > t.c:6:3 start: t.c:6:3 finish: t.c:6:3> t.c:6:3 start: t.c:6:3 finish: t.c:6:3> t.c:6:3 start: t.c:6:3 finish: t.c:6:3> which we then gimplify to __builtin_trap (); <<< Unknown tree: integer_cst >>> ();
[Bug c/105149] [9/10/11/12 Regression] ICE in verify_ssa, at tree-ssa.cc:1211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105149 --- Comment #6 from Richard Biener --- (In reply to Richard Biener from comment #5) > The C++ frontend accepts this and diagnoses > > In file included from t.c:1: > t.c: In function 'void foo(int, ...)': > t.c:6:15: warning: 'D()' is promoted to 'D (*)()' when passed through '...' > 6 | va_arg (ap, D()) (); > > and produces the following GENERIC, decaying the "loaded function": include/stdarg.h:49:44: note: in definition of macro 'va_arg' 49 | #define va_arg(v,l) __builtin_va_arg(v,l) |^ t.c:6:15: note: (so you should pass 'D (*)()' not 'D()' to 'va_arg') 6 | va_arg (ap, D()) (); include/stdarg.h:49:44: note: in definition of macro 'va_arg' 49 | #define va_arg(v,l) __builtin_va_arg(v,l) |^ t.c:6:15: note: if this code is reached, the program will abort 6 | va_arg (ap, D()) (); include/stdarg.h:49:44: note: in definition of macro 'va_arg' 49 | #define va_arg(v,l) __builtin_va_arg(v,l) |^ because the C++ implementation of lang_hooks.types.type_promotes_to says the function type doesn't promote to itself. The C frontend seems to lack that. > > > type size > unit-size > align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type > 0x76681348 > fields 0x76698000> > public abstract external autoinline decl_3 QI t.c:2:19 align:16 > warn_if_not_align:0 context > full-name "D::~D() noexcept ()" > not-really-extern chain >> context > full-name "struct D" > X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown > pointer_to_this chain 0x76547980 ._anon_0>> > side-effects > fn type > unsigned DI > size > unit-size > align:64 warn_if_not_align:0 symtab:0 alias-set -1 > canonical-type 0x76681690> > side-effects > arg:0 > side-effects > arg:0 0x76544dc8> > arg:0 > > t.c:6:3 start: t.c:6:3 finish: t.c:6:3> > t.c:6:3 start: t.c:6:3 finish: t.c:6:3> > t.c:6:3 start: t.c:6:3 finish: t.c:6:3> > > which we then gimplify to > > __builtin_trap (); > <<< Unknown tree: integer_cst >>> ();
[Bug c/105151] [12 Regression] ICE in gimple_range_global with invalid "gimple" language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105151 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e68f5c90bae44e886bd1b13a135dbfd00bceea0a commit r12-7994-ge68f5c90bae44e886bd1b13a135dbfd00bceea0a Author: Richard Biener Date: Tue Apr 5 09:51:32 2022 +0200 c/105151 - move early walloca pass When the walloca pass gained support for ranger the early pass was not moved to a place where SSA form is available but remained in the lowering pipeline. For the testcase in this bug this is a problem because for errorneous input we still run the lowering pipeline but here have broken SSA form which ranger does not like. The solution is to rectify the mistake with using ranger without SSA form and move the pass which solves both issues. 2022-04-05 Richard Biener PR c/105151 * passes.def (pass_walloca): Move early instance into pass_build_ssa_passes to make SSA form available. * gcc.dg/gimplefe-error-14.c: New testcase.
[Bug c/105151] [12 Regression] ICE in gimple_range_global with invalid "gimple" language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105151 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug c/101057] [gimplefe] GIMPLE frontend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101057 Bug 101057 depends on bug 105151, which changed state. Bug 105151 Summary: [12 Regression] ICE in gimple_range_global with invalid "gimple" language https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105151 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/105156] No diagnostic for `enum { toobig = UINT_MAX }`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105156 --- Comment #5 from Jonathan Wakely --- There are loads of similar bugs related to macros in system headers such as NULL and UINT_MAX.
[Bug ada/67837] Ada ATC with delay abort syscalls not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67837 Nicolas Boulenguez changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Nicolas Boulenguez --- The original author agrees to close this issue.
[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's bits value propagation since r10-5538-gc7ac9a0c7e3916f1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:8c3e60933fa56dba47e75c88757395a73d38b04d commit r10-10523-g8c3e60933fa56dba47e75c88757395a73d38b04d Author: Martin Jambor Date: Tue Apr 5 11:19:49 2022 +0200 ipa: Careful processing ANCESTOR jump functions and NULL pointers (PR 103083) IPA_JF_ANCESTOR jump functions are constructed also when the formal parameter of the caller is first checked whether it is NULL and left as it is if it is NULL, to accommodate C++ casts to an ancestor class. The jump function type was invented for devirtualization and IPA-CP propagation of tree constants is also careful to apply it only to existing DECLs(*) but as PR 103083 shows, the part propagating "known bits" was not careful about this, which can lead to miscompilations. This patch introduces a flag to the ancestor jump functions which tells whether a NULL-check was elided when creating it and makes the bits propagation behave accordingly, masking any bits otherwise would be known to be one. This should safely preserve alignment info, which is the primary ifnormation that we keep in bits for pointers. (*) There still may remain problems when a DECL resides on address zero (with -fno-delete-null-pointer-checks ...I hope it cannot happen otherwise). I am looking into that now but I think it will be easier for everyone if I do so in a follow-up patch. gcc/ChangeLog: 2022-02-11 Martin Jambor PR ipa/103083 * ipa-prop.h (ipa_ancestor_jf_data): New flag keep_null; (ipa_get_jf_ancestor_keep_null): New function. * ipa-prop.c (ipa_set_ancestor_jf): Initialize keep_null field of the ancestor function. (compute_complex_assign_jump_func): Pass false to keep_null parameter of ipa_set_ancestor_jf. (compute_complex_ancestor_jump_func): Pass true to keep_null parameter of ipa_set_ancestor_jf. (update_jump_functions_after_inlining): Carry over keep_null from the original ancestor jump-function or merge them. (ipa_write_jump_function): Stream keep_null flag. (ipa_read_jump_function): Likewise. (ipa_print_node_jump_functions_for_edge): Print the new flag. * ipa-cp.c (class ipcp_bits_lattice): Make various getters const. New member function known_nonzero_p. (ipcp_bits_lattice::known_nonzero_p): New. (ipcp_bits_lattice::meet_with_1): New parameter drop_all_ones, observe it. (ipcp_bits_lattice::meet_with): Likewise. (propagate_bits_across_jump_function): Simplify. Pass true in drop_all_ones when it is necessary. (propagate_aggs_across_jump_function): Take care of keep_null flag. (ipa_get_jf_ancestor_result): Propagate NULL accross keep_null jump functions. gcc/testsuite/ChangeLog: 2021-11-25 Martin Jambor * gcc.dg/ipa/pr103083-1.c: New test. * gcc.dg/ipa/pr103083-2.c: Likewise. (cherry picked from commit 7ea3a73c195a79e6740ae594ee1a14c8bf7a938d)
[Bug tree-optimization/105150] [9/10/11/12 Regression] ICE with -Ofast: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105150 --- Comment #4 from Richard Biener --- So it's GENERIC folding and get_call_combined_fn as opposed to the GIMPLE variant does not verify argument compatibility. We have unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7653b348 precision:64 pointer_to_this > readonly fn unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76650dc8> readonly constant arg:0 readonly addressable used nothrow public external built-in decl_3 decl_5 decl_6 QI defer-output t.c:5:1 align:8 warn_if_not_align:0 built-in: BUILT_IN_NORMAL:BUILT_IN_SQRT attributes chain chain t.c:5:1 start: t.c:5:1 finish: t.c:5:1> arg:0 constant 1> where the CALL_EXPR_FN is an ADDR_EXPR of pointer-to unprototyped and the decl is unprototyped as well but it got BUILT_IN_NORMAL:BUILT_IN_SQRT and the inherited attributes. IMHO that's a frontend problem - it should not do that. There's nothing get_call_combined_fn can do here if we do not want to resort to check against the actual built-in decl that is registered via builtin_decl_explicit ().
[Bug c/105156] No diagnostic for `enum { toobig = UINT_MAX }`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105156 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- It is a hard problem how to figure out whether the reason for the warning when mixing code from a system header macro and non-system header tokens are caused purely by the system header macro content, or purely by non-system header tokens, or the mix of them. Currently the diagnostic code has just a single location on which it warns and without -Wsystem-headers is suppressed if that single location comes from system headers. So, except for hacks here and there for just a few warnings, we'd probably need to pass to the diagnostics code multiple locations relevant to the warning and warn if any of them is not from a system header or something similar. But we have over 2000 warning/warning_at calls and figuring out the right set of locations would be quite a lot of work.
[Bug c/105150] [9/10/11/12 Regression] ICE with -Ofast: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105150 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |c --- Comment #5 from Andrew Pinski --- > IMHO that's a frontend problem - it should not do that. Yes I think when we go and merge the builtin and the user supplied (un-prototyped) decl, we should handle it similar to argument missmatch wtih respect to not copying the builtins info.
[Bug sanitizer/105155] -fsanitize=signed-integer-overflow failed to check an overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105155
--- Comment #2 from Li Shaohua ---
(In reply to Richard Biener from comment #1)
> We fold this already before gimplification to
>
> ;; Function foo (null)
> ;; enabled by -tree-original
>
>
> {
> return a > 0 ? -2147483648(OVF) : 2147483646;
> }
Does this mean that it is not a bug?
[Bug target/105157] New: [12 Regression] compile-time regressions with generic tuning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157 Bug ID: 105157 Summary: [12 Regression] compile-time regressions with generic tuning Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- 507.cactuBSSN_r sees a 100% (-O2 -flto) or 70% (-Ofast) compile-time regression on aarch64 recently. https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=581.437.8 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=585.437.8
[Bug target/105157] [12 Regression] compile-time regressions with generic tuning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157 Richard Biener changed: What|Removed |Added Target||aarch64 CC||marxin at gcc dot gnu.org Keywords||compile-time-hog Target Milestone|--- |12.0 --- Comment #1 from Richard Biener --- last known good r12-7716-g0c016888ffd569, first known bad r12-7789-g2cd0c9a5310420 I don't know how exactly the compiler is configured (CCed Martin) and thus to what "generic tuning" would map to.
[Bug debug/105158] New: ftree-ccp drops DWARF const value attribute at -Og/-O1/-O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105158
Bug ID: 105158
Summary: ftree-ccp drops DWARF const value attribute at
-Og/-O1/-O2/-O3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dc.delia at protonmail dot com
Target Milestone: ---
In this code, variable l_171 is displayed optimized out at every stepped line
when debugging, including line 10 where it is used as a call argument to an
externally defined function. We tested with -Og/O1/O2/O3 and the issue is
present at all these levels.
Apparently, -ftree-ccp drops the const value attribute in the DWARF DIE for
l_171 while the final compiled code stays the same. By turning it off, the
debugger can display the value of the variable.
We found this issue on gcc commit 500d3f0a302 using gdb 11.2 and the behavior
seems consistent with prior gcc versions (e.g., 6.4, 7.5, 8.4, 9.3, 10.3,
11.1).
$ cat a.c
int a;
void b()
{
int l_169, l_174 = 0, l_188 = 0, l_191 = 0, l_240 = 1;
short l_171 ;
l_171 = (l_169 = 0) && a;
for (; l_169 <= 9; l_169 = l_169 + 3)
{
int l_187 = 0, l_189 = 0, l_190 = 8;
test(l_169, l_171, l_174, l_188, l_191, l_240, l_187, l_189, l_190);
}
}
int main ()
{
b();
}
$ cat lib.c
#include
void test(int l_169, int l_171, int l_174, int l_188, int l_191, int l_240, int
l_187, int l_189, int l_190) {
printf("%d %d %d %d %d %d %d %d %d", l_169, l_171, l_174, l_188, l_191,
l_240, l_187, l_189, l_190);
}
GDB trace:
$ gcc -O1 -g a.c lib.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 10
Breakpoint 1 at 0x4004fc: file a.c, line 10.
(gdb) r
Starting program: /tmp/opt
Breakpoint 1, b () at a.c:10
10 test(l_169, l_171, l_174, l_188, l_191, l_240, l_187, l_189,
l_190);
(gdb) info locals
l_187 = 0
l_189 = 0
l_190 = 8
l_169 = 0
l_174 = 0
l_188 = 0
l_191 = 0
l_240 = 1
l_171 =
Code at -O1:
004004f6 :
4004f6: 53 push %rbx
4004f7: bb 00 00 00 00 mov$0x0,%ebx
4004fc: 48 83 ec 08 sub$0x8,%rsp
400500: 6a 08 pushq $0x8
400502: 6a 00 pushq $0x0
400504: 6a 00 pushq $0x0
400506: 41 b9 01 00 00 00 mov$0x1,%r9d
40050c: 41 b8 00 00 00 00 mov$0x0,%r8d
400512: b9 00 00 00 00 mov$0x0,%ecx
400517: ba 00 00 00 00 mov$0x0,%edx
40051c: be 00 00 00 00 mov$0x0,%esi
400521: 89 df mov%ebx,%edi
400523: b8 00 00 00 00 mov$0x0,%eax
400528: e8 26 00 00 00 callq 400553
40052d: 83 c3 03add$0x3,%ebx
400530: 48 83 c4 20 add$0x20,%rsp
400534: 83 fb 0ccmp$0xc,%ebx
400537: 75 c3 jne4004fc
400539: 5b pop%rbx
40053a: c3 retq
The code at higher optimization levels is very similar, besides where strength
reduction, we suppose, kicks in (e.g. mov $0, %edi => xor %edi, %edi).
DWARF at -O1:
0x00e8: DW_TAG_variable
DW_AT_name("l_171")
DW_AT_decl_file ("/tmp/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column (0x0b)
DW_AT_type(0x0167 "short int")
If we add -fno-tree-ccp to the compilation command line used above, the code of
function b remains unchanged but the DWARF const value information is preserved
for the variable, meaning its value 0 is visible when debugging throughout its
whole lifetime.
DWARF at -O1 with -fno-tree-ccp:
0x00e8: DW_TAG_variable
DW_AT_name("l_171")
DW_AT_decl_file ("/tmp/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column (0x0b)
DW_AT_type(0x0167 "short int")
[Bug fortran/102043] [9/10/11/12 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 Mikael Morin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #43 from Mikael Morin --- I’m working on it.
[Bug debug/105159] New: -fipa-reference-addressable causes drop of DWARF location info at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105159
Bug ID: 105159
Summary: -fipa-reference-addressable causes drop of DWARF
location info at -Og
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dc.delia at protonmail dot com
Target Milestone: ---
In this code, pointer variable l_515 assigned at line 4 appears as optimized
out at line 6 during source-level debugging, then the newly assigned value at
line 7 is available at line 8. This happens with -Og where
-fipa-reference-addressable makes the involved DWARF location information go
away but the compiled code stays the same. By disabling this option, the value
from line 4 becomes visible too.
We found this issue on gcc commit 500d3f0a302 on an x64 target using gdb 11.2,
while on prior gcc versions the behavior is either the same or the variable is
marked as optimized out the whole time.
$ cat -n a.c
int a, b;
static char c, d;
void foo() {
char *l_515 = &c;
char **f = &l_515;
b++;
*f = &d;
d = 0;
}
int main() {
foo();
a = c;
}
GDB trace:
$ gcc -Og -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 6
Breakpoint 1 at 0x400486: file a.c, line 6.
(gdb) r
Starting program: /home/stepping/57/reduce/opt
Breakpoint 1, foo () at a.c:6
6 b++;
(gdb) info locals
l_515 =
f =
(gdb) n
8 d = 0;
(gdb) info locals
l_515 = 0x601034 ""
f =
Compiled code of foo function:
00400486 :
400486: 83 05 9f 0b 20 00 01addl $0x1,0x200b9f(%rip)#
60102c
40048d: c6 05 a0 0b 20 00 00movb $0x0,0x200ba0(%rip)#
601034
400494: c3 retq
The first two instructions of function foo are associated with line 6 and 8,
respectively.
DWARF at -Og:
0x00cc: DW_TAG_variable
DW_AT_name("l_515")
DW_AT_decl_file ("/home/stepping/57/reduce/a.c")
DW_AT_decl_line (4)
DW_AT_decl_column (0x09)
DW_AT_type(0x00f3 "char*")
DW_AT_location(0x000e:
[0x0040048d, 0x00400494): DW_OP_addr
0x601034, DW_OP_stack_value)
DW_AT_GNU_locviews(0x000c)
In the DWARF information, there is only one location entry associated with the
instruction at 40048d which is mapped to line 8.
We found out that the optimization that makes the variable disappear is likely
-fipa-reference-addressable. After disabling it, when stepping at line 6 we can
now see the value of pointer l_515, since a new entry appeared in the list in
the DWARF location info of l_515 and is associated with the instruction at
400486, which is mapped to line 6.
DWARF at -Og with -fno-ipa-reference-addressable:
0x00d2: DW_TAG_variable
DW_AT_name("l_515")
DW_AT_decl_file ("/home/stepping/57/reduce/a.c")
DW_AT_decl_line (4)
DW_AT_decl_column (0x09)
DW_AT_type(0x00f9 "char*")
DW_AT_location(0x0010:
[0x00400486, 0x0040048d): DW_OP_addr
0x601035, DW_OP_stack_value
[0x0040048d, 0x00400494): DW_OP_addr
0x601034, DW_OP_stack_value)
DW_AT_GNU_locviews(0x000c)
This is what we found for a selection of prior gcc versions:
- 6.4, 7.5, 8.4, 9.3: l_515 is marked as optimized out the whole time and DWARF
location info is missing entirely
- 10.3, 11.1: the behavior is like the 500d3f0a302 git version that we tested
[Bug sanitizer/105155] -fsanitize=signed-integer-overflow failed to check an overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105155
--- Comment #3 from Jakub Jelinek ---
-fsanitize=signed-integer-overflow
currently instruments (unlike e.g. the shift or division instrumentation) only
what falls through unfolded from the early passes (generic folding,
gimplification and up to switching into ssa form), with some
!TYPE_OVERFLOW_SANITIZED checks in match.pd; the reason for that is that there
are simply way too many spots in the FE that produce the arithmetics and we
need to ensure that sanitization doesn't break constant expressions.
We don't even instrument
int bar (int a) { return __INT_MAX__ + 1; }
but do:
int baz (int a) { int x = __INT_MAX__; return x + 1; }
(but there is a warning in the bar case).
E.g. to instrument it even in bar, we'd need to change e.g. in the C FE:
/* Treat expressions in initializers specially as they can't trap. */
if (int_const_or_overflow)
ret = (require_constant_value
? fold_build2_initializer_loc (location, resultcode, build_type,
op0, op1)
: fold_build2_loc (location, resultcode, build_type, op0, op1));
else
ret = build2 (resultcode, build_type, op0, op1);
such that if for the int_const_or_overflow && !require_constant_value case
ret has TREE_OVERFLOW on it and signed-integer-overflow is enabled, we'd
do build2 instead.
[Bug d/104740] gdc.dg/simd_ctfe.d etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104740 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Iain Buclaw --- > I think all are covered now. Yes and no: while the test is now UNSUPPORTED on SPARC, it also became UNSUPPORTED on x86 (both 32 and 64-bit) where it previously PASSed. ISTM the requirements have become too strict now.
[Bug ipa/105160] New: [12 regression] ipa modref marks functions with asm volatile as const or pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160
Bug ID: 105160
Summary: [12 regression] ipa modref marks functions with asm
volatile as const or pure
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
the following code is miscompiled with gcc -O1
#define sysreg_read(regname)\
({ \
unsigned long __sr_val; \
asm volatile( \
"mrs %0, " #regname "\n"\
: "=r" (__sr_val)); \
\
__sr_val; \
})
#define sysreg_write(regname, __sw_val) \
do {\
asm volatile( \
"msr " #regname ", %0\n"\
: \
: "r" (__sw_val)); \
} while (0)
#define isb() \
do {\
asm volatile( \
"isb" \
: \
: \
: "memory");\
} while (0)
static unsigned long sctlr_read(void)
{
return sysreg_read(sctlr_el1);
}
static void sctlr_write(unsigned long val)
{
sysreg_write(sctlr_el1, val);
}
static void sctlr_rmw(void)
{
unsigned long val;
val = sctlr_read();
val |= 1UL << 7;
sctlr_write(val);
}
void sctlr_read_multiple(void)
{
sctlr_read();
sctlr_read();
sctlr_read();
sctlr_read();
}
void sctlr_write_multiple(void)
{
sctlr_write(0);
sctlr_write(0);
sctlr_write(0);
sctlr_write(0);
sctlr_write(0);
}
void sctlr_rmw_multiple(void)
{
sctlr_rmw();
sctlr_rmw();
sctlr_rmw();
sctlr_rmw();
}
void function(void)
{
sctlr_read_multiple();
sctlr_write_multiple();
sctlr_rmw_multiple();
isb();
}
aarch64-linux-gnu-gcc -O1 compiles it to
(note 'function' and 'sctlr_rmw_multiple'):
sctlr_rmw:
mrs x0, sctlr_el1
orr x0, x0, 128
msr sctlr_el1, x0
ret
sctlr_read_multiple:
mrs x0, sctlr_el1
mrs x0, sctlr_el1
mrs x0, sctlr_el1
mrs x0, sctlr_el1
ret
sctlr_write_multiple:
mov x0, 0
msr sctlr_el1, x0
msr sctlr_el1, x0
msr sctlr_el1, x0
msr sctlr_el1, x0
msr sctlr_el1, x0
ret
sctlr_rmw_multiple:
ret
function:
isb
ret
a similar issue in linux (but lager source file) got bisected to
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=1b62cddcf091fb8cadf575246a7d3ff778650a6b
commit 1b62cddcf091fb8cadf575246a7d3ff778650a6b
Author: Jan Hubicka
Date: Fri Nov 12 14:00:47 2021 +0100
Fix ipa-modref pure/const discovery
PR ipa/103200
* ipa-modref.c (analyze_function, modref_propagate_in_scc): Do
not mark pure/const function if there are side-effects.
with -fdump-ipa-all
$ grep found t.c.087i.modref
Function found to be const: sctlr_rmw/2
Function found to be const: sctlr_read_multiple/3
Function found to be const: sctlr_write_multiple/4
Function found to be const: sctlr_rmw_multiple/5
even though t.c.086i.pure-const correctly identifies asm volatile
as not const/pure.
[Bug ipa/105160] [12 regression] ipa modref marks functions with asm volatile as const or pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |12.0
Last reconfirmed||2022-04-05
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener ---
Agreed, 'volatile' is documented as
@item volatile
The typical use of extended @code{asm} statements is to manipulate input
values to produce output values. However, your @code{asm} statements may
also produce side effects. If so, you may need to use the @code{volatile}
qualifier to disable certain optimizations. @xref{Volatile}.
so for the side-effects the asms should make the functions non-pure/const.
[Bug ipa/105160] [12 regression] ipa modref marks functions with asm volatile as const or pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
The odd thing is that during IPA propagation (modref_propagate_in_scc), the
summary of sctlr_read is
(gdb) p *cur_summary
$2 = {loads = 0x7665af00, stores = 0x7665af10,
kills = {> = {
m_vec = 0x0}, },
arg_flags = {> = {
m_vec = 0x0}, }, retslot_flags = 0,
static_chain_flags = 0, writes_errno = 0, side_effects = 0,
nondeterministic = 0, calls_interposable = 0, load_accesses = 0,
global_memory_read = 0, global_memory_written = 0, try_dse = 1}
which is because we access the summary of cur->inlined_to (sctlr_rmw) here
but that hasn't been processed. But the non-inlined node doesn't have a
summary.
So somehow we fail to merge the info from the inlined clones?
But even using ->clone_of instead of ->inlined_to doesn't make a difference
(no summary for that node either).
Something is wrong. Honza?
[Bug ipa/105160] [12 regression] ipa modref marks functions with asm volatile as const or pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160
--- Comment #3 from Richard Biener ---
Hmm, we ignore inlined edges during propagation!?
for (cgraph_edge *callee_edge = cur->callees; callee_edge;
callee_edge = callee_edge->next_callee)
{
int flags = flags_from_decl_or_type (callee_edge->callee->decl);
modref_summary *callee_summary = NULL;
modref_summary_lto *callee_summary_lto = NULL;
struct cgraph_node *callee;
if (!callee_edge->inline_failed
|| ((flags & (ECF_CONST | ECF_NOVOPS))
&& !(flags & ECF_LOOPING_CONST_OR_PURE)))
continue;
but we also ignore calls during local analysis in IPA mode. Where are we
supposed to factor in flags from inline clones? Is the IPA inline pass
supposed to update summaries somehow?
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #8 from Xi Ruoyao --- Shall I close it as FIXED, or keep it opening waiting for AMD response?
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #9 from Jakub Jelinek --- Besides missing AMD response, it isn't fully fixed, because the change is on the libatomic side only. So we still pay the cost to call those functions (and often PLT cost too) and return from them. For GCC 13, we should add some option that optionally reverts the change to use library calls all the time, and default that option for -march= Intel CPUs with AVX support or something similar (perhaps only if AVX is also enabled).
[Bug debug/105158] ftree-ccp (CFG cleanup) drops DWARF const value attribute at -Og/-O1/-O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105158 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|ftree-ccp drops DWARF const |ftree-ccp (CFG cleanup) |value attribute at |drops DWARF const value |-Og/-O1/-O2/-O3 |attribute at ||-Og/-O1/-O2/-O3 Severity|normal |enhancement Last reconfirmed||2022-04-05 --- Comment #1 from Richard Biener --- The issue is that the definition we put the debug stmt into is in : [t.c:4:5] # DEBUG BEGIN_STMT [t.c:4:16] # DEBUG l_174 => 0 [t.c:4:27] # DEBUG l_188 => 0 [t.c:4:38] # DEBUG l_191 => 0 [t.c:4:49] # DEBUG l_240 => 1 [t.c:5:5] # DEBUG BEGIN_STMT [t.c:6:5] # DEBUG BEGIN_STMT [t.c:6:20] # DEBUG l_169 => 0 [t.c:6:25] if (0 != 0) goto ; [INV] else goto ; [INV] : : [t.c:6:11] # DEBUG l_171 => 0 [t.c:7:5] # DEBUG BEGIN_STMT [t.c:7:5] goto ; [INV] : # l_169_3 = PHI <[t.c:6:20] 0(6), [t.c:7:30] l_169_19(7)> # DEBUG l_169 => l_169_3 [t.c:7:18] # DEBUG BEGIN_STMT [t.c:7:18] if (l_169_3 <= 9) goto ; [INV] else goto ; [INV] and when CFG cleanup merges all the forwarders it finds no location to put the debug stmt to - it tries to move the debug stmts to the successor but that doesn't have a single predecessor so that's not a valid thing to do. Moving to the predecessor would be valid if that has a single successor though but that's not implemented. In this case the predecessor is block 2 at the point in question and it has a single successor plus the last stmt in it doesn't end the BB.
[Bug c/105148] [11/12 Regression] ICE in verify_use, at tree-ssa.cc:881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105148
--- Comment #2 from Jakub Jelinek ---
Reduced testcase:
extern void foo (void);
static inline int
bar (int n)
{
for (int i = 0; i < n; i++)
{
foo ();
int y[1][i];
y[n][i] = 0;
}
}
int
baz (void)
{
return bar (5);
}
[Bug debug/105158] ftree-ccp (CFG cleanup) drops DWARF const value attribute at -Og/-O1/-O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105158 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 debug/105158] ftree-ccp (CFG cleanup) drops DWARF const value attribute at -Og/-O1/-O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105158 --- Comment #3 from Richard Biener --- Created attachment 52748 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52748&action=edit patch
[Bug jit/104071] Add support for bitcast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104071 David Malcolm changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/jit/2022q1/001475.html --- Comment #1 from David Malcolm --- Latest version of patch seems to be: https://gcc.gnu.org/pipermail/jit/2022q1/001475.html
[Bug c/105148] [11/12 Regression] ICE in verify_use, at tree-ssa.cc:881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105148
Jakub Jelinek changed:
What|Removed |Added
Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Status|ASSIGNED|NEW
--- Comment #3 from Jakub Jelinek ---
This looks like an ivopts bug and I'm unfortunately not familiar enough with
that pass.
Before ivopts we have:
[local count: 8687547547]:
# i_2 = PHI
# ivtmp_19 = PHI
saved_stack.2_4 = __builtin_stack_save ();
foo ();
_6 = (sizetype) i_2;
_7 = _6 * 4;
y.1_8 = __builtin_alloca_with_align (_7, 32);
MEM [(int[1][0:D.1996] *)y.1_8][5]{lb: 0 sz: _6 * 4}[i_2]
= 0;
__builtin_stack_restore (saved_stack.2_4);
i_10 = i_2 + 1;
ivtmp_11 = ivtmp_19 - 1;
if (ivtmp_11 != 0)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 7731917322]:
goto ; [100.00%]
loop and ivopts decides to create a new unsigned long ivtmp.9 IV going from
0 with step 1. But it doesn't properly adjust the ARRAY_REF with sz:, so it
keeps referencing a freed SSA_NAME _6:
[local count: 8687547547]:
# ivtmp.9_5 = PHI
_20 = (unsigned int) ivtmp.9_5;
i_2 = (int) _20;
saved_stack.2_4 = __builtin_stack_save ();
foo ();
_3 = ivtmp.9_5 * 4;
_7 = _3;
y.1_8 = __builtin_alloca_with_align (_7, 32);
MEM [(int[1][0:D.1996] *)y.1_8][5]{lb: 0 sz: <<< error
>>>}[i_2] = 0;
__builtin_stack_restore (saved_stack.2_4);
ivtmp.9_9 = ivtmp.9_5 + 1;
if (ivtmp.9_9 != 5)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 7731917322]:
goto ; [100.00%]
I believe it should use ivtmp.9_5 (printed as ivtmp.9_5 * 4).
[Bug c/105148] [11/12 Regression] ICE in verify_use, at tree-ssa.cc:881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105148
--- Comment #4 from Richard Biener ---
- MEM [(int[1][0:D.1996] *)y.1_8][5]{lb: 0 sz: _6 * 4}[i_2]
= 0;
+ MEM [(int[1][0:D.1996] *)y.1_8][5]{lb: 0 sz: <<< error
>>>}[i_2] = 0;
find_interesting_uses_op fails to consider _6 * 4, in fact idx_record_use
does
if (TREE_CODE (base) == ARRAY_REF || TREE_CODE (base) == ARRAY_RANGE_REF)
{
find_interesting_uses_op (data, array_ref_element_size (base));
find_interesting_uses_op (data, array_ref_low_bound (base));
}
but it should probably pass down the raw TREE_OPERANDs, not the scaled
array_ref_element_size ().
I have a patch:
diff --git a/gcc/tree-ssa-loop-ivopts.cc b/gcc/tree-ssa-loop-ivopts.cc
index b0305c494cd..81b536f9304 100644
--- a/gcc/tree-ssa-loop-ivopts.cc
+++ b/gcc/tree-ssa-loop-ivopts.cc
@@ -2124,8 +2124,10 @@ idx_record_use (tree base, tree *idx,
find_interesting_uses_op (data, *idx);
if (TREE_CODE (base) == ARRAY_REF || TREE_CODE (base) == ARRAY_RANGE_REF)
{
- find_interesting_uses_op (data, array_ref_element_size (base));
- find_interesting_uses_op (data, array_ref_low_bound (base));
+ if (TREE_OPERAND (base, 2))
+ find_interesting_uses_op (data, TREE_OPERAND (base, 2));
+ if (TREE_OPERAND (base, 3))
+ find_interesting_uses_op (data, TREE_OPERAND (base, 3));
}
return true;
}
[Bug c/105148] [11/12 Regression] ICE in verify_use, at tree-ssa.cc:881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105148 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug jit/104073] Add option to hide stderr logging in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104073 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/jit/attachments/20220123 ||/22c69b0c/attachment.bin Ever confirmed|0 |1 Keywords||patch Last reconfirmed||2022-04-05
[Bug jit/104293] Add support for setting the alignment of variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104293 David Malcolm changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/jit/2022q1/001494.html Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2022-04-05
[Bug debug/105161] New: variable constant-folded in its uses appears as optimized out depending on where it is assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105161
Bug ID: 105161
Summary: variable constant-folded in its uses appears as
optimized out depending on where it is assigned
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: assaiante at diag dot uniroma1.it
Target Milestone: ---
In this minimized C code, variable j is shown as optimized out when debugging
line 8, where it is used to index an access to global array b for assigning
volatile global variable a. The other two variables i and k used for the access
are instead available. This happens at possibly any optimization level: we
tested -Og, -O1, -O2, and -O3.
We suppose the operation (j)*k is constant-folded to 0 when computing the
offset for accessing b. The variable remains optimized out also under other
value choices for j that we tested. But it becomes visible if we make j
non-constant (for instance with “(j++)*k” at line 8).
We also note that if the assignment is done at declaration time (e.g., “int i =
0, j = 0, k;” with line 6 becoming simply “k=0;”), then variable j becomes
visible with 0 value.
Furthemore, for the modified code, older versions of gdb (e.g. 8.1) will not
list j among local variables: we believe this may be a then-fixed gdb bug, but
perhaps still worth mentioning.
We provide details for -Og on x64 and a quick assessment of older gcc versions
below.
$ cat a.c
volatile int a;
int b[10][2];
int main() {
int i = 0, j, k;
for (; i < 10; i++) {
j = k = 0;
for (; k < 1; k++)
a = b[i][(j)*k];
}
}
GCC and GDB version:
- gcc (GCC) 12.0.0 20211227 (experimental) - commit id: 500d3f0a302
- GNU gdb (GDB) 11.2
GDB trace:
$ gcc -Og -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 8
Breakpoint 1 at 0x40048d: file a.c, line 8.
(gdb) r
Starting program: /home/stepping/37/reduce/opt
Breakpoint 1, main () at a.c:8
8 a = b[i][(j)*k];
(gdb) info loc
i = 0
j =
k = 0
ASM of main function at Og:
00400486 :
400486: ba 00 00 00 00 mov$0x0,%edx
40048b: eb 1a jmp4004a7
40048d: 48 63 camovslq %edx,%rcx
400490: 8b 0c cd 60 10 60 00mov0x601060(,%rcx,8),%ecx
400497: 89 0d 13 0c 20 00 mov%ecx,0x200c13(%rip)#
6010b0
40049d: 83 c0 01add$0x1,%eax
4004a0: 85 c0 test %eax,%eax
4004a2: 7e e9 jle40048d
4004a4: 83 c2 01add$0x1,%edx
4004a7: 83 fa 09cmp$0x9,%edx
4004aa: 7f 07 jg 4004b3
4004ac: b8 00 00 00 00 mov$0x0,%eax
4004b1: eb ed jmp4004a0
4004b3: b8 00 00 00 00 mov$0x0,%eax
4004b8: c3 retq
4004b9: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
DWARF at -Og:
0x009b: DW_TAG_variable
DW_AT_name("i")
DW_AT_decl_column (0x07)
DW_AT_type(0x0041 "int")
DW_AT_location(0x0010:
[0x00400486, 0x0040048d): DW_OP_lit0,
DW_OP_stack_value
[0x0040048d, 0x004004b9): DW_OP_reg1 RDX)
DW_AT_GNU_locviews
(0x000c)
0x00ab: DW_TAG_variable
DW_AT_name("j")
DW_AT_decl_file ("/home/stepping/37/reduce/a.c")
DW_AT_decl_line (4)
DW_AT_decl_column (0x0e)
DW_AT_type(0x0041 "int")
0x00b5: DW_TAG_variable
DW_AT_name("k")
DW_AT_decl_column (0x11)
DW_AT_type(0x0041 "int")
DW_AT_location(0x001e:
[0x0040048d, 0x004004a7): DW_OP_reg0 RAX)
DW_AT_GNU_locviews
(0x001c)
>From DWARF information, attributes location and const value are completely
missing for variable j, while other variables have a correct location
definition that makes them available at line 8.
Interestingly, if we modify the source code by initializing variable j earlier
at line 4, the const value attribute is correctly added to variable’s DIE and
therefore the variable is correctly available at line 8 at every optimization
level.
DWARF at -Og (with j initialization at line 4):
0x009b: DW_TAG_variable
DW_AT_name("i")
DW_AT_decl_column (0x07)
DW_AT_type(0x0041 "int")
DW_AT_location(0x0010:
[0x00400486, 0x0040048d): DW_OP_lit0,
DW_OP_st
[Bug testsuite/93260] Deal with missing CUDA etc. installation in libgomp '-lcuda' etc. test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93260
Thomas Schwinge changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
Component|libgomp |testsuite
Target||nvptx
--- Comment #3 from Thomas Schwinge ---
Need to verify what remains to be done here after Jakub's commit
r12-1098-g79e3f7d54bc4e34b096082d3b90042d9f0fbaf1a "libgomp: Add
openacc_{cuda,cublas,cudart} effective targets and use them in openacc
testsuite".
[Bug ipa/105160] [12 regression] ipa modref marks functions with asm volatile as const or pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #4 from Jan Hubicka --- Mine. The inliner pass is supposed to update the summary so it seems like a bug there. I will take a look tonight.
[Bug target/105147] New test case gcc.dg/pr105140.c introduced in r12-7979-geaaf77dd85c333 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105147 Segher Boessenkool changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Segher Boessenkool --- This is an error from 2005 (g:4d3e6fae4dd3, r96124). It is generic code that makes this an error (instead of a warning), not the rs6000 backend, which just provides the string (via the invalid_arg_for_unprototyped_fn hook). s390 has this exact same error btw.
[Bug fortran/104812] Construct-name with same variable name in scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104812 --- Comment #4 from Mike K. --- Created attachment 52749 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52749&action=edit propose to return an error if constuct-name clashes with variable name > Note, the prohibition in the standard is not a numbered > constraint, which means a compiler need not issue an > error or warning. It is expected that the programmer > writes conforming code. Could we enforce this constraint and print error message instead of relying on programmer? I think that explicit error is better than silently accepting non-conforming code for some corner-cases. Attached patch with proposed fix, wdyth?
[Bug target/105162] New: [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162
Bug ID: 105162
Summary: [AArch64] outline-atomics drops dmb ish barrier on
__sync builtins
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: spop at gcc dot gnu.org
Target Milestone: ---
With -mno-outline-atomics gcc produces a `dmb ish` barrier on __sync builtins
as required by the Intel specification
(see fix for https://gcc.gnu.org/PR65697
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=f70fb3b635f9618c6d2ee3848ba836914f7951c2
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ab876106eb689947cdd8203f8ecc6e8ac38bf5ba
)
$ cat a.c
int foo(int a)
{
return __sync_bool_compare_and_swap(&a, 4, 5);
}
$ gcc -O2 a.c -S -o- -mno-outline-atomics
foo:
sub sp, sp, #16
mov w1, 5
str w0, [sp, 12]
add x0, sp, 12
.L4:
ldxrw2, [x0]
cmp w2, 4
bne .L5
stlxr w3, w1, [x0]
cbnzw3, .L4
.L5:
dmb ish
csetw0, eq
add sp, sp, 16
ret
With -moutline-atomics gcc does not generate the barrier:
$ gcc -O2 a.c -S -o- -moutline-atomics
foo:
stp x29, x30, [sp, -32]!
mov w1, 5
mov x29, sp
add x2, sp, 28
str w0, [sp, 28]
mov w0, 4
bl __aarch64_cas4_acq_rel
cmp w0, 4
csetw0, eq
ldp x29, x30, [sp], 32
ret
Happens on gcc-8, 9, 10, 11, and trunk.
[Bug c/105163] New: ICE: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105163
Bug ID: 105163
Summary: ICE: SSA corruption
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least r5, at -O1+ :
(follow-up of pr79411.c)
$ cat z1.c
typedef struct __jmp_buf_tag { char buf[1024]; } jmp_buf[1];
extern int setjmp (jmp_buf);
extern int bar (unsigned int *);
extern jmp_buf *baz (void);
struct C { int c1; };
void foo (struct C *x, int *z, int e)
{
unsigned int d = 0;
long f;
setjmp (*baz());
f = 1 + ~d;
d = 8;
if ((!0) && !e && bar(z)) *z = 1 + f;
}
$ gcc-12-20220403 -c z1.c -O2
Unable to coalesce ssa_names 5 and 17 which are marked as MUST COALESCE.
d_5(ab) and d_17(ab)
during RTL pass: expand
z1.c: In function 'foo':
z1.c:6:6: internal compiler error: SSA corruption
6 | void foo (struct C *x, int *z, int e)
| ^~~
0xd18bc8 fail_abnormal_edge_coalesce
../../gcc/tree-ssa-coalesce.cc:1003
0xd18bc8 coalesce_partitions
../../gcc/tree-ssa-coalesce.cc:1425
0xd18bc8 coalesce_ssa_name(_var_map*)
../../gcc/tree-ssa-coalesce.cc:1755
0xcc26a0 remove_ssa_form
../../gcc/tree-outof-ssa.cc:1065
0xcc26a0 rewrite_out_of_ssa(ssaexpand*)
../../gcc/tree-outof-ssa.cc:1323
0x7cfa73 execute
../../gcc/cfgexpand.cc:6585
[Bug c++/105164] New: new warning in clang, missing in gcc: -Wbitwise-instead-of-logical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105164
Bug ID: 105164
Summary: new warning in clang, missing in gcc:
-Wbitwise-instead-of-logical
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:
extern bool f1( int);
extern void f3( int);
void
f2( int n)
{
if (!f1(n) & !f1( n + 1))
f3( n - 1);
if (!f1(n) | !f1( n + 1))
f3( n + 1);
}
recent gcc trunk says not a lot:
$ /home/dcb/gcc/results/bin/g++ -g -O2 -Wall -Wextra -pedantic -c jul01a.cc
$
However, new clang-14 says:
$ clang++ -g -O2 -Wall -Wextra -pedantic -c jul01a.cc
jul01a.cc:8:6: warning: use of bitwise '&' with boolean operands
[-Wbitwise-instead-of-logical]
if (!f1(n) & !f1( n + 1))
^~~~
&&
jul01a.cc:8:6: note: cast one or both operands to int to silence this warning
jul01a.cc:11:6: warning: use of bitwise '|' with boolean operands
[-Wbitwise-instead-of-logical]
if (!f1(n) | !f1( n + 1))
^~~~
||
jul01a.cc:11:6: note: cast one or both operands to int to silence this warning
2 warnings generated.
$
Static analyser cppcheck also finds the problem:
$ /home/dcb/cppcheck/trunk.git/cppcheck --enable=all jul01a.cc
jul01a.cc:8:13: style: Boolean result is used in bitwise operation. Clarify
expression with parentheses. [clarifyCondition]
if (!f1(n) & !f1( n + 1))
^
jul01a.cc:11:13: style: Boolean result is used in bitwise operation. Clarify
expression with parentheses. [clarifyCondition]
if (!f1(n) | !f1( n + 1))
^
jul01a.cc:6:0: style: The function 'f2' is never used. [unusedFunction]
^
[Bug c/105163] ICE: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105163
G. Steinmetz changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
Keywords||ice-on-valid-code
--- Comment #1 from G. Steinmetz ---
A corrupted variant starts to give an ICE between 20201018 and 20201108 :
$ cat z2.c
typedef struct __jmp_buf_tag { char buf[1024]; } jmp_buf[1];
extern int setjmp (jmp_buf);
extern jmp_buf *baz (void);
struct A { int b; };
void foo (struct A, int *z, int c)
{
unsigned d = 0;
long e;
setjmp (*baz());
e = 1 + ~d;
d = 8;
if ((!0) && !c && bar(z)) *z = 1 + e;
}
[Bug c/105165] New: [11/12 Regression] ICE in gimple_redirect_edge_and_branch, at tree-cfg.cc:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105165
Bug ID: 105165
Summary: [11/12 Regression] ICE in
gimple_redirect_edge_and_branch, at tree-cfg.cc:6136
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20201108 and 20201115, at -O1+ :
(derived from pr100329.c)
$ cat z1.c
unsigned int _Complex a0;
unsigned int _Complex
foo (unsigned int _Complex a1, unsigned int _Complex a2)
{
unsigned int _Complex x;
asm goto ("" : "=r" (x) : : : lab);
a0 = x;
lab:
return x + a1 + a2 + 1;
}
$ gcc-12-20220403 -c z1.c -O2
during GIMPLE pass: pre
z1.c: In function 'foo':
z1.c:3:1: internal compiler error: in gimple_redirect_edge_and_branch, at
tree-cfg.cc:6136
3 | foo (unsigned int _Complex a1, unsigned int _Complex a2)
| ^~~
0xc611c5 gimple_redirect_edge_and_branch
../../gcc/tree-cfg.cc:6136
0x7d3139 redirect_edge_and_branch(edge_def*, basic_block_def*)
../../gcc/cfghooks.cc:388
0xc593b8 gimple_split_edge
../../gcc/tree-cfg.cc:2983
0x7d37c5 split_edge(edge_def*)
../../gcc/cfghooks.cc:668
0xc61f67 split_critical_edges(bool)
../../gcc/tree-cfg.cc:9172
0xda6ab1 split_edges_for_insertion()
../../gcc/tree-cfg.h:130
0xda6ab1 execute
../../gcc/tree-ssa-pre.cc:4402
[Bug c/105166] New: [12 Regression] ICE in ao_ref_init_from_ptr_and_range, at tree-ssa-alias.cc:863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105166
Bug ID: 105166
Summary: [12 Regression] ICE in ao_ref_init_from_ptr_and_range,
at tree-ssa-alias.cc:863
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20211107 and 2024, at -O1+ :
$ cat z1.c
bar (foo, a)
int (**foo) ();
{
(foo)[1] = bar;
foo[1] (1);
}
$ gcc-12-20220403 -c z1.c -O2
z1.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
1 | bar (foo, a)
| ^~~
z1.c: In function 'bar':
z1.c:1:1: warning: type of 'a' defaults to 'int' [-Wimplicit-int]
during GIMPLE pass: dse
z1.c:1:1: internal compiler error: in ao_ref_init_from_ptr_and_range, at
tree-ssa-alias.cc:863
0xcfd747 ao_ref_init_from_ptr_and_range(ao_ref*, tree_node*, bool, poly_int<1u,
long>, poly_int<1u, long>, poly_int<1u, long>)
../../gcc/tree-ssa-alias.cc:863
0xa1080b modref_access_node::get_ao_ref(gcall const*, ao_ref*) const
../../gcc/ipa-modref-tree.cc:688
0xd03eb3 stmt_kills_ref_p(gimple*, ao_ref*)
../../gcc/tree-ssa-alias.cc:3461
0xd28b56 dse_classify_store(ao_ref*, gimple*, bool, simple_bitmap_def*, bool*,
tree_node*)
../../gcc/tree-ssa-dse.cc:1053
0xd2aecf dse_optimize_stmt
../../gcc/tree-ssa-dse.cc:1385
0xd2aecf execute
../../gcc/tree-ssa-dse.cc:1491
[Bug fortran/105167] New: ICE in gfc_set_default_type, at fortran/symbol.cc:298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167 Bug ID: 105167 Summary: ICE in gfc_set_default_type, at fortran/symbol.cc:298 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: --- Gives an ICE with undefined "n" (also sporadically before 20210926) : $ cat z1.f90 program p if ( len([character(n) :: '']) /= 0 ) stop end $ gfortran-12-20210905 -c z1.f90 z1.f90:2:23: 2 |if ( len([character(n) :: '']) /= 0 ) stop | 1 Error: Scalar INTEGER expression expected at (1) z1.f90:2:23: 2 |if ( len([character(n) :: '']) /= 0 ) stop | 1 Error: Scalar INTEGER expression expected at (1) $ gfortran-12-20220403 -c z1.f90 f951: internal compiler error: Segmentation fault 0xcce34f crash_signal ../../gcc/toplev.cc:322 0x7919da gfc_get_default_type(char const*, gfc_namespace*) ../../gcc/fortran/symbol.cc:231 0x795734 gfc_set_default_type(gfc_symbol*, int, gfc_namespace*) ../../gcc/fortran/symbol.cc:298 0x765671 resolve_variable ../../gcc/fortran/resolve.cc:5886 0x765671 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7189 0x767024 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:12657 0x767024 resolve_charlen ../../gcc/fortran/resolve.cc:12607 0x773809 resolve_charlen ../../gcc/fortran/resolve.cc:12598 0x773809 resolve_types ../../gcc/fortran/resolve.cc:17482 0x76ecbc gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17599 0x756c44 resolve_all_program_units ../../gcc/fortran/parse.cc:6604 0x756c44 gfc_parse_file() ../../gcc/fortran/parse.cc:6860 0x7a47df gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167 G. Steinmetz changed: What|Removed |Added Keywords||accepts-invalid, ||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Interestingly, this type-spec "character(n)" with undefined "n" is simply ignored in following test case : $ cat z7.f90 program p print *, len([character(n) :: '']) print *, len([character(n) :: '1']) print *, len([character(n) :: '12']) print *, len([character(n) :: '123']) print *, len([character(n) :: '123456789']) print *, len([character(n) :: '1234567890123456789']) end $ gfortran-12-20220403 z7.f90 && ./a.out 0 1 2 3 9 19
[Bug fortran/105168] New: [9/10/11/12 Regression] ICE in gfc_maybe_dereference_var, at fortran/trans-expr.cc:2870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105168 Bug ID: 105168 Summary: [9/10/11/12 Regression] ICE in gfc_maybe_dereference_var, at fortran/trans-expr.cc:2870 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 r8, changed between 20190503 and 20190614 : (follow-up of pr104430) $ cat z1.f90 module m type t integer :: a end type contains function f(x) result(z) class(t) :: x(:) type(t) :: z(size(x%a)) end end program p use m class(t), allocatable :: y(:), z(:) z = f((y)) end $ gfortran-7 -c z1.f90 $ $ gfortran-12-20220403 -c z1.f90 z1.f90:14:13: 14 |z = f((y)) | 1 internal compiler error: Segmentation fault 0xcce34f crash_signal ../../gcc/toplev.cc:322 0x7d8cfd gfc_maybe_dereference_var(gfc_symbol*, tree_node*, bool, bool) ../../gcc/fortran/trans-expr.cc:2870 0x7e06fb gfc_conv_variable ../../gcc/fortran/trans-expr.cc:3065 0x7dc7da gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9413 0x7df570 gfc_conv_expr_lhs(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9443 0x7afdf8 gfc_conv_ss_descriptor ../../gcc/fortran/trans-array.cc:3219 0x7ba85b gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-array.cc:7501 0x7f10ff gfc_conv_intrinsic_size ../../gcc/fortran/trans-intrinsic.cc:7975 0x807f8b gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-intrinsic.cc:10646 0x7dc7ba gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9405 0x7deb8a gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:4867 0x7aeb57 gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*, gfc_array_spec*) ../../gcc/fortran/trans-array.cc:1080 0x7ea037 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.cc:7479 0x7eb93c gfc_trans_arrayfunc_assign ../../gcc/fortran/trans-expr.cc:10880 0x7ef614 gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool, bool, bool) ../../gcc/fortran/trans-expr.cc:12045 0x7ab6c7 trans_code ../../gcc/fortran/trans.cc:1916 0x7d4b7e gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7654 0x75734e translate_all_program_units ../../gcc/fortran/parse.cc:6669 0x75734e gfc_parse_file() ../../gcc/fortran/parse.cc:6956 0x7a47df gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug c++/101677] [11/12 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101677 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1de6612d994ada8edaab18bbc6afd8e9a57413aa commit r12-7997-g1de6612d994ada8edaab18bbc6afd8e9a57413aa Author: Jason Merrill Date: Sun Mar 27 22:31:51 2022 -0400 c++: elaborated-type-spec in requires-expr [PR101677] We were failing to declare class S in the global namespace because we were treating the requires-expression parameter scope as a normal block scope, so the implicit declaration went there. It seems to me that the requires parameter scope is more like a function parameter scope (not least in the use of the word "parameter"), so let's change the scope kind. But then we need to adjust the prohibition on placeholders declaring implicit template parameters. PR c++/101677 gcc/cp/ChangeLog: * name-lookup.h (struct cp_binding_level): Add requires_expression bit-field. * parser.cc (cp_parser_requires_expression): Set it. (synthesize_implicit_template_parm): Check it. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-pr67178.C: Adjust error. * g++.dg/cpp2a/concepts-requires28.C: New test.
[Bug c++/103852] [10/11/12 Regression] Alias template argument deduction is available in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103852 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5d583d24200ac33a1cb281b7ddee9aad351151b5 commit r12-7998-g5d583d24200ac33a1cb281b7ddee9aad351151b5 Author: Jason Merrill Date: Mon Apr 4 11:56:38 2022 -0400 c++: alias template equivalence and CTAD [PR103852] I had been thinking about DR1286 "equivalence" as meaning generally interchangeable, but looking back at the proposed resolution in the context of this PR, I see that it's just about use as a template argument. So let's give a pedwarn if we look through a renaming alias. PR c++/103852 DR 1286 gcc/cp/ChangeLog: * pt.cc (do_class_deduction): Pedwarn for renaming alias in C++17. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/class-deduction-alias1.C: Expect warning.
[Bug c/105165] [11/12 Regression] ICE in gimple_redirect_edge_and_branch, at tree-cfg.cc:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105165 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-04-05 --- Comment #1 from Jakub Jelinek --- This started with r11-5002-ge3b3b59683c1e7d31a9d313dd97394abebf644be so not really sure if we can call it a regression. It is a regression in that something that didn't ICE before now ICEs, but it was invalid before and now is valid.
[Bug fortran/104812] Construct-name with same variable name in scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104812 kargl at gcc dot gnu.org changed: What|Removed |Added Resolution|INVALID |--- Ever confirmed|0 |1 Priority|P3 |P4 Status|RESOLVED|REOPENED Last reconfirmed||2022-04-05 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to Mike K. from comment #4) > Created attachment 52749 [details] > propose to return an error if constuct-name clashes with variable name > > > Note, the prohibition in the standard is not a numbered > > constraint, which means a compiler need not issue an > > error or warning. It is expected that the programmer > > writes conforming code. > > Could we enforce this constraint and print error message instead of relying > on programmer? I think that explicit error is better than silently accepting > non-conforming code for some corner-cases. > > Attached patch with proposed fix, wdyth? Thanks for the patch. I no longer commit due to the migration to git. I've changed the Status to Reopened so that another gfortran developer might take a look. You can likely get some attention for this PR and your patch if you post it in fort...@gcc.gnu.org and gcc-patc...@gcc.gnu.org. Ask someone to committed. You might need to ping the email after a week or so if no one respondes.
[Bug target/104897] wrong plural form in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104897 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:e8bc70cc17b0105e2c463a98c9ff76039d03ff60 commit r12-7999-ge8bc70cc17b0105e2c463a98c9ff76039d03ff60 Author: Richard Sandiford Date: Tue Apr 5 17:31:35 2022 +0100 aarch64: Use error_n for plural text [PR104897] Use error_n rather than error_at for â%d vectorsâ, so that translators can pick different translations based on the number (2 vs more than 2, etc.) gcc/ PR target/104897 * config/aarch64/aarch64-sve-builtins.cc (function_resolver::infer_vector_or_tuple_type): Use error_n for "%d vectors" messages.
[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103147 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:14814e20161d7b6a4e9cac244c7013fa56f71f55 commit r12-8000-g14814e20161d7b6a4e9cac244c7013fa56f71f55 Author: Richard Sandiford Date: Tue Apr 5 17:31:35 2022 +0100 aarch64: Fix -fpack-struct + [PR103147] This PR is about -fpack-struct causing a crash when is included. The new register_tuple_type code was expecting a normal unpacked structure layout instead of a packed one. For SVE we got around this by temporarily suppressing -fpack-struct, so that the tuple types always have their normal ABI. However: (a) The SVE ACLE tuple types are defined to be abstract. The fact that GCC uses structures is an internal implementation detail. (b) In contrast, the ACLE explicitly defines the Advanced SIMD tuple types to be particular structures. (c) Clang and previous versions of GCC are consistent in applying -fpack-struct to these tuple structures. This patch therefore honours -fpack-struct and -fpack-struct=. It also adds tests for some other combinations, such as -mgeneral-regs-only and -fpack-struct -mstrict-align. gcc/ PR target/103147 * config/aarch64/aarch64-protos.h (aarch64_simd_switcher): New class. * config/aarch64/aarch64-sve-builtins.h (sve_switcher): Inherit from aarch64_simd_switcher. * config/aarch64/aarch64-builtins.cc (aarch64_simd_tuple_modes): New variable. (aarch64_lookup_simd_builtin_type): Use it instead of TYPE_MODE. (register_tuple_type): Add more asserts. Expect the alignment of the structure to be subject to flag_pack_struct and maximum_field_alignment. Set aarch64_simd_tuple_modes. (aarch64_simd_switcher::aarch64_simd_switcher): New function. (aarch64_simd_switcher::~aarch64_simd_switcher): Likewise. (handle_arm_neon_h): Hold an aarch64_simd_switcher throughout. (aarch64_general_init_builtins): Hold an aarch64_simd_switcher while calling aarch64_init_simd_builtins. * config/aarch64/aarch64-sve-builtins.cc (sve_switcher::sve_switcher) (sve_switcher::~sve_switcher): Remove code now performed by aarch64_simd_switcher. gcc/testsuite/ PR target/103147 * gcc.target/aarch64/pr103147-1.c: New test. * gcc.target/aarch64/pr103147-2.c: Likewise. * gcc.target/aarch64/pr103147-3.c: Likewise. * gcc.target/aarch64/pr103147-4.c: Likewise. * gcc.target/aarch64/pr103147-5.c: Likewise. * gcc.target/aarch64/pr103147-6.c: Likewise. * gcc.target/aarch64/pr103147-7.c: Likewise. * gcc.target/aarch64/pr103147-8.c: Likewise. * gcc.target/aarch64/pr103147-9.c: Likewise. * gcc.target/aarch64/pr103147-10.c: Likewise. * g++.target/aarch64/pr103147-1.C: Likewise. * g++.target/aarch64/pr103147-2.C: Likewise. * g++.target/aarch64/pr103147-3.C: Likewise. * g++.target/aarch64/pr103147-4.C: Likewise. * g++.target/aarch64/pr103147-5.C: Likewise. * g++.target/aarch64/pr103147-6.C: Likewise. * g++.target/aarch64/pr103147-7.C: Likewise. * g++.target/aarch64/pr103147-8.C: Likewise. * g++.target/aarch64/pr103147-9.C: Likewise. * g++.target/aarch64/pr103147-10.C: Likewise.
[Bug c++/103852] [10/11/12 Regression] Alias template argument deduction is available in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103852 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- GCC 12 will give a pedwarn about the testcase. Not backporting.
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 Bug 94404 depends on bug 103852, which changed state. Bug 103852 Summary: [10/11/12 Regression] Alias template argument deduction is available in C++17 mode https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103852 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/104897] wrong plural form in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104897 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 Bug 104552 depends on bug 104897, which changed state. Bug 104897 Summary: wrong plural form in diagnostic https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104897 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103147 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug c++/103329] [11/12 Regression] Code divergence in debug info with -fdump-tree-original since r11-291-g0f50f6daa140186a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103329 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162 --- Comment #1 from Sebastian Pop --- Also happens when compiling with LSE: -march=armv8.1-a or later.
[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162 --- Comment #2 from Sebastian Pop --- Created attachment 52750 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52750&action=edit patch Fix.
[Bug tree-optimization/105163] ICE: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105163 --- Comment #2 from Jakub Jelinek --- #c0 started to ICE with r0-122928-gf6b64c35014ca111711e753be85bb99280a1e115 #c1 as well if you don't omit the argument name.
[Bug tree-optimization/105163] [9/10/11/12 Regression] ICE: SSA corruption since r0-122928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105163 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-04-05 Ever confirmed|0 |1 Target Milestone|--- |9.5 CC||jakub at gcc dot gnu.org Summary|ICE: SSA corruption |[9/10/11/12 Regression] ||ICE: SSA corruption since ||r0-122928 Priority|P3 |P2 Status|UNCONFIRMED |NEW
[Bug c++/105169] New: Compiling C++ code with -fpatchable-function-entry=16,14 results in references to discarded sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105169 Bug ID: 105169 Summary: Compiling C++ code with -fpatchable-function-entry=16,14 results in references to discarded sections Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: giuliano.belinassi at gmail dot com Target Milestone: --- Created attachment 52751 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52751&action=edit Small project to reproduce claimed failure. Compiling the attached project running `make` results in the following messages from ld (GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.37.20211103-7.26): `.text._ZN21WinsockInterfaceClass12Get_ProtocolEv' referenced in section `__patchable_function_entries' of wsproto.o: defined in discarded section `.text._ZN21WinsockInterfaceClass12Get_ProtocolEv[_ZN21WinsockInterfaceClass12Get_ProtocolEv]' of wsproto.o The project compiles fine without -fpatchable-function-entry. PS: I could not manage to reduce the testcase into a single file.
[Bug ipa/105166] [12 Regression] ICE in ao_ref_init_from_ptr_and_range, at tree-ssa-alias.cc:863 since r12-5244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105166 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |12.0 Priority|P3 |P1 Status|UNCONFIRMED |NEW Component|c |ipa CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2022-04-05 Ever confirmed|0 |1 Summary|[12 Regression] ICE in |[12 Regression] ICE in |ao_ref_init_from_ptr_and_ra |ao_ref_init_from_ptr_and_ra |nge, at |nge, at |tree-ssa-alias.cc:863 |tree-ssa-alias.cc:863 since ||r12-5244 --- Comment #1 from Jakub Jelinek --- Started with r12-5244-g64f3e71c302b4a13e61656ee509e7050b9bce978
[Bug ipa/105166] [12 Regression] ICE in ao_ref_init_from_ptr_and_range, at tree-ssa-alias.cc:863 since r12-5244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105166
--- Comment #2 from Jakub Jelinek ---
Testcase without warnings:
void
bar (foo, a)
void (**foo) ();
int a;
{
(foo)[1] = bar;
foo[1] (1);
}
[Bug fortran/104812] Construct-name with same variable name in scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104812 --- Comment #6 from Mike K. --- Thanks a lot for the guidance, posted patch.
[Bug fortran/105138] [7,8,9,10,11,12,F95] Bogus error when function name does not shadow an intrinsic when RESULT clause is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138 --- Comment #12 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d46685b04071a485b56de353d997a866bfc8caba commit r12-8002-gd46685b04071a485b56de353d997a866bfc8caba Author: Harald Anlauf Date: Mon Apr 4 20:42:51 2022 +0200 Fortran: a RECURSIVE procedure cannot be an INTRINSIC gcc/fortran/ChangeLog: PR fortran/105138 * intrinsic.cc (gfc_is_intrinsic): When a symbol refers to a RECURSIVE procedure, it cannot be an INTRINSIC. gcc/testsuite/ChangeLog: PR fortran/105138 * gfortran.dg/recursive_reference_3.f90: New test. Co-authored-by: Steven G. Kargl
[Bug fortran/104210] [11/12 Regression] ICE in gfc_zero_size_array, at fortran/arith.cc:1685 since r11-1814-gcc9a9229285a26ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104210 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:892c7f03ae63121766a8be48f7e3b672547fd627 commit r12-8003-g892c7f03ae63121766a8be48f7e3b672547fd627 Author: Harald Anlauf Date: Tue Mar 29 23:33:23 2022 +0200 Fortran: improve error recovery for invalid coarray function declarations gcc/fortran/ChangeLog: PR fortran/104210 * arith.cc (eval_intrinsic): Avoid NULL pointer dereference. (gfc_zero_size_array): Likewise. gcc/testsuite/ChangeLog: PR fortran/104210 * gfortran.dg/pr104210.f90: New test.
[Bug fortran/104210] [11 Regression] ICE in gfc_zero_size_array, at fortran/arith.cc:1685 since r11-1814-gcc9a9229285a26ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104210 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[11/12 Regression] ICE in |[11 Regression] ICE in |gfc_zero_size_array, at |gfc_zero_size_array, at |fortran/arith.cc:1685 since |fortran/arith.cc:1685 since |r11-1814-gcc9a9229285a26ac |r11-1814-gcc9a9229285a26ac --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12 so far.
[Bug fortran/105138] [7,8,9,10,11,F95] Bogus error when function name does not shadow an intrinsic when RESULT clause is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[7,8,9,10,11,12,F95] Bogus |[7,8,9,10,11,F95] Bogus |error when function name|error when function name |does not shadow an |does not shadow an |intrinsic when RESULT |intrinsic when RESULT |clause is used |clause is used --- Comment #13 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12 so far.
[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
--- Comment #13 from Andrew Macleod ---
huh, so even after fixing the testcase, ranger is still tripping over this test
case.
uv1ti ashl_v1ti (uv1ti x, unsigned int i)
{
uv1ti _3;
:
_3 = x_1(D) << i_2(D);
return _3;
we have an ssa_name for x_1 with a type of uvlti.
This passes the INTEGRAL_TYPE_P test and an ssa_name is created, but is it
actually a vector_type. This seems to be OK, but being unaware of this, and
having a type which passes the INTEGRAL_TYPE_P (type), I was using
TYPE_PRECISION (type) to find the upper bounds for i_2.
It appears that if VECTOR_TYPE_P (type) is true, then TYPE_PRECISION (type) is
not a valid request? but it silently returns 0 and happily moves on.
As near as I can tell, I am suppose to ask for:
TYPE_PRECISION (TREE_TYPE (type)) when its a VECTOR_TYPE?
IS there a good reason we don't fill in the TYPE_PRECISION field? Or if its
not suppose to be used, then can we trap on it if its passed a vector type? It
seems like the sort of thing that is easy to trip over. Are their other bits
which make VECTOR_TYPE incompatible with scalar INTGERAL_TYPEs that should not
be queried?
[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178 --- Comment #14 from Jakub Jelinek --- INTEGRAL_TYPE_P is only true for scalar integral types (integer, enum and boolean). Do you mean ANY_INTEGRAL_TYPE_P instead which is true also for integral vector and complex types? Anyway, one can use element_precision (type) to query the precision for scalar types and precision of each element (for vector and complex types).
[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167 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 --- Created attachment 52752 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52752&action=edit Patch to fix PR The problem is two-fold. First, there is the infamous NULL pointer dereference in resolve.cc(resolve_variable). Second, if the variable 'n' is implicitly defined and it is in a PROGRAM or MODULE specification part of the scoping unit, it cannot be a variable.
[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167 kargl at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-04-05 Ever confirmed|0 |1 Priority|P3 |P4 Status|UNCONFIRMED |NEW Target Milestone|--- |13.0 --- Comment #3 from kargl at gcc dot gnu.org --- Patch attached.
[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178 --- Comment #15 from Andrew Macleod --- no... we won't process ranges for anything unless it passes supports_type_p (): (INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type))) oh oh oh. Never mind. I see. we are generating a range for i_2, and I'm now using the type of op1... we probably are NOT generating ranges for x_1... but I am looking at its type in this case. Doh! my bad. I shall use element_precision. problem solved. Thanks
[Bug c/105149] [9/10/11/12 Regression] ICE in verify_ssa, at tree-ssa.cc:1211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105149 --- Comment #7 from joseph at codesourcery dot com --- I think it's valid to reject this at compile time (rather than just generating a runtime trap): the "such that the type of a pointer to an object that has the specified type can be obtained simply by postfixing a * to type" can never be satisfied for a function type, even if e.g. a typedef name is used so that postfixing '*' produces valid syntax for the corresponding pointer type, because it still wouldn't be "the type of a pointer to an object".
[Bug target/105139] [12 Regression] GCC produces vmovw instruction with an incorrect argument for -O3 -march=sapphirerapids since r12-6215-g708b87dcb6e48cb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139 --- Comment #7 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:cbc9dd66484a51d450f78ab748a872b939c90c3f commit r12-8004-gcbc9dd66484a51d450f78ab748a872b939c90c3f Author: Uros Bizjak Date: Tue Apr 5 21:03:18 2022 +0200 i386: Fix movv2qi_internal xmm reg to xmm reg move for AVX512FP16 [PR105139] 2022-04-05 Uroš Bizjak gcc/ChangeLog: PR target/105139 * config/i386/mmx.md (*movv2qi_internal): Change insn mode of alternative 5 to HF for TARGET_AVX512FP16. gcc/testsuite/ChangeLog: PR target/105139 * gcc.target/i386/pr105139.c: New test.
[Bug target/105139] [12 Regression] GCC produces vmovw instruction with an incorrect argument for -O3 -march=sapphirerapids since r12-6215-g708b87dcb6e48cb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139 Uroš Bizjak changed: What|Removed |Added CC|uros at gcc dot gnu.org| Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Uroš Bizjak --- Fixed.
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 105139, which changed state. Bug 105139 Summary: [12 Regression] GCC produces vmovw instruction with an incorrect argument for -O3 -march=sapphirerapids since r12-6215-g708b87dcb6e48cb4 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/103329] [11/12 Regression] Code divergence in debug info with -fdump-tree-original since r11-291-g0f50f6daa140186a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103329 --- Comment #5 from Jason Merrill --- Created attachment 52753 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52753&action=edit fix? I can't reproduce this with the top of either the 11 or 12 branches; if you can, does this fix it?
[Bug c++/103329] [11/12 Regression] Code divergence in debug info with -fdump-tree-original since r11-291-g0f50f6daa140186a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103329 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug fortran/105168] [9/10/11/12 Regression] ICE in gfc_maybe_dereference_var, at fortran/trans-expr.cc:2870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105168 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P4 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100155 Last reconfirmed||2022-04-05 --- Comment #1 from anlauf at gcc dot gnu.org --- Likely related to pr100155 or a duplicate.
[Bug tree-optimization/24021] VRP does not work with floating points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021 --- Comment #19 from Andrew Macleod --- We can use the original testcase as the litmus test for basic support if we compile it with -O2 -fno-tree-fre -fno-tree-dominator-opts The unroller will unroll the loop and the VRP2 pass will be presented with: [local count: 97603129]: i_1 = 1.100149011611438876201418679556809365749359130859375e-1; i_17 = i_1 + 1.0001490116119384765625e-1; i_22 = i_17 + 1.0001490116119384765625e-1; i_27 = i_22 + 1.0001490116119384765625e-1; i_32 = i_27 + 1.0001490116119384765625e-1; i_37 = i_32 + 1.0001490116119384765625e-1; i_42 = i_37 + 1.0001490116119384765625e-1; i_47 = i_42 + 1.0001490116119384765625e-1; i_52 = i_47 + 1.0001490116119384765625e-1; if (i_52 == 0.0) goto ; [50.00%] else goto ; [50.00%] [local count: 48801565]: [local count: 97603129]: # lastPoint_12 = PHI return lastPoint_12; Which is we can track floating point ranges in VRP and simplification, recognize that i_52 != 0.0 and VRP2 should be able to resolve this to return 2.0e+0;
[Bug c++/102593] [10/11/12 Regression] ICE in cp_oacc_check_attachments, at cp/semantics.c:6561 since r10-5596-g519d7496beac32c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102593 Jason Merrill changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jason Merrill --- I'm not entirely clear on the restrictions on the var-list argument, but "t.a" can't be valid: "t" is a type, not an expression. cp_parser_omp_var_list_no_open mysteriously goes out of its way to accept it anyway: if (identifier_p (name)) decl = cp_parser_lookup_name_simple (parser, name, token->location); this lookup will return any kind of decl. I don't know what this code is trying to allow, but the effect is to build a nonsense COMPONENT_REF which understandably confuses later code.
[Bug fortran/105170] New: Invalid finalization in intrinsic assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105170 Bug ID: 105170 Summary: Invalid finalization in intrinsic assignment Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: baradi09 at gmail dot com Target Milestone: --- Created attachment 52754 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52754&action=edit Minimal working example demonstrating the bug I have a derived type (TWrapper), which has a component with defined assignment. The containing derived type itself has no defined assignment. Upon an assignment between two TWrapper instances, a copy of the RHS seems to get finalized. The attached MWE demonstrates the problem. Expected output (as delivered by current Intel and NAG compilers): RefCounter_final, id:0 TRefCounter_init: id:42 -> Assignment wrapper2 = wrapper TRefCounter_final, id:0 TRefCounter_final, id:0 TRefCounter_assign: this%id, other%id: 0 42 GFortran output: TRefCounter_final, id:0 TRefCounter_init: id:42 -> Assignment wrapper2 = wrapper TRefCounter_final, id:42 TRefCounter_assign: this%id, other%id: 0 42 One finalization seems to be missing. Additionally, the finalized instance seems to be a copy of the RHS. (A copy, because after the finalization, the RHS still seems to have kept its id-value...)
[Bug c++/100608] [10/11/12 Regression] -Wshadow=compatible-local false positive: function local type declaration shadows variable of different type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100608 Jason Merrill changed: What|Removed |Added Depends on||92024 Last reconfirmed||2022-04-05 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED CC||edlinger at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jason Merrill --- This was changed by the patch for PR92024. In the comment for that patch, Bernd wrote "I think shadowing one type with another type of the same name is always a no no" but then warns if either old or new decl is a type. I think a type and a non-type can't really be considered compatible. Testing a patch. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92024 [Bug 92024] crash in check_local_shadow
[Bug ipa/105160] [12 regression] ipa modref marks functions with asm volatile as const or pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160
--- Comment #5 from Jan Hubicka ---
It is indeed missing logic to merge the side_effect and nondeterministic flag
while updating after inlining. I am testing the following
diff --git a/gcc/ipa-modref.cc b/gcc/ipa-modref.cc
index acfd7d80ff8..556816ab429 100644
--- a/gcc/ipa-modref.cc
+++ b/gcc/ipa-modref.cc
@@ -5281,6 +5281,29 @@ ipa_merge_modref_summary_after_inlining (cgraph_edge
*edge)
if (!ignore_stores)
to_info_lto->stores->collapse ();
}
+ /* Merge side effects and non-determinism.
+ PURE/CONST flags makes functions deterministic and if there is
+ no LOOPING_CONST_OR_PURE they also have no side effects. */
+ if (!(flags & (ECF_CONST | ECF_NOVOPS | ECF_PURE))
+ || (flags & ECF_LOOPING_CONST_OR_PURE))
+{
+ if (to_info)
+ {
+ if (!callee_info || callee_info->side_effects)
+ to_info->side_effects = true;
+ if ((!callee_info || callee_info->nondeterministic)
+ && !ignore_nondeterminism_p (edge->caller->decl, flags))
+ to_info->nondeterministic = true;
+ }
+ if (to_info_lto)
+ {
+ if (!callee_info_lto || callee_info_lto->side_effects)
+ to_info_lto->side_effects = true;
+ if ((!callee_info_lto || callee_info_lto->nondeterministic)
+ && !ignore_nondeterminism_p (edge->caller->decl, flags))
+ to_info_lto->nondeterministic = true;
+ }
+ }
if (callee_info || callee_info_lto)
{
auto_vec parm_map;
[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162 Sebastian Pop changed: What|Removed |Added Attachment #52750|0 |1 is obsolete|| --- Comment #3 from Sebastian Pop --- Created attachment 52755 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52755&action=edit patch LSE atomics do not need a barrier. Updated the patch to only generate the barriers after outline-atomics calls.
[Bug c++/105164] new warning in clang, missing in gcc: -Wbitwise-instead-of-logical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105164 --- Comment #1 from David Binderman --- Interestingly, I tried a build of gcc trunk with the new clang-14 and got many cases of this warning. $ grep "warning:.*Wbitwise-instead-of-logical" mk.out | sort | uniq -c > /tmp/0 $ wc -l /tmp/0 16 /tmp/0 $ cat /tmp/0 1 :184:13: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/c-family/c-attribs.cc:2384:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/cp/decl.cc:11850:7: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 2 ../../trunk.git/gcc/cp/lex.cc:124:24: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/cp/lex.cc:571:11: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/cp/module.cc:16843:11: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/cp/name-lookup.cc:7528:12: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/cp/parser.cc:883:11: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 51 ../../trunk.git/gcc/function-abi.h:177:13: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 49 ../../trunk.git/gcc/function-abi.h:184:13: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/function-abi.h../../trunk.git/gcc/loop-unroll.cc::1841750::1319:: warning: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds] 1 ../../trunk.git/gcc/gimple-ssa-sprintf.cc:1225:19: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/gimple-ssa-sprintf.cc:1664:12: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/rtl.h:../../trunk.git/gcc/function-abi.h:184:13: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 :../../trunk.git/gcc/rtl.h warning: :use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]1237 5 ../../trunk.git/gcc/rtl-ssa/internals.inl:436:25: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] On the evidence of the source code of gcc, this new clang warning might be worth implementing in gcc.
[Bug ipa/104303] [12 regression] gnatmake is miscompiled by IPA/modref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104303
--- Comment #6 from Jan Hubicka ---
OK, tree-ssa-alias is using:
if (ref_may_access_global_memory_p (ref))
to determine if the access to S9b.6_22 may be used by the call. I expected
this to return true because memory pointed to S9b.6_22 is escaping and thus it
is accessible from global memory accesses.
However the implementation does:
/* Return ture if REF may access global memory. */
bool
ref_may_access_global_memory_p (ao_ref *ref)
{
if (!ref->ref)
return true;
tree base = ao_ref_base (ref);
if (TREE_CODE (base) == MEM_REF
|| TREE_CODE (base) == TARGET_MEM_REF)
{
if (ptr_deref_may_alias_global_p (TREE_OPERAND (base, 0)))
return true;
}
else
{
if (!auto_var_in_fn_p (base, current_function_decl)
|| pt_solution_includes (&cfun->gimple_df->escaped,
base))
return true;
}
return false;
}
so for automatic variables we check "escaped" flag, but since this is heap
alocated we go the ptr_deref_may_alias_global_p path which checks:
/* Return true, if dereferencing PTR may alias with a global variable. */
bool
ptr_deref_may_alias_global_p (tree ptr)
{
struct ptr_info_def *pi;
/* If we end up with a pointer constant here that may point
to global memory. */
if (TREE_CODE (ptr) != SSA_NAME)
return true;
pi = SSA_NAME_PTR_INFO (ptr);
/* If we do not have points-to information for this variable,
we have to punt. */
if (!pi)
return true;
/* ??? This does not use TBAA to prune globals ptr may not access. */
return pt_solution_includes_global (&pi->pt);
}
So this predicate tests something different - it tests if the deref can alias
global variable, not global memory in a sense of anything accessible from
outside world.
So I want to also return true on points to set that contains escaped?
diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
index 50bd47b31f3..9e34f76c3cb 100644
--- a/gcc/tree-ssa-alias.cc
+++ b/gcc/tree-ssa-alias.cc
@@ -2578,8 +2578,24 @@ ref_may_access_global_memory_p (ao_ref *ref)
if (TREE_CODE (base) == MEM_REF
|| TREE_CODE (base) == TARGET_MEM_REF)
{
- if (ptr_deref_may_alias_global_p (TREE_OPERAND (base, 0)))
+ struct ptr_info_def *pi;
+ tree ptr = TREE_OPERAND (base, 0);
+
+ /* If we end up with a pointer constant here that may point
+to global memory. */
+ if (TREE_CODE (ptr) != SSA_NAME)
+ return true;
+
+ pi = SSA_NAME_PTR_INFO (ptr);
+
+ /* If we do not have points-to information for this variable,
+we have to punt. */
+ if (!pi)
return true;
+
+ /* ??? This does not use TBAA to prune globals ptr may not access. */
+ return pt_solution_includes_global (&pi->pt)
+|| pi->pt.vars_contains_escaped;
}
else
{
[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894 Peter Bergner changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Status|NEW |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2022-April/5 ||92808.html
