[Bug tree-optimization/94021] -Wformat-truncation false positive due to excessive integer range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94021 --- Comment #10 from ishikawa,chiaki --- It would be great if the problem is fixed in later versions. I observe the error with gcc-12 on my computer yet. *BUT* compiling with -O instead of -O2 succeeds !? gcc-12 version. gcc-12 (Debian 12.2.0-14) 12.2.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. No error with -O !? ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ gcc-12 -c -O -Wall /tmp/pr94021.c Error with -O2 as before. ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ gcc-12 -c -O2 -Wall /tmp/pr94021.c /tmp/pr94021.c: In function ‘format_utc_offset’: /tmp/pr94021.c:14:45: warning: ‘%02i’ directive output may be truncated writing 2 bytes into a region of size between 1 and 5 [-Wformat-truncation=] 14 | __builtin_snprintf (a, sizeof a, "%s%02i%02i", "+", h, m); | ^~~~ /tmp/pr94021.c:14:38: note: directive argument in the range [0, 59] 14 | __builtin_snprintf (a, sizeof a, "%s%02i%02i", "+", h, m); | ^~~~ /tmp/pr94021.c:14:5: note: ‘__builtin_snprintf’ output between 6 and 10 bytes into a destination of size 8 14 | __builtin_snprintf (a, sizeof a, "%s%02i%02i", "+", h, m); | ^ ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$
[Bug target/109508] [13 Regression] ICE: in extract_insn, at recog.cc:2791 with -mcpu=sifive-s76 on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109508 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org Priority|P3 |P4 --- Comment #1 from Jeffrey A. Law --- Trivial issue in the riscv backend. We just need to fix the operand on the movXXcc pattern.
[Bug fortran/105800] Segfault deallocating a class, dimension(:) array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105800 --- Comment #1 from martin --- Created attachment 54856 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54856=edit fixed testcase class_dealloc.f90 As I just see, the first attachment does not show the bug as return value "a" of function create is declared as "class(t), dimension(:), pointer". And as described in the initial report, with class instead of type, there is no error. The fixed attachment declares "a" as "type(t), dimension(:), pointer". This shows the described error. It is still present in the current 13 development branch.
[Bug target/109508] [13 Regression] ICE: in extract_insn, at recog.cc:2791 with -mcpu=sifive-s76 on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109508 Jeffrey A. Law changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-04-14 Status|UNCONFIRMED |NEW
[Bug analyzer/103602] [11/12/13 regression] Analyzer takes excessive amount of memory and time linking GNU grep with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103602 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug middle-end/103637] [12/13 Regression] missing warning writing past the end of one of multiple elements of the same array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103637 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug rtl-optimization/103829] [10/11/12/13 Regression] missing shrink wrapping for simple/obvious code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103829 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug target/109508] New: [13 Regression] ICE: in extract_insn, at recog.cc:2791 with -mcpu=sifive-s76 on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109508 Bug ID: 109508 Summary: [13 Regression] ICE: in extract_insn, at recog.cc:2791 with -mcpu=sifive-s76 on riscv64 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: riscv64-unknown-linux-gnu Created attachment 54855 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54855=edit reduced testcase Compiler output: $ riscv64-unknown-linux-gnu-gcc -mcpu=sifive-s76 testcase.c testcase.c: In function 'foo': testcase.c:9:1: error: unrecognizable insn: 9 | } | ^ (insn 16 15 17 2 (set (reg:DI 146) (if_then_else:DI (ne:DI (reg:DI 147) (const_int 0 [0])) (const_int 0 [0]) (const_int 6 [0x6]))) -1 (nil)) during RTL pass: vregs testcase.c:9:1: internal compiler error: in extract_insn, at recog.cc:2791 0x7a1b18 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.cc:108 0x7a1b94 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.cc:116 0x7932ca extract_insn(rtx_insn*) /repo/gcc-trunk/gcc/recog.cc:2791 0xd1ae6f instantiate_virtual_regs_in_insn /repo/gcc-trunk/gcc/function.cc:1611 0xd1ae6f instantiate_virtual_regs /repo/gcc-trunk/gcc/function.cc:1985 0xd1ae6f execute /repo/gcc-trunk/gcc/function.cc:2034 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ riscv64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-7168-20230413170248-ga1afdc6e2aa-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/13.0.1/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-isa-spec=2.2 --with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu --with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld --with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-7168-20230413170248-ga1afdc6e2aa-checking-yes-rtl-df-extra-riscv64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.1 20230413 (experimental) (GCC)
[Bug analyzer/107943] [11/12/13 Regression] gcc -fanalyzer hangs in openssl curve25519.c since r11-3840-gaf66094d03779377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug analyzer/109027] [13 Regression] ICE: SIGSEGV (infinite recursion in ana::constraint_manager::eval_condition / ana::constraint_manager::impossible_derived_conditions_p) with -fanalyzer since r13-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109027 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug analyzer/108722] gcc.dg/analyzer/file-CWE-1341-example.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108722 --- Comment #3 from CVS Commits --- The master branch has been updated by Jiu Fu Guo : https://gcc.gnu.org/g:edc6659c97c4a747123b1150b372dc8e7a83a824 commit r13-7176-gedc6659c97c4a747123b1150b372dc8e7a83a824 Author: Jiufu Guo Date: Wed Apr 12 10:12:58 2023 +0800 testsuite: filter out warning noise for CWE-1341 test The case file-CWE-1341-example.c checkes [CWE-1341](`double-fclose`). While on some systems, besides [CWE-1341], a message of [CWE-415] is also reported. On those systems, attribute `malloc` may be attached on fopen: ``` # 258 "/usr/include/stdio.h" 3 4 extern FILE *fopen (const char *__restrict __filename, const char *__restrict __modes) __attribute__ ((__malloc__)) __attribute__ ((__malloc__ (fclose, 1))) ; or say: __attribute_malloc__ __attr_dealloc_fclose __wur; ``` See (PR analyzer/108722) for future fix in the analyzer. This workaround patch adds -Wno-analyzer-double-free to this case. gcc/testsuite/ChangeLog: PR analyzer/108722 * gcc.dg/analyzer/file-CWE-1341-example.c: Update.
[Bug tree-optimization/109502] [12/13 Regression] wrong code with -O -ftree-vectorize -fvect-cost-model=unlimited on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109502
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> SLP transforms:
>
> g.0_1 = g;
> _2 = g.0_1 == 0;
> a_7 = (unsigned int) _2;
> _3 = a_7 % 6;
> _4 = _3 == 0;
> _5 = (unsigned int) _4;
> a_8 = _5 + a_7;
>
> To:
>
> g.0_1 = g;
> _2 = g.0_1 == 0;
> a_7 = (unsigned int) _2;
> _3 = a_7 % 6;
> _15 = {_3, g.0_1};
> mask__4.4_16 = { 0, 0 } == _15;
> vect__5.5_19 = VIEW_CONVERT_EXPR(mask__4.4_16);
> _17 = BIT_FIELD_REF ;
> _18 = (bool) _17;
> _4 = _3 == 0;
> _5 = (unsigned int) _18;
> _20 = .REDUC_PLUS (vect__5.5_19);
> a_8 = _20;
>
If anything there is a missing, a negative after the
reduc_plus (or before) when it translates the bools comparisons into vector
comparisons.
[Bug tree-optimization/109502] [12/13 Regression] wrong code with -O -ftree-vectorize -fvect-cost-model=unlimited on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109502
Andrew Pinski changed:
What|Removed |Added
Component|target |tree-optimization
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-04-14
--- Comment #1 from Andrew Pinski ---
SLP transforms:
g.0_1 = g;
_2 = g.0_1 == 0;
a_7 = (unsigned int) _2;
_3 = a_7 % 6;
_4 = _3 == 0;
_5 = (unsigned int) _4;
a_8 = _5 + a_7;
To:
g.0_1 = g;
_2 = g.0_1 == 0;
a_7 = (unsigned int) _2;
_3 = a_7 % 6;
_15 = {_3, g.0_1};
mask__4.4_16 = { 0, 0 } == _15;
vect__5.5_19 = VIEW_CONVERT_EXPR(mask__4.4_16);
_17 = BIT_FIELD_REF ;
_18 = (bool) _17;
_4 = _3 == 0;
_5 = (unsigned int) _18;
_20 = .REDUC_PLUS (vect__5.5_19);
a_8 = _20;
Which is wrong. The if anything there is a missing - missing after the
reduc_plus (or before) when it translates the bools comparisons into vector
comparisons.
[Bug target/109502] [12/13 Regression] wrong code with -O -ftree-vectorize -fvect-cost-model=unlimited on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109502 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.3
[Bug c/109507] Optimizer creates incorrect program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109507 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- -fsanitize=undefined, at runtime gives: /app/example.cpp:4:7: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself Note the message is slightly wrong but points you to the right reason. There is an overflow. because ~0x8000 is 2147483648 and then you add 1 to it giving you an overflow which is undefined. Note ~a+1 is the same as -a as both cases will overflow at the same time with 0x8000 which is why GCC is providing that error message rather then on dealing with +1 like clang does: Note clang gives: /app/example.cpp:4:15: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
[Bug c/109507] Optimizer creates incorrect program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109507 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- UBSAN with GCC: ``` $ /tmp/foo /tmp/foo.c:4:7: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself 0 ``` UBSAN with Clang: ``` /tmp/foo.c:4:15: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /tmp/foo.c:4:15 in 0 ```
[Bug c/109507] New: Optimizer creates incorrect program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109507 Bug ID: 109507 Summary: Optimizer creates incorrect program Product: gcc Version: 12.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: aran at 100acres dot us Target Milestone: --- Created attachment 54854 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54854=edit Example program. The attached program should print 0 and does with optimization level zero (0). However, with optimization at any non-zero value (e.g., g, s, 1, 2) it prints 1. This is on an Intel I7-2600. The code that the optimizer writes reduces to a single test instruction that checks if x is less or equal to zero. However, this is incorrect for the most negative number. To reproduce compile the attached file with -O0 and with -O1.
[Bug c++/109506] [10/11/12/13 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109506 --- Comment #8 from Andrew Pinski --- build_non_dependent_expr has the only code which does: flag_checking > 1
[Bug c++/109506] [10/11/12/13 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109506 --- Comment #7 from Andrew Pinski --- >This works with 12 and Arsen reports that an earlier 13 is ok, but not had a >chance to bisect yet. Just a quick note on why Arsen could not reproduce it in an earlier 13, he was using --enable-checking=yes .
[Bug c++/109506] [10/11/12/13 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109506 Andrew Pinski changed: What|Removed |Added Summary|[13 regression] 'error: |[10/11/12/13 regression] |inlining failed in call to |-fchecking=2 causes some |‘always_inline’ |template constructor not be |‘foo::foo() [with T =|instantiated when used with |void]’: function body not |NSDMI |available' | Target Milestone|13.0|10.5 Known to fail||12.2.0 Known to work|12.2.0 | --- Comment #6 from Andrew Pinski --- >On our box, I bisected this to r251422. Surely that isn't the real cause of >the problem. it is in the end as oh yes adding -fchecking=2 causes the failure in released versions.
[Bug c++/109506] [13 regression] 'error: inlining failed in call to ‘always_inline’ ‘foo::foo() [with T = void]’: function body not available'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109506
--- Comment #5 from Andrew Pinski ---
Even that happens locally:
apinski@xeond:~/src/upstream-gcc$ ./gcc/objdir/gcc/cc1plus t.cc -quiet
t.cc: In constructor ‘constexpr bar::bar()’:
t.cc:3:38: error: inlining failed in call to ‘always_inline’ ‘foo::foo()
[with T = void]’: function body not available
3 | __attribute__((__always_inline__)) foo() {};
| ^~~
t.cc:5:29: note: called from here
5 | template class bar {
| ^~~
apinski@xeond:~/src/upstream-gcc$ ./gcc/objdir/gcc/cc1plus t.cc -quiet
-fchecking
[Bug c++/109506] [13 regression] 'error: inlining failed in call to ‘always_inline’ ‘foo::foo() [with T = void]’: function body not available'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109506 --- Comment #4 from Andrew Pinski --- (In reply to Marek Polacek from comment #3) > On our box, I bisected this to r251422. Surely that isn't the real cause of > the problem. It could not be as GCC 12.1.0 definitely works so does GCC 9.1.0. Ok, this is interesting. This fails: /opt/compiler-explorer/gcc-trunk-20230413/bin/../libexec/gcc/x86_64-linux-gnu/13.0.1/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-trunk-20230413/bin/../lib/gcc/x86_64-linux-gnu/13.0.1/ -D_GNU_SOURCE -isystem /opt/compiler-explorer/libs/boost_1_81_0 -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -g -g0 -O0 -version -fdiagnostics-color=always -fdump-passes -fdump-tree-all -fdump-rtl-all -fdump-ipa-all -o /app/output.s But this passes: /opt/compiler-explorer/gcc-trunk-20230413/bin/../libexec/gcc/x86_64-linux-gnu/13.0.1/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-trunk-20230413/bin/../lib/gcc/x86_64-linux-gnu/13.0.1/ -D_GNU_SOURCE -isystem /opt/compiler-explorer/libs/boost_1_81_0 -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -g -g0 -O0 -version -fdiagnostics-color=always -fdump-passes -fdump-tree-all -fdump-rtl-all -fdump-ipa-all -fchecking -o /app/output.s
[Bug c++/109506] [13 regression] 'error: inlining failed in call to ‘always_inline’ ‘foo::foo() [with T = void]’: function body not available'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109506 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- On our box, I bisected this to r251422. Surely that isn't the real cause of the problem.
[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 --- Comment #14 from Roger Sayle --- My apologies for the delay/issues. My bootstrap and regression testing of this patch (on x86_64-pc-linux-gnu) revealed an issue or two (including the reported ICE). My plan was to fix/resolve all these before posting a concrete submission to gcc-patches. The general approach is solid (thanks to everyone that agreed this was the correct place to fix things) but it's the corner cases (such as RTL sharing) that all need to be addressed prior to a reviewable submission.
[Bug c++/109506] [13 regression] 'error: inlining failed in call to ‘always_inline’ ‘foo::foo() [with T = void]’: function body not available'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109506
Andrew Pinski changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #2 from Andrew Pinski ---
Here is an accept invalid testcase:
```
class a
{
a();
};
template
struct foo {
//__attribute__((__always_inline__))
foo() {a b; };
};
template class bar {
foo<2> alloc_{};
};
template
void func1() {
bar<1>();
}
void func2() {
func1<2>();
}
```
[Bug c++/109506] [13 regression] 'error: inlining failed in call to ‘always_inline’ ‘foo::foo() [with T = void]’: function body not available'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109506
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-04-13
Keywords||link-failure, rejects-valid
Known to work||12.2.0
Target Milestone|--- |13.0
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed. This is also a link failure issue:
Take:
```
template
struct foo {
foo() {};
};
template class bar {
foo<2> alloc_{};
};
template
void func1() {
bar<1>();
}
void func2() {
func1<2>();
}
int main()
{
func2();
}
```
This should link and it currently fails for the same reason as the
always_inline too.
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 --- Comment #7 from Steve Kargl --- On Thu, Apr 13, 2023 at 07:44:36PM +, leandro.lupori at linaro dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 > > --- Comment #5 from Leandro Lupori --- > Ok, thanks for the detailed explanations. Now I see that the standard doesn't > allow the return of an unallocated value. This can be closed as invalid. > > But may I just ask a last related question? As mentioned in the last comment > and according to Note 1 in F2018 8.5.3 ALLOCATABLE attribute, the result of > referencing a function cannot be used as an allocatable argument. This is > however allowed by gfortran (and ifort), with the exception of intrinsic > procedures, and seems to work correctly. Should this be considered an > extension > or does it just work by accident and there are no guarantees at all when using > it? > I suspect it works by accident, but I don't have enough time at the moment to go read the gfortran source. What is likely happening is gfortran checks that the actual and dummy argument both have the allocatable attribute. For the actual argument, the symbol is probably marked an allocatable attribute and an internal attribute that designates this as a function-result, and gfortran does not check for the latter.
[Bug c++/109506] New: [13 regression] 'error: inlining failed in call to ‘always_inline’ ‘foo::foo() [with T = void]’: function body not available'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109506
Bug ID: 109506
Summary: [13 regression] 'error: inlining failed in call to
‘always_inline’ ‘foo::foo() [with T = void]’:
function body not available'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
```
$ cat /tmp/foo.cxx
template struct foo {
__attribute__((__always_inline__)) foo() {};
};
template class bar {
foo alloc_ {};
};
template
void func1(A &&...) {
bar();
}
void func2() {
func1();
}
$ g++ -c -std=c++20 /tmp/foo.cxx
/tmp/foo.cxx: In constructor ‘constexpr bar::bar()’:
/tmp/foo.cxx:2:38: error: inlining failed in call to ‘always_inline’
‘foo::foo() [with T = void]’: function body not available
2 | __attribute__((__always_inline__)) foo() {};
| ^~~
/tmp/foo.cxx:4:29: note: called from here
4 | template class bar {
| ^~~
$ g++ --version
g++ (Gentoo Hardened 13.0.1_pre20230409-r4 p9) 13.0.1 20230409 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```
It compiles if the template on func1 is removed.
This works with 12 and Arsen reports that an earlier 13 is ok, but not had a
chance to bisect yet.
[Bug target/109504] Compilation fails with pragma GCC target sse4.1 and immintrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109504
Andrew Pinski changed:
What|Removed |Added
Target||i686-linux-gnu
Keywords||rejects-valid
--- Comment #1 from Andrew Pinski ---
testcae:
```
#pragma GCC target("sse4.1")
#include
int main(){return 0;}
```
Works on x86_64-linux-gnu with `-m32 -march=i686 -mno-sse`
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Leandro Lupori from comment #5) > Ok, thanks for the detailed explanations. Now I see that the standard > doesn't allow the return of an unallocated value. This can be closed as > invalid. > > But may I just ask a last related question? As mentioned in the last comment > and according to Note 1 in F2018 8.5.3 ALLOCATABLE attribute, the result of > referencing a function cannot be used as an allocatable argument. The precise text is: "... The result of referencing a function whose result variable has the ALLOCATABLE attribute is a value that does not itself have the ALLOCATABLE attribute." So you can add e.g. allocate (f, source=42) to the body of f to define the result, and then use it as e.g. integer, allocatable :: p p = f() print *, allocated (p) I am still trying to find the exact place in the standard that explains whether - with the corrected f - the following is legal: print *, is_allocated(f()) > This is > however allowed by gfortran (and ifort), with the exception of intrinsic > procedures, and seems to work correctly. Should this be considered an > extension or does it just work by accident and there are no guarantees at > all when using it? I think we are in dangerous waters here. If something appears to work empirically with one compiler, that does not guarantee anything. So as already discussed, if the allocation status of the result cannot be guaranteed, better use a subroutine.
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183
Andrew Pinski changed:
What|Removed |Added
Version|unknown |11.1.0
--- Comment #12 from Andrew Pinski ---
This what the gcc.cc includes:
%{MD:-MD %{!o:%b.d}%{o*:%.d%*}}\
%{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}}\
+ %b substitute the basename for outputs related with the input file
+ being processed. This is often a substring of the input file name,
+ up to (and not including) the last period but, unless %w is active,
+ it is affected by the directory selected by -save-temps=*, by
+ -dumpdir, and, in case of multiple compilations, even by -dumpbase
+ and -dumpbase-ext and, in case of linking, by the linker output
+ name. When %w is active, it derives the main output name only from
+ the input file base name; when it is not, it names aux/dump output
+ file.
Anyways this changed with r11-627-g1dedc12d186a11 .
I think it is the correct behavior though.
[Bug c++/109505] Compiler loops forever to OOM while compiling evaluate_prg_hwy.cc in Chromium
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2023-04-13 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Can you provide the information as requested at https://gcc.gnu.org/bugs/ ?
[Bug fortran/109492] gcc/fortran/trans-expr.cc:3407:17: error: call of overloaded ‘abs(long long int&)’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109492 --- Comment #5 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:43816633afd275a9057232a6ebfdc19e441f09ec commit r13-7174-g43816633afd275a9057232a6ebfdc19e441f09ec Author: Harald Anlauf Date: Thu Apr 13 22:42:23 2023 +0200 Fortran: call of overloaded âabs(long long int&)â is ambiguous [PR109492] gcc/fortran/ChangeLog: PR fortran/109492 * trans-expr.cc (gfc_conv_power_op): Use absu_hwi and unsigned HOST_WIDE_INT for portability.
[Bug c++/109420] [13 Regression] lookup of 'struct T::X' at instantiation time does not ignore non-type bindings of 'X' since r13-6098-g46711ff8e60d64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109420 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Patrick Palka --- Fixed.
[Bug c++/109420] [13 Regression] lookup of 'struct T::X' at instantiation time does not ignore non-type bindings of 'X' since r13-6098-g46711ff8e60d64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109420 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:50dc52e853ff267ad1f4c98571c262017b0536f8 commit r13-7173-g50dc52e853ff267ad1f4c98571c262017b0536f8 Author: Patrick Palka Date: Thu Apr 13 16:02:21 2023 -0400 c++: 'typename T::X' vs 'struct T::X' lookup [PR109420] r13-6098-g46711ff8e60d64 made make_typename_type no longer ignore non-types during the lookup, unless the TYPENAME_TYPE in question was followed by the :: scope resolution operator. But there is another exception to this rule: we need to ignore non-types during the lookup also if the TYPENAME_TYPE was named with a tag other than 'typename', such as 'struct' or 'enum', since in that case we're dealing with an elaborated-type-specifier and so [basic.lookup.elab] applies. This patch implements this additional exception. PR c++/109420 gcc/cp/ChangeLog: * decl.cc (make_typename_type): Also ignore non-types during the lookup if tag_type corresponds to an elaborated-type-specifier. * pt.cc (tsubst) : Pass class_type or enum_type as tag_type to make_typename_type accordingly instead of always passing typename_type. gcc/testsuite/ChangeLog: * g++.dg/template/typename27.C: New test.
[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931 --- Comment #15 from Bernhard Reutner-Fischer --- (In reply to Bernhard Reutner-Fischer from comment #13) > I'm testing a patch. I have to admit that this is a mess. It's even more frustrating now as i did some preparatory cleanup for at least some of the inconveniences in that area a while ago but never got to apply these. Anyway. Not sure if the following would be correct: Under the assumption that we have a generic "c_ptr" in a module, we know (?) that "c_ptr" is not ambiguous. Is that right? >From what i see from a quick glance, we seem to write more symbols to the module files than strictly needed, and that does not really help the case. Short of a broader fix, a quick-hack to avoid the error about ambiguous intrinsic built-in symbols might be to (*cough*): --- a/gcc/fortran/module.cc +++ b/gcc/fortran/module.cc @@ -5320,6 +5322,11 @@ check_for_ambiguous (gfc_symtree *st, pointer_info *info) return false; } + /* A symbol from an intrinsic module is not ambiguous. */ + /* This should not be necessary, at least not in this form! */ + if (st_sym->from_intmod != INTMOD_NONE) +return false; + return true; } This works as expected, fixes this specific PR and tests cleanly. Should i propose this workaround as a patch or is it a bit too gross? WDYT?
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 --- Comment #5 from Leandro Lupori --- Ok, thanks for the detailed explanations. Now I see that the standard doesn't allow the return of an unallocated value. This can be closed as invalid. But may I just ask a last related question? As mentioned in the last comment and according to Note 1 in F2018 8.5.3 ALLOCATABLE attribute, the result of referencing a function cannot be used as an allocatable argument. This is however allowed by gfortran (and ifort), with the exception of intrinsic procedures, and seems to work correctly. Should this be considered an extension or does it just work by accident and there are no guarantees at all when using it?
[Bug fortran/109492] gcc/fortran/trans-expr.cc:3407:17: error: call of overloaded ‘abs(long long int&)’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109492 --- Comment #4 from Jonathan Wakely --- (In reply to anlauf from comment #3) > Does the following patch work? It compiles OK on Solaris with gcc-5.5
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 --- Comment #11 from Allan W. Macdonald --- The makefiles I've been maintaining contain a mechanism to make sure that any change in a locally-included file will cause the c file that includes it to be compiled again, like so: ### Extract of makefile: %.d: %.c gcc -MM -MD $< -include $(OBJECTS:.o=.d) ### So, if I understand this correctly (tell me if I'm wrong), preprocessing is performed to generate the .d files before any file is compiled to an object in this situation. These .d files are then included and turned into rules using a substitution reference. The 'a-' prefix breaks this mechanism. The workaround I mentioned, gcc -E -MMD $< > /dev/null seems to achieve the same behaviour but there's probably a better way to do it.
[Bug c++/109505] New: Compiler loops forever to OOM while compiling evaluate_prg_hwy.cc in Chromium
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
Bug ID: 109505
Summary: Compiler loops forever to OOM while compiling
evaluate_prg_hwy.cc in Chromium
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jdapena at igalia dot com
Target Milestone: ---
Steps to reproduce:
1. Install kas tool
2. Clone https://github.com/Igalia/meta-chromium
3. Kick checkout of repositories:
kas checkout kas/chromium.yml:kas/commercial.yml
3. Kick build for raspberrypi4-64:
KAS_MACHINE=raspberrypi4-64 kas build kas/chromium.yml:kas/commercial.yml
Compilation will progress, but then fail on building Chromium:
FAILED:
obj/third_party/distributed_point_functions/distributed_point_functions/evaluate_prg_hwy.o
aarch64-poky-linux-g++ -mcpu=cortex-a72 -march=armv8-a+crc
-fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=format-security
--sysroot=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/recipe-sysroot
-MMD -MF
obj/third_party/distributed_point_functions/distributed_point_functions/evaluate_prg_hwy.o.d
-DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-DNO_UNWIND_TABLES -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
-DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_56
-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_56
-DBASE_USE_PERFETTO_CLIENT_LIBRARY=1 -DGOOGLE_PROTOBUF_NO_RTTI
-DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER
-DGOOGLE_PROTOBUF_INTERNAL_DONATE_STEAL_INLINE=0 -DHAVE_PTHREAD
-I../chromium-114.0.5696.0 -Igen
-I../chromium-114.0.5696.0/third_party/distributed_point_functions
-I../chromium-114.0.5696.0/third_party/distributed_point_functions/code
-Igen/third_party/distributed_point_functions
-I../chromium-114.0.5696.0/third_party/perfetto/include
-Igen/third_party/perfetto/build_config -Igen/third_party/perfetto
-I../chromium-114.0.5696.0/third_party/protobuf/src -Igen/protoc_out
-I../chromium-114.0.5696.0/third_party/abseil-cpp
-I../chromium-114.0.5696.0/third_party/highway/src
-I../chromium-114.0.5696.0/third_party/boringssl/src/include -fno-ident
-fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector
-fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pipe -pthread
-mbranch-protection=standard -O2 -fdata-sections -ffunction-sections
-fno-omit-frame-pointer -gdwarf-4 -g1 -fvisibility=hidden
-Wno-unused-local-typedefs -Wno-maybe-uninitialized
-Wno-deprecated-declarations -Wno-comments -Wno-packed-not-aligned
-Wno-missing-field-initializers -Wno-unused-parameter -Wno-psabi
-I/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/recipe-sysroot/usr/include/glib-2.0
-I/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/recipe-sysroot/usr/lib/glib-2.0/include
-std=gnu++2a -fno-exceptions -fno-rtti -fvisibility-inlines-hidden
-Wno-narrowing -Wno-class-memaccess -feliminate-unused-debug-types
-fmacro-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/chromium-114.0.5696.0=/usr/src/debug/chromium-dev/114.0.5696.0-r0
-fdebug-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/chromium-114.0.5696.0=/usr/src/debug/chromium-dev/114.0.5696.0-r0
-fmacro-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/build=/usr/src/debug/chromium-dev/114.0.5696.0-r0
-fdebug-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/build=/usr/src/debug/chromium-dev/114.0.5696.0-r0
-fdebug-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/recipe-sysroot=
-fmacro-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/recipe-sysroot=
-fdebug-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/recipe-sysroot-native=
-fvisibility-inlines-hidden -c
../chromium-114.0.5696.0/third_party/distributed_point_functions/code/dpf/internal/evaluate_prg_hwy.cc
-o
obj/third_party/distributed_point_functions/distributed_point_functions/evaluate_prg_hwy.o
{standard input}: Assembler messages:
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
aarch64-poky-linux-g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
ninja: build stopped: subcommand failed.
WARNING: exit code 1 from a shell command.
This is after exhausting all the
[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109277 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Jason Merrill --- Chromium can now use -fpermissive to make this code compile. But better to fix the code, of course.
[Bug fortran/109492] gcc/fortran/trans-expr.cc:3407:17: error: call of overloaded ‘abs(long long int&)’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109492
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #3 from anlauf at gcc dot gnu.org ---
There is no unsigned integer type in Fortran, so anything that is done to
solve this should be fine.
Does the following patch work?
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 79367fa2ae0..09cdd9263c4 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -3400,11 +3400,12 @@ gfc_conv_power_op (gfc_se * se, gfc_expr * expr)
&& TREE_CODE (TREE_TYPE (rse.expr)) == INTEGER_TYPE)
{
wi::tree_to_wide_ref wlhs = wi::to_wide (lse.expr);
- HOST_WIDE_INT v, w;
+ HOST_WIDE_INT v;
+ unsigned HOST_WIDE_INT w;
int kind, ikind, bit_size;
v = wlhs.to_shwi ();
- w = abs (v);
+ w = absu_hwi (v);
kind = expr->value.op.op1->ts.kind;
ikind = gfc_validate_kind (BT_INTEGER, kind, false);
It works here on x86_64-pc-linux-gnu.
If this fixes the reported issue on Solaris, it is approved.
[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109277 --- Comment #13 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:f32f7881fb0db085479525b5a23db5dabd990c3b commit r13-7172-gf32f7881fb0db085479525b5a23db5dabd990c3b Author: Jason Merrill Date: Mon Apr 3 23:20:13 2023 -0400 c++: make trait of incomplete type a permerror [PR109277] An incomplete type argument to several traits is specified to be undefined behavior in the library; since it's a compile-time property, we diagnose it. But apparently some code was relying on the previous behavior of not diagnosing. So let's make it a permerror. The assert in cxx_incomplete_type_diagnostic didn't like that, and I don't see the point of having the assert, so let's just remove it. PR c++/109277 gcc/cp/ChangeLog: * semantics.cc (check_trait_type): Handle incomplete type directly. * typeck2.cc (cxx_incomplete_type_diagnostic): Remove assert. gcc/testsuite/ChangeLog: * g++.dg/ext/is_convertible5.C: New test.
[Bug c/109504] New: Compilation fails with pragma GCC target sse4.1 and immintrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109504
Bug ID: 109504
Summary: Compilation fails with pragma GCC target sse4.1 and
immintrin.h
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vd.kraats at hccnet dot nl
Target Milestone: ---
Problem occurs at Debian Bookworm (Testing) i686 (32 bit).
debian:~$ cat test.c
#pragma GCC target(sse4.1)
#include immintrin.h
int main(){return 0;}
debian:~$ gcc -v test.c 21 | head -100
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/12/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion=Debian
12.2.0-14 --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=i686-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-targets=all
--enable-multiarch --disable-werror --with-arch-32=i686
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
--target=i686-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)
COLLECT_GCC_OPTIONS=-v -mtune=generic
-march=i686 -dumpdir a-
/usr/lib/gcc/i686-linux-gnu/12/cc1 -quiet -v -imultiarch i386-linux-gnu test.c
-quiet -dumpdir a- -dumpbase test.c -dumpbase-ext .c -mtune=generic -march=i686
-version -fasynchronous-unwind-tables -o /tmp/ccvTqsb4.s
GNU C17 (Debian 12.2.0-14) version 12.2.0 (i686-linux-gnu)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.1.1-p1, MPC version 1.3.1, isl version isl-0.25-GMP
warning: MPFR header version 4.1.1-p1 differs from library version 4.2.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory /usr/local/include/i386-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i686-linux-gnu/12/include-fixed
ignoring nonexistent directory
/usr/lib/gcc/i686-linux-gnu/12/../../../../i686-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i686-linux-gnu/12/include
/usr/local/include
/usr/include/i386-linux-gnu
/usr/include
End of search list.
GNU C17 (Debian 12.2.0-14) version 12.2.0 (i686-linux-gnu)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.1.1-p1, MPC version 1.3.1, isl version isl-0.25-GMP
warning: MPFR header version 4.1.1-p1 differs from library version 4.2.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e1e0efc2c04a9ab28e35cf4254d1a7fe
In file included from /usr/lib/gcc/i686-linux-gnu/12/include/immintrin.h:98,
from test.c:2:
/usr/lib/gcc/i686-linux-gnu/12/include/avx512fp16intrin.h:38:9: error:
‘_Float16’ is not supported on this target
38 | typedef _Float16 __v8hf __attribute__ ((__vector_size__ (16)));
This error should not be given.The current target should be sse4.1,
because of the pragma. The error makes cross-compiling with a low target
machine (i686 in this case) not workable.
The error only occurs at gcc-12, not at gcc-11. So this seeems to be
regression. The error disappears if compiling with option -msse2.
This error caused filezilla not being delivered anymore at latest upgrade of
Debian Bookworm.
I wrote bug-request https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034195 .
This problem was noticed before at Debian. But Debian blaimed Filezilla,
and Filezila blaimed Debian/GCC, because nothing was changed in this
area since previous release.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020327 and
https://trac.filezilla-project.org/ticket/12777 .
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 --- Comment #4 from anlauf at gcc dot gnu.org --- I think one cannot achieve what the OP wants by using allocable function results. One should use a subroutine instead. Compiling the code with the NAG compiler gives: NAG Fortran Compiler Release 7.1(Hanzomon) Build 7101 Warning: pr109500.f90, line 7: Allocatable function F has not been allocated or assigned a value Error: pr109500.f90, line 2: Expected an ALLOCATABLE variable for argument P (no. 1) of IS_ALLOCATED [NAG Fortran Compiler error termination, 1 error, 1 warning] Not perfect, but what you are seeing is an attempt by the compiler to do argument association when you invoke function is_allocated. Now look at the following variants in the main: 1) print *, allocated(f()) You'll get: 2 | print *, allocated(f()) | 1 Error: 'array' argument of 'allocated' intrinsic at (1) must be a variable This is what the standard says. 2) integer, allocatable :: p p = f() print *, allocated(p) This compiles, but you get a runtime error (SIGSEGV) with gfortran and ifort. Why? The assignment p=f() is invalid for unallocated r.h.s., and you are hitting this. The running program will never reach the allocated(p). I don't see a legal way to use an allocatable function without allocating the result. So you should use a subroutine and allocate a result variable. The only potential issue I see here with gfortran is that there is no working runtime diagnostics for the non-allocated r.h.s. above. But there is none for current ifort/ifx either. If the reporter agrees, we should close this PR as invalid.
[Bug tree-optimization/109462] [13 Regression] Possible miscompilation of clang LocalizationChecker since r13-1938
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109462 --- Comment #11 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:9c2a5db997446a9438a3e01f5229dec3f78b09e7 commit r13-7170-g9c2a5db997446a9438a3e01f5229dec3f78b09e7 Author: Andrew MacLeod Date: Wed Apr 12 13:10:55 2023 -0400 Ensure PHI equivalencies do not dominate the argument edge. When we create an equivalency between a PHI definition and an argument, ensure the definition does not dominate the incoming argument edge. PR tree-optimization/108139 PR tree-optimization/109462 * gimple-range-cache.cc (ranger_cache::fill_block_cache): Remove equivalency check for PHI nodes. * gimple-range-fold.cc (fold_using_range::range_of_phi): Ensure def does not dominate single-arg equivalency edges.
[Bug tree-optimization/108139] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1938-g87dd4c8c83768aaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108139 --- Comment #8 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:9c2a5db997446a9438a3e01f5229dec3f78b09e7 commit r13-7170-g9c2a5db997446a9438a3e01f5229dec3f78b09e7 Author: Andrew MacLeod Date: Wed Apr 12 13:10:55 2023 -0400 Ensure PHI equivalencies do not dominate the argument edge. When we create an equivalency between a PHI definition and an argument, ensure the definition does not dominate the incoming argument edge. PR tree-optimization/108139 PR tree-optimization/109462 * gimple-range-cache.cc (ranger_cache::fill_block_cache): Remove equivalency check for PHI nodes. * gimple-range-fold.cc (fold_using_range::range_of_phi): Ensure def does not dominate single-arg equivalency edges.
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Leandro Lupori from comment #2) > Thanks for the quick response. > > What if 'f' is changed to this: > > function f() > integer, allocatable :: f > > allocate(f) > f = 123 > deallocate(f) > end function > > Is the program still invalid? gfortran -Wall doesn't complain in this case, > but I get a SIGSEGV instead of SIGABRT. Yes. It is not valid Fortran. You've deallocated 'f', which means the function result is not set. Your example is also likely why the warning is hidden behind -Wall. I suspect there are too many false positive and with your code you're getting a false negative (ie., no warning). F2023, p. 331 15.5.3 Function reference A function is invoked during expression evaluation by a function-reference or by a defined operation (10.1.6). When it is invoked, all actual argument expressions are evaluated, then the arguments are associated, and then the function is executed. When execution of the function is complete, the value of the function result is available for use in the expression that caused the function to be invoked. In 'print *, is_allocated(f())', the function-reference is evaluated. F2023, p. 336 On completion of execution of the function, the value returned is that of its function result. ... If the function result is not a pointer, its value shall be defined by the function. 19.6.6 Events that cause variables to become undefined ... (10) When an allocatable entity is deallocated, it becomes undefined.
[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 --- Comment #13 from Wilhelm M --- Yes, the ICE is with the patch. I'm pretty sure that this does not happen without the patch, but I will that check again.
[Bug c++/109503] New: attribute visibility on template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109503
Bug ID: 109503
Summary: attribute visibility on template specialization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
(I know there are many bugs in this area but I'm not finding an exact dup of
this very problem.)
template__attribute__((visibility("default"))) void foo() {}
template<> __attribute__((visibility("protected"))) void foo();
template<> __attribute__((visibility("protected"))) void foo() {}
$ ./cc1plus -quiet t.C
t.C:3:58: warning: ‘void foo() [with T = int]’: visibility attribute ignored
because it conflicts with previous declaration [-Wattributes]
3 | template<> __attribute__((visibility("protected"))) void foo() {}
| ^~~~
t.C:2:58: note: previous declaration of ‘void foo() [with T = int]’
2 | template<> __attribute__((visibility("protected"))) void foo();
| ^~~~
Should the foo attribute override the primary template's attribute? In
any case, at least the diagnostic is wrong.
[Bug modula2/109488] typo in lang.opt: libraries maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109488 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Gaius Mulley --- Many thanks for the bug report - now closing as the patch has been applied.
[Bug modula2/109488] typo in lang.opt: libraries maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109488 --- Comment #1 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:52bb22bb5e1f951c73b5cd43b0b3a423f67e5e7a commit r13-7169-g52bb22bb5e1f951c73b5cd43b0b3a423f67e5e7a Author: Gaius Mulley Date: Thu Apr 13 18:43:44 2023 +0100 PR modula2/109488 Typo in lang.opt: libraries maybe Correct spelling of "maybe" to "may be" in the modula-2 language options. gcc/m2/ChangeLog: PR modula2/109488 * lang.opt: Fix typo "maybe" to "may be". Signed-off-by: Gaius Mulley
[Bug c++/101295] constexpr destructor: ''result_decl' not supported by dump_expr' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101295 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Last reconfirmed||2023-04-13 Known to fail||10.4.0, 11.3.0, 12.2.0, ||13.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Patrick Palka --- Confirmed.
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #47 from Jakub Jelinek ---
The testcase then doesn't have to be floating point, say on x86 -O3 -mavx512f
void
foo (int *f, int d, int e)
{
for (int i = 0; i < 1024; i++)
{
int a = f[i];
int t;
if (a < 0)
t = 1;
else if (a < e)
t = 1 - a * d;
else
t = 0;
f[i] = t;
}
}
shows similar problems. Strangely, for
void
foo (int *f, int d, int e)
{
if (e < 32 || e > 64)
__builtin_unreachable ();
for (int i = 0; i < 1024; i++)
{
int a = f[i];
f[i] = (a < 0 ? 1 : 1 - a * d) * (a < e ? 1 : 0);
}
}
the threader doesn't do what it does for floating point code and we use just 2
comparisons rather than 3 (or more). Still, only one multiplication, not 2.
Strangely, in that case the second multiplication is there until vrp2, which
folds it using
/* Transform x * { 0 or 1, 0 or 1, ... } into x & { 0 or -1, 0 or -1, ...},
unless the target has native support for the former but not the latter. */
match.pd pattern and others into oblivion.
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #46 from rguenther at suse dot de ---
Am 13.04.2023 um 18:54 schrieb jakub at gcc dot gnu.org
:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
>
> --- Comment #45 from Jakub Jelinek ---
> So, would
> void
> foo (float *f, float d, float e)
> {
> if (e >= 2.0f && e <= 4.0f)
>;
> else
>__builtin_unreachable ();
> for (int i = 0; i < 1024; i++)
>{
> float a = f[i];
> f[i] = (a < 0.0f ? 1.0f : 1.0f - a * d) * (a < e ? 1.0f : 0.0f);
>}
> }
> be a better reduction on what's going on?
> From the frange/threading POV, when e is in [2.0f, 4.0f] range, if a < 0.0f,
> we
> know that a < e is also true, so there is no point in testing that at runtime.
> So I think what threadfull1 does is right and desirable if the final code
> actually performs those comparisons and uses conditional jumps.
> The only thing is that it is harmful for vectorization and maybe for
> predicated
> code.
> Therefore, for scalar code at least without massive ARM style conditional
> execution,
> the above is better emitted as
> if (a < 0.0f)
>tmp = 1.0f;
> else
>{
> tmp = (1.0f - a * d) * (a < e ? 1.0f : 0.0f);
>}
> or even
> if (a < 0.0f)
>tmp = 1.0f;
> else if (a < e)
>tmp = 1.0f - a * d;
> else
>tmp = 0.0f;
> f[i] = tmp;
> Thus, could we effectively try to undo it at ifcvt time on loops for
> vectorization only, or during vectorization or something similar?
> As ifcvt then turns the IMHO desirable
> if (a_16 >= 0.0)
>goto ; [59.00%]
> else
>goto ; [41.00%]
>
> [local count: 435831803]:
> goto ; [100.00%]
>
> [local count: 627172605]:
> _7 = a_16 * d_17(D);
> iftmp.0_18 = 1.0e+0 - _7;
> if (e_13(D) > a_16)
>goto ; [20.00%]
> else
>goto ; [80.00%]
>
> [local count: 125434523]:
> goto ; [100.00%]
>
> [local count: 501738082]:
>
> [local count: 1063004410]:
> # prephitmp_26 = PHI
> (ok, the 2 empty forwarders are unlikely useful) into:
> _7 = a_16 * d_17(D);
> iftmp.0_18 = 1.0e+0 - _7;
> _21 = a_16 >= 0.0;
> _10 = e_13(D) > a_16;
> _9 = _10 & _21;
> _27 = e_13(D) <= a_16;
> _28 = _21 & _27;
> _ifc__43 = _9 ? iftmp.0_18 : 0.0;
> _ifc__44 = _28 ? 0.0 : _ifc__43;
> _45 = a_16 < 0.0;
> prephitmp_26 = _45 ? 1.0e+0 : _ifc__44;
> Now, perhaps if ifcvt used ranger, it could figure out that a_16 < 0.0 implies
> e_13(D) > a_16 and do something smarter with it.
> Or maybe just try to do smarter ifcvt just based on the original CFG.
> The pre-ifcvt code was a_16 < 0.0f ? 1.0f : a_16 < e_13 ? 1.0f - a_16 * d_17 :
> 0.0f
> so when ifcvt puts everything together, make it
> _7 = a_16 * d_17(D);
> iftmp.0_18 = 1.0e+0 - _7;
> _27 = e_13(D) > a_16;
> _28 = a_16 < 0.0;
> _ifc__43 = _27 ? iftmp.0_18 : 0.0f;
> prephitmp_26 = _28 ? 1.0f : _ifc__43;
> ?
Certainly improving what ifcvt produces for multiarg phis is desirable. I’m not
sure if undoing the threading is generally possible.
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug middle-end/109478] FAIL: g++.dg/other/pr104989.C -std=gnu++14 (internal compiler error: Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109478
--- Comment #3 from dave.anglin at bell dot net ---
On 2023-04-12 7:31 a.m., rguenth at gcc dot gnu.org wrote:
> and the RTL for the argument is
>
> (parallel:BLK [])
>
> ick. pa_function_arg runs into
>
> 9786 arg_size = pa_function_arg_size (mode, type);
> 9800 if (arg_size > 1)
> (gdb) p arg_size
> $7 = 0
>
> so isn't able to decipher things down to a "valid" argument spec. Note
> above for the argument type we have TYPE_SIZE == 0 but a very
> large TYPE_SIZE_UNIT.
>
> One "obvious" mistake is to use 'int arg_size' for the HOST_WIDE_INT
> pa_function_arg_size return value. Adjusting also downstream variable
> types helps to some extent but then we ICE in
Yes, this is wrong. However, pa_function_arg only handles the distribution of
arguments to registers.
It's should return NULL_RTX for "large" arg_size values. Don't know why this
didn't show up before.
>
> during RTL pass: dwarf2
> t.ii: In function 'void c(...)':
> t.ii:4:23: internal compiler error: in dwarf2out_frame_debug_expr, at
> dwarf2cfi.cc:1960
> 4 | void c(...) { c(a()); }
>| ^
> 0x12bd9d2 dwarf2out_frame_debug_expr
> /space/rguenther/src/gcc/gcc/dwarf2cfi.cc:1960
> 0x12bea15 dwarf2out_frame_debug
> /space/rguenther/src/gcc/gcc/dwarf2cfi.cc:2367
> 0x12bf81b scan_insn_after
> /space/rguenther/src/gcc/gcc/dwarf2cfi.cc:2726
> 0x12bfe3c scan_trace
>
> seeing
>
> (set (reg:DI 1 %r1)
> (plus:DI (reg/f:DI 30 %r30)
> (const_int 4611686018427379840 [0x3fffe080])))
Need to investigate where this stack adjustment comes from.
Even if we force the const_int to memory, this will never work with real
hardware. The maximum physical
address size is 44 bits.
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 --- Comment #2 from Leandro Lupori --- Thanks for the quick response. What if 'f' is changed to this: function f() integer, allocatable :: f allocate(f) f = 123 deallocate(f) end function Is the program still invalid? gfortran -Wall doesn't complain in this case, but I get a SIGSEGV instead of SIGABRT.
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #45 from Jakub Jelinek ---
So, would
void
foo (float *f, float d, float e)
{
if (e >= 2.0f && e <= 4.0f)
;
else
__builtin_unreachable ();
for (int i = 0; i < 1024; i++)
{
float a = f[i];
f[i] = (a < 0.0f ? 1.0f : 1.0f - a * d) * (a < e ? 1.0f : 0.0f);
}
}
be a better reduction on what's going on?
>From the frange/threading POV, when e is in [2.0f, 4.0f] range, if a < 0.0f, we
know that a < e is also true, so there is no point in testing that at runtime.
So I think what threadfull1 does is right and desirable if the final code
actually performs those comparisons and uses conditional jumps.
The only thing is that it is harmful for vectorization and maybe for predicated
code.
Therefore, for scalar code at least without massive ARM style conditional
execution,
the above is better emitted as
if (a < 0.0f)
tmp = 1.0f;
else
{
tmp = (1.0f - a * d) * (a < e ? 1.0f : 0.0f);
}
or even
if (a < 0.0f)
tmp = 1.0f;
else if (a < e)
tmp = 1.0f - a * d;
else
tmp = 0.0f;
f[i] = tmp;
Thus, could we effectively try to undo it at ifcvt time on loops for
vectorization only, or during vectorization or something similar?
As ifcvt then turns the IMHO desirable
if (a_16 >= 0.0)
goto ; [59.00%]
else
goto ; [41.00%]
[local count: 435831803]:
goto ; [100.00%]
[local count: 627172605]:
_7 = a_16 * d_17(D);
iftmp.0_18 = 1.0e+0 - _7;
if (e_13(D) > a_16)
goto ; [20.00%]
else
goto ; [80.00%]
[local count: 125434523]:
goto ; [100.00%]
[local count: 501738082]:
[local count: 1063004410]:
# prephitmp_26 = PHI
(ok, the 2 empty forwarders are unlikely useful) into:
_7 = a_16 * d_17(D);
iftmp.0_18 = 1.0e+0 - _7;
_21 = a_16 >= 0.0;
_10 = e_13(D) > a_16;
_9 = _10 & _21;
_27 = e_13(D) <= a_16;
_28 = _21 & _27;
_ifc__43 = _9 ? iftmp.0_18 : 0.0;
_ifc__44 = _28 ? 0.0 : _ifc__43;
_45 = a_16 < 0.0;
prephitmp_26 = _45 ? 1.0e+0 : _ifc__44;
Now, perhaps if ifcvt used ranger, it could figure out that a_16 < 0.0 implies
e_13(D) > a_16 and do something smarter with it.
Or maybe just try to do smarter ifcvt just based on the original CFG.
The pre-ifcvt code was a_16 < 0.0f ? 1.0f : a_16 < e_13 ? 1.0f - a_16 * d_17 :
0.0f
so when ifcvt puts everything together, make it
_7 = a_16 * d_17(D);
iftmp.0_18 = 1.0e+0 - _7;
_27 = e_13(D) > a_16;
_28 = a_16 < 0.0;
_ifc__43 = _27 ? iftmp.0_18 : 0.0f;
prephitmp_26 = _28 ? 1.0f : _ifc__43;
?
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 --- Comment #10 from Andreas Schwab --- If you want to generate only dependencies, use -M or -MM. -MD and -MMD are primarily used to generate dependencies as side effect of compilation.
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- And why would you want to preprocess it when not needed? That is the same thing. Normally the dependencies are generated when a source file is being compiled. And, that compilation happens when either the corresponding file with dependencies doesn't exist or the object file is older than at least one of its dependencies.
[Bug tree-optimization/109491] [11/12 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491 --- Comment #12 from Chip Kerchner --- > having always_inline across a deep call stack can exponentially increase > compile-time Do you think it would be worth requesting a feature to reduce the compilation times in situations like this? Ideally exponentially is not a good thing.
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 --- Comment #8 from Allan W. Macdonald --- (In reply to Andrew Pinski from comment #7) > Does using -c instead help? Why would we want to compile the file without FIRST checking for dependencies? The .d file needs to be up to date so that an included makefile rule can check for any changes in the files listed in each .d file before the target file is compiled.
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 --- Comment #7 from Andrew Pinski --- Does using -c instead help?
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 --- Comment #6 from Allan W. Macdonald --- (In reply to Allan W. Macdonald from comment #5) > Here is a workaround: or just gcc -E -MMD test.c > /dev/null if gcc-11 is default gcc.
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 Allan W. Macdonald changed: What|Removed |Added CC||allan.w.macdonald at gmail dot com --- Comment #5 from Allan W. Macdonald --- This is annoying as it breaks all my existing makefiles. Here is a workaround: $ gcc-11 -E -MMD test.c > /dev/null
[Bug target/109501] rs6000: Add suggested defines for vec_test_data_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2023-04-13 Ever confirmed|0 |1 Summary|vec_test_data_class defines |rs6000: Add suggested |missing |defines for ||vec_test_data_class Priority|P3 |P4 Status|UNCONFIRMED |NEW Severity|normal |enhancement --- Comment #9 from Segher Boessenkool --- I marked this as enhancement, and changed the summary. Thanks!
[Bug target/109502] New: [12/13 Regression] wrong code with -O -ftree-vectorize -fvect-cost-model=unlimited on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109502 Bug ID: 109502 Summary: [12/13 Regression] wrong code with -O -ftree-vectorize -fvect-cost-model=unlimited on aarch64 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: aarch64-unknown-linux-gnu Created attachment 54853 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54853=edit reduced testcase Output: $ aarch64-unknown-linux-gnu-gcc -O -ftree-vectorize -fvect-cost-model=unlimited testcase.c -static $ qemu-aarch64 -- ./a.out qemu: uncaught target signal 6 (Aborted) - core dumped Aborted The value is 0x instead of 1. $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-7165-20230413001648-g66c7257b675-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-7165-20230413001648-g66c7257b675-checking-yes-rtl-df-extra-aarch64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.1 20230413 (experimental) (GCC)
[Bug modula2/109497] Adding two constant chars should result in a string of two chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109497 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Gaius Mulley --- Closing as patch has been applied and regression test code added.
[Bug modula2/109496] Cannot pass a constant char to an array of char formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109496 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Gaius Mulley --- Closed as patch (and test code) has been applied.
[Bug modula2/109497] Adding two constant chars should result in a string of two chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109497 --- Comment #1 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:a1afdc6e2aa77d0a990e1a82aceeffc837b7e50c commit r13-7168-ga1afdc6e2aa77d0a990e1a82aceeffc837b7e50c Author: Gaius Mulley Date: Thu Apr 13 17:02:48 2023 +0100 PR modula2/109496 Fix constant char parameter passing to an array of char This patch fixes PR modula2/109496 and PR modula2/109497. The fix for PR modula2/109496 promotes a char constant to a string. The PR modula2/109497 allows for constant chars to be added to form a string. The fixes for both PR's occur in M2GenGCC.mod and M2GCCDeclare.mod after the resolving of constant declarations. gcc/m2/ChangeLog: * gm2-compiler/M2ALU.def (PopChar): New procedure function. * gm2-compiler/M2ALU.mod (PopChar): New procedure function. * gm2-compiler/M2GCCDeclare.mod (PromoteToString): Detect a single constant char and build a C string. * gm2-compiler/M2GenGCC.mod (IsConstStr): New procedure function. (GetStr): New procedure function. (FoldAdd): Use IsConstStr. * gm2-compiler/M2Quads.mod: Formatting changes. * gm2-gcc/m2expr.cc (m2expr_GetCstInteger): New function. * gm2-gcc/m2expr.def (GetCstInteger): New procedure function. * gm2-gcc/m2expr.h (m2expr_GetCstInteger): New prototype. gcc/testsuite/ChangeLog: PR modula2/109497 * gm2/pim/run/pass/addcharconst.mod: New test. PR modula2/109496 * gm2/pim/run/pass/singlechar.mod: New test. Signed-off-by: Gaius Mulley
[Bug modula2/109496] Cannot pass a constant char to an array of char formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109496 --- Comment #1 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:a1afdc6e2aa77d0a990e1a82aceeffc837b7e50c commit r13-7168-ga1afdc6e2aa77d0a990e1a82aceeffc837b7e50c Author: Gaius Mulley Date: Thu Apr 13 17:02:48 2023 +0100 PR modula2/109496 Fix constant char parameter passing to an array of char This patch fixes PR modula2/109496 and PR modula2/109497. The fix for PR modula2/109496 promotes a char constant to a string. The PR modula2/109497 allows for constant chars to be added to form a string. The fixes for both PR's occur in M2GenGCC.mod and M2GCCDeclare.mod after the resolving of constant declarations. gcc/m2/ChangeLog: * gm2-compiler/M2ALU.def (PopChar): New procedure function. * gm2-compiler/M2ALU.mod (PopChar): New procedure function. * gm2-compiler/M2GCCDeclare.mod (PromoteToString): Detect a single constant char and build a C string. * gm2-compiler/M2GenGCC.mod (IsConstStr): New procedure function. (GetStr): New procedure function. (FoldAdd): Use IsConstStr. * gm2-compiler/M2Quads.mod: Formatting changes. * gm2-gcc/m2expr.cc (m2expr_GetCstInteger): New function. * gm2-gcc/m2expr.def (GetCstInteger): New procedure function. * gm2-gcc/m2expr.h (m2expr_GetCstInteger): New prototype. gcc/testsuite/ChangeLog: PR modula2/109497 * gm2/pim/run/pass/addcharconst.mod: New test. PR modula2/109496 * gm2/pim/run/pass/singlechar.mod: New test. Signed-off-by: Gaius Mulley
[Bug target/108910] [12 Regression] Further ICE in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910 rsandifo at gcc dot gnu.org changed: What|Removed |Added Summary|[12/13 Regression] Further |[12 Regression] Further ICE |ICE in aarch64_layout_arg |in aarch64_layout_arg Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #15 from rsandifo at gcc dot gnu.org --- Fixed on trunk so far.
[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910 --- Comment #14 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:66946624b96b762985de56444d726a0ebd4e0df5 commit r13-7167-g66946624b96b762985de56444d726a0ebd4e0df5 Author: Richard Sandiford Date: Thu Apr 13 16:57:57 2023 +0100 aarch64: Don't trust TYPE_ALIGN for pointers [PR108910] The aarch64 PCS rules ignore user alignment for scalars and vectors and use the "natural" alignment of the type. GCC tried to calculate that natural alignment using: TYPE_ALIGN (TYPE_MAIN_VARIANT (type)) But as discussed in the PR, it's possible that the main variant of a pointer type is an overaligned type (although that's usually accidental). This isn't known to be a problem for other types, so this patch changes the bare minimum. It might be that we need to ignore TYPE_ALIGN in other cases too. gcc/ PR target/108910 * config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Do not trust TYPE_ALIGN for pointer types; use POINTER_SIZE instead. gcc/testsuite/ PR target/108910 * gcc.dg/torture/pr108910.c: New test.
[Bug target/100268] lm32-uclinux: ../.././gcc/config/lm32/uclinux-elf.h:70: error: "LINK_GCC_C_SEQUENCE_SPEC" redefined [-Werror]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100268 Jan-Benedict Glaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Jan-Benedict Glaw --- This seems to be fixed, so I'm closing this ticket.
[Bug target/100836] microblaze-linux: RTX may be used uninitialized in this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100836 Jan-Benedict Glaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Jan-Benedict Glaw --- This is fixed in recent builds, so I'm closing this ticket.
[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109277 Jason Merrill changed: What|Removed |Added Last reconfirmed|2023-03-24 00:00:00 |2023-04-13 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #3 from Oliver Rosten --- Created attachment 54852 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54852=edit Preprocessed file for Test.cpp
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #2 from Oliver Rosten --- Created attachment 54851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54851=edit Preprocessed file
[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 --- Comment #12 from Segher Boessenkool --- With the modified compiler? Does it ICE with an unmodified compiler as well?
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Fortunately, this is not a bug in gfortran. Unfortunately, this is a bug in your program. A function is required by the Fortran standard to have its result variable assigned when it returns. If you compile your code with the -Wall option, you'll see gfortran -o z -Wall a.f90 a.f90:5:2: 5 | function f() | 1 Warning: Return value of function 'f' at (1) not set [-Wreturn-type] On my system, 'z' either segfaults or prints 'T'. For 'T' the function f() is pointing to whatever is left on the stack.
[Bug c/56528] __attribute__((visibility)) ignored for a function declaration with an asm label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56528 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Last reconfirmed||2023-04-13 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug target/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 --- Comment #8 from Chip Kerchner --- Well, then I'm asking GCC to add these to make it easier to use `vec_test_data_class`
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-04-13 Ever confirmed|0 |1 Component|c++ |target Keywords|diagnostic |wrong-code Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- Can you provide the information as requested on https://gcc.gnu.org/bugs/ ? At least the output of "gcc -v". Also can you attach the testcase and not use cmake as cmake makes it hard to figure out the exact command line which is being invoked, a shell script or a simple make file should be enough?
[Bug target/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 --- Comment #7 from Segher Boessenkool --- "For clarity of code, the following named constants are suggested. Preferably, compilers will provide these constants in a header file, but this is not required for compliance."
[Bug target/109499] Unnecessary zeroing in SVE loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499 --- Comment #4 from rsandifo at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #3) > AVX512 masking allows merge and zero modes, zero being cheaper > (obviously). I think "zero" is what all targets support so we could > define GIMPLE to be that way - inactive lanes become zero. That's > then also less of a "partial definition" and "undefined" should be > avoided at best? Thanks, sounds good to me. If direct support for merging turns out to be useful in future, maybe we could add the value of inactive lanes as an extra parameter at that point. Would be quite an invasive change, but it would just be work.
[Bug target/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #6 from Segher Boessenkool --- None of those are required. All are optional. No portable code should use them.
[Bug target/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
--- Comment #5 from Chip Kerchner ---
Here's a testcase
```
#include
#include
int main()
{
__vector float p4f = { float(0), float(1), float(2), float(3) };
__vector __bool int nan_selector = vec_test_data_class(p4f,
__VEC_CLASS_FP_NAN);
return 0;
}
```
```
NAN_defines.cpp: In function ‘int main()’:
NAN_defines.cpp:7:63: error: ‘__VEC_CLASS_FP_NAN’ was not declared in this
scope
7 | __vector __bool int nan_selector = vec_test_data_class(p4f,
__VEC_CLASS_FP_NAN);
|
^~
```
```
/opt/gcc-nightly/trunk/bin/g++ -O3 -mcpu=power9 NAN_defines.cpp
[Bug target/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 --- Comment #4 from Chip Kerchner --- PowerPC LE - P9. Yes, other PVIPR APIs are available and compile in more source code.
[Bug target/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 Andrew Pinski changed: What|Removed |Added Component|c++ |target --- Comment #3 from Andrew Pinski --- Which target is this for? If s390 did you include vecintrin.h?
[Bug c++/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 --- Comment #2 from Chip Kerchner --- '__VEC_CLASS_FP_NAN' was not declared in this scope
[Bug c++/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 Chip Kerchner changed: What|Removed |Added CC||chip.kerchner at ibm dot com --- Comment #1 from Chip Kerchner --- ``` __vector float p4f = some data; 1645 | __vector __bool int nan_selector = vec_test_data_class(p4f, __VEC_CLASS_FP_NAN); ```
[Bug c++/109501] New: vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 Bug ID: 109501 Summary: vec_test_data_class defines missing Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: chip.kerchner at ibm dot com Target Milestone: --- These defines seems to be missing #define __VEC_CLASS_FP_NAN (1<<6) #define __VEC_CLASS_FP_INFINITY_P (1<<5) #define __VEC_CLASS_FP_INFINITY_N (1<<4) #define __VEC_CLASS_FP_ZERO_P (1<<3) #define __VEC_CLASS_FP_ZERO_N (1<<2) #define __VEC_CLASS_FP_SUBNORMAL_P (1<<1) #define __VEC_CLASS_FP_SUBNORMAL_N (1<<0) #define __VEC_CLASS_FP_INFINITY (__VEC_CLASS_FP_INFINITY_P | __VEC_CLASS_FP_INFINITY_N) #define __VEC_CLASS_FP_ZERO (__VEC_CLASS_FP_ZERO_P | __VEC_CLASS_FP_ZERO_N) #define __VEC_CLASS_FP_SUBNORMAL (__VEC_CLASS_FP_SUBNORMAL_P | __VEC_CLASS_FP_SUBNORMAL_N) #define __VEC_CLASS_FP_NOT_NORMAL (__VEC_CLASS_FP_NAN | __VEC_CLASS_FP_SUBNORMAL | __VEC_CLASS_FP_ZERO | __VEC_CLASS_FP_INFINITY)
[Bug c++/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 --- Comment #16 from rguenther at suse dot de --- On Thu, 13 Apr 2023, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||redi at gcc dot gnu.org > > --- Comment #15 from Jakub Jelinek --- > (In reply to rguent...@suse.de from comment #14) > > If that's valid then all bets for this PR are off since f() then > > _can_ change v.size (). > > Well, in C++ the ctors are typically defined inline, so if we wanted and they > would be inline the FE could do some quick check whether the ctor could leak > the this address or some address derived from it and we could do the > optimization only if we prove that the copy constructor (and default > constructor?) doesn't do this. Yes, with IPA we could also figure out cases where arguments / return by reference could be effectively restrict.
[Bug fortran/109500] New: SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 Bug ID: 109500 Summary: SIGABRT when calling a function that returns an unallocated value Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: leandro.lupori at linaro dot org Target Milestone: --- While doing some tests with functions that return an allocatable result, I found out that the following program receives a SIGABRT: program main print *, is_allocated(f()) contains function f() integer, allocatable :: f end function logical function is_allocated(p) integer, allocatable :: p is_allocated = allocated(p) end function end program This is the output (without the backtrace): free(): invalid pointer Program received signal SIGABRT: Process abort signal. I tested it with gfortran 11.3.0 and 12.0.0 20220117 (experimental) [master r12-6624-gb75aab194e3] (from gcc-snapshot). The program above is a reduced version. I was actually trying to use a function that could return either an allocated result or an unallocated one, depending on the argument, such as: function f(p) integer, allocatable :: f, p if (allocated(p)) then f = p endif end function
[Bug target/109499] Unnecessary zeroing in SVE loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499 --- Comment #3 from rguenther at suse dot de --- On Thu, 13 Apr 2023, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499 > > --- Comment #2 from rsandifo at gcc dot gnu.org > --- > (In reply to Richard Biener from comment #1) > > Is there not enough info to catch this on the RTL level with a peephole? > That works for simple cases like the first loop. But in general, I think we > want the full power of gimple to push the information down. The second loop > is > one example of that, but in general, there could be a chain of operations that > naturally do the right thing for inactive lanes. AVX512 masking allows merge and zero modes, zero being cheaper (obviously). I think "zero" is what all targets support so we could define GIMPLE to be that way - inactive lanes become zero. That's then also less of a "partial definition" and "undefined" should be avoided at best?
[Bug c++/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 Jakub Jelinek changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #15 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #14) > If that's valid then all bets for this PR are off since f() then > _can_ change v.size (). Well, in C++ the ctors are typically defined inline, so if we wanted and they would be inline the FE could do some quick check whether the ctor could leak the this address or some address derived from it and we could do the optimization only if we prove that the copy constructor (and default constructor?) doesn't do this. CCing Jonathan on whether it is valid.
[Bug target/109499] Unnecessary zeroing in SVE loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499 --- Comment #2 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) > Is there not enough info to catch this on the RTL level with a peephole? That works for simple cases like the first loop. But in general, I think we want the full power of gimple to push the information down. The second loop is one example of that, but in general, there could be a chain of operations that naturally do the right thing for inactive lanes.
[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #15 from rguenther at suse dot de ---
On Thu, 13 Apr 2023, xry111 at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
>
> --- Comment #14 from Xi Ruoyao ---
> (In reply to rguent...@suse.de from comment #13)
> > On Thu, 13 Apr 2023, chenglulu at loongson dot cn wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
> > >
> > > --- Comment #10 from chenglulu ---
> > > (In reply to Xi Ruoyao from comment #5)
> > > > The test fails on loongarch64-linux-gnu. foo is kept in
> > > > 114t.threadfull1,
> > > > but removed in 135t.forwprop3.
> > > >
> > > > Does this mean something is wrong for LoongArch, or we should simply
> > > > check
> > > > the tree dump in a later pass (for e.g. 254t.optimized)?
> > >
> > > If the definition of the macro DEFAULT_SIGNED_CHAR is changed to 0, the
> > > test
> > > case can pass the test. I guess it is because the definition of
> > > DEFAULT_SIGNED_CHAR affects the optimization of the ccp pass, resulting
> > > in some
> > > blocks that cannot be removed, resulting in the failure of this test case.
> >
> > Can you check if making b unsigned fixes the test for you? If so
> > that's what we should do.
>
> It works?
>
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
> b/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
> index 44c457b7a97..79cf371ef28 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
> @@ -1,7 +1,7 @@
> /* { dg-do compile } */
> /* { dg-options "-O2 -fdump-tree-threadfull1" } */
>
> -static char b;
> +static unsigned char b;
> static unsigned c;
> void foo();
> short(a)(short d, short e) { return d * e; }
>
> But I'm still wondering why this is not an issue for x86_64.
Yes, that's interesting to see. It does change how b is extended
in b ^ 9854 (but for the value zero it doesn't matter).
[Bug c++/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #14 from rguenther at suse dot de ---
On Thu, 13 Apr 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
>
> --- Comment #13 from Jakub Jelinek ---
> (In reply to Richard Biener from comment #12)
> > Note maybe the restrict qualification isn't the best representation since
> > it doesn't capture the value will die upon function return (does it? I
> > gues the DTOR if any will run in caller context and thus stores to it
> > are not necessarily "dead").
>
> Yes, the dtors will be invoked by the caller and those can inspect the values
> and do all kinds of things with them.
> In fact, the restrict isn't probably right either, the constructor of the
> object in the caller could legally save the address of the object somewhere
> else (say global pointer,
> or inside of the object, or wherever else) and as long as say the destructor
> undoes that, it could be valid.
>
> Something like:
>
> struct S {
> static bool enabled;
> static S *p;
> S () : s (0) {}
> ~S () { if (enabled) p = nullptr; }
> S (const S ) : s (x.s) { if (enabled) p = this; }
> int s;
> };
>
> [[gnu::noipa]] void
> bar (S s)
> {
> s.s++;
> S::p->s = 0;
> s.s++;
> }
>
> void
> foo ()
> {
> S s;
> S::enabled = true;
> bar (s);
> }
If that's valid then all bets for this PR are off since f() then
_can_ change v.size ().
[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #14 from Xi Ruoyao ---
(In reply to rguent...@suse.de from comment #13)
> On Thu, 13 Apr 2023, chenglulu at loongson dot cn wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
> >
> > --- Comment #10 from chenglulu ---
> > (In reply to Xi Ruoyao from comment #5)
> > > The test fails on loongarch64-linux-gnu. foo is kept in 114t.threadfull1,
> > > but removed in 135t.forwprop3.
> > >
> > > Does this mean something is wrong for LoongArch, or we should simply check
> > > the tree dump in a later pass (for e.g. 254t.optimized)?
> >
> > If the definition of the macro DEFAULT_SIGNED_CHAR is changed to 0, the test
> > case can pass the test. I guess it is because the definition of
> > DEFAULT_SIGNED_CHAR affects the optimization of the ccp pass, resulting in
> > some
> > blocks that cannot be removed, resulting in the failure of this test case.
>
> Can you check if making b unsigned fixes the test for you? If so
> that's what we should do.
It works：
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
index 44c457b7a97..79cf371ef28 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
@@ -1,7 +1,7 @@
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-threadfull1" } */
-static char b;
+static unsigned char b;
static unsigned c;
void foo();
short(a)(short d, short e) { return d * e; }
But I'm still wondering why this is not an issue for x86_64.
