Add stub 'gcc/rust/ChangeLog' (was: Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust)
Hi! On 2022-12-10T07:39:24+0100, I wrote: > I've pushed "Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust" > to master branch in commit 325529e21e81fbc3561d2568cb7e8a26296e5b2f, see > attached. > > Please let me know if there is anything that I need to do to actually > generate the empty 'gcc/rust/ChangeLog' file. I've now been informed of a non-public email, that indeed there is a manual step involved; pushed "Add stub 'gcc/rust/ChangeLog'" to master branch in commit 24ff0b3e0c41e3997fb4c11736b8a412afbaadf3, see attached. > (For avoidance of doubt: yes, only 'gcc/rust/' at this time.) Grüße Thomas - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 24ff0b3e0c41e3997fb4c11736b8a412afbaadf3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 10 Dec 2022 08:33:22 +0100 Subject: [PATCH] Add stub 'gcc/rust/ChangeLog' --- gcc/rust/ChangeLog | 6 ++ 1 file changed, 6 insertions(+) create mode 100644 gcc/rust/ChangeLog diff --git a/gcc/rust/ChangeLog b/gcc/rust/ChangeLog new file mode 100644 index ..3a4f03c28af8 --- /dev/null +++ b/gcc/rust/ChangeLog @@ -0,0 +1,6 @@ + +Copyright (C) 2022 Free Software Foundation, Inc. + +Copying and distribution of this file, with or without modification, +are permitted in any medium without royalty provided the copyright +notice and this notice are preserved. -- 2.35.1
Add stub 'gcc/rust/ChangeLog' (was: Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust)
Hi! On 2022-12-10T07:39:24+0100, I wrote: > I've pushed "Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust" > to master branch in commit 325529e21e81fbc3561d2568cb7e8a26296e5b2f, see > attached. > > Please let me know if there is anything that I need to do to actually > generate the empty 'gcc/rust/ChangeLog' file. I've now been informed of a non-public email, that indeed there is a manual step involved; pushed "Add stub 'gcc/rust/ChangeLog'" to master branch in commit 24ff0b3e0c41e3997fb4c11736b8a412afbaadf3, see attached. > (For avoidance of doubt: yes, only 'gcc/rust/' at this time.) Grüße Thomas - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 24ff0b3e0c41e3997fb4c11736b8a412afbaadf3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 10 Dec 2022 08:33:22 +0100 Subject: [PATCH] Add stub 'gcc/rust/ChangeLog' --- gcc/rust/ChangeLog | 6 ++ 1 file changed, 6 insertions(+) create mode 100644 gcc/rust/ChangeLog diff --git a/gcc/rust/ChangeLog b/gcc/rust/ChangeLog new file mode 100644 index ..3a4f03c28af8 --- /dev/null +++ b/gcc/rust/ChangeLog @@ -0,0 +1,6 @@ + +Copyright (C) 2022 Free Software Foundation, Inc. + +Copying and distribution of this file, with or without modification, +are permitted in any medium without royalty provided the copyright +notice and this notice are preserved. -- 2.35.1 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug preprocessor/105207] Translation phase 2: splicing physical source lines to form logical source lines may not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105207 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup of bug 55242. *** This bug has been marked as a duplicate of bug 55242 ***
[Bug preprocessor/55242] continued lines not always merged into one long line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55242 Andrew Pinski changed: What|Removed |Added CC||pavel.morozkin at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 105207 has been marked as a duplicate of this bug. ***
[Bug c/108043] [13 Regression] ICE: in fold_convert_loc, at fold-const.cc:2618 on invalid function braced initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108043 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-10 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. Either introduced by: r13-2205-g14cfa01755a66a or r13-3930-gb556d1773db717
[Bug c/108043] [13 Regression] ICE: in fold_convert_loc, at fold-const.cc:2618 on invalid function braced initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108043 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Target Milestone|--- |13.0
Re: [PATCH] Backport gcc-12: jobserver FIFO support
On Fri, 2022-12-09 at 11:07 +0100, Martin Liška wrote: > Hi. > > As make 4.4 has been release, it switches to FIFO by default. That makes > troubles to the latest GCC release, version 12. Right now, we've been using > the following 4 patches in openSUSE gcc12 package: > > 1270ccda70ca09f7d4fe76b5156dca8992bd77a6 > 53e3b2bf16a486c15c20991c6095f7be09012b55 > fed766af32ed6cd371016cc24e931131e19b4eb1 > 3f1c2f89f6b8b8d23a9072f8549b0a2c1de06b03 > > Would it be fine to backport it to gcc-12 branch? Arsen asked me the today > as Gentoo people want it as well. I'd vote a +1, I've applied them to a GCC 12.2 build and used it to build many packages with -flto=auto. GCC seems communicating with make- 4.4 correctly with these patches. > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Thanks, > Martin -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust (was: Rust front-end patches v4)
Hi!
On 2022-12-06T12:03:56+0100, Richard Biener via Gcc-patches
wrote:
> On Tue, Dec 6, 2022 at 11:11 AM wrote:
>> This patchset contains the fixed version of our most recent patchset. [...]
>
> Thanks a lot - this is OK to merge now
Hey, hey! :-)
Still working on some final edits to make the Git commits comply with GCC
policies, but hopefully ready to push soon.
I've pushed "Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust"
to master branch in commit 325529e21e81fbc3561d2568cb7e8a26296e5b2f, see
attached.
Please let me know if there is anything that I need to do to actually
generate the empty 'gcc/rust/ChangeLog' file.
(For avoidance of doubt: yes, only 'gcc/rust/' at this time.)
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
>From 325529e21e81fbc3561d2568cb7e8a26296e5b2f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Sat, 10 Dec 2022 07:27:55 +0100
Subject: [PATCH] Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust
contrib/
* gcc-changelog/git_commit.py (default_changelog_locations): Add
'gcc/rust'.
(bug_components): Add 'rust'.
---
contrib/gcc-changelog/git_commit.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index fb1d15fd86df..aae3416e082f 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -45,6 +45,7 @@ default_changelog_locations = {
'gcc/objc',
'gcc/objcp',
'gcc/po',
+'gcc/rust',
'gcc/testsuite',
'gnattools',
'gotools',
@@ -122,6 +123,7 @@ bug_components = {
'preprocessor',
'regression',
'rtl-optimization',
+'rust',
'sanitizer',
'spam',
'target',
--
2.35.1
Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust (was: Rust front-end patches v4)
Hi!
On 2022-12-06T12:03:56+0100, Richard Biener via Gcc-patches
wrote:
> On Tue, Dec 6, 2022 at 11:11 AM wrote:
>> This patchset contains the fixed version of our most recent patchset. [...]
>
> Thanks a lot - this is OK to merge now
Hey, hey! :-)
Still working on some final edits to make the Git commits comply with GCC
policies, but hopefully ready to push soon.
I've pushed "Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust"
to master branch in commit 325529e21e81fbc3561d2568cb7e8a26296e5b2f, see
attached.
Please let me know if there is anything that I need to do to actually
generate the empty 'gcc/rust/ChangeLog' file.
(For avoidance of doubt: yes, only 'gcc/rust/' at this time.)
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
>From 325529e21e81fbc3561d2568cb7e8a26296e5b2f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Sat, 10 Dec 2022 07:27:55 +0100
Subject: [PATCH] Prepare 'contrib/gcc-changelog/git_commit.py' for GCC/Rust
contrib/
* gcc-changelog/git_commit.py (default_changelog_locations): Add
'gcc/rust'.
(bug_components): Add 'rust'.
---
contrib/gcc-changelog/git_commit.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index fb1d15fd86df..aae3416e082f 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -45,6 +45,7 @@ default_changelog_locations = {
'gcc/objc',
'gcc/objcp',
'gcc/po',
+'gcc/rust',
'gcc/testsuite',
'gnattools',
'gotools',
@@ -122,6 +123,7 @@ bug_components = {
'preprocessor',
'regression',
'rtl-optimization',
+'rust',
'sanitizer',
'spam',
'target',
--
2.35.1
--
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug analyzer/108045] New: analyzer: false positive memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108045 Bug ID: 108045 Summary: analyzer: false positive memory leak Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: jamie.bainbridge at gmail dot com Target Milestone: --- Created attachment 54060 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54060=edit minimal reproducer The analyzer detects a memory leak here, but I don't think there is one. It seems not to have understood that I've kept the reference to "new_scr" (and its child allocation) in the global "ctx->scr" when I swap the pointers on line 80/81 with: struct screen_s *old_scr = ctx->scr; ctx->scr = new_scr; I found that if I omit the body of resize_screen() and place its instructions directly in main(), then the analyzer doesn't report anything is wrong. It seems the extra layer of indirection with the resize_screen() function trips it up. This problem happens with GCC 11.3.0, 12.1.0, and 13.0-20221209 nightly from Compiler Explorer. Full output from CE nightly below, using these options: -v -save-temps -g3 -Og -std=c99 -Wall -Wextra -Wpedantic -fanalyzer Using built-in specs. COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/gcc Target: x86_64-linux-gnu Configured with: ../gcc-trunk-20221209/configure --prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,objc,obj-c++,d --enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix --with-pkgversion=Compiler-Explorer-Build-gcc-e6110da479951b759a12c5618f5304187b650326-binutils-2.38 --enable-libstdcxx-backtrace=yes Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.0.0 20221209 (experimental) (Compiler-Explorer-Build-gcc-e6110da479951b759a12c5618f5304187b650326-binutils-2.38) COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s' '-masm=intel' '-S' '-v' '-save-temps' '-g3' '-Og' '-std=c99' '-Wall' '-Wextra' '-Wpedantic' '-fanalyzer' '-mtune=generic' '-march=x86-64' '-dumpdir' '/app/' /opt/compiler-explorer/gcc-trunk-20221209/bin/../libexec/gcc/x86_64-linux-gnu/13.0.0/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/x86_64-linux-gnu/13.0.0/ -dD -masm=intel -mtune=generic -march=x86-64 -std=c99 -Wall -Wextra -Wpedantic -fdiagnostics-color=always -fanalyzer -g -g3 -fworking-directory -Og -fpch-preprocess -o /app/output.i ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/x86_64-linux-gnu/13.0.0/../../../../x86_64-linux-gnu/include" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/13.0.0/include" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/13.0.0/include-fixed/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/13.0.0/include-fixed" ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/13.0.0/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/x86_64-linux-gnu/13.0.0/include /opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/x86_64-linux-gnu/13.0.0/include-fixed/x86_64-linux-gnu /opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/x86_64-linux-gnu/13.0.0/include-fixed /usr/local/include /opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/../../include /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s' '-masm=intel' '-S' '-v' '-save-temps' '-g3' '-Og' '-std=c99' '-Wall' '-Wextra' '-Wpedantic' '-fanalyzer' '-mtune=generic' '-march=x86-64' '-dumpdir' '/app/' /opt/compiler-explorer/gcc-trunk-20221209/bin/../libexec/gcc/x86_64-linux-gnu/13.0.0/cc1 -fpreprocessed /app/output.i -quiet -dumpdir /app/ -dumpbase output.c -dumpbase-ext .c -masm=intel -mtune=generic -march=x86-64 -g -g3 -Og -Wall -Wextra -Wpedantic -std=c99 -version -fdiagnostics-color=always -fanalyzer -o /app/output.s GNU C99 (Compiler-Explorer-Build-gcc-e6110da479951b759a12c5618f5304187b650326-binutils-2.38) version
[Bug target/108044] New: [13 Regression] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints) at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108044
Bug ID: 108044
Summary: [13 Regression] ICE: in extract_constrain_insn, at
recog.cc:2692 (insn does not satisfy its constraints)
at -O
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: x86_64-pc-linux-gnu
Created attachment 54059
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54059=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c
testcase.c: In function 'foo':
testcase.c:9:1: error: insn does not satisfy its constraints:
9 | }
| ^
(insn 20 19 18 2 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0])) [2 %sfp+-8 S8 A64])
(const_int -9223372036854775808 [0x8000]))
"testcase.c":8:49 82 {*movdi_internal}
(nil))
during RTL pass: cprop_hardreg
testcase.c:9:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2692
0x77a82b _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x77a8b1 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:118
0x769601 extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2692
0x12ff6b3 copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.cc:826
0x1300b9f execute
/repo/gcc-trunk/gcc/regcprop.cc:1408
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.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-4583-20221209191939-g71b31d13757-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-4583-20221209191939-g71b31d13757-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221209 (experimental) (GCC)
[Bug c/108043] New: [13 Regression] ICE: in fold_convert_loc, at fold-const.cc:2618 on invalid function braced initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108043
Bug ID: 108043
Summary: [13 Regression] ICE: in fold_convert_loc, at
fold-const.cc:2618 on invalid function braced
initializer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Created attachment 54058
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54058=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c
testcase.c: In function 'foo':
testcase.c:6:3: internal compiler error: in fold_convert_loc, at
fold-const.cc:2618
6 | (F){};
| ^
0x6ef305 fold_convert_loc(unsigned int, tree_node*, tree_node*)
/repo/gcc-trunk/gcc/fold-const.cc:2618
0xd58d59 pop_init_level(unsigned int, int, obstack*, unsigned int)
/repo/gcc-trunk/gcc/c/c-typeck.cc:9371
0xd7d018 c_parser_braced_init
/repo/gcc-trunk/gcc/c/c-parser.cc:5784
0xd7d383 c_parser_postfix_expression_after_paren_type
/repo/gcc-trunk/gcc/c/c-parser.cc:10945
0xd77f70 c_parser_cast_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:8659
0xd77fef c_parser_binary_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:8449
0xd7944b c_parser_conditional_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:8147
0xd79c64 c_parser_expr_no_commas
/repo/gcc-trunk/gcc/c/c-parser.cc:8061
0xd79f11 c_parser_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:11385
0xd7a657 c_parser_expression_conv
/repo/gcc-trunk/gcc/c/c-parser.cc:11425
0xd6f1cf c_parser_statement_after_labels
/repo/gcc-trunk/gcc/c/c-parser.cc:6790
0xd71714 c_parser_compound_statement_nostart
/repo/gcc-trunk/gcc/c/c-parser.cc:6305
0xd96ec4 c_parser_compound_statement
/repo/gcc-trunk/gcc/c/c-parser.cc:6114
0xd98ef8 c_parser_declaration_or_fndef
/repo/gcc-trunk/gcc/c/c-parser.cc:2850
0xda07c3 c_parser_external_declaration
/repo/gcc-trunk/gcc/c/c-parser.cc:1925
0xda11f3 c_parser_translation_unit
/repo/gcc-trunk/gcc/c/c-parser.cc:1779
0xda11f3 c_parse_file()
/repo/gcc-trunk/gcc/c/c-parser.cc:24596
0xe0d2b1 c_common_parse_file()
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1248
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.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-4583-20221209191939-g71b31d13757-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-4583-20221209191939-g71b31d13757-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221209 (experimental) (GCC)
Re: A problem of weak & weakref function attribute
On Fri, Dec 9, 2022 at 7:17 PM 刘畅 via Gcc wrote:
>
> Hi all,
>
> I met a problem when I was testing the weak attribute and the weakref
> attribute of GCC. I've read the documentation and in the 6.33.1 Common
> Function Attributes - weakref part I found:
>
> Without a target given as an argument to weakref or to alias,
> weakref is equivalent to weak (in that case the declaration may be
> extern).
>
> To verify this statement, I wrote the following two C programs:
>
> a.c
> #include
>
> void func(void) __attribute__((weak));
>
> int main() {
> if (func)
> printf("1\n");
> else
> printf("0\n");
>
> return 0;
> }
>
> b.c
> #include
>
> extern void func(void) __attribute__((weakref));
>
> int main() {
> if (func)
> printf("1\n");
> else
> printf("0\n");
>
> return 0;
> }
>
> The only difference is a.c uses __attribute__((weak)) while b.c uses
> __attribute__((weakref)). According to the statement I referred above,
> I expect the two programs have the smae behavior. However, after I
> compiled the two programs with:
>
> $ gcc a.c -o a.out; gcc b.c -o b.out
>
> I got a warning:
>
> b.c:3:13: warning: ‘weakref’ attribute should be accompanied with an
> ‘alias’ attribute [-Wattributes]
> 3 | extern void func(void) __attribute__((weakref));
> |
>
> then I found they have different output:
>
> $ ./a.out; ./b.out
> 0
> 1
>
> Then I disassembled the main function of a.out and b.out, and found
> the func symbol didn't even appear in the assemble code of b.c (I
> recompiled the 2 programs with -g option):
>
> assemble code of a.c:
> 5 int main() {
>0x1149 <+0>: f3 0f 1e fa endbr64
>0x114d <+4>: 55 push %rbp
>0x114e <+5>: 48 89 e5mov%rsp,%rbp
>
> 6 if (func)
>0x1151 <+8>: 48 8b 05 90 2e 00 00mov
> 0x2e90(%rip),%rax# 0x3fe8
>0x1158 <+15>:48 85 c0test %rax,%rax
>0x115b <+18>:74 0e je 0x116b
>
> 7 printf("1\n");
>0x115d <+20>:48 8d 3d a0 0e 00 00lea
> 0xea0(%rip),%rdi# 0x2004
>0x1164 <+27>:e8 e7 fe ff ff callq 0x1050
>0x1169 <+32>:eb 0c jmp0x1177
>
> 8 else
> 9 printf("0\n");
>0x116b <+34>:48 8d 3d 94 0e 00 00lea
> 0xe94(%rip),%rdi# 0x2006
>0x1172 <+41>:e8 d9 fe ff ff callq 0x1050
>
> 10
> 11 return 0;
>0x1177 <+46>:b8 00 00 00 00 mov$0x0,%eax
>
> 12 }
>0x117c <+51>:5d pop%rbp
>0x117d <+52>:c3 retq
>
> assemble code of b.c:
> 5 int main() {
>0x1149 <+0>: f3 0f 1e fa endbr64
>0x114d <+4>: 55 push %rbp
>0x114e <+5>: 48 89 e5mov%rsp,%rbp
>
> 6 if (func)
> 7 printf("1\n");
>0x1151 <+8>: 48 8d 3d ac 0e 00 00lea
> 0xeac(%rip),%rdi# 0x2004
>0x1158 <+15>:e8 f3 fe ff ff callq 0x1050
>
> 8 else
> 9 printf("0\n");
> 10
> 11 return 0;
>0x115d <+20>:b8 00 00 00 00 mov$0x0,%eax
>
> 12 }
>0x1162 <+25>:5d pop%rbp
>0x1163 <+26>:c3 retq
>
> In my test, the weak attribute and the weakref attribute without a
> target given as an argument to weakref or to alias have different
> behavior, which is different from the documentation. I don't know if
> it's because I misunderstood the documentation. I would be appreciate
> if anyone can help me :)
No it is a bug, at least the documentation no longer matches the implementation.
I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108042 and even
pointed out the (old) revision which changed the behavior to no longer
match the documentation.
Thanks,
Andrew
>
> Best regards,
>
> Chang Liu
[Bug middle-end/108042] [10/11/12/13 Regression] weakref on an extern decl is incorrectly ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108042 Andrew Pinski changed: What|Removed |Added Known to work||4.5.3 Known to fail||4.6.0 --- Comment #1 from Andrew Pinski --- This started to fail with r169288 . Reported originally at https://gcc.gnu.org/pipermail/gcc/2022-December/240283.html .
[Bug middle-end/108042] New: [10/11/12/13 Regression] weakref on an extern decl is incorrectly ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108042
Bug ID: 108042
Summary: [10/11/12/13 Regression] weakref on an extern decl is
incorrectly ignored
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
From:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Function-Attributes.html#index-weakref-function-attribute
Without a target given as an argument to weakref or to alias, weakref is
equivalent to weak (in that case the declaration may be extern).
Testcase:
```
void KNOWNNOTOBEAFUNCTION(void) __attribute__((weakref));
int main() {
if (KNOWNNOTOBEAFUNCTION)
__builtin_abort();
else
return 0;
}
```
This should pass.
A problem of weak & weakref function attribute
Hi all,
I met a problem when I was testing the weak attribute and the weakref
attribute of GCC. I've read the documentation and in the 6.33.1 Common
Function Attributes - weakref part I found:
Without a target given as an argument to weakref or to alias,
weakref is equivalent to weak (in that case the declaration may be
extern).
To verify this statement, I wrote the following two C programs:
a.c
#include
void func(void) __attribute__((weak));
int main() {
if (func)
printf("1\n");
else
printf("0\n");
return 0;
}
b.c
#include
extern void func(void) __attribute__((weakref));
int main() {
if (func)
printf("1\n");
else
printf("0\n");
return 0;
}
The only difference is a.c uses __attribute__((weak)) while b.c uses
__attribute__((weakref)). According to the statement I referred above,
I expect the two programs have the smae behavior. However, after I
compiled the two programs with:
$ gcc a.c -o a.out; gcc b.c -o b.out
I got a warning:
b.c:3:13: warning: ‘weakref’ attribute should be accompanied with an
‘alias’ attribute [-Wattributes]
3 | extern void func(void) __attribute__((weakref));
|
then I found they have different output:
$ ./a.out; ./b.out
0
1
Then I disassembled the main function of a.out and b.out, and found
the func symbol didn't even appear in the assemble code of b.c (I
recompiled the 2 programs with -g option):
assemble code of a.c:
5 int main() {
0x1149 <+0>: f3 0f 1e fa endbr64
0x114d <+4>: 55 push %rbp
0x114e <+5>: 48 89 e5mov%rsp,%rbp
6 if (func)
0x1151 <+8>: 48 8b 05 90 2e 00 00mov
0x2e90(%rip),%rax# 0x3fe8
0x1158 <+15>:48 85 c0test %rax,%rax
0x115b <+18>:74 0e je 0x116b
7 printf("1\n");
0x115d <+20>:48 8d 3d a0 0e 00 00lea
0xea0(%rip),%rdi# 0x2004
0x1164 <+27>:e8 e7 fe ff ff callq 0x1050
0x1169 <+32>:eb 0c jmp0x1177
8 else
9 printf("0\n");
0x116b <+34>:48 8d 3d 94 0e 00 00lea
0xe94(%rip),%rdi# 0x2006
0x1172 <+41>:e8 d9 fe ff ff callq 0x1050
10
11 return 0;
0x1177 <+46>:b8 00 00 00 00 mov$0x0,%eax
12 }
0x117c <+51>:5d pop%rbp
0x117d <+52>:c3 retq
assemble code of b.c:
5 int main() {
0x1149 <+0>: f3 0f 1e fa endbr64
0x114d <+4>: 55 push %rbp
0x114e <+5>: 48 89 e5mov%rsp,%rbp
6 if (func)
7 printf("1\n");
0x1151 <+8>: 48 8d 3d ac 0e 00 00lea
0xeac(%rip),%rdi# 0x2004
0x1158 <+15>:e8 f3 fe ff ff callq 0x1050
8 else
9 printf("0\n");
10
11 return 0;
0x115d <+20>:b8 00 00 00 00 mov$0x0,%eax
12 }
0x1162 <+25>:5d pop%rbp
0x1163 <+26>:c3 retq
In my test, the weak attribute and the weakref attribute without a
target given as an argument to weakref or to alias have different
behavior, which is different from the documentation. I don't know if
it's because I misunderstood the documentation. I would be appreciate
if anyone can help me :)
Best regards,
Chang Liu
[Bug fortran/107995] ICE: Segmentation fault, without backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107995
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Priority|P3 |P4
Ever confirmed|0 |1
Last reconfirmed||2022-12-10
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
This patch prevents the ICE. It has been regression tested, and not regression
occurred. AFAICT, a statement function cannot be a dummy argument.
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index d3e199535b3..8f9eabf0f1c 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -1334,6 +1334,9 @@ gfc_check_dummy_characteristics (gfc_symbol *s1,
gfc_symbol *s2,
if (s1 == NULL || s2 == NULL)
return s1 == s2 ? true : false;
+ if (s1->attr.proc == PROC_ST_FUNCTION || s2->attr.proc == PROC_ST_FUNCTION)
+return false;
+
/* Check type and rank. */
if (type_must_agree)
{
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
--- Comment #15 from Steve Kargl ---
On Sat, Dec 10, 2022 at 01:47:44AM +, barrowes at alum dot mit.edu wrote:
>
> Thanks for engaging, and thanks for the suggestion. I might be able to do this
> over the winter. Could you give me a hint as to where to look. Which files.
>
I suspect that you should start by understand gcc/fortran/lang-specs.h.
That's where most of the the filename suffixes are defined. In particular,
this chuck of code
/* Identical to gcc.cc (cpp_options), but omitting %(cpp_unique_options)
and -fpch-preprocess on -save-temps. */
#define CPP_ONLY_OPTIONS"%1 %{m*} %{f*} %{g*:%{!g0:%{g*} \
%{!fno-working-directory:-fworking-directory}}} \
%{std*} %{W**} %{w} \
%{O*} %{undef}"
Re: The method of determining the specific assignment of gcc optimization options
Thank you for your response. Jonathan Wakely 于2022年12月9日周五 22:40写道： > This question belongs on the gcc-help mailing list, not here. > > On Fri, 9 Dec 2022 at 12:01, hongjie wu via Gcc wrote: > > > > Dear Sir or Madam， > > I want to know how to obtain optimal level of the value of the > > What do you mean by optimal? > > They have pros and cons. > > > specific compiler options, for example - fexcess - precision = [fast | > > standard] [default], including the default represent？Or how to determine? > > gcc -Q --help=optim > > > I am looking forward to your favorable replay. >
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 --- Comment #14 from Ben Barrowes --- Thanks for engaging, and thanks for the suggestion. I might be able to do this over the winter. Could you give me a hint as to where to look. Which files.
Re: Add zstd support to libbacktrace
On Wed, Dec 7, 2022 at 4:22 PM Ian Lance Taylor wrote:
>
> This patch adds zstd support to libbacktrace, to support the new
> linker option --compress-debug-sections=zstd.
This patch rewrites and simplifies the main zstd decompression loop
using some ideas from the reference implementation. This speeds it up
a bit, although it still runs at about 35% of the speed of the
reference implementaiton. Bootstrapped and ran libbacktrace tests on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
* elf.c (ZSTD_TABLE_*): Use elf_zstd_fse_baseline_entry.
(ZSTD_ENCODE_BASELINE_BITS): Define.
(ZSTD_DECODE_BASELINE, ZSTD_DECODE_BASEBITS): Define.
(elf_zstd_literal_length_base): New static const array.
(elf_zstd_match_length_base): Likewise.
(struct elf_zstd_fse_baseline_entry): Define.
(elf_zstd_make_literal_baseline_fse): New static function.
(elf_zstd_make_offset_baseline_fse): Likewise.
(elf_zstd_make_match_baseline_fse): Likewise.
(print_table, main): Use elf_zstd_fse_baseline_entry.
(elf_zstd_lit_table, elf_zstd_match_table): Likewise.
(elf_zstd_offset_table): Likewise.
(struct elf_zstd_seq_decode): Likewise. Remove use_rle and rle
fields.
(elf_zstd_unpack_seq_decode): Use elf_zstd_fse_baseline_entry,
taking a conversion function. Convert RLE to FSE.
(elf_zstd_literal_length_baseline): Remove.
(elf_zstd_literal_length_bits): Remove.
(elf_zstd_match_length_baseline): Remove.
(elf_zstd_match_length_bits): Remove.
(elf_zstd_decompress): Use elf_zstd_fse_baseline_entry. Rewrite
and simplify main loop.
diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
index 15e6f284db6..ece02db27f1 100644
--- a/libbacktrace/elf.c
+++ b/libbacktrace/elf.c
@@ -2610,9 +2610,9 @@ elf_zlib_inflate_and_verify (const unsigned char *pin,
size_t sin,
}
/* For working memory during zstd compression, we need
- - a literal length FSE table: 512 32-bit values == 2048 bytes
- - a match length FSE table: 512 32-bit values == 2048 bytes
- - a offset FSE table: 256 32-bit values == 1024 bytes
+ - a literal length FSE table: 512 64-bit values == 4096 bytes
+ - a match length FSE table: 512 64-bit values == 4096 bytes
+ - a offset FSE table: 256 64-bit values == 2048 bytes
- a Huffman tree: 2048 uint16_t values == 4096 bytes
- scratch space, one of
- to build an FSE table: 512 uint16_t values == 1024 bytes
@@ -2620,21 +2620,24 @@ elf_zlib_inflate_and_verify (const unsigned char *pin,
size_t sin,
- buffer for literal values == 2048 bytes
*/
-#define ZSTD_TABLE_SIZE\
- (2 * 512 * sizeof (struct elf_zstd_fse_entry)\
- + 256 * sizeof (struct elf_zstd_fse_entry) \
- + 2048 * sizeof (uint16_t) \
+#define ZSTD_TABLE_SIZE\
+ (2 * 512 * sizeof (struct elf_zstd_fse_baseline_entry) \
+ + 256 * sizeof (struct elf_zstd_fse_baseline_entry) \
+ + 2048 * sizeof (uint16_t) \
+ 2048)
#define ZSTD_TABLE_LITERAL_FSE_OFFSET (0)
-#define ZSTD_TABLE_MATCH_FSE_OFFSET (512 * sizeof (struct elf_zstd_fse_entry))
+#define ZSTD_TABLE_MATCH_FSE_OFFSET\
+ (512 * sizeof (struct elf_zstd_fse_baseline_entry))
-#define ZSTD_TABLE_OFFSET_FSE_OFFSET \
- (ZSTD_TABLE_MATCH_FSE_OFFSET + 512 * sizeof (struct elf_zstd_fse_entry))
+#define ZSTD_TABLE_OFFSET_FSE_OFFSET \
+ (ZSTD_TABLE_MATCH_FSE_OFFSET \
+ + 512 * sizeof (struct elf_zstd_fse_baseline_entry))
-#define ZSTD_TABLE_HUFFMAN_OFFSET \
- (ZSTD_TABLE_OFFSET_FSE_OFFSET + 256 * sizeof (struct elf_zstd_fse_entry))
+#define ZSTD_TABLE_HUFFMAN_OFFSET \
+ (ZSTD_TABLE_OFFSET_FSE_OFFSET
\
+ + 256 * sizeof (struct elf_zstd_fse_baseline_entry))
#define ZSTD_TABLE_WORK_OFFSET \
(ZSTD_TABLE_HUFFMAN_OFFSET + 2048 * sizeof (uint16_t))
@@ -2645,8 +2648,11 @@ elf_zlib_inflate_and_verify (const unsigned char *pin,
size_t sin,
struct elf_zstd_fse_entry
{
+ /* The value that this FSE entry represents. */
unsigned char symbol;
+ /* The number of bits to read to determine the next state. */
unsigned char bits;
+ /* Add the bits to this base to get the next state. */
uint16_t base;
};
@@ -2925,6 +2931,270 @@ elf_zstd_build_fse (const int16_t *norm, int idx,
uint16_t *next,
return 1;
}
+/* Encode the baseline and bits into a single 32-bit value. */
+
+#define ZSTD_ENCODE_BASELINE_BITS(baseline, basebits) \
+ ((uint32_t)(baseline) | ((uint32_t)(basebits) << 24))
+
+#define ZSTD_DECODE_BASELINE(baseline_basebits)\
+ ((uint32_t)(baseline_basebits) & 0xff)
+
+#define ZSTD_DECODE_BASEBITS(baseline_basebits)\
+ ((uint32_t)(baseline_basebits) >> 24)
+
+/* Given a literal length code, we need to read a number of bits and add that
+ to a baseline. For states 0 to 15 the baseline is the state and the number
+ of bits is zero. */
+
+#define
[PATCH v4 1/19] modula2 front end: changes outside gcc/m2, libgm2 and gcc/testsuite.
While writing the ChangeLog entries git gcc-verify spotted an oversight
with v3 of this patch set. I had forgotten to post gm2.texi and also a
tiny patchlet in gcc/configure.ac (to detect Python). HAVE_PYTHON is
used within gcc/m2/Make-lang.in to avoid generating the library section
included by gm2.texi should Python not be available.
ok to commit? I've included gm2-lang.cc and lang.opt for reference.
regards,
Gaius
diff -ruw gcc-git-master/gcc/configure.ac gcc-git-devel-modula2/gcc/configure.ac
--- gcc-git-master/gcc/configure.ac 2022-12-07 20:16:24.571677189 +
+++ gcc-git-devel-modula2/gcc/configure.ac 2022-12-07 19:46:20.036302786
+
@@ -1263,6 +1263,10 @@
# Bison?
AC_CHECK_PROGS([BISON], bison, [$MISSING bison])
+# Python3?
+AM_PATH_PYTHON(,, [:])
+AM_CONDITIONAL([HAVE_PYTHON], [test "$PYTHON" != :])
+
# Binutils are not build modules, unlike bison/flex/makeinfo. So we
# check for build == host before using them.
@@ -7651,4 +7655,3 @@
],
[subdirs='$subdirs'])
AC_OUTPUT
-
diff -ruw /dev/null gcc-git-devel-modula2/gcc/doc/gm2.texi
--- /dev/null 2022-08-24 16:22:16.88870 +0100
+++ gcc-git-devel-modula2/gcc/doc/gm2.texi 2022-12-10 00:04:30.263603238
+
@@ -0,0 +1,2944 @@
+\input texinfo
+@c -*-texinfo-*-
+@c Copyright (C) 2001-2022 Free Software Foundation, Inc.
+@c This is part of the GM2 manual.
+
+@c User level documentation for GNU Modula-2
+@c
+@c header
+
+@setfilename gm2.info
+@settitle The GNU Modula-2 Compiler
+
+@set version-python 3.5
+
+@include gcc-common.texi
+
+@c Copyright years for this manual.
+@set copyrights-gm2 1999-2022
+
+@copying
+@c man begin COPYRIGHT
+Copyright @copyright{} @value{copyrights-gm2} Free Software Foundation, Inc.
+
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with no
+Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
+A copy of the license is included in the
+@c man end
+section entitled ``GNU Free Documentation License''.
+@ignore
+@c man begin COPYRIGHT
+man page gfdl(7).
+@c man end
+@end ignore
+@end copying
+
+@ifinfo
+@format
+@dircategory Software development
+@direntry
+* gm2: (gm2). A GCC-based compiler for the Modula-2 language
+@end direntry
+@end format
+
+@insertcopying
+@end ifinfo
+
+@titlepage
+@title The GNU Modula-2 Compiler
+@versionsubtitle
+@author Gaius Mulley
+
+@page
+@vskip 0pt plus 1filll
+Published by the Free Software Foundation @*
+51 Franklin Street, Fifth Floor@*
+Boston, MA 02110-1301, USA@*
+@sp 1
+@insertcopying
+@end titlepage
+@contents
+@page
+
+@c `Top' Node and Master Menu
+
+@node Top, Overview, (dir), (dir)
+@top Introduction
+
+@menu
+* Overview:: What is GNU Modula-2.
+* Using::Using GNU Modula-2.
+* Licence:: Licence of GNU Modula-2
+* Copying:: GNU Public Licence V3.
+* Contributing:: Contributing to GNU Modula-2
+* Internals::GNU Modula-2 internals.
+* EBNF:: EBNF of GNU Modula-2
+* Libraries::PIM and ISO library definitions.
+* Indices:: Document and function indices.
+@end menu
+
+@node Overview, Using, Top, Top
+@chapter Overview of GNU Modula-2
+
+@menu
+* What is GNU Modula-2:: Brief description of GNU Modula-2.
+* Why use GNU Modula-2:: Advantages of GNU Modula-2.
+* News:: Latest news about GNU Modula-2.
+* Development:: How to get source code using git.
+* Obtaining:: Where to get the source code using git.
+* Features:: GNU Modula-2 Features
+@end menu
+
+@node What is GNU Modula-2, Why use GNU Modula-2, , Using
+@section What is GNU Modula-2
+
+GNU Modula-2 is a @uref{http://gcc.gnu.org/frontends.html, front end}
+for the GNU Compiler Collection (@uref{http://gcc.gnu.org/, GCC}).
+The GNU Modula-2 compiler is compliant with the PIM2, PIM3, PIM4 and
+ISO dialects. Also implemented are a complete set of free ISO
+libraries and PIM libraries.
+
+@footnote{The four Modula-2 dialects supported are defined in the following
+references:
+
+PIM2: 'Programming in Modula-2', 2nd Edition, Springer Verlag, 1982,
+1983 by Niklaus Wirth (PIM2).
+
+PIM3: 'Programming in Modula-2', 3rd Corrected Edition, Springer Verlag,
+1985 (PIM3).
+
+PIM4: 'Programming in Modula-2', 4th Edition, Springer Verlag, 1988
+(@uref{http://freepages.modula2.org/report4/modula-2.html, PIM4}).
+
+ISO: the ISO Modula-2 language as defined in 'ISO/IEC Information
+technology - programming languages - part 1: Modula-2 Language,
+ISO/IEC 10514-1 (1996)'
+}
+
+@node Why use GNU Modula-2, Release map, What is GNU Modula-2, Using
+@section Why use GNU Modula-2
+
+There are a number of advantages of using GNU Modula-2 rather than
+translate an existing project into another language.
+
+The first advantage is of maintainability of the original sources
+and the ability to debug the
[Bug ipa/108000] Assert during ipa-cp with AutoFDO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108000 Eugene Rozenfeld changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Eugene Rozenfeld --- Fixed by https://gcc.gnu.org/g:7410032a772a9e77b620b091c2b551b68113a179 .
[Bug target/104921] aarch64: Assembler failure with vbfmlalbq_lane_f32 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921
--- Comment #3 from Andrew Pinski ---
The following patterns has the same problem too:
(define_insn "aarch64_bfdot_lane"
[(set (match_operand:VDQSF 0 "register_operand" "=w")
(plus:VDQSF
(unspec:VDQSF
[(match_operand: 2 "register_operand" "w")
(match_operand:VBF 3 "register_operand" "w")
(match_operand:SI 4 "const_int_operand" "n")]
UNSPEC_BFDOT)
(match_operand:VDQSF 1 "register_operand" "0")))]
"TARGET_BF16_SIMD"
{
int nunits = GET_MODE_NUNITS (mode).to_constant ();
int lane = INTVAL (operands[4]);
operands[4] = gen_int_mode (ENDIAN_LANE_N (nunits / 2, lane), SImode);
return "bfdot\t%0., %2., %3.2h[%4]";
}
[(set_attr "type" "neon_dot")]
That is operand 3 should be using "x" constraint.
[Bug target/104921] aarch64: Assembler failure with vbfmlalbq_lane_f32 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921
--- Comment #2 from Andrew Pinski ---
(define_insn "aarch64_bfmlal_lanev4sf"
[(set (match_operand:V4SF 0 "register_operand" "=w")
(plus: V4SF (match_operand:V4SF 1 "register_operand" "0")
(unspec:V4SF [(match_operand:V8BF 2 "register_operand" "w")
(match_operand:VBF 3 "register_operand" "w")
(match_operand:SI 4 "const_int_operand" "n")]
BF_MLA)))]
"TARGET_BF16_SIMD"
{
operands[4] = aarch64_endian_lane_rtx (mode, INTVAL (operands[4]));
return "bfmlal\\t%0.4s, %2.8h, %3.h[%4]";
}
[(set_attr "type" "neon_fp_mla_s_scalar_q")]
)
Operand 3 should have be:
(match_operand:VBF 3 "register_operand" "x")
[Bug libgcc/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ statically linked programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675 --- Comment #15 from Thomas Neumann --- > You cannot use 'relaxed' atomic load in is_object_initialized - as thread > performing such load will not observe/synchronize with any modifications > (other than atomic variable itself) performed by other threads. you are right, this has to be acquire. Very unfortunate. I thought we would get away with relaxed because we double-check anyway, but with relaxed we might miss the writes to the other fields of object. On systems with strong memory order it does not matter, but on ARM this will make the check slower.
[Bug tree-optimization/108041] New: ivopts results in extra instruction in simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108041
Bug ID: 108041
Summary: ivopts results in extra instruction in simple loop
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
CC: rzinsly at ventanamicro dot com
Target Milestone: ---
ivopts seems to make a bit of a mess out of this code resulting in the loop
having an unnecessary instruction. Compile with rv64 -O2:
typedef struct network
{
long nr_group, full_groups, max_elems;
} network_t;
void marc_arcs(network_t* net)
{
while (net->full_groups < 0) {
net->full_groups = net->nr_group + net->full_groups;
net->max_elems--;
}
}
After slp1 we have this loop:
;; basic block 3, loop depth 0
;;pred: 2
_1 = net_8(D)->nr_group;
net__max_elems_lsm.4_16 = net_8(D)->max_elems;
;;succ: 4
;; basic block 4, loop depth 1
;;pred: 7
;;3
# _13 = PHI <_2(7), _11(3)>
# net__max_elems_lsm.4_5 = PHI <_4(7), net__max_elems_lsm.4_16(3)>
_2 = _1 + _13;
_4 = net__max_elems_lsm.4_5 + -1;
if (_2 < 0)
goto ; [89.00%]
else
goto ; [11.00%]
;;succ: 7
;;5
;; basic block 7, loop depth 1
;;pred: 4
goto ; [100.00%]
;;succ: 4
;; basic block 5, loop depth 0
;;pred: 4
# _12 = PHI <_2(4)>
# _17 = PHI <_4(4)>
net_8(D)->full_groups = _12;
net_8(D)->max_elems = _17;
;;succ: 6
Of particular interest is the max_elems computation into _4. We accumulate it
in the loop, then do the final store after the loop (thank you LSM!). After
ivopts we have:
;; basic block 3, loop depth 0
;;pred: 2
_1 = net_8(D)->nr_group;
net__max_elems_lsm.4_16 = net_8(D)->max_elems;
_22 = net__max_elems_lsm.4_16 + -1;
ivtmp.10_21 = (unsigned long) _22;
;;succ: 4
;; basic block 4, loop depth 1
;;pred: 7
;;3
# _13 = PHI <_2(7), _11(3)>
# ivtmp.10_3 = PHI
_2 = _1 + _13;
_4 = (long int) ivtmp.10_3;
ivtmp.10_18 = ivtmp.10_3 - 1;
if (_2 < 0)
goto ; [89.00%]
else
goto ; [11.00%]
;;succ: 7
;;5
;; basic block 7, loop depth 1
;;pred: 4
goto ; [100.00%]
;;succ: 4
;; basic block 5, loop depth 0
;;pred: 4
# _12 = PHI <_2(4)>
# _17 = PHI <_4(4)>
net_8(D)->full_groups = _12;
net_8(D)->max_elems = _17;
;;succ: 6
Note the introduction of the IV and its relationship to _4. Essentially we
compute both in the loop even _4 is always one greater than the IV. Worse yet,
the IV is only used to compute _4! And since they differ by 1, we actually
compute both and keep them alive resulting in this final code for rv64:
.L3:
add a5,a5,a2
mv a3,a4
addia4,a4,-1
blt a5,zero,.L3
sd a5,8(a0)
sd a3,16(a0)
Note how we had to "stash away" the value of a4 before the decrement so that we
could store it after the loop. The induction variable doesn't really buy us
anything in this loop -- it's actively harmful. Not using the IV would
probably be best. Second best would be to realize that _4 (aka a3) can be
derived from the IV (a4) after the loop by adding 1.
[Bug target/104921] aarch64: Assembler failure with vbfmlalbq_lane_f32 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-09 --- Comment #1 from Andrew Pinski --- Confirmed.
gcc-11-20221209 is now available
Snapshot gcc-11-20221209 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20221209/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision 5d3bf022a7bf7dba2f376fb328c5c60cfd21eb91 You'll find: gcc-11-20221209.tar.xz Complete GCC SHA256=8b46e1371ebf8f6eed980af1c1af19ed23502cb38bb98dae3ba7613124f2f8b1 SHA1=962cabe4364831445b18ca55254420f0693dd6cc Diffs from 11-20221202 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 --- Comment #8 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:01254aa2eb766c7584fd047568d7277d4d65d067 commit r13-4585-g01254aa2eb766c7584fd047568d7277d4d65d067 Author: Paul Thomas Date: Fri Dec 9 22:13:45 2022 +0100 Fortran: ICE on recursive derived types with allocatable components [PR107872] gcc/fortran/ChangeLog: PR fortran/107872 * resolve.cc (derived_inaccessible): Skip over allocatable components to prevent an infinite loop. gcc/testsuite/ChangeLog: PR fortran/107872 * gfortran.dg/pr107872.f90: New test.
[Bug rtl-optimization/108039] Unnecessary extension storing same value twice to small location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108039 --- Comment #2 from Andrew Pinski --- I did something similar years ago: https://gcc.gnu.org/pipermail/gcc-patches/2010-October/297761.html https://gcc.gnu.org/pipermail/gcc-patches/2010-October/297762.html
[Bug c++/108040] New: -fdevirtualize causes part of function to be missing in output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108040 Bug ID: 108040 Summary: -fdevirtualize causes part of function to be missing in output Product: gcc Version: 12.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alvinhochun at gmail dot com Target Milestone: --- Created attachment 54057 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54057=edit preprocessed source file Using MSYS2 UCRT64 GCC 12.2.0 $ g++ -v Using built-in specs. COLLECT_GCC=C:\msys64\ucrt64\bin\g++.exe COLLECT_LTO_WRAPPER=C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-12.2.0/configure --prefix=/ucrt64 --with-local-prefix=/ucrt64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/ucrt64/include --libexe cdir=/ucrt64/lib --enable-bootstrap --enable-checking=release --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=po six --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-multilib --disable-rpath --disable-win32-registry --disa ble-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/ucrt64 --with-mpfr=/ucrt64 --with-mpc=/ucrt64 --with-isl=/ucrt64 --with-pkgversion='Rev6, Built by MSYS2 project' --with-bugurl=https://git hub.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++ Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Rev6, Built by MSYS2 project) I compiled the original source with the following commands: $ g++ -DCATCH_CONFIG_COLOUR_ANSI -D_WIN32_WINNT=0x0602 -ID:/dev/mingw-winrt/cppwinrt/test -ID:/dev/mingw-winrt/cppwinrt/test/../cppwinrt -IC:/msys64/home/Alvin/cppwinrt_rel/test/cppwinrt -O2 -g -DNDEBUG -fno-omit-frame-pointer -fdiagnostics-color=always -mcx16 -O1 -finline-functions -finline-small-functions -findirect-inlining -fno-devirtualize -std=gnu++20 -MD -MT test/test/CMakeFiles/test-out_params_bad.dir/out_params_bad.cpp.obj -MF 'test\test\CMakeFiles\test-out_params_bad.dir\out_params_bad.cpp.obj.d' D:/dev/mingw-winrt/cppwinrt/test/test/out_params_bad.cpp -g0 -S -o ../good.s -fverbose-asm -save-temps $ g++ -DCATCH_CONFIG_COLOUR_ANSI -D_WIN32_WINNT=0x0602 -ID:/dev/mingw-winrt/cppwinrt/test -ID:/dev/mingw-winrt/cppwinrt/test/../cppwinrt -IC:/msys64/home/Alvin/cppwinrt_rel/test/cppwinrt -O2 -g -DNDEBUG -fno-omit-frame-pointer -fdiagnostics-color=always -mcx16 -O1 -finline-functions -finline-small-functions -findirect-inlining -fno-devirtualize -std=gnu++20 -MD -MT test/test/CMakeFiles/test-out_params_bad.dir/out_params_bad.cpp.obj -MF 'test\test\CMakeFiles\test-out_params_bad.dir\out_params_bad.cpp.obj.d' D:/dev/mingw-winrt/cppwinrt/test/test/out_params_bad.cpp -g0 -S -o ../bad.s -fdevirtualize -fverbose-asm -save-temps I then compared `good.s` and `bad.s` and checked inside the function `static void C_A_T_C_H_T_E_S_T_0()` (_ZL19C_A_T_C_H_T_E_S_T_0v). At around `D:/dev/mingw-winrt/cppwinrt/test/test/out_params_bad.cpp:211`, `bad.s` is missing a large chunk of the function (all the way to the function epilogue) compared to `good.s`. The only difference is that `bad.s` is compiled with `-fdevirtualize`. Attached the preprocessed source with gzip compression.
Re: [PATCH] Fortran: ICE on recursive derived types with allocatable components [PR107872]
Hi Harald, Thanks for doing that. My attention is elsewhere gfortran-wise. Good for mainline. Paul On Fri, 9 Dec 2022 at 21:27, Harald Anlauf via Fortran wrote: > Dear all, > > I am submitting the attached simple - and obvious - patch on > behalf of Paul. It prevents a resource exhaustion due to an > infinite loop, and has been regtested by multiple contributers, ;-) > at least on x86_64-pc-linux-gnu. > > I intend to commit it to mainline within 24 hours, unless > there are further comments. > > Thanks, > Harald > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[PATCH] c++: extract_local_specs and unevaluated contexts [PR100295]
Here during partial instantiation of the constexpr if, extra_local_specs
walks the statement looking for local specializations within to save and
possibly capture. However, we're thwarted by the fact that 'ts' first
appears inside an unevaluated context, and so the calls to
process_outer_var_ref for its local specializations are a no-op. And
since we walk each tree exactly once, we end up not capturing them
despite it later occuring in an evaluated context.
This patch fixes this by making extract_local_specs walk evaluated
contexts first before walking unevaluated contexts. We could probably
get away with not walking unevaluated contexts at all, but this approach
seems safer.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/12?
PR c++/100295
PR c++/107579
gcc/cp/ChangeLog:
* pt.cc (el_data::skip_unevaluated_operands): New data member.
(extract_locals_r): If skip_unevaluated_operands is true,
don't walk into unevaluated contexts.
(extract_local_specs): Walk the pattern twice, first with
skip_unevaluated_operands true followed by it set to false.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/constexpr-if-lambda5.C: New test.
---
gcc/cp/pt.cc | 19 ++-
.../g++.dg/cpp1z/constexpr-if-lambda5.C | 15 +++
2 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-if-lambda5.C
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index d05a49b1c11..2b22bf14c53 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -13015,17 +13015,26 @@ public:
/* List of local_specializations used within the pattern. */
tree extra;
tsubst_flags_t complain;
+ /* True iff we don't want to walk into unevaluated contexts. */
+ bool skip_unevaluated_operands = false;
el_data (tsubst_flags_t c)
: extra (NULL_TREE), complain (c) {}
};
static tree
-extract_locals_r (tree *tp, int */*walk_subtrees*/, void *data_)
+extract_locals_r (tree *tp, int *walk_subtrees, void *data_)
{
el_data = *reinterpret_cast(data_);
tree *extra =
tsubst_flags_t complain = data.complain;
+ if (data.skip_unevaluated_operands
+ && unevaluated_p (TREE_CODE (*tp)))
+{
+ *walk_subtrees = 0;
+ return NULL_TREE;
+}
+
if (TYPE_P (*tp) && typedef_variant_p (*tp))
/* Remember local typedefs (85214). */
tp = _NAME (*tp);
@@ -13117,6 +13126,14 @@ static tree
extract_local_specs (tree pattern, tsubst_flags_t complain)
{
el_data data (complain);
+ /* Walk the pattern twice, ignoring unevaluated operands the first time
+ around, so that if a local specialization appears in both an
+ evaluated and unevaluated context we prefer to process it in the
+ former context (since e.g. process_outer_var_ref is a no-op inside
+ an unevaluated context). */
+ data.skip_unevaluated_operands = true;
+ cp_walk_tree (, extract_locals_r, , );
+ data.skip_unevaluated_operands = false;
cp_walk_tree (, extract_locals_r, , );
return data.extra;
}
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if-lambda5.C
b/gcc/testsuite/g++.dg/cpp1z/constexpr-if-lambda5.C
new file mode 100644
index 000..d2bf0221743
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-if-lambda5.C
@@ -0,0 +1,15 @@
+// PR c++/100295
+// { dg-do compile { target c++17 } }
+
+template
+void f(Ts... ts) {
+ auto lambda = [=](auto x) {
+if constexpr (sizeof((ts+x) + ...) != 0)
+ (..., ts);
+ };
+ lambda(0);
+}
+
+int main() {
+ f(0, 'a');
+}
--
2.39.0.rc2
[Bug rtl-optimization/108039] Unnecessary extension on riscv-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108039
Andrew Pinski changed:
What|Removed |Added
Target|riscv-64|riscv64 aarch64
Last reconfirmed||2022-12-09
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed. You can reproduce the issue on aarch64 with a slightly modified
testcase:
void replace_weaker_arc(short *id1, short *id2, long long number)
{
*id1 = number;
*id2 = number;
}
[Bug rtl-optimization/108039] Unnecessary extension on riscv-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108039 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug rtl-optimization/108039] New: Unnecessary extension on riscv-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108039
Bug ID: 108039
Summary: Unnecessary extension on riscv-64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
CC: rzinsly at ventanamicro dot com
Target Milestone: ---
Target: riscv-64
Compile the following code for rv64 with -O2:
typedef signed long int int64_t;
void replace_weaker_arc(int *id1, int *id2, int64_t number)
{
*id1 = number;
*id2 = number;
}
We generate:
replace_weaker_arc:
sext.w a2,a2
sw a2,0(a0)
sw a2,0(a1)
ret
The key insns (from cse1 dump) are:
(insn 8 5 9 2 (set (reg:DI 134 [ _1 ])
(sign_extend:DI (subreg:SI (reg/v:DI 137 [ number ]) 0))) "j.c":4:10
116 {extendsidi2}
(nil))
(insn 9 8 10 2 (set (mem:SI (reg/v/f:DI 135 [ id1 ]) [1 *id1_4(D)+0 S4 A32])
(subreg/s/u:SI (reg:DI 134 [ _1 ]) 0)) "j.c":4:10 178 {*movsi_internal}
(nil))
(insn 10 9 0 2 (set (mem:SI (reg/v/f:DI 136 [ id2 ]) [1 *id2_6(D)+0 S4 A32])
(subreg/s/u:SI (reg:DI 134 [ _1 ]) 0)) "j.c":5:10 178 {*movsi_internal}
(nil))
fwprop tries to propagate insn 8 into insns 9 and 10, but that fails the
complexity check:
cannot propagate from insn 8 into insn 9: would increase complexity of pattern
cannot propagate from insn 8 into insn 10: would increase complexity of pattern
But propagation in this case allows us to eliminate a subreg & extension, so
it's profitable.
I haven't tested it, but something like this captures the RTL propagation
generates and the fact that it should simplify. We may need to tighten it a
little by verifying modes:
diff --git a/gcc/fwprop.cc b/gcc/fwprop.cc
index fc652ab9a1f..a86e9320908 100644
--- a/gcc/fwprop.cc
+++ b/gcc/fwprop.cc
@@ -258,6 +258,14 @@ fwprop_propagation::classify_result (rtx old_rtx, rtx
new_rtx)
return CONSTANT | PROFITABLE;
}
+ /* Allow replacements where we are able to eliminate a
+ (subreg (any_extend (...)). */
+ if (GET_CODE (old_rtx) == SUBREG
+ && (GET_CODE (SUBREG_REG (old_rtx)) == SIGN_EXTEND
+ || GET_CODE (SUBREG_REG (old_rtx)) == ZERO_EXTEND)
+ && XEXP (SUBREG_REG (old_rtx), 0) == new_rtx)
+return PROFITABLE;
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from anlauf at gcc dot gnu.org --- Assigning to you, Paul, then, after submitting to the ML: https://gcc.gnu.org/pipermail/fortran/2022-December/058603.html
[PATCH] Fortran: ICE on recursive derived types with allocatable components [PR107872]
Dear all,
I am submitting the attached simple - and obvious - patch on
behalf of Paul. It prevents a resource exhaustion due to an
infinite loop, and has been regtested by multiple contributers, ;-)
at least on x86_64-pc-linux-gnu.
I intend to commit it to mainline within 24 hours, unless
there are further comments.
Thanks,
Harald
From 01254aa2eb766c7584fd047568d7277d4d65d067 Mon Sep 17 00:00:00 2001
From: Paul Thomas
Date: Fri, 9 Dec 2022 22:13:45 +0100
Subject: [PATCH] Fortran: ICE on recursive derived types with allocatable
components [PR107872]
gcc/fortran/ChangeLog:
PR fortran/107872
* resolve.cc (derived_inaccessible): Skip over allocatable components
to prevent an infinite loop.
gcc/testsuite/ChangeLog:
PR fortran/107872
* gfortran.dg/pr107872.f90: New test.
---
gcc/fortran/resolve.cc | 3 +-
gcc/testsuite/gfortran.dg/pr107872.f90 | 40 ++
2 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr107872.f90
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 75dc4b59105..158bf08ec26 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -7536,7 +7536,8 @@ derived_inaccessible (gfc_symbol *sym)
for (c = sym->components; c; c = c->next)
{
/* Prevent an infinite loop through this function. */
- if (c->ts.type == BT_DERIVED && c->attr.pointer
+ if (c->ts.type == BT_DERIVED
+ && (c->attr.pointer || c->attr.allocatable)
&& sym == c->ts.u.derived)
continue;
diff --git a/gcc/testsuite/gfortran.dg/pr107872.f90 b/gcc/testsuite/gfortran.dg/pr107872.f90
new file mode 100644
index 000..09838479e92
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107872.f90
@@ -0,0 +1,40 @@
+! { dg-do run }
+!
+! Test the fix for PR107872, where an ICE occurred in
+! resolve.cc(derived_inaccessible) because derived types with
+! recursive allocatable components were not catered for.
+!
+module mod1
+ type t
+ integer :: data
+ type(t), allocatable :: next
+ contains
+ procedure, private :: write_t
+ generic :: write(formatted) => write_t
+ end type
+contains
+ recursive subroutine write_t(this, unit, iotype, v_list, iostat, iomsg)
+class(t), intent(in) :: this
+integer, intent(in) :: unit
+character(*), intent(in) :: iotype
+integer, intent(in) :: v_list(:)
+integer, intent(out) :: iostat
+character(*), intent(inout) :: iomsg
+if (ALLOCATED(this%next)) &
+ write (unit, '(dt)') this%next
+write (unit, '(i2)') this%data
+ end subroutine
+end module
+
+ use mod1
+ type(t) :: a
+ character (8) :: buffer
+ a%data = 1
+ allocate (a%next)
+ a%next%data = 2
+ allocate (a%next%next)
+ a%next%next%data = 3
+ write (buffer, '(dt)')a
+ deallocate (a%next)
+ if (trim (buffer) .ne. ' 3 2 1') stop 1
+end
--
2.35.3
[Bug target/108038] New: GCC generates poor code for select of consecutive constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108038
Bug ID: 108038
Summary: GCC generates poor code for select of consecutive
constants
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
CC: rzinsly at ventanamicro dot com
Target Milestone: ---
Target: riscv-64
This testcase:
typedef signed long int __int64_t;
#define X(OP, OPN) __int64_t test##OPN(__int64_t x, __int64_t y) { __int64_t
cmp; cmp = (x OP y) ? 2 : 3; return cmp; }
X(>,GT)
X(<,LT)
typedef unsigned long int __uint64_t;
#define XU(OP, OPN) __uint64_t test##OPN(__uint64_t x, __uint64_t y) {
__uint64_t cmp; cmp = (x OP y) ? 2 : 3; return cmp; }
X(>,GTU)
X(<,LTU)
Compiled for rv64 with -O2 -march=rv64gc_zba gets this code for the first test.
The others are similar in having the extraneous xori.
testGT:
sgt a0,a0,a1# 25[c=4 l=4] *sgt_didi
xoria0,a0,1 # 27[c=4 l=4] xordi3/1
addia0,a0,2 # 16[c=4 l=4] adddi3/1
ret # 35[c=0 l=4] simple_return
But ISTM we could generate this instead:
testGT:
sgt a0,a1,a0# 24[c=4 l=4] *riscv.md:2535
addia0,a0,2 # 16[c=4 l=4] adddi3/1
ret # 32[c=0 l=4] simple_return
I think the key is this:
Trying 25 -> 27:
25: r139:DI=r140:DI>r141:DI
REG_DEAD r141:DI
REG_DEAD r140:DI
27: r134:DI=r139:DI^0x1
REG_DEAD r139:DI
Failed to match this instruction:
(set (reg:DI 134 [ ])
(le:DI (reg:DI 140)
(reg:DI 141)))
We can invert the condition and swap the operands with something like this:
(define_insn ""
[(set (match_operand:GPR 0 "register_operand" "=r")
(any_le:GPR (match_operand:X 1 "register_operand" " r")
(match_operand:X 2 "register_operand" "r")))]
""
"sgt\t%0,%2,%1"
[(set_attr "type" "slt")
(set_attr "mode" "")])
We probably need another pattern to handle the LT/LTU cases which want to
match:
rying 24 -> 25:
24: r139:DI=r140:DI
Re: [IRA] Code bloat due to register spills in v9, v10, v11, v12 and master
On 2022-12-09 14:23, Georg-Johann Lay wrote:
There is the following code size regression, filed as
https://gcc.gnu.org/PR90706
I am sorry, I feel your frustration. I was not aware of this PR.
Unfortunately, the PR was marked as P4 and I have too many open PRs and
should prioritize them.
I've just started to work on this issue. It is hard for me to say when
it will be fixed. I'll give an update on the next week.
Simple test cases are, for example
#define PORT (*((unsigned char volatile*) 0x24))
unsigned short var16;
void func (void)
{
if (2048000ul * var16 > 120ul)
PORT |= 1;
}
When I compile it with
$ avr-gcc -Os bloat1.c -c && avr-size bloat1.o
the code size increases from 36 bytes (v8) to 88 bytes (v13).
Apart from that, register pressure is much higher because a frame
pointer is set up for no reason, and the values go through stack slots
for no reason.
Even test cases which don't require any code like
long func2 (void)
{
long var32;
__asm ("; some code %0" : "=r" (var32));
return var32;
}
increase in register pressure (x2), stack usage (from 0 to 6 bytes)
and code size from 2 bytes (v8) to 34 bytes (v13).
Some projects like QMK "solved" the problem by declaring GCC > v8 to
be "incompatible" with their project, see
https://github.com/qmk/qmk_firmware/issues/6719
In own projects I observed the problem, too, and the only solution is
to use v8 or older. Options like -fcaller-saves or -fira-algorithm=
have no effect.
To configure, I used --target=avr --disable-nls --with-dwarf2
--enable-languages=c,c++ --with-gnu-as --with-gnu-ld --disable-shared,
so nothing special.
The problem is present in v9, v10, v11, v12 and master (future v13),
so sitting around for quite a while, so maybe it's not fixed because
RA maintainers are not aware of the problem.
[Patch] Fortran: Replace simple '.' quotes by %<.%>
Found when working on the just submitted/committed patch.
I intent to commit it to mainline as obvious tomorrow (or Sun or Mon),
unless there are comments.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Fortran: Replace simple '.' quotes by %<.%>
When using %qs instead of '%s' or %<=%> instead of '=' looks nicer
by having nicer quotes and bold text, if the terminal supports it;
otherwise, plain quotes are used.
gcc/fortran/ChangeLog:
* match.cc (gfc_match_member_sep): Use %<...%> in gfc_error.
* openmp.cc (gfc_match_oacc_routine, gfc_match_omp_context_selector,
gfc_match_omp_context_selector_specification,
gfc_match_omp_declare_variant, resolve_omp_clauses): Likewise;
use %qs instead of '%s'.
* primary.cc (match_real_constant, gfc_match_varspec): Likewise.
* resolve.cc (gfc_resolve_formal_arglist, resolve_operator,
resolve_ordinary_assign): Likewise.
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index 7ba0f349993..89fb115c0f6 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -195,3 +195,3 @@ gfc_match_member_sep(gfc_symbol *sym)
gfc_error ("Expected structure component or operator name "
- "after '.' at %C");
+ "after %<.%> at %C");
goto error;
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 4b4e6ac6947..7edc78ad0cb 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -4061,3 +4061,3 @@ gfc_match_oacc_routine (void)
gfc_error ("Syntax error in !$ACC ROUTINE ( NAME ) at %C, expecting"
- " ')' after NAME");
+ " %<)%> after NAME");
gfc_current_locus = old_loc;
@@ -5350,4 +5350,4 @@ gfc_match_omp_context_selector (gfc_omp_set_selector *oss)
{
- gfc_error ("selector '%s' not allowed for context selector "
- "set '%s' at %C",
+ gfc_error ("selector %qs not allowed for context selector "
+ "set %qs at %C",
selector, oss->trait_set_selector_name);
@@ -5370,3 +5370,3 @@ gfc_match_omp_context_selector (gfc_omp_set_selector *oss)
{
- gfc_error ("selector '%s' does not accept any properties at %C",
+ gfc_error ("selector %qs does not accept any properties at %C",
selector);
@@ -5379,3 +5379,3 @@ gfc_match_omp_context_selector (gfc_omp_set_selector *oss)
{
- gfc_error ("expected '(' at %C");
+ gfc_error ("expected %<(%> at %C");
return MATCH_ERROR;
@@ -5401,3 +5401,3 @@ gfc_match_omp_context_selector (gfc_omp_set_selector *oss)
{
- gfc_error ("expected ')' at %C");
+ gfc_error ("expected %<)%> at %C");
return MATCH_ERROR;
@@ -5514,3 +5514,3 @@ gfc_match_omp_context_selector (gfc_omp_set_selector *oss)
{
- gfc_error ("expected ')' at %C");
+ gfc_error ("expected %<)%> at %C");
return MATCH_ERROR;
@@ -5524,3 +5524,3 @@ gfc_match_omp_context_selector (gfc_omp_set_selector *oss)
{
- gfc_error ("expected '(' at %C");
+ gfc_error ("expected %<(%> at %C");
return MATCH_ERROR;
@@ -5570,4 +5570,4 @@ gfc_match_omp_context_selector_specification (gfc_omp_declare_variant *odv)
{
- gfc_error ("expected 'construct', 'device', 'implementation' or "
- "'user' at %C");
+ gfc_error ("expected %, %, % "
+ "or % at %C");
return MATCH_ERROR;
@@ -5578,3 +5578,3 @@ gfc_match_omp_context_selector_specification (gfc_omp_declare_variant *odv)
{
- gfc_error ("expected '=' at %C");
+ gfc_error ("expected %<=%> at %C");
return MATCH_ERROR;
@@ -5585,3 +5585,3 @@ gfc_match_omp_context_selector_specification (gfc_omp_declare_variant *odv)
{
- gfc_error ("expected '{' at %C");
+ gfc_error ("expected %<{%> at %C");
return MATCH_ERROR;
@@ -5600,3 +5600,3 @@ gfc_match_omp_context_selector_specification (gfc_omp_declare_variant *odv)
{
- gfc_error ("expected '}' at %C");
+ gfc_error ("expected %<}%> at %C");
return MATCH_ERROR;
@@ -5622,3 +5622,3 @@ gfc_match_omp_declare_variant (void)
{
- gfc_error ("expected '(' at %C");
+ gfc_error ("expected %<(%> at %C");
return MATCH_ERROR;
@@ -5670,3 +5670,3 @@ gfc_match_omp_declare_variant (void)
{
- gfc_error ("expected ')' at %C");
+ gfc_error ("expected %<)%> at %C");
return MATCH_ERROR;
@@ -5680,3 +5680,3 @@ gfc_match_omp_declare_variant (void)
{
- gfc_error ("expected 'match' at %C");
+ gfc_error ("expected % at %C");
return MATCH_ERROR;
@@ -5689,3 +5689,3 @@ gfc_match_omp_declare_variant (void)
{
- gfc_error ("expected '(' at %C");
+ gfc_error ("expected %<(%> at %C");
return MATCH_ERROR;
@@ -5698,3 +5698,3 @@ gfc_match_omp_declare_variant (void)
{
- gfc_error ("expected ')' at %C");
+ gfc_error ("expected %<)%> at %C");
return MATCH_ERROR;
@@ -7380,3 +7380,3 @@ resolve_omp_clauses (gfc_code
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #3) > Created attachment 53975 [details] > Fix for this PR > > I am tied up with my finalization work at present. If somebody else wishes > to commit the patch, be my guest. I'll submit the patch on your behalf to the ML, if you don't mind.
[Bug c++/107579] [11/12/13 Regression] ICE on fold-expression on .* member access operator since r12-2862-g9707d2e5dbb92d2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107579 --- Comment #7 from Patrick Palka --- This is essentially a dup of PR100295, except here the unevaluated context is a requires-expr instead of sizeof, and r12-2862 exposed this bug by making us correctly recognize a requires-expr as an unevaluated context during cp_walk_subtrees
Re: [Patch] Fortran/OpenMP: align/allocator modifiers to the allocate clause
On Fri, Dec 09, 2022 at 09:14:55PM +0100, Tobias Burnus wrote: > Implementing the 5.1 syntax inside the 'allocate' clause. That's a > fallout of working on something else... > > OK for mainline? > > Tobias > - > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 > München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas > Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht > München, HRB 106955 > Fortran/OpenMP: align/allocator modifiers to the allocate clause > > gcc/fortran/ChangeLog: > > * dump-parse-tree.cc (show_omp_namelist): Improve OMP_LIST_ALLOCATE > output. > * gfortran.h (struct gfc_omp_namelist): Add 'align' to 'u'. > (gfc_free_omp_namelist): Add bool arg. > * match.cc (gfc_free_omp_namelist): Likewise; free 'u.align'. > * openmp.cc (gfc_free_omp_clauses, gfc_match_omp_clause_reduction, > gfc_match_omp_flush): Update call. > (gfc_match_omp_clauses): Match 'align/allocate modifers in > 'allocate' clause. > (resolve_omp_clauses): Resolve align. > * st.cc (gfc_free_statement): Update call > * trans-openmp.cc (gfc_trans_omp_clauses): Handle 'align'. > > libgomp/ChangeLog: > > * libgomp.texi (5.1 Impl. Status): Split allocate clause/directive > item about 'align'; mark clause as 'Y' and directive as 'N'. > * testsuite/libgomp.fortran/allocate-2.f90: New test. > * testsuite/libgomp.fortran/allocate-3.f90: New test. LGTM, thanks. Jakub
Re: Spurious warning for zero-sized array parameters to a function
On 12/9/22 21:19, Alejandro Colomar wrote:
Hi Martin,
On 12/9/22 21:04, mse...@gmail.com wrote:
Most of these warnings are designed to find simple mistakes in common use
cases so "tricky," unusual, or otherwise unexpected code is likely to lead to
surprises. This warning expects that in calls to a function, every parameter
declared using the array syntax (which is expected to have a nonzero bound) is
passed a dereferenceable pointer as an argument. It considers neither the
definition of the function to see if it does in fact dereference the argument,
nor this unlikely (and strictly invalid) use case.
Hi Martin,
Is it really invalid? AFAIK, ISO C doesn't specify anything for array syntax in
function parameters othen than that they are equivalent to a pointer. The only
exception is when using 'static', which requires a minimum of 0.
Oops, typo there. I wanted to say that 'static' requires a minimum of 1.
So, [0], by
not using 'static', is conforming code, I believe. Or does the restriction to
0-sized arrays also apply to function parameters? What if you pass a size of 0
through a variable? I don't think it's undefined behavior to do so.
Could you please quote the standard about being "strictly invalid"?
Cheers,
Alex
The warning should not be issued if the parameter is declared as an ordinary
pointer
I confirm; it doesn't warn.
so I would suggest to use that instead. It's possible that declaring the
array parameter with attribute access none might also suppress the warning,
but there is no utility in using a zero-length array in this context. The
intended purpose of the zero-length array GCC extension is as trailing members
of structs in legacy (pre-C99 code) that cannot use flexible array members.
Using them anywhere else is likely to be surprising, both to tools and to
readers, so the attribute on a pointer parameter would be preferable.
Heh, then the following function will blow brains :P
char *
stpecpy(char *dst, const char *restrict src, char past_end[0])
{
char *p;
if (dst == past_end)
return past_end;
p = memccpy(dst, src, '\0', past_end - dst);
if (p != NULL)
return p - 1;
/* truncation detected */
past_end[-1] = '\0';
return past_end;
}
which similar to strscpy(9), but allows chaining.
In this case, I can't even use the access attribute. I _need_ to use the
'past_end' pointer to access the array (or perform unnecessary pointer
arithmetic that would hurt readability: 'p = [past_end - dst];').
For the curious, a variant that behaves like strlcpy(3), can be implemented as:
inline char *
stpecpyx(char *dst, const char *restrict src, char past_end[0])
{
if (src[strlen(src)] != '\0')
raise(SIGSEGV);
return stpecpy(dst, src, past_end);
}
Cheers,
Alex
--
Re: Spurious warning for zero-sized array parameters to a function
Hi Martin,
On 12/9/22 21:04, mse...@gmail.com wrote:
Most of these warnings are designed to find simple mistakes in common use cases so
"tricky," unusual, or otherwise unexpected code is likely to lead to surprises.
This warning expects that in calls to a function, every parameter declared using the
array syntax (which is expected to have a nonzero bound) is passed a dereferenceable
pointer as an argument. It considers neither the definition of the function to see if it
does in fact dereference the argument, nor this unlikely (and strictly invalid) use case.
Hi Martin,
Is it really invalid? AFAIK, ISO C doesn't specify anything for array syntax in
function parameters othen than that they are equivalent to a pointer. The only
exception is when using 'static', which requires a minimum of 0. So, [0], by
not using 'static', is conforming code, I believe. Or does the restriction to
0-sized arrays also apply to function parameters? What if you pass a size of 0
through a variable? I don't think it's undefined behavior to do so.
Could you please quote the standard about being "strictly invalid"?
Cheers,
Alex
The warning should not be issued if the parameter is declared as an ordinary
pointer
I confirm; it doesn't warn.
so I would suggest to use that instead. It's possible that declaring the array
parameter with attribute access none might also suppress the warning, but there
is no utility in using a zero-length array in this context. The intended
purpose of the zero-length array GCC extension is as trailing members of
structs in legacy (pre-C99 code) that cannot use flexible array members. Using
them anywhere else is likely to be surprising, both to tools and to readers, so
the attribute on a pointer parameter would be preferable.
Heh, then the following function will blow brains :P
char *
stpecpy(char *dst, const char *restrict src, char past_end[0])
{
char *p;
if (dst == past_end)
return past_end;
p = memccpy(dst, src, '\0', past_end - dst);
if (p != NULL)
return p - 1;
/* truncation detected */
past_end[-1] = '\0';
return past_end;
}
which similar to strscpy(9), but allows chaining.
In this case, I can't even use the access attribute. I _need_ to use the
'past_end' pointer to access the array (or perform unnecessary pointer
arithmetic that would hurt readability: 'p = [past_end - dst];').
For the curious, a variant that behaves like strlcpy(3), can be implemented as:
inline char *
stpecpyx(char *dst, const char *restrict src, char past_end[0])
{
if (src[strlen(src)] != '\0')
raise(SIGSEGV);
return stpecpy(dst, src, past_end);
}
Cheers,
Alex
--
[Patch] Fortran/OpenMP: align/allocator modifiers to the allocate clause
Implementing the 5.1 syntax inside the 'allocate' clause. That's a
fallout of working on something else...
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Fortran/OpenMP: align/allocator modifiers to the allocate clause
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (show_omp_namelist): Improve OMP_LIST_ALLOCATE
output.
* gfortran.h (struct gfc_omp_namelist): Add 'align' to 'u'.
(gfc_free_omp_namelist): Add bool arg.
* match.cc (gfc_free_omp_namelist): Likewise; free 'u.align'.
* openmp.cc (gfc_free_omp_clauses, gfc_match_omp_clause_reduction,
gfc_match_omp_flush): Update call.
(gfc_match_omp_clauses): Match 'align/allocate modifers in
'allocate' clause.
(resolve_omp_clauses): Resolve align.
* st.cc (gfc_free_statement): Update call
* trans-openmp.cc (gfc_trans_omp_clauses): Handle 'align'.
libgomp/ChangeLog:
* libgomp.texi (5.1 Impl. Status): Split allocate clause/directive
item about 'align'; mark clause as 'Y' and directive as 'N'.
* testsuite/libgomp.fortran/allocate-2.f90: New test.
* testsuite/libgomp.fortran/allocate-3.f90: New test.
gcc/fortran/dump-parse-tree.cc | 23 +
gcc/fortran/gfortran.h | 3 +-
gcc/fortran/match.cc | 4 +-
gcc/fortran/openmp.cc| 106 +++
gcc/fortran/st.cc| 2 +-
gcc/fortran/trans-openmp.cc | 8 ++
libgomp/libgomp.texi | 4 +-
libgomp/testsuite/libgomp.fortran/allocate-2.f90 | 25 ++
libgomp/testsuite/libgomp.fortran/allocate-3.f90 | 28 ++
9 files changed, 163 insertions(+), 40 deletions(-)
diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 2f042ab5142..5ae72dc1cac 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -1357,6 +1357,29 @@ show_omp_namelist (int list_type, gfc_omp_namelist *n)
}
ns_iter = n->u2.ns;
}
+ if (list_type == OMP_LIST_ALLOCATE)
+ {
+ if (n->expr)
+ {
+ fputs ("allocator(", dumpfile);
+ show_expr (n->expr);
+ fputc (')', dumpfile);
+ }
+ if (n->expr && n->u.align)
+ fputc (',', dumpfile);
+ if (n->u.align)
+ {
+ fputs ("allocator(", dumpfile);
+ show_expr (n->u.align);
+ fputc (')', dumpfile);
+ }
+ if (n->expr || n->u.align)
+ fputc (':', dumpfile);
+ fputs (n->sym->name, dumpfile);
+ if (n->next)
+ fputs (") ALLOCATE(", dumpfile);
+ continue;
+ }
if (list_type == OMP_LIST_REDUCTION)
switch (n->u.reduction_op)
{
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index b541a07e2c7..5f8a81ae4a1 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1349,6 +1349,7 @@ typedef struct gfc_omp_namelist
gfc_omp_reduction_op reduction_op;
gfc_omp_depend_doacross_op depend_doacross_op;
gfc_omp_map_op map_op;
+ gfc_expr *align;
struct
{
ENUM_BITFIELD (gfc_omp_linear_op) op:4;
@@ -3572,7 +3573,7 @@ void gfc_free_iterator (gfc_iterator *, int);
void gfc_free_forall_iterator (gfc_forall_iterator *);
void gfc_free_alloc_list (gfc_alloc *);
void gfc_free_namelist (gfc_namelist *);
-void gfc_free_omp_namelist (gfc_omp_namelist *, bool);
+void gfc_free_omp_namelist (gfc_omp_namelist *, bool, bool);
void gfc_free_equiv (gfc_equiv *);
void gfc_free_equiv_until (gfc_equiv *, gfc_equiv *);
void gfc_free_data (gfc_data *);
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index 8b8b6e79c8b..7ba0f349993 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -5524,13 +5524,15 @@ gfc_free_namelist (gfc_namelist *name)
/* Free an OpenMP namelist structure. */
void
-gfc_free_omp_namelist (gfc_omp_namelist *name, bool free_ns)
+gfc_free_omp_namelist (gfc_omp_namelist *name, bool free_ns, bool free_align)
{
gfc_omp_namelist *n;
for (; name; name = n)
{
gfc_free_expr (name->expr);
+ if (free_align)
+ gfc_free_expr (name->u.align);
if (free_ns)
gfc_free_namespace (name->u2.ns);
else if (name->u2.udr)
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 862c649b0b6..4b4e6ac6947 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -187,7 +187,8 @@ gfc_free_omp_clauses (gfc_omp_clauses *c)
gfc_free_expr (c->vector_length_expr);
for (i = 0; i < OMP_LIST_NUM; i++)
gfc_free_omp_namelist (c->lists[i],
- i == OMP_LIST_AFFINITY || i == OMP_LIST_DEPEND);
+ i == OMP_LIST_AFFINITY || i == OMP_LIST_DEPEND,
+ i == OMP_LIST_ALLOCATE);
gfc_free_expr_list (c->wait_list);
gfc_free_expr_list (c->tile_list);
free (CONST_CAST (char *, c->critical_name));
@@ -542,7
Re: Spurious warning for zero-sized array parameters to a function
> On Dec 6, 2022, at 9:22 AM, Alejandro Colomar via Gcc wrote:
>
> Hi!
>
> In the following function, past_end is a pointer to one-past-the-end of the
> array. Holding such a pointer is legal in C. I use it as a sentinel value
> that helps (1) avoid overrunning the buffer, and (2) detect truncation. I
> mark it as having a size of [0], which clearly states that it can't be
> dereferenced (and as you can see, I don't).
>
> /*
> * This function copies an unterminated string into a string.
> * - It never overruns the dest buffer.
> * - It can be chained, to concatenate strings.
> * - It detects truncation.
> * - Truncation only needs to be tested once after all concatenations.
> * - The name is self-documenting, compared to its alternative: strncat(3).
> */
> char *
> ustr2stpe(char *dst, const char *restrict src, size_t n, char past_end[0])
> {
>bool trunc;
>char *end;
>ptrdiff_t len;
>
>if (dst == past_end)
>return past_end;
>
>trunc = false;
>len = strnlen(src, n);
>if (len > past_end - dst - 1) {
>len = past_end - dst - 1;
>trunc = true;
>}
>
>end = mempcpy(dst, src, len);
>*end = '\0';
>
>return trunc ? past_end : end;
> }
>
>
> If I compile the code above, GCC considers the function definition to be
> fine. However, at call site, it always warns:
>
>
> #define nitems(arr) (sizeof((arr)) / sizeof((arr)[0]))
>
> int
> main(void)
> {
>char pre[4] = "pre.";
>char *post = ".post";
>char *src = "some-long-body.post";
>char dest[100];
>char *p, *past_end;
>
>past_end = dest + nitems(dest);
>p = dest;
>p = ustr2stpe(p, pre, nitems(pre), past_end);
>p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
>p = ustr2stpe(p, "", 0, past_end);
>if (p == past_end)
>fprintf(stderr, "truncation\n");
>
>puts(dest); // "pre.some-long-body"
> }
>
>
>
> $ cc -Wall -Wextra ustr2stpe.c
> ustr2stpe.c: In function ‘main’:
> ustr2stpe.c:43:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size
> 0 [-Wstringop-overflow=]
> 43 | p = ustr2stpe(p, pre, nitems(pre), past_end);
> | ^~~~
> ustr2stpe.c:43:13: note: referencing argument 4 of type ‘char[0]’
> ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
> 10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
> past_end[0])
> | ^
> ustr2stpe.c:44:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size
> 0 [-Wstringop-overflow=]
> 44 | p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
> | ^~~
> ustr2stpe.c:44:13: note: referencing argument 4 of type ‘char[0]’
> ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
> 10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
> past_end[0])
> | ^
> ustr2stpe.c:45:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size
> 0 [-Wstringop-overflow=]
> 45 | p = ustr2stpe(p, "", 0, past_end);
> | ^
> ustr2stpe.c:45:13: note: referencing argument 4 of type ‘char[0]’
> ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
> 10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
> past_end[0])
> | ^
> ustr2stpe.c:43:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size
> 0 [-Wstringop-overflow=]
> 43 | p = ustr2stpe(p, pre, nitems(pre), past_end);
> | ^~~~
> ustr2stpe.c:43:13: note: referencing argument 4 of type ‘char[0]’
> ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
> 10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
> past_end[0])
> | ^
> ustr2stpe.c:44:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size
> 0 [-Wstringop-overflow=]
> 44 | p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
> | ^~~
> ustr2stpe.c:44:13: note: referencing argument 4 of type ‘char[0]’
> ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
> 10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
> past_end[0])
> | ^
> ustr2stpe.c:45:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size
> 0 [-Wstringop-overflow=]
> 45 | p = ustr2stpe(p, "", 0, past_end);
> | ^
> ustr2stpe.c:45:13: note: referencing argument 4 of type ‘char[0]’
> ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
> 10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
> past_end[0])
> | ^
>
>
> The warnings are invalid. While it's true that I'm referencing a pointer of
> size 0, it's false that I'm "accessing 1 byte" in that region. I guess this
> is
[Bug libgcc/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ statically linked programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675 m.cencora at gmail dot com changed: What|Removed |Added CC||m.cencora at gmail dot com --- Comment #14 from m.cencora at gmail dot com --- A comment to Thomas proposed patch "[PATCH] initialize fde objects lazily" You cannot use 'relaxed' atomic load in is_object_initialized - as thread performing such load will not observe/synchronize with any modifications (other than atomic variable itself) performed by other threads. Excerpt from cppreference: Relaxed operation: there are no synchronization or ordering constraints imposed on other reads or writes, only this operation's atomicity is guaranteed.
[Bug c++/107495] GCC does not consider the right contextual implicit conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107495 --- Comment #3 from Andrew Pinski --- (In reply to Giuseppe D'Angelo from comment #1) > Variation of the above: The testcase in comment #1 is almost definitely the same as PR 59328. Note the testcase in comment #0 is also rejected by clang ...
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
kargl at gcc dot gnu.org changed:
What|Removed |Added
Severity|normal |enhancement
Priority|P3 |P5
--- Comment #13 from kargl at gcc dot gnu.org ---
(In reply to Ben Barrowes from comment #12)
> Can gfortran be modified to have the option to do this as well?
Sure, gfortran can be modified. The nontrivial part is that there are very few
active contributors to gfortran. I suspect your patch would be much
appreciated.
Until then, you can modify your Makefile with very minor changes to stuff
intermediate files into subdirectories.
% ls
Makefilea1.f90 b1.f90 c1.f90 d1.f90
% cat Makefile
FC = gfortran11
PP = preprocessed/
FF = -c -cpp -save-temps -dumpdir ${PP}
IN = f90
NAMES = a1 b1 c1 d1
all:
mkdir -p ${PP}
.for i in ${NAMES}
${FC} ${FF} $i.${IN}
.endfor
clean:
@rm -rf ${PP} *.o
% make
mkdir -p preprocessed/
gfortran11 -c -cpp -save-temps -dumpdir preprocessed/ a1.f90
gfortran11 -c -cpp -save-temps -dumpdir preprocessed/ b1.f90
gfortran11 -c -cpp -save-temps -dumpdir preprocessed/ c1.f90
gfortran11 -c -cpp -save-temps -dumpdir preprocessed/ d1.f90
% ls
Makefilea1.ob1.oc1.od1.o
a1.f90 b1.f90 c1.f90 d1.f90 preprocessed/
% ls preprocessed/
a1.f90 a1.sb1.f90 b1.sc1.f90 c1.sd1.f90 d1.s
[IRA] Code bloat due to register spills in v9, v10, v11, v12 and master
There is the following code size regression, filed as
https://gcc.gnu.org/PR90706
Simple test cases are, for example
#define PORT (*((unsigned char volatile*) 0x24))
unsigned short var16;
void func (void)
{
if (2048000ul * var16 > 120ul)
PORT |= 1;
}
When I compile it with
$ avr-gcc -Os bloat1.c -c && avr-size bloat1.o
the code size increases from 36 bytes (v8) to 88 bytes (v13).
Apart from that, register pressure is much higher because a frame
pointer is set up for no reason, and the values go through stack slots
for no reason.
Even test cases which don't require any code like
long func2 (void)
{
long var32;
__asm ("; some code %0" : "=r" (var32));
return var32;
}
increase in register pressure (x2), stack usage (from 0 to 6 bytes) and
code size from 2 bytes (v8) to 34 bytes (v13).
Some projects like QMK "solved" the problem by declaring GCC > v8 to be
"incompatible" with their project, see
https://github.com/qmk/qmk_firmware/issues/6719
In own projects I observed the problem, too, and the only solution is to
use v8 or older. Options like -fcaller-saves or -fira-algorithm= have
no effect.
To configure, I used --target=avr --disable-nls --with-dwarf2
--enable-languages=c,c++ --with-gnu-as --with-gnu-ld --disable-shared,
so nothing special.
The problem is present in v9, v10, v11, v12 and master (future v13), so
sitting around for quite a while, so maybe it's not fixed because RA
maintainers are not aware of the problem.
Thanks for any help,
Johann
[Bug middle-end/108036] [11/12/13 Regression] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 --- Comment #5 from Alejandro Colomar --- Interesting. Thanks for clarifying :)
[Bug middle-end/108036] [11/12/13 Regression] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 --- Comment #4 from Andrew Pinski --- (In reply to Alejandro Colomar from comment #3) > - In the reduced test case, you call the pointer to one past the end as > 'end'. That is misleading, since 'end' is commonly also used for pointers > to the last byte in an array, normally the NUL byte in strings. In the C++ standard, the function end() returns one past the last element of an array. So I am not misusing the name end here. Just using it different from you.
[Bug middle-end/108036] [11/12/13 Regression] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 --- Comment #3 from Alejandro Colomar --- Hi Andrew! Just a few nitpicks: - In the first testcase you posted, the [] is missing the 0: [0]. - In the reduced test case, you call the pointer to one past the end as 'end'. That is misleading, since 'end' is commonly also used for pointers to the last byte in an array, normally the NUL byte in strings. Using the term 'end' meaning one-past-the-end is likely to end up in off-by-one errors. So much that I found a few of them for exactly that reason this week :) This last point is why I like using array syntax, so I can clrealy specify 'end[1]' and 'past_end[0]', and they are clearly different things. Cheers, Alex
[Bug middle-end/108036] [11/12/13 Regression] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |11.4 Ever confirmed|0 |1 Last reconfirmed||2022-12-09
[Bug middle-end/108036] [11/12/13 Regression] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 --- Comment #2 from Andrew Pinski --- Created attachment 54056 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54056=edit Reduced testcase
[Bug c/108036] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 --- Comment #1 from Andrew Pinski --- Created attachment 54055 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54055=edit Full testcase that actually compiles
[Bug libstdc++/108035] libstdc++ implementation of std::source_location::function_name() provides an empty string when used with clang++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108035 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/59422 Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- As mentioned there is nothing GCC's libstdc++ can be done if clang/llvm's __builtin_source_location implementation does not fill in the function name.
[Bug c/108037] New: prefer for affinity with OMP_PROC_BIND=true to match "spread" instead of "close"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108037
Bug ID: 108037
Summary: prefer for affinity with OMP_PROC_BIND=true to match
"spread" instead of "close"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yhe at lbl dot gov
Target Milestone: ---
With gcc version 11.2.0 (same for a few previous versions too), it seems that
OMP_PROC_BIND=true does the same affinity as OMP_PROC_BIND=close. When there
are multiple hyperthreads per physical core, and when OMP_PLACES=threads is
set, it will end up with multiple threads bind on the same physical core, which
is not optimal.
I would like to propose OMP_PROC_BIND=true use the same affinity as
OMP_PROC_SPREAD, which is seen in a few other compilers (nvidia, cray, for
example).
Below are some sample affinity output on an Intel Haswell node (32 physical
cores, 2 hyperthreads each).
% numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46
48 50 52 54 56 58 60 62
node 0 size: 257592 MB
node 0 free: 188196 MB
node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47
49 51 53 55 57 59 61 63
node 1 size: 257527 MB
node 1 free: 173862 MB
node distances:
node 0 1
0: 10 21
1: 21 10
% gcc --version
gcc (GCC) 11.2.0 20210728 (Cray Inc.)
Copyright (C) 2021 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.
% more hello-omp.c
#include
#include
int main ()
{
#pragma omp parallel
printf("Hello World... from thread = %d\n", omp_get_thread_num());
}
% gcc -fopenmp hello-omp.c -o hello
% export OMP_NUM_THREADS=4
% export OMP_PLACES=threads
% export OMP_DISPLAY_AFFINITY=true
% export OMP_PROC_BIND=true
% ./hello |sort -k4n
level 1 thread 0x154f3d80 affinity 0
level 1 thread 0x1490b700 affinity 32
level 1 thread 0x1470a700 affinity 1
level 1 thread 0x14509700 affinity 33
Hello World... from thread = 0
Hello World... from thread = 1
Hello World... from thread = 2
Hello World... from thread = 3
% export OMP_PROC_BIND=close
% ./hello |sort -k4n
level 1 thread 0x154f3d80 affinity 0
level 1 thread 0x1490b700 affinity 32
level 1 thread 0x1470a700 affinity 1
level 1 thread 0x14509700 affinity 33
Hello World... from thread = 0
Hello World... from thread = 1
% export OMP_PROC_BIND=spread
% ./hello |sort -k4n
level 1 thread 0x154f3d80 affinity 0
level 1 thread 0x1490b700 affinity 8
level 1 thread 0x1470a700 affinity 16
level 1 thread 0x14509700 affinity 24
Hello World... from thread = 0
Hello World... from thread = 1
Hello World... from thread = 2
Hello World... from thread = 3
When setting OMP_PLACES=cores, even when OMP_PROC_BIND=true still does the same
as OMP_PROC_BIND=close, the affinity for pure OpenMP codes would be fine.
However, it is still preferred that OMP_PROC_BIND=true to use the same affinity
as OMP_PROC_BIND=spread for optimal process and thread affinity for hybrid
MPI/OpenMP codes.
% export OMP_PLACES=cores
% export OMP_PROC_BIND=true
%./hello |sort -k4n
level 1 thread 0x154f3d80 affinity 0,32
level 1 thread 0x1490b700 affinity 1,33
level 1 thread 0x1470a700 affinity 2,34
level 1 thread 0x14509700 affinity 3,35
Hello World... from thread = 0
Hello World... from thread = 1
Hello World... from thread = 2
Hello World... from thread = 3
% export OMP_PROC_BIND=close
% ./hello |sort -k4n
level 1 thread 0x154f3d80 affinity 0,32
level 1 thread 0x1490b700 affinity 1,33
level 1 thread 0x1470a700 affinity 2,34
level 1 thread 0x14509700 affinity 3,35
Hello World... from thread = 0
Hello World... from thread = 1
Hello World... from thread = 2
Hello World... from thread = 3
% export OMP_PROC_BIND=spread
% ./hello |sort -k4n
level 1 thread 0x154f3d80 affinity 0,32
level 1 thread 0x1490b700 affinity 8,40
level 1 thread 0x1470a700 affinity 16,48
level 1 thread 0x14509700 affinity 24,56
Hello World... from thread = 0
Hello World... from thread = 1
Hello World... from thread = 2
Hello World... from thread = 3
[Bug libstdc++/108035] libstdc++ implementation of std::source_location::function_name() provides an empty string when used with clang++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108035 --- Comment #2 from Jonathan Wakely --- Right, if Clang doesn't provide a name then there's nothing libstdc++ can do about it.
[Bug libstdc++/108035] libstdc++ implementation of std::source_location::function_name() provides an empty string when used with clang++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108035 --- Comment #1 from Jakub Jelinek --- That looks solely like a clang issue. It implements the builtin gcc has added for - __builtin_source_location () - but fills in _M_function_name with just "" rather than a pretty name.
[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 --- Comment #10 from Jan-Benedict Glaw --- I gave that patch a try: GCC build is successful, as is the Linux build afterwards using that toolchain. (Cannot test the resulting kernel of course---I don't have the hardware.)
[PATCH v2] RISC-V: Produce better code with complex constants [PR95632] [PR106602]
Changes since v1:
- Fixed formatting issues.
- Added a name to the define_insn_and_split pattern.
- Set the target on the 'dg-do compile' in pr106602.c.
- Removed the rv32 restriction in pr95632.c.
-- >8 --
Due to RISC-V limitations on operations with big constants combine
is failing to match such operations and is not being able to
produce optimal code as it keeps splitting them. By pretending we
can do those operations we can get more opportunities for
simplification of surrounding instructions.
2022-12-06 Raphael Moreira Zinsly
Jeff Law
gcc/Changelog:
PR target/95632
PR target/106602
* config/riscv/riscv.md: New pattern to simulate complex
const_int loads.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr95632.c: New test.
* gcc.target/riscv/pr106602.c: New test.
---
gcc/config/riscv/riscv.md | 15 +++
gcc/testsuite/gcc.target/riscv/pr106602.c | 14 ++
gcc/testsuite/gcc.target/riscv/pr95632.c | 15 +++
3 files changed, 44 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/pr106602.c
create mode 100644 gcc/testsuite/gcc.target/riscv/pr95632.c
diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index df57e2b0b4a..b0daa4b19eb 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -1667,6 +1667,21 @@
MAX_MACHINE_MODE, [3], TRUE);
})
+;; Pretend to have the ability to load complex const_int in order to get
+;; better code generation around them.
+(define_insn_and_split "*mvconst_internal"
+ [(set (match_operand:GPR 0 "register_operand" "=r")
+(match_operand:GPR 1 "splittable_const_int_operand" "i"))]
+ "cse_not_expected"
+ "#"
+ "&& 1"
+ [(const_int 0)]
+{
+ riscv_move_integer (operands[0], operands[0], INTVAL (operands[1]),
+ mode, TRUE);
+ DONE;
+})
+
;; 64-bit integer moves
(define_expand "movdi"
diff --git a/gcc/testsuite/gcc.target/riscv/pr106602.c
b/gcc/testsuite/gcc.target/riscv/pr106602.c
new file mode 100644
index 000..825b1a143b5
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/pr106602.c
@@ -0,0 +1,14 @@
+/* { dg-do compile { target { riscv64*-*-* } } } */
+/* { dg-options "-O2" } */
+
+unsigned long
+foo2 (unsigned long a)
+{
+ return (unsigned long)(unsigned int) a << 6;
+}
+
+/* { dg-final { scan-assembler-times "slli\t" 1 } } */
+/* { dg-final { scan-assembler-times "srli\t" 1 } } */
+/* { dg-final { scan-assembler-not "\tli\t" } } */
+/* { dg-final { scan-assembler-not "addi\t" } } */
+/* { dg-final { scan-assembler-not "and\t" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/pr95632.c
b/gcc/testsuite/gcc.target/riscv/pr95632.c
new file mode 100644
index 000..b865c2f2e97
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/pr95632.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+unsigned short
+foo (unsigned short crc)
+{
+ crc ^= 0x4002;
+ crc >>= 1;
+ crc |= 0x8000;
+
+ return crc;
+}
+
+/* { dg-final { scan-assembler-times "srli\t" 1 } } */
+/* { dg-final { scan-assembler-not "slli\t" } } */
--
2.38.1
[PATCH] i386: correct division modeling in lujiazui.md
Model the divider in Lujiazui processors as a separate automaton to significantly reduce the overall model size. This should also result in improved accuracy, as pipe 0 should be able to accept new instructions while the divider is occupied. It is unclear why integer divisions are modeled as if pipes 0-3 are all occupied. I've opted to keep a single-cycle reservation of all four pipes together, so GCC should continue trying to pack instructions around a division accordingly. Currently top three symbols in insn-automata.o are: 106102 r lujiazui_core_check 106102 r lujiazui_core_transitions 196123 r lujiazui_core_min_issue_delay This patch shrinks all lujiazui tables to: 3 r lujiazui_decoder_min_issue_delay 20 r lujiazui_decoder_transitions 32 r lujiazui_agu_min_issue_delay 126 r lujiazui_agu_transitions 304 r lujiazui_div_base 352 r lujiazui_div_check 352 r lujiazui_div_transitions 1152 r lujiazui_core_min_issue_delay 1592 r lujiazui_agu_translate 1592 r lujiazui_core_translate 1592 r lujiazui_decoder_translate 1592 r lujiazui_div_translate 3952 r lujiazui_div_min_issue_delay 9216 r lujiazui_core_transitions This continues the work on reducing i386 insn-automata.o size started with similar fixes for division and multiplication instructions in znver.md [1][2]. I plan to submit corresponding fixes for b[td]ver[123].md as well. [1] https://inbox.sourceware.org/gcc-patches/23c795d6-403c-5927-e610-f0f1215f5...@ispras.ru/T/#m36e069d43d07d768d4842a779e26b4a0915cc543 [2] https://inbox.sourceware.org/gcc-patches/20221101162637.14238-1-amona...@ispras.ru/ gcc/ChangeLog: PR target/87832 * config/i386/lujiazui.md (lujiazui_div): New automaton. (lua_div): New unit. (lua_idiv_qi): Correct unit in the reservation. (lua_idiv_qi_load): Ditto. (lua_idiv_hi): Ditto. (lua_idiv_hi_load): Ditto. (lua_idiv_si): Ditto. (lua_idiv_si_load): Ditto. (lua_idiv_di): Ditto. (lua_idiv_di_load): Ditto. (lua_fdiv_SF): Ditto. (lua_fdiv_SF_load): Ditto. (lua_fdiv_DF): Ditto. (lua_fdiv_DF_load): Ditto. (lua_fdiv_XF): Ditto. (lua_fdiv_XF_load): Ditto. (lua_ssediv_SF): Ditto. (lua_ssediv_load_SF): Ditto. (lua_ssediv_V4SF): Ditto. (lua_ssediv_load_V4SF): Ditto. (lua_ssediv_V8SF): Ditto. (lua_ssediv_load_V8SF): Ditto. (lua_ssediv_SD): Ditto. (lua_ssediv_load_SD): Ditto. (lua_ssediv_V2DF): Ditto. (lua_ssediv_load_V2DF): Ditto. (lua_ssediv_V4DF): Ditto. (lua_ssediv_load_V4DF): Ditto. (lua_sseicvt_si): Ditto. --- gcc/config/i386/lujiazui.md | 58 +++-- 1 file changed, 30 insertions(+), 28 deletions(-) diff --git a/gcc/config/i386/lujiazui.md b/gcc/config/i386/lujiazui.md index 9046c09f2..58a230c70 100644 --- a/gcc/config/i386/lujiazui.md +++ b/gcc/config/i386/lujiazui.md @@ -19,8 +19,8 @@ ;; Scheduling for ZHAOXIN lujiazui processor. -;; Modeling automatons for decoders, execution pipes and AGU pipes. -(define_automaton "lujiazui_decoder,lujiazui_core,lujiazui_agu") +;; Modeling automatons for decoders, execution pipes, AGU pipes, and divider. +(define_automaton "lujiazui_decoder,lujiazui_core,lujiazui_agu,lujiazui_div") ;; The rules for the decoder are simple: ;; - an instruction with 1 uop can be decoded by any of the three @@ -55,6 +55,8 @@ (define_reservation "lua_decoder01" "lua_decoder0|lua_decoder1") (define_cpu_unit "lua_p0,lua_p1,lua_p2,lua_p3" "lujiazui_core") (define_cpu_unit "lua_p4,lua_p5" "lujiazui_agu") +(define_cpu_unit "lua_div" "lujiazui_div") + (define_reservation "lua_p03" "lua_p0|lua_p3") (define_reservation "lua_p12" "lua_p1|lua_p2") (define_reservation "lua_p1p2" "lua_p1+lua_p2") @@ -229,56 +231,56 @@ (define_insn_reservation "lua_idiv_qi" 21 (and (eq_attr "memory" "none") (and (eq_attr "mode" "QI") (eq_attr "type" "idiv" -"lua_decoder0,lua_p0p1p2p3*21") +"lua_decoder0,lua_p0p1p2p3,lua_div*21") (define_insn_reservation "lua_idiv_qi_load" 25 (and (eq_attr "cpu" "lujiazui") (and (eq_attr "memory" "load") (and (eq_attr "mode" "QI") (eq_attr "type" "idiv" -"lua_decoder0,lua_p45,lua_p0p1p2p3*21") +"lua_decoder0,lua_p45,lua_p0p1p2p3,lua_div*21") (define_insn_reservation "lua_idiv_hi" 22 (and (eq_attr "cpu" "lujiazui") (and (eq_attr "memory" "none") (and (eq_attr "mode" "HI") (eq_attr "type" "idiv" -"lua_decoder0,lua_p0p1p2p3*22") +
Re: Naming flag for specifying the output file name for Binary Module Interface files
Thanks Iain for the summary/thanks everyone for the discussion! On Fri, Dec 9, 2022 at 9:33 AM Iain Sandoe wrote: > > Hello all. > > > On 9 Dec 2022, at 01:58, chuanqi.xcq wrote: > > > > It looks like `-fmodule-file` is better from the discussion. So let's take > > it. Thanks for everyone here > > So FAOD (after this discussion) Chuanqi's current patchset implements the > following in clang: > > -fmodule-output > > - this causes the BMI to be saved in the CWG with the basename of the > source file and a suffix of .pcm. > > -fmodule-output= > > - this causes the BMI to be saved at the path specified. > > === > > These facilities support build systems that do not use the P1184 interface to > map between module names and paths. > > cheers > Iain > > > > > Thanks, > > Chuanqi > > -- > > From:Nathan Sidwell > > Send Time:2022年12月8日(星期四) 01:00 > > To:Iain Sandoe ; GCC Development > > Cc:Jonathan Wakely ; chuanqi.xcq > > ; David Blaikie ; > > ben.boeckel > > Subject:Re: Naming flag for specifying the output file name for Binary > > Module Interface files > > > > On 12/7/22 11:58, Iain Sandoe wrote: > > > > > > > > >> On 7 Dec 2022, at 16:52, Nathan Sidwell via Gcc wrote: > > >> > > >> On 12/7/22 11:18, Iain Sandoe wrote: > > >> > > >>> I think it is reasonable to include c++ in the spelling, since other > > >>> languages supported by > > >>> GCC (and clang in due course) have modules. > > >> > > >> I disagree (about the reasonableness part). Other languages have > > >> modules, true, but if they want to name the output file, why not have > > >> the same option spelling? > > >> > > >> I.e. why are we considering: > > >> > > >>$compiler -fc++-module-file=bob foo.cc > > >>$compiler -ffortran-module-file=bob foo.f77 > > >> > > >> The language is being selected implicitly by the file suffix (or > > >> explictly via -X$lang). There's no reason for some other option > > >> controlling an aspect of the compilation to rename the language. We > > >> don't do it for language-specific warning options, and similar. (i.e. > > >> no -f[no-]c++-type-aliasing vs -fc-type-aliasing, nor -Wc++-extra vs > > >> -Wc-extra[*] > > > > > > Fair points. > > > > > > Unfortunately (in case it has not already been mentioned in this thread) > > > ‘-fmodule-file=‘ is already taken and it means an input, not an output. > > > So, whatever we choose it needs to be distinct from that. > > > > Yes, that's why I suggested -fmodule-output= > > > > nathan > > > > -- > > Nathan Sidwell >
[PATCH] initialize fde objects lazily
When registering an unwind frame with __register_frame_info_bases
we currently initialize that fde object eagerly. This has the
advantage that it is immutable afterwards and we can safely
access it from multiple threads, but it has the disadvantage
that we pay the initialization cost even if the application
never throws an exception.
This commit changes the logic to initialize the objects lazily.
The objects themselves are inserted into the b-tree when
registering the frame, but the sorted fde_vector is
not constructed yet. Only on the first time that an
exception tries to pass through the registered code the
object is initialized. We notice that with a double checking,
first doing a relaxed load of the sorted bit and then re-checking
under a mutex when the object was not initialized yet.
Note that the check must implicitly be safe concering a concurrent
frame deregistration, as trying the deregister a frame that is
on the unwinding path of a concurrent exception is inherently racy.
libgcc/ChangeLog:
* unwind-dw2-fde.c: Initialize fde object lazily when
the first exception tries to pass through.
---
libgcc/unwind-dw2-fde.c | 52 -
1 file changed, 41 insertions(+), 11 deletions(-)
diff --git a/libgcc/unwind-dw2-fde.c b/libgcc/unwind-dw2-fde.c
index 3c0cc654ec0..6f69c20ff4b 100644
--- a/libgcc/unwind-dw2-fde.c
+++ b/libgcc/unwind-dw2-fde.c
@@ -63,8 +63,6 @@ release_registered_frames (void)
static void
get_pc_range (const struct object *ob, uintptr_type *range);
-static void
-init_object (struct object *ob);
#else
/* Without fast path frame deregistration must always succeed. */
@@ -76,6 +74,7 @@ static const int in_shutdown = 0;
by decreasing value of pc_begin. */
static struct object *unseen_objects;
static struct object *seen_objects;
+#endif
#ifdef __GTHREAD_MUTEX_INIT
static __gthread_mutex_t object_mutex = __GTHREAD_MUTEX_INIT;
@@ -103,7 +102,6 @@ init_object_mutex_once (void)
static __gthread_mutex_t object_mutex;
#endif
#endif
-#endif
/* Called from crtbegin.o to register the unwind info for an object. */
@@ -126,10 +124,7 @@ __register_frame_info_bases (const void *begin, struct object *ob,
#endif
#ifdef ATOMIC_FDE_FAST_PATH
- // Initialize eagerly to avoid locking later
- init_object (ob);
-
- // And register the frame
+ // Register the frame in the b-tree
uintptr_type range[2];
get_pc_range (ob, range);
btree_insert (_frames, range[0], range[1] - range[0], ob);
@@ -180,10 +175,7 @@ __register_frame_info_table_bases (void *begin, struct
object *ob,
ob->s.b.encoding = DW_EH_PE_omit;
#ifdef ATOMIC_FDE_FAST_PATH
- // Initialize eagerly to avoid locking later
- init_object (ob);
-
- // And register the frame
+ // Register the frame in the b-tree
uintptr_type range[2];
get_pc_range (ob, range);
btree_insert (_frames, range[0], range[1] - range[0], ob);
@@ -892,7 +884,15 @@ init_object (struct object* ob)
accu.linear->orig_data = ob->u.single;
ob->u.sort = accu.linear;
+#ifdef ATOMIC_FDE_FAST_PATH
+ // We must update the sorted bit with an atomic operation
+ struct object tmp;
+ tmp.s.b = ob->s.b;
+ tmp.s.b.sorted = 1;
+ __atomic_store (&(ob->s.b), &(tmp.s.b), __ATOMIC_SEQ_CST);
+#else
ob->s.b.sorted = 1;
+#endif
}
#ifdef ATOMIC_FDE_FAST_PATH
@@ -1130,6 +1130,21 @@ search_object (struct object* ob, void *pc)
}
}
+#ifdef ATOMIC_FDE_FAST_PATH
+
+// Check if the object was already initialized
+static inline bool
+is_object_initialized (struct object *ob)
+{
+ // We have to use relaxed atomics for the read, which
+ // is a bit involved as we read from a bitfield
+ struct object tmp;
+ __atomic_load (&(ob->s.b), &(tmp.s.b), __ATOMIC_RELAXED);
+ return tmp.s.b.sorted;
+}
+
+#endif
+
const fde *
_Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
{
@@ -1141,6 +1156,21 @@ _Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
if (!ob)
return NULL;
+ // Initialize the object lazily
+ if (!is_object_initialized (ob))
+{
+ // Check again under mutex
+ init_object_mutex_once ();
+ __gthread_mutex_lock (_mutex);
+
+ if (!ob->s.b.sorted)
+ {
+ init_object (ob);
+ }
+
+ __gthread_mutex_unlock (_mutex);
+}
+
f = search_object (ob, pc);
#else
--
2.37.2
Re: Naming flag for specifying the output file name for Binary Module Interface files
Hello all. > On 9 Dec 2022, at 01:58, chuanqi.xcq wrote: > > It looks like `-fmodule-file` is better from the discussion. So let's take > it. Thanks for everyone here So FAOD (after this discussion) Chuanqi's current patchset implements the following in clang: -fmodule-output - this causes the BMI to be saved in the CWG with the basename of the source file and a suffix of .pcm. -fmodule-output= - this causes the BMI to be saved at the path specified. === These facilities support build systems that do not use the P1184 interface to map between module names and paths. cheers Iain > > Thanks, > Chuanqi > -- > From:Nathan Sidwell > Send Time:2022年12月8日(星期四) 01:00 > To:Iain Sandoe ; GCC Development > Cc:Jonathan Wakely ; chuanqi.xcq > ; David Blaikie ; > ben.boeckel > Subject:Re: Naming flag for specifying the output file name for Binary Module > Interface files > > On 12/7/22 11:58, Iain Sandoe wrote: > > > > > >> On 7 Dec 2022, at 16:52, Nathan Sidwell via Gcc wrote: > >> > >> On 12/7/22 11:18, Iain Sandoe wrote: > >> > >>> I think it is reasonable to include c++ in the spelling, since other > >>> languages supported by > >>> GCC (and clang in due course) have modules. > >> > >> I disagree (about the reasonableness part). Other languages have modules, > >> true, but if they want to name the output file, why not have the same > >> option spelling? > >> > >> I.e. why are we considering: > >> > >>$compiler -fc++-module-file=bob foo.cc > >>$compiler -ffortran-module-file=bob foo.f77 > >> > >> The language is being selected implicitly by the file suffix (or explictly > >> via -X$lang). There's no reason for some other option controlling an > >> aspect of the compilation to rename the language. We don't do it for > >> language-specific warning options, and similar. (i.e. no > >> -f[no-]c++-type-aliasing vs -fc-type-aliasing, nor -Wc++-extra vs > >> -Wc-extra[*] > > > > Fair points. > > > > Unfortunately (in case it has not already been mentioned in this thread) > > ‘-fmodule-file=‘ is already taken and it means an input, not an output. > > So, whatever we choose it needs to be distinct from that. > > Yes, that's why I suggested -fmodule-output= > > nathan > > -- > Nathan Sidwell
[Bug c/108036] New: Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036
Bug ID: 108036
Summary: Spurious warning for zero-sized array parameters to a
function
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: colomar.6.4.3 at gmail dot com
Target Milestone: ---
It's interesting to pass pointers to one past the end of an array to a
function, acting as a sentinel value that serves as an alternative to the size
of the buffer. It helps chaining string copy functions, for example:
char *
ustr2stpe(char *dst, const char *restrict src, size_t n, char past_end[0])
{
bool trunc;
char *end;
ptrdiff_t len;
if (dst == past_end)
return past_end;
trunc = false;
len = strnlen(src, n);
if (len > past_end - dst - 1) {
len = past_end - dst - 1;
trunc = true;
}
end = mempcpy(dst, src, len);
*end = '\0';
return trunc ? past_end : end;
}
However, if you use array syntax for it, which clarifies where it points to,
the GCC complains, not at the function implementation, but at call site:
#define nitems(arr) (sizeof((arr)) / sizeof((arr)[0]))
int
main(void)
{
char pre[4] = "pre.";
char *post = ".post";
char *src = "some-long-body.post";
char dest[100];
char *p, *past_end;
past_end = dest + nitems(dest);
p = dest;
p = ustr2stpe(p, pre, nitems(pre), past_end);
p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
p = ustr2stpe(p, "", 0, past_end);
if (p == past_end)
fprintf(stderr, "truncation\n");
puts(dest); // "pre.some-long-body"
}
$ cc -Wall -Wextra ustr2stpe.c
ustr2stpe.c: In function ‘main’:
ustr2stpe.c:43:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
43 | p = ustr2stpe(p, pre, nitems(pre), past_end);
| ^~~~
ustr2stpe.c:43:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:44:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
44 | p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
| ^~~
ustr2stpe.c:44:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:45:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
45 | p = ustr2stpe(p, "", 0, past_end);
| ^
ustr2stpe.c:45:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:43:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
43 | p = ustr2stpe(p, pre, nitems(pre), past_end);
| ^~~~
ustr2stpe.c:43:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:44:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
44 | p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
| ^~~
ustr2stpe.c:44:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:45:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
45 | p = ustr2stpe(p, "", 0, past_end);
| ^
ustr2stpe.c:45:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
The warnings are invalid. While it's true that I'm referencing a pointer of
size 0, it's false that I'm "accessing 1 byte" in that region. I guess this is
all about the bogus design of 'static' in ISO C, where you can have an array
parameter of size 0, which is very
Re: Spurious warning for zero-sized array parameters to a function
Hi Richard,
On 12/7/22 09:17, Richard Biener wrote:
[...]
The warnings are invalid. While it's true that I'm referencing a pointer of
size 0, it's false that I'm "accessing 1 byte" in that region. I guess this is
all about the bogus design of 'static' in ISO C, where you can have an array
parameter of size 0, which is very useful in cases like this one.
It looks like we run into pass_waccess::maybe_check_access_sizes doing
if (sizidx == -1)
{
/* If only the pointer attribute operand was specified and
not size, set SIZE to the greater of MINSIZE or size of
one element of the pointed to type to detect smaller
objects (null pointers are diagnosed in this case only
if the pointer is also declared with attribute nonnull. */
if (access.second.minsize
&& access.second.minsize != HOST_WIDE_INT_M1U)
access_nelts = build_int_cstu (sizetype, access.second.minsize);
else if (VOID_TYPE_P (argtype) && access.second.mode == access_none)
/* Treat access mode none on a void* argument as expecting
as little as zero bytes. */
access_nelts = size_zero_node;
else
access_nelts = size_one_node;
and use size_one_node as fallback - it either doesn't consider [0] "valid" or
for some reason chooses to interpret it as "unknown". Can you file a bugreport
please?
Sure; will do!
Cheers,
Alex
Martin?
Richard.
--
Missing optimization: mempcpy(3) vs memcpy(3)
Hi!
I expect mempcpy(3) to be at least as fast as memcpy(3), since it performs the
same operations, with the exception that mempcpy(3) returns something useful (as
opposed to memcpy(3), which could perfectly return void), and in fact something
more likely to be in cache, if the copy is performed upwards.
The following two files are alternative implementations of a function, each one
written in terms of one of memcpy(3) and mempcpy(3):
$ cat usts2stp1.c
#include
struct ustr_s {
size_t len;
char*ustr;
};
char *
usts2stp(char *restrict dst, const struct ustr_s *restrict src)
{
memcpy(dst, src->ustr, src->len);
dst[src->len] = '\0';
return dst + src->len;
}
$ cat usts2stp3.c
#define _GNU_SOURCE
#include
struct ustr_s {
size_t len;
char*ustr;
};
char *
usts2stp(char *restrict dst, const struct ustr_s *restrict src)
{
char *end;
end = mempcpy(dst, src->ustr, src->len);
*end = '\0';
return end;
}
I expect the compiler to be knowledgeable enough to call whatever is fastest,
whatever it is, but be consistent in both cases. However, here are the results:
$ cc -Wall -Wextra -O3 -S usts2stp*.c
$ diff -u usts2stp[13].s
--- usts2stp1.s 2022-12-09 18:06:11.708367061 +0100
+++ usts2stp3.s 2022-12-09 18:06:11.740366451 +0100
@@ -1,4 +1,4 @@
- .file "usts2stp1.c"
+ .file "usts2stp3.c"
.text
.p2align 4
.globl usts2stp
@@ -6,16 +6,13 @@
usts2stp:
.LFB0:
.cfi_startproc
- pushq %rbx
+ subq$8, %rsp
.cfi_def_cfa_offset 16
- .cfi_offset 3, -16
- movq(%rsi), %rbx
+ movq(%rsi), %rdx
movq8(%rsi), %rsi
- movq%rbx, %rdx
- callmemcpy@PLT
- leaq(%rax,%rbx), %rax
+ callmempcpy@PLT
movb$0, (%rax)
- popq%rbx
+ addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
The code with memcpy(3) seems to be worse (assuming both calls to be
equivalent). Shouldn't GCC produce the same code for both implementations?
Cheers,
Alex
--
[Bug libstdc++/108035] New: std::source_location::function_name() provides an empty string when used with clang++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108035 Bug ID: 108035 Summary: std::source_location::function_name() provides an empty string when used with clang++ Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danhan at live dot ie Target Milestone: --- I ran this minimal example from cppreference https://en.cppreference.com/w/cpp/utility/source_location on godbolt https://godbolt.org/z/jYMYb8ez6 and source_location::function_name() returned an empty string where if the same code is compiled with gcc it returns what appears to be the value of __PRETTY_FUNCTION__ for the caller of the log(...) function, as both have __PRETTY_FUNCTION__ as an internal I would have expected the behavior to be the same. Consequentally I have posted this on the llvm bugtracker as well :) https://github.com/llvm/llvm-project/issues/59422
[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569 --- Comment #43 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #42) > On #c0 foo, this was previously optimized in dom2 which optimized > _4 = ABS_EXPR ; > _3 = _4 u> 1.79769313486231570814527423731704356798070567525844996599e+308; > _5 = ~_3; > if (_4 u> 1.79769313486231570814527423731704356798070567525844996599e+308) > goto ; [0.00%] > else > goto ; [100.00%] > >[count: 0]: > __builtin_unreachable (); > >[local count: 1073741824]: > return _5; > without any frange related stuff as: > - if (_4 u> 1.79769313486231570814527423731704356798070567525844996599e+308) > + if (_3 != 0) > and > - return _5; > + return 1; > > But because __builtin_unreachable () is now removed earlier (vrp1 already; > without providing useful global range though), we don't do that anymore. Hmm. its because when vrp1 removes the branch to builtin_unreachable, it calculates the global range of _4 as the union of all the ranges at each use.. this is to avoid issues where the unreachable call may not post-dominate an earlier use. THe initial use of _4 still is resolved to only [0, max] so we end up only using that for the range. Im experimenting with doing things the same way, except NOT removing the branch in VRP, but continuing to set the global range the way we do. I might also be able to revisit the branch *after* all the globals have been set, and see if the globals values now cause the condition to fold, and if they do, remove them only then... ThIs would leave the above case for DOM2 (or someone else to resolve). It seems like it might be a reasonable balance... ie, we only remove the unreachable in VRP1 if we can determine with 100% positivity that setting the global value will result in the branch being able to remove. Its also possible it could also just be left... and another pass should remove it shortly as it folds away... and certainly by VRP2 time... Anyway, I'll try it a few ways and see what seems to work best.
[Bug web/107333] bugzilla see also should support savannah bug URLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107333 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug web/108034] New: cannot use bug alias name in see also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108034 Bug ID: 108034 Summary: cannot use bug alias name in see also Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- If you try to use an alias name for a bug in the see also, you get an error message saying it is not an URL. I would have expected to do a search for the alias before reporting that error.
[Bug libstdc++/106852] Implement C++23 P2465R3 Standard Library Modules std and std.compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103524 Last reconfirmed||2022-12-09 --- Comment #2 from Andrew Pinski --- .
[Bug c++/106658] [C++23] P2590 - Explicit lifetime management
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106658 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-09 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- .
[Bug c++/106657] [C++23] P2460 - Relax requirements on wchar_t to match existing practices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106657 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-09 --- Comment #1 from Andrew Pinski --- .
[Bug c++/106653] [C++23] P2582 - Class template argument deduction from inherited constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106653 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-09 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- .
[Bug c++/106650] [C++23] P2280 - Using unknown references in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106650 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-09 --- Comment #1 from Andrew Pinski --- .
[Bug c++/105595] Coroutines can trigger -Wsubobject-linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105595 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-09 --- Comment #2 from Andrew Pinski --- Confirmed. I noticed this also when reducing a different testcase.
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 Andrew Pinski changed: What|Removed |Added CC||thiago at kde dot org --- Comment #19 from Andrew Pinski --- *** Bug 105509 has been marked as a duplicate of this bug. ***
[Bug c++/105509] [compatibility] f16 suffix not supported in C++ mode - unable to find numeric literal operator ‘operator""f16’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105509 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 106652. f16 was added for GCC 13. *** This bug has been marked as a duplicate of bug 106652 ***
[Bug target/104951] avx512fintrin.h(9146): error: identifier "__builtin_ia32_rndscaless_round" is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104951 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #3 from Andrew Pinski --- Not a GCC bug so closing.
Patch ping
Hi!
I'd like to ping a few pending patches:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606973.html
- PR107465 - c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607104.html
- PR107465 - c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR
handling
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607145.html
- PR107558 - c++: Don't clear TREE_READONLY for -fmerge-all-constants for
non-aggregates
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
- PR107846 - c-family: Account for integral promotions of left shifts for
-Wshift-overflow warning
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606382.html
- PR107703 - libgcc, i386: Add __fix{,uns}bfti and __float{,un}tibf
Thanks
Jakub
Re: [PATCH] AArch64: Enable TARGET_CONST_ANCHOR
Wilco Dijkstra writes:
> Enable TARGET_CONST_ANCHOR to allow complex constants to be created via
> immediate add.
> Use a 24-bit range as that enables a 3 or 4-instruction immediate to be
> replaced by
> 2 additions. Fix the costing of immediate add to support 24-bit immediate
> and 12-bit shifted
> immediates. The generated code for the testcase is now the same or better
> than LLVM.
> It also results in a small codesize reduction on SPEC.
>
> Passes bootstrap and regress, OK for commit?
>
> gcc/
> * config/aarch64/aarch64.cc (aarch64_rtx_costs): Add correct costs for
> 24-bit immediate add and 12-bit high immediate add.
Very minor, but it might be worth saying "add/sub" rather than "add".
The reason picking the 24-bit range is right is that add & sub together
give us a 25-bit range.
> (TARGET_CONST_ANCHOR): Define.
>
> gcc/testsuite/
> * gcc.target/aarch64/movk_3.c: New test.
>
> ---
>
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index
> e97f3b32f7c7f43564d6a4207eae5a34b9e9bfe7..a73741800c963ee6605fd2cfa918f4399da4bfdf
> 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -14257,6 +14257,16 @@ cost_plus:
> return true;
> }
>
> + if (aarch64_pluslong_immediate (op1, mode))
> + {
> + /* 24-bit add in 2 instructions or 12-bit shifted add. */
> + if ((INTVAL (op1) & 0xfff) != 0)
> + *cost += COSTS_N_INSNS (1);
> +
> + *cost += rtx_cost (op0, mode, PLUS, 0, speed);
> + return true;
> + }
> +
I guess for consistency, we arguably should add extra_cost->alu.arith
for each instruction, like we do for the other cases. But that seems
a bit daft when all arith costs are 0. And it's hard to believe that
they would be nonzero for any new core (i.e. that a plain addition
would be more expensive than a typical "fast" instruction). ADD
immediate is effectively the benchmark cost of COSTS_N_INSN (1).
So I agree what you wrote is what we should use. It might be good to
get rid of the existing uses of alu.arith (for integer ADD only), as a
separate follow-up patch.
It looks like there's an off-by-one error in:
(define_predicate "aarch64_pluslong_immediate"
(and (match_code "const_int")
(match_test "(INTVAL (op) < 0xff && INTVAL (op) > -0xff)")))
which might make the optimisation fail at the extremes. I think it
should be:
(define_predicate "aarch64_pluslong_immediate"
(and (match_code "const_int")
(match_test "IN_RANGE (ival, -0xff, 0xff)")))
instead.
OK with that change to the predicate, thanks.
Richard
> *cost += rtx_cost (op1, mode, PLUS, 1, speed);
>
> /* Look for ADD (extended register). */
> @@ -28051,6 +28061,9 @@ aarch64_libgcc_floating_mode_supported_p
> #undef TARGET_HAVE_SHADOW_CALL_STACK
> #define TARGET_HAVE_SHADOW_CALL_STACK true
>
> +#undef TARGET_CONST_ANCHOR
> +#define TARGET_CONST_ANCHOR 0x100
> +
> struct gcc_target targetm = TARGET_INITIALIZER;
>
> #include "gt-aarch64.h"
> diff --git a/gcc/testsuite/gcc.target/aarch64/movk_3.c
> b/gcc/testsuite/gcc.target/aarch64/movk_3.c
> new file mode 100644
> index
> ..9e8c0c42671bef3f63028b4e51d0bd78c9903994
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/movk_3.c
> @@ -0,0 +1,56 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 --save-temps" } */
> +
> +
> +/* 2 MOV */
> +void f16 (long *p)
> +{
> + p[0] = 0x1234;
> + p[2] = 0x1235;
> +}
> +
> +/* MOV, MOVK and ADD */
> +void f32_1 (long *p)
> +{
> + p[0] = 0x12345678;
> + p[2] = 0x12345678 + 0xfff;
> +}
> +
> +/* 2 MOV, 2 MOVK */
> +void f32_2 (long *p)
> +{
> + p[0] = 0x12345678;
> + p[2] = 0x12345678 + 0x55;
> +}
> +
> +/* MOV, MOVK and ADD */
> +void f32_3 (long *p)
> +{
> + p[0] = 0x12345678;
> + p[2] = 0x12345678 + 0x999000;
> +}
> +
> +/* MOV, 2 MOVK and ADD */
> +void f48_1 (long *p)
> +{
> + p[0] = 0x123456789abc;
> + p[2] = 0x123456789abc + 0xfff;
> +}
> +
> +/* MOV, 2 MOVK and 2 ADD */
> +void f48_2 (long *p)
> +{
> + p[0] = 0x123456789abc;
> + p[2] = 0x123456789abc + 0x66;
> +}
> +
> +/* 2 MOV, 4 MOVK */
> +void f48_3 (long *p)
> +{
> + p[0] = 0x123456789abc;
> + p[2] = 0x123456789abc + 0x166;
> +}
> +
> +/* { dg-final { scan-assembler-times "mov\tx\[0-9\]+, \[0-9\]+" 10 } } */
> +/* { dg-final { scan-assembler-times "movk\tx\[0-9\]+, 0x\[0-9a-f\]+" 12 } }
> */
> +/* { dg-final { scan-assembler-times "add\tx\[0-9\]+, x\[0-9\]+, \[0-9\]+" 5
> } } */
[Bug preprocessor/104471] ICE with -nostdinc: NULL directory in find_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104471
--- Comment #2 from Andrew Pinski ---
This patch should fix the issue (I might get to it in a few weeks though):
diff --git a/libcpp/files.cc b/libcpp/files.cc
index a18b1caf48d..eb90fa4f65a 100644
--- a/libcpp/files.cc
+++ b/libcpp/files.cc
@@ -177,7 +177,7 @@ static bool read_file_guts (cpp_reader *pfile, _cpp_file
*file,
static bool read_file (cpp_reader *pfile, _cpp_file *file,
location_t loc);
static struct cpp_dir *search_path_head (cpp_reader *, const char *fname,
-int angle_brackets, enum include_type);
+int angle_brackets, enum include_type, bool =
true);
static const char *dir_name_of_file (_cpp_file *file);
static void open_file_failed (cpp_reader *pfile, _cpp_file *file, int,
location_t);
@@ -1026,7 +1026,7 @@ _cpp_mark_file_once_only (cpp_reader *pfile, _cpp_file
*file)
nothing left in the path, returns NULL. */
static struct cpp_dir *
search_path_head (cpp_reader *pfile, const char *fname, int angle_brackets,
- enum include_type type)
+ enum include_type type, bool canerror)
{
cpp_dir *dir;
_cpp_file *file;
@@ -1055,7 +1055,7 @@ search_path_head (cpp_reader *pfile, const char *fname,
int angle_brackets,
return make_cpp_dir (pfile, dir_name_of_file (file),
pfile->buffer ? pfile->buffer->sysp : 0);
- if (dir == NULL)
+ if (canerror && dir == NULL)
cpp_error (pfile, CPP_DL_ERROR,
"no include path in which to search for %s", fname);
@@ -2144,7 +2144,9 @@ bool
_cpp_has_header (cpp_reader *pfile, const char *fname, int angle_brackets,
enum include_type type)
{
- cpp_dir *start_dir = search_path_head (pfile, fname, angle_brackets, type);
+ cpp_dir *start_dir = search_path_head (pfile, fname, angle_brackets, type,
false);
+ if (!start_dir)
+return false;
_cpp_file *file = _cpp_find_file (pfile, fname, start_dir, angle_brackets,
_cpp_FFK_HAS_INCLUDE, 0);
return file->err_no != ENOENT;
[Bug preprocessor/104471] ICE with -nostdinc: NULL directory in find_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104471 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-09 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug libstdc++/108030] `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 --- Comment #4 from Jakub Jelinek --- (In reply to Matthias Kretz (Vir) from comment #3) > (In reply to Jakub Jelinek from comment #2) > > I bet by adding too many always_inline functions that call normal inlines > > that is what is bound to happen, one runs into inline growth limits. It is > > better to use always_inline on the leaf functions rather than on what calls > > them. > > How is the inline growth limit determined? I mean, in the cases where it > really hurts, the resulting function compiles down to a single instruction > (plus parameter passing boilerplate). The optimizer cannot know about the > number of instructions, so what is the measure it uses? I've CCed Honza, who should know the answers. The inliner can't know if say some builtin will fold into a single instruction or not, it uses some heuristics on GIMPLE IL sizes. Bet -fdump-ipa-inline-details contain all the reasons, but at least for me those dumps are hard to read.
[Bug target/108033] -G should be an alias to -msmall-data-limit=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108033 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/108033] New: -G should be an alias to -msmall-data-limit=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108033 Bug ID: 108033 Summary: -G should be an alias to -msmall-data-limit= Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: riscv*-*-* -G is the more generic option name and someone coming from MIPS, or another embedded target, they will know about -G before they know about -msmall-data-limit= option.
[Bug libstdc++/108030] `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 --- Comment #3 from Matthias Kretz (Vir) --- (In reply to Jakub Jelinek from comment #2) > I bet by adding too many always_inline functions that call normal inlines > that is what is bound to happen, one runs into inline growth limits. It is > better to use always_inline on the leaf functions rather than on what calls > them. How is the inline growth limit determined? I mean, in the cases where it really hurts, the resulting function compiles down to a single instruction (plus parameter passing boilerplate). The optimizer cannot know about the number of instructions, so what is the measure it uses? Especially with the helper functions necessary to work with parameter packs / index_sequence, it's not enough to use always_inline on the leaf functions. E.g. any simd binary operator basically should be [[gnu::always_inline, gnu::flatten]]. However, simd maybe shouldn't use 'flatten' for functions that call a user-provided callable (e.g. the simd generator constructor).
[Bug target/108032] internal compiler error : in final_scan_insn_1, at final.c:3079
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108032 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Also note that GCC 9.x is not supported anymore.
Re: [Patch] libgomp: Handle OpenMP's reverse offloads
On Tue, Dec 06, 2022 at 08:45:07AM +0100, Tobias Burnus wrote: > 32bit vs. 64bit: libgomp itself is compiled with both -m32 and -m64; however, > nvptx and gcn requires -m64 on the device side and assume that the device > pointers are representable on the host (i.e. all are 64bit). The new code > tries to be in principle compatible with uint32_t pointers and uses uint64_t > to represent it consistently. – The code should be mostly fine, except that > one called function requires an array of void* and size_t. Instead of handling > that case, I added some code to permit optimizing away the function content > without offloading - and a run-time assert if it should ever happen that this > function gets called on a 32bit host from the target side. I think we just shouldn't support libgomp plugins for 32-bit libgomp, only host fallback. If you want offloading, use 64-bit host... > libgomp: Handle OpenMP's reverse offloads > > This commit enabled reverse offload for nvptx such that gomp_target_rev > actually gets called. And it fills the latter function to do all of > the following: finding the host function to the device func ptr and > copying the arguments to the host, processing the mapping/firstprivate, > calling the host function, copying back the data and freeing as needed. > > The data handling is made easier by assuming that all host variables > either existed before (and are in the mapping) or that those are > devices variables not yet available on the host. Thus, the reverse > mapping can do without refcounts etc. Note that the spec disallows > inside a target region device-affecting constructs other than target > plus ancestor device-modifier and it also limits the clauses permitted > on this construct. > > For the function addresses, an additional splay tree is used; for > the lookup of mapped variables, the existing splay-tree is used. > Unfortunately, its data structure requires a full walk of the tree; > Additionally, the just mapped variables are recorded in a separate > data structure an extra lookup. While the lookup is slow, assuming > that only few variables get mapped in each reverse offload construct > and that reverse offload is the exception and not performance critical, > this seems to be acceptable. > > libgomp/ChangeLog: > > * libgomp.h (struct target_mem_desc): Predeclare; move > below after 'reverse_splay_tree_node' and add rev_array > member. > (struct reverse_splay_tree_key_s, reverse_splay_compare): New. > (reverse_splay_tree_node, reverse_splay_tree, > reverse_splay_tree_key): New typedef. > (struct gomp_device_descr): Add mem_map_rev member. > * oacc-host.c (host_dispatch): NULL init .mem_map_rev. > * plugin/plugin-nvptx.c (GOMP_OFFLOAD_get_num_devices): Claim > support for GOMP_REQUIRES_REVERSE_OFFLOAD. > * splay-tree.h (splay_tree_callback_stop): New typedef; like > splay_tree_callback but returning int not void. > (splay_tree_foreach_lazy): Define; like splay_tree_foreach but > taking splay_tree_callback_stop as argument. > * splay-tree.c (splay_tree_foreach_internal_lazy, > splay_tree_foreach_lazy): New; but early exit if callback returns > nonzero. > * target.c: Instatiate splay_tree_c with splay_tree_prefix 'reverse'. > (gomp_map_lookup_rev): New. > (gomp_load_image_to_device): Handle reverse-offload function > lookup table. > (gomp_unload_image_from_device): Free devicep->mem_map_rev. > (struct gomp_splay_tree_rev_lookup_data, gomp_splay_tree_rev_lookup, > gomp_map_rev_lookup, struct cpy_data, gomp_map_cdata_lookup_int, > gomp_map_cdata_lookup): New auxiliary structs and functions for > gomp_target_rev. > (gomp_target_rev): Implement reverse offloading and its mapping. > (gomp_target_init): Init current_device.mem_map_rev.root. > * testsuite/libgomp.fortran/reverse-offload-2.f90: New test. > * testsuite/libgomp.fortran/reverse-offload-3.f90: New test. > * testsuite/libgomp.fortran/reverse-offload-4.f90: New test. > * testsuite/libgomp.fortran/reverse-offload-5.f90: New test. > * testsuite/libgomp.fortran/reverse-offload-5a.f90: New test without > mapping of on-device allocated variables. > + /* Likeverse for the reverse lookup device->host for reverse offload. */ Likewise > + reverse_splay_tree_node rev_array; Do we need reverse_splay_tree* stuff in libgomp.h? As splay_tree_node is just a pointer, perhaps just struct reverse_splay_tree_node_s; early and struct reverse_splay_tree_node_s *rev_array; in libgomp.h and include the extra splay-tree.h only in target.c? Unless one needs it anywhere else... Otherwise LGTM. Jakub
Re: The method of determining the specific assignment of gcc optimization options
This question belongs on the gcc-help mailing list, not here. On Fri, 9 Dec 2022 at 12:01, hongjie wu via Gcc wrote: > > Dear Sir or Madam， > I want to know how to obtain optimal level of the value of the What do you mean by optimal? They have pros and cons. > specific compiler options, for example - fexcess - precision = [fast | > standard] [default], including the default represent？Or how to determine? gcc -Q --help=optim > I am looking forward to your favorable replay.
[Bug c++/107977] ICE: in add_specializations, at cp/module.cc:13186 with -fdump-ada-spec -fmodule-header since r11-6084-g4efde6781bba8d64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107977 Andrew Pinski changed: What|Removed |Added Summary|[11/12/13 Regression] ICE: |ICE: in |in add_specializations, at |add_specializations, at |cp/module.cc:13186 with |cp/module.cc:13186 with |-fdump-ada-spec |-fdump-ada-spec |-fmodule-header since |-fmodule-header since |r11-6084-g4efde6781bba8d64 |r11-6084-g4efde6781bba8d64 --- Comment #2 from Andrew Pinski --- This is not a regression as -fmodule-header didn't exist before that revision.
[Bug target/108032] internal compiler error : in final_scan_insn_1, at final.c:3079
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108032 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2022-12-09 Ever confirmed|0 |1 Component|c++ |target --- Comment #1 from Andrew Pinski --- /* If we have a length attribute, this instruction should have been split in shorten_branches, to ensure that we would have valid length info for the splitees. */ gcc_assert (!HAVE_ATTR_length); Can you read https://gcc.gnu.org/bugs/ and provide what is requested there?
[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753 --- Comment #9 from fiesh at zefix dot tv --- I forgot to mention that my test case requires -flto to be present.
[Bug c++/108032] New: internal compiler error : in final_scan_insn_1, at final.c:3079
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108032 Bug ID: 108032 Summary: internal compiler error : in final_scan_insn_1, at final.c:3079 Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ramesh.rajender at mavenir dot com Target Milestone: --- Error: = IScpCmiApp.cpp: In member function ‘virtual void IScpCmiApp::_ZThn23947680_N10IScpCmiAppD1Ev()’: IScpCmiApp.cpp:7128:1: internal compiler error: in final_scan_insn_1, at final.c:3079 7128 | } Sample Code: = IScpCmiApp::IScpCmiApp(): AsCommonCmi< CMI >(INTERFACE_ISCP), TasRegionCmi, IScpCmiApp >::TasRegionCmi(INTERFACE_ISCP), HASyncCmi< CMI >(INTERFACE_ISCP), TasDiamCmi,IScpCmiApp>::TasDiamCmi(INTERFACE_ISCP), CtasDiamAppInterfaceMap,IScpCmiApp>::CtasDiamAppInterfaceMap(INTERFACE_ISCP), RestApiTemplates,IScpCmiApp>::RestApiTemplates(INTERFACE_ISCP)
