[Bug c++/113966] New: Internal compiler error in `do_auto_deduction`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113966
Bug ID: 113966
Summary: Internal compiler error in `do_auto_deduction`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
The following ICE has been happening for a longer time now for
https://godbolt.org/z/7EK64PPr6:
```
quantity.h:316:9: internal compiler error: in do_auto_deduction, at
cp/pt.cc:31135
315 | {
| ~
316 | a += b
| ^~
317 | } -> std::same_as;
| ~~~
0x264d1cc internal_error(char const*, ...)
???:0
0xa526c5 fancy_abort(char const*, int, char const*)
???:0
0xad5976 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0xacf547 maybe_substitute_reqs_for(tree_node*, tree_node const*)
???:0
0xcb4d66 instantiate_class_template(tree_node*)
???:0
0xd0b594 complete_type_or_maybe_complain(tree_node*, tree_node*, int)
???:0
0xd0b6ac require_complete_type(tree_node*, int)
???:0
0xa6d24d build_cxx_call(tree_node*, int, tree_node**, int, tree_node*)
???:0
0xa87af8 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xd0e002 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0xc555aa c_parse_file()
???:0
0xda9739 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug testsuite/113965] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails with qemu due to _Float16 rounding error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965 --- Comment #3 from Andrew Pinski --- Created attachment 57443 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57443=edit Reduced testcase Attached is the reduced testcase that I was using here.
[Bug testsuite/113965] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails with qemu due to _Float16 rounding error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |testsuite Blocks|53947 | Target Milestone|14.0|--- Summary|[14 Regression] |gcc.target/aarch64/sve/mask |gcc.target/aarch64/sve/mask |_struct_load_3_run.c still |_struct_load_3_run.c still |fails with qemu due to |fails |_Float16 rounding error --- Comment #2 from Andrew Pinski --- I think this might be a rounding issue with qemu and _Float16 I think. So _Float16 has 10/11 bits of Significand precision which means it can represent 0 - 2047 and then outside of that it will need to truncate some bits. In the testcase the first time where we get a failure is: i: 40 mask: 1 out[i]: 2906.00 if_true: 2904.00 if_false: 140.00 expected[i]: 2904.00 As you can see there is one bit difference at the end. I have not looked into why not using SVE here we are able to get the correct value though. But I can say for sure that the vectorizer is doing the correct thing in that using "unsigned short" instead produces the exact same .optimized file out for the function (test_f16_f16_i8_4). So removing the regression markers and moving this to testsuite as I think this is not an issue with the code generation. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/113965] [14 Regression] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965 --- Comment #1 from Andrew Pinski --- Hmm, debugging this a little further, this might be a qemu issue with fp16 support
[Bug c++/113958] support visibility attribute for typeinfo symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113958 --- Comment #3 from Noel Grandin --- Andrew, the specific application here is a very large (10MLoc) codebase (LibreOffice), where we have lots of very large classes with tons of methods, where I want to limit symbol visibility to only the symbols that are needed for running unit tests. So sure, technically I could make the whole class visibility=default, and then annotate most of the methods with visibility=hidden. Or I could use linker scripts. But ergonomically, the easiest thing to do is to compile with visibility=hidden, and then annotate the small subset of symbols I want exposed. So this is an ergonomic / quality-of-life feature request, not a bug.
[Bug tree-optimization/113965] [14 Regression] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Blocks||53947 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/113965] New: [14 Regression] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965 Bug ID: 113965 Summary: [14 Regression] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: aarch64-linux-gnu I thought this was a dup of bug mask_struct_store_4.c issue but nope, gcc.target/aarch64/sve/mask_struct_load_3_run.c testcase still fails for me after the fix for that. Note I am using the trunk of qemu to run the testcase so maybe there is a bug in qemu ...
[Bug tree-optimization/113964] [11/12/13/14/15 Regression] repeat copy of struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964 Andrew Pinski changed: What|Removed |Added Summary|repeat copy of struct |[11/12/13/14/15 Regression] ||repeat copy of struct Known to fail||4.6.4, 4.7.1, 4.9.0, 5.1.0 Known to work||4.1.2, 4.4.7, 4.5.3 Last reconfirmed||2024-02-17 Target Milestone|--- |11.5 Keywords||missed-optimization Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. There is no DSE before esra And ESRA goes wrong because of that. Before ESRA we have: ``` _1 = e.f0.f4; _2 = (unsigned char) _1; e.f3 = _2; e.f0 = g_50; g_16 = MEM[(const struct S1 &)]; ``` And SRA thinks it should do: ``` Created a replacement for e offset: 0, size: 8: e$f3D.4642 Created a replacement for e offset: 192, size: 32: e$f0$f4D.4643 ``` But the store to e.f3 is dead due to the store to e.f0. I suspect this should be defered until GCC 15 and maybe we should try to reorg the optimization pipeline there ...
[Bug tree-optimization/113964] New: repeat copy of struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
Bug ID: 113964
Summary: repeat copy of struct
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: absoler at smail dot nju.edu.cn
Target Milestone: ---
here's the code:
```
struct S1 {
uint32_t f0;
uint8_t f1;
uint64_t f2;
uint64_t f3;
int32_t f4;
};
union U8 {
struct S1 f0;
int32_t f1;
int64_t f2;
uint8_t f3;
const int64_t f4;
};
/* --- GLOBAL VARIABLES --- */
struct S1 g_16 = {4294967293UL,1UL,1UL,0xA9C1C73B017290B1LL,0x5ADF851FL};
union U8 g_37 = {{1UL,1UL,0x2361AE7D51263067LL,0xEEFD7F9B64A47447LL,0L}};
struct S1 g_50 =
{0x0CFC2012L,1UL,0x43E1243B3BE7B8BBLL,0x03C5CEC10C1A6FE1LL,1L};
/* --- FORWARD DECLARATIONS --- */
void func_32(union U8 e) {
e.f3 = e.f0.f4;
g_16 = e.f0 = g_50;
}
```
and compiled with gcc-13.2.0 -O2, generated binary code is:
```
00401400 :
func_32():
/root/myCSmith/test/output2.c:54
401400: movzbl 0x2c79(%rip),%eax# 404080
401407: movdqa 0x2c71(%rip),%xmm0# 404080
40140f: movdqa 0x2c79(%rip),%xmm1# 404090
401417: movups %xmm0,0x8(%rsp)
40141c: mov%al,0x8(%rsp)
401420: mov0x2c72(%rip),%eax# 404098
401426: movups %xmm1,0x18(%rsp)
40142b: movdqu 0x8(%rsp),%xmm2
401431: mov%eax,0x20(%rsp)
401435: movdqu 0x18(%rsp),%xmm3
40143b: movaps %xmm2,0x2c7e(%rip)# 4040c0
401442: movaps %xmm3,0x2c87(%rip)# 4040d0
/root/myCSmith/test/output2.c:55
401449: retq
40144a: nopw 0x0(%rax,%rax,1)
```
we can see that g_50.f0 and g_50.f4 have been repeatedly copy to e.
[Bug analyzer/113963] analyzer-null-dereference, analyzer-malloc-leak false alarms in Gnulib savedir.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113963 --- Comment #1 from Paul Eggert --- Created attachment 57442 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57442=edit test program without line number directives (also compressed) This is the same program as savedir.i, except without line number directives. Like the other test program, it's compressed with gzip.
[Bug analyzer/113963] New: analyzer-null-dereference, analyzer-malloc-leak false alarms in Gnulib savedir.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113963
Bug ID: 113963
Summary: analyzer-null-dereference, analyzer-malloc-leak false
alarms in Gnulib savedir.c
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: eggert at cs dot ucla.edu
Target Milestone: ---
Created attachment 57441
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57441=edit
test program with line number directives
I ran into this problem when compiling programs using Gnulib's lib/savedir.c
code.
This is gcc (GCC) 13.2.1 20231205 (Red Hat 13.2.1-6) on x86-64. Compile the
attached programs with:
gcc -O2 -fanalyzer -S savedir.i
gcc -O2 -fanalyzer -S savedis.i
Two problems. First, although savedis.i is merely a copy of savedir.i with line
number directives removed, the second command outputs an extra
-Wanalyzer-null-argument warning that the first command does not. Surely the
presence of line number directives should not affect which warnings are issued.
Second and more important, all the warnings are false positives. The pointers
can't possibly be null when the sizes are nonzero, and there is no memory leak.
The source files savedir.i and savedis.i are attached, compressed.
Here are the incorrect warnings that I get:
$ gcc -O2 -fanalyzer -S savedir.i
savedir.c: In function ‘streamsavedir’:
savedir.c:135:42: warning: dereference of NULL ‘entries’ [CWE-476]
[-Wanalyzer-null-dereference]
135 | entries[entries_used].name = used;
| ~~~^~
‘streamsavedir’: event 1
|
|savedir.c:106:6:
| 106 | if (dirp == NULL)
| | ^
| | |
| | (1) following ‘false’ branch (when ‘dirp’ is non-NULL)...
|
‘streamsavedir’: event 2
|
|cc1:
| (2): ...to here
|
‘streamsavedir’: events 3-5
|
|savedir.c:116:10:
| 116 | if (! dp)
| | ^
| | |
| | (3) following ‘false’ branch (when ‘dp’ is non-NULL)...
|..
| 121 | entry = dp->d_name;
| | ~~
| | |
| | (4) ...to here
| 122 | if (entry[entry[0] != '.' ? 0 : entry[1] != '.' ? 1 : 2] !=
'\0')
| | ~
| | |
| | (5) following ‘true’ branch...
|
‘streamsavedir’: event 6
|
|savedir.c:124:30:
| 124 | idx_t entry_size = _D_EXACT_NAMLEN (dp) + 1;
|
‘streamsavedir’: event 7
|
|savedir.c:125:14:
| 125 | if (allocated - used <= entry_size)
| | ^
| | |
| | (7) following ‘true’ branch...
|
‘streamsavedir’: event 8
|
| 126 | name_space = xpalloc (name_space, ,
|
‘streamsavedir’: events 9-14
|
|savedir.c:130:14:
| 130 | if (cmp)
| | ^
| | |
| | (9) following ‘true’ branch (when ‘cmp’ is
non-NULL)...
| 131 | {
| 132 | if (entries_allocated == entries_used)
| | ~~
| | | |
| | | (10) ...to here
| | (11) following ‘false’ branch...
|..
| 135 | entries[entries_used].name = used;
| | ~
| | | |
| | (12) ...to here (14) dereference of NULL
‘entries + (long unsigned int)entries_used * 16’
| | (13) ‘entries’ is NULL
|
savedir.c:169:3: warning: leak of ‘name_space’ [CWE-401]
[-Wanalyzer-malloc-leak]
169 | free (entries);
| ^~
‘savedir’: events 1-2
|
| 179 | savedir (char const *dir, enum savedir_option option)
| | ^~~
| | |
| | (1) entry to ‘savedir’
|..
| 182 | if (! dirp)
| | ~
| | |
| | (2) following ‘false’ branch (when ‘dirp’ is non-NULL)...
|
‘savedir’: events 3-5
|
|savedir.c:186:26:
| 186 | char *name_space = streamsavedir (dirp, option);
| | ^~~~
| | |
| | (3) ...to here
| | (4) allocated here
| | (5) calling ‘streamsavedir’ from
‘savedir’
|
+--> ‘streamsavedir’: event 6
|
|savedir.c:96:1:
| 96 | streamsavedir (DIR *dirp, enum
[Bug libgcc/113497] error: implicit declaration of function 'abort' on enable-execute-stack.c on i686-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113497 Sam James changed: What|Removed |Added Last reconfirmed||2024-02-17 Ever confirmed|0 |1 CC||law at gcc dot gnu.org, ||sjames at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #3 from Sam James --- Fixed in r14-8753-g2c27aa8d75113f. It should probably be backported though to 11/12/13.
[Bug c/71219] Warn about (struct S*)malloc(n) where n < sizeof(struct S)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71219 Sam James changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #7 from Sam James --- Fixed for 14?
[Bug c/88687] redundant -Wbuiltin-declaration-mismatch after -Wimplicit-function-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88687 Sam James changed: What|Removed |Added Last reconfirmed||2024-02-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Sam James --- Confirmed. I wasn't sure if this would've gone away with some of the earlier diagnostic fixups wrt permerror but it hasn't.
[Bug tree-optimization/87313] attribute malloc not used for alias analysis when it could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87313 Sam James changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106850 --- Comment #5 from Sam James --- (In reply to Petr Skocik from comment #4) PR106850 for that, pretty much.
[Bug tree-optimization/83194] Possibly missed simplification with strcmp(s, t) == strcmp(t, s)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83194 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-17 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- Confirmed. Though I am not sure if this will happen in real code but with C++ code who knows.
[patch, libgfortran] Bug 105473 - semicolon allowed when list-directed read integer with decimal='point'
Hello,
I posted the attached patch in bugzilla some time ago. This includes a
new test case. The patch adds additional checks in key places to catch
eroneous use of semicolons
Regression tested on x86_64,
OK for trunk and later backport to 13?
Jerrydiff --git a/gcc/testsuite/gfortran.dg/pr105473.f90 b/gcc/testsuite/gfortran.dg/pr105473.f90
new file mode 100644
index 000..b309217540d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr105473.f90
@@ -0,0 +1,46 @@
+! { dg-do run }
+! PR libgfortran/105473
+ implicit none
+ integer n,m,ios
+ real r
+ complex z
+ character(40):: testinput
+ n = 999; m = 777; r=1.2345
+ z = cmplx(0.0,0.0)
+
+! Check that semi-colon is not allowed as separator with decimal=point.
+ ios=0
+ testinput = '1;17;3.14159'
+ read(testinput,*,decimal='point',iostat=ios) n, m, r
+ if (ios /= 5010) print *, "stop 1"
+
+! Check that comma is not allowed as a separator with decimal=comma.
+ ios=0
+ testinput = '1,17,3,14159'
+ read(testinput,*,decimal='comma',iostat=ios) n, m, r
+ if (ios /= 5010) print *, "stop 2"
+
+! Check a good read.
+ ios=99
+ testinput = '1;17;3,14159'
+ read(testinput,*,decimal='comma',iostat=ios) n, m, r
+ if (ios /= 0) print *, "stop 3"
+
+! Check that comma is not allowed as a separator with decimal=comma.
+ ios=99; z = cmplx(0.0,0.0)
+ testinput = '1,17, (3,14159, 1,7182)'
+ read(testinput,*,decimal='comma', iostat=ios) n, m, z
+ if (ios /= 5010) stop 4
+
+! Check that semi-colon is not allowed as separator with decimal=point.
+ ios=99; z = cmplx(0.0,0.0)
+ testinput = '1,17; (3.14159; 1.7182)'
+ read(testinput,*,decimal='point', iostat=ios) n, m, z
+ if (ios /= 5010) stop 5
+
+! Check a good read.
+ ios=99;z = cmplx(0.0,0.0)
+ testinput = '1;17; (3,14159; 1,7182)'
+ read(testinput,*,decimal='comma', iostat=ios) n, m, z
+ if (ios /= 0) stop 6
+end program
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 0b7884fdda7..d2316ad6fe2 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -53,7 +53,6 @@ typedef unsigned char uchar;
#define CASE_SEPARATORS /* Fall through. */ \
case ' ': case ',': case '/': case '\n': \
case '\t': case '\r': case ';'
-
/* This macro assumes that we're operating on a variable. */
#define is_separator(c) (c == '/' || c == ',' || c == '\n' || c == ' ' \
@@ -475,11 +474,23 @@ eat_separator (st_parameter_dt *dtp)
case ',':
if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
{
+ generate_error (>common, LIBERROR_READ_VALUE,
+ "Comma not allowed as separator with DECIMAL='comma'");
unget_char (dtp, c);
break;
}
- /* Fall through. */
+ dtp->u.p.comma_flag = 1;
+ eat_spaces (dtp);
+ break;
+
case ';':
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_POINT)
+ {
+ generate_error (>common, LIBERROR_READ_VALUE,
+ "Semicolon not allowed as separator with DECIMAL='point'");
+ unget_char (dtp, c);
+ break;
+ }
dtp->u.p.comma_flag = 1;
eat_spaces (dtp);
break;
@@ -1326,8 +1337,13 @@ parse_real (st_parameter_dt *dtp, void *buffer, int length)
{
if ((c = next_char (dtp)) == EOF)
goto bad;
- if (c == ',' && dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
- c = '.';
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
+ {
+ if (c == '.')
+ goto bad;
+ if (c == ',')
+ c = '.';
+ }
switch (c)
{
CASE_DIGITS:
@@ -1636,8 +1652,18 @@ read_real (st_parameter_dt *dtp, void *dest, int length)
seen_dp = 0;
c = next_char (dtp);
- if (c == ',' && dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
-c = '.';
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
+{
+ if (c == '.')
+ goto bad_real;
+ if (c == ',')
+ c = '.';
+}
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_POINT)
+{
+ if (c == ';')
+ goto bad_real;
+}
switch (c)
{
CASE_DIGITS:
@@ -1677,8 +1703,13 @@ read_real (st_parameter_dt *dtp, void *dest, int length)
for (;;)
{
c = next_char (dtp);
- if (c == ',' && dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
- c = '.';
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
+ {
+ if (c == '.')
+ goto bad_real;
+ if (c == ',')
+ c = '.';
+ }
switch (c)
{
CASE_DIGITS:
@@ -1718,7 +1749,7 @@ read_real (st_parameter_dt *dtp, void *dest, int length)
CASE_SEPARATORS:
case EOF:
- if (c != '\n' && c != ',' && c != '\r' && c != ';')
+ if (c != '\n' && c != ',' && c != ';' && c != '\r')
unget_char (dtp, c);
goto done;
diff --git a/libgfortran/io/read.c b/libgfortran/io/read.c
index e2d2f8be806..7a9e341d7d8 100644
--- a/libgfortran/io/read.c
+++ b/libgfortran/io/read.c
@@ -1062,8 +1062,17 @@ read_f (st_parameter_dt *dtp, const fnode *f, char *dest, int length)
case ',':
if (dtp->u.p.current_unit->decimal_status != DECIMAL_COMMA)
[Bug target/111935] gcc ICE with risc-v vector intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111935 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #4 from Alexandre Oliva --- Does the test pass in gcc-13 for anyone? ISTM that it doesn't. I bisected it and got to commit 973eb0deb467c79cc21f265a710a81054cfd3e8c AKA r14-3535, for bug 110943, as the first in which the test generates the expected number of matches of the vs... pattern.
[Bug target/113331] AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus ---
All of the following is in except.cc.
The problem is that the count in the label is relative to 'call_site_base'.
In convert_to_eh_region_ranges, those get bumped - but the function reset it at
the end. They do get accumulated via, e.g., dw2_output_call_site_table but, in
GCN, the output_function_exception_table is exit early because of:
3229 if (!crtl->uses_eh_lsda
3230 || targetm_common.except_unwind_info (_options) ==
UI_NONE)
3231return;
Thus, the next time convert_to_eh_region_ranges is called, it starts with the
very same numbers.
The reason that this gets produced is because there is an ERT_MUST_NOT_THROW
("MUST_NOT_THROW regions prevent all exceptions from propagating. This region
type is used in C++ to surround destructors being run inside a CLEANUP
region.")
As there are both "-1" (implies no action) and "-2" (MUST_NOT_THROW), GCN
produces this output. For whatever reason, nvptx has no "-1" actions in the
function, thus, after the change to "-2", there is no flip and - hence, no
output is produced - avoiding the issue.
→ I bet that both gcn and nvptx are affected (unless luck or compiled with
-fno-exceptions).
[Bug middle-end/113959] Optimize `__builtin_isnan(x) || __builtin_isinf(x)` to `__builtin_isfinite(x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113959 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #2 from Harald van Dijk --- See also bug #66462: the code currently generated is wrong under -fsignaling-nans, a patch has been posted to fix that, and had then been forgotten. The patch may possibly improve codegen regardless of -fsignaling-nans.
[patch, libgfortran] PR107068 Run-time error when reading logical arrays with a namelist
The attached patch fixes this one. Se the ChangeLog below for explanation.
OK for trunk?
I think simple enough to backport to 13 as well.
Regards,
Jerry
Author: Jerry DeLisle
Date: Fri Feb 16 17:06:37 2024 -0800
libgfortran: Fix namelist read.
PR libgfortran/107068
libgfortran/ChangeLog:
* io/list_read.c (read_logical): When looking for a possible
variable name, check for left paren, indicating a possible
array reference.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr107068.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/pr107068.f90 b/gcc/testsuite/gfortran.dg/pr107068.f90
new file mode 100644
index 000..c5ea0c1d244
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107068.f90
@@ -0,0 +1,22 @@
+! { dg-do run }
+program test
+ implicit none
+ integer :: error
+ logical, dimension(3,3) :: flc,flp
+ namelist/inputdata/flc, flp
+
+ flc = .false.
+ flp = .false.
+
+ open(10, file="inputfile")
+ write(10,*) ""
+ write(10,*) " FLC = T, "
+ write(10,*) " FLP(1,2) = T,"
+ write(10,*) "/"
+ rewind(10)
+ !write(*, nml=inputdata)
+ !open(10,file="inputfile")
+ read(10,inputdata,iostat=error)
+ close(10, status='delete')
+ if (error /= 0) stop 20
+end program test
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index f8ca64422de..0b7884fdda7 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -888,6 +888,14 @@ read_logical (st_parameter_dt *dtp, int length)
for(i = 0; i < 63; i++)
{
c = next_char (dtp);
+ if (c == '(')
+ {
+ l_push_char (dtp, c);
+ dtp->u.p.nml_read_error = 1;
+ dtp->u.p.line_buffer_enabled = 1;
+ dtp->u.p.line_buffer_pos = 0;
+ return;
+ }
if (is_separator(c))
{
/* All done if this is not a namelist read. */
[Bug target/113960] std::map with std::vector as input overwrites itself with c++20, on s390x platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- I can reproduce it w/ 13.2.1 20231216 although I'd prefer to leave it to someone else to confirm...
[Bug c++/113958] support visibility attribute for typeinfo symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113958 --- Comment #2 from Andrew Pinski --- I am not 100% sure if type_visibility is needed here or in general. You can also use -fvisibility-inlines-hidden to hide methods that are declared as inline which I suspect you want really too.
[Bug c++/113958] support visibility attribute for typeinfo symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113958
--- Comment #1 from Andrew Pinski ---
You can use visibility on the type even Like:
```
struct __attribute__ ((visibility("default"))) Foo1{
virtual void some_member() = 0;
};
struct __attribute__ ((visibility("default"))) Foo : Foo1 {
virtual void some_member();
};
```
Which changes the visibility back to default for the whole class.
This is documented here:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Type-Attributes.html#index-visibility-type-attribute
You can also use the `pragma GCC visibility` too in the same way:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Visibility-Pragmas.html#index-pragma_002c-visibility
#pragma GCC visibility push(default)
Though visibility on the struct applies to all methods too. Which I suspect you
want really instead of marking each method as being default.
The pragma push/pop makes it easier to mark the classes you want to be exported
too. E.g. you can wrap including a header file with that to make sure those are
exported.
[Bug target/113779] Very inefficient m68k code generated for simple copy loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #7 from Hans-Peter Nilsson --- (In reply to Richard Biener from comment #6) > The auto-inc pass is well > structured, so it should be possible to extend it. Or just replace it, as it doesn't look far enough to be able to handle all incdec-opportunities.
Re: [PATCH] Turn on LRA on all targets
On Fri, 16 Feb 2024, Maciej W. Rozycki wrote: > On Fri, 16 Feb 2024, Jakub Jelinek wrote: > > > > There is no function prologue to optimise in the VAX case, because all > > > the frame setup has already been made by the CALLS instruction itself in > > > the caller. The first machine instruction of the callee is technically > > > already past the "prologue". And then RET serves as the whole function > > > "epilogue". > > > > So, what is the problem with DWARF unwinding? Just make sure to emit > > appropriate instructions describing the saving of the corresponding > > registers at specific points based on CFA at the start of the function > > (so that it appears in CIE instructions) and that should be all that is > > needed, no? > > I may not remember all the issues correctly offhand as it's been a while > since I looked into it, but as I recall DWARF handling code has not been > prepared for all the frame to have been already allocated and initialised > at a function's entry point, and also at least DWARF-4 is IIRC required to > have statics at offsets positive from FP (for a stack growing downwards). There is a further complication actually where lazy binding is in use. In that case a function that has been jumped to indirectly from the lazy resolver will often have a different number of statics saved in the frame from where the function has been called directly via a fully resolved PLT GOT entry. This is because at the time the lazy resolver is being called it is not known what statics the ultimate callee wants to save, as it is not a part of the ABI. Therefore the worst condition is assumed and the resolver requests all the statics (R6-R11) to be saved, observing that saving more statics than required makes no change to code semantics, it just hurts performance (but calls to the lazy resolver are rare, so this is not a big deal). Conversely when the function has been already resolved, the PLT GOT entry points at the callee instead, which will then only save the statics it has requested itself, knowing them to be used. Obviously a frame that has all the statics saved will have a different size of its variable part and slots will have been assigned differently there from the case where only some statics have been saved. Of course it does not matter for regular code execution as RET will always correctly interpret a stack frame and restore exactly these statics that have been saved in the frame, but for unwinding actual frame contents have to be interpreted. I am not sure if this run-time dependent frame layout can be described in DWARF terms even, so I am leaning towards concluding a native unwinder is the only feasible way to go. For those who are unaware how information as to what statics are to be saved is made available by functions with VAX hardware: it is embedded at the function's address in a form of a 16-bit data quantity, which is a register save bitmask (an entry mask in VAX-speak) for registers R0-R11; 1 in the mask requests that the corresponding register be saved in the callee's frame by the CALLS instruction. Once the frame has been built by CALLS, control is then passed to the location immediately following the bitmask, which is the function's actual entry point, i.e. the PC is set to the function's address + 2. Maciej
[Bug middle-end/113959] Optimize `__builtin_isnan(x) || __builtin_isinf(x)` to `__builtin_isfinite(x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113959 --- Comment #1 from Andrew Pinski --- Created attachment 57440 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57440=edit testcase from the godbolt link Next time attach the testcase or put it in line instead of just linking to godbolt.
Re: [PATCH] Fortran: deferred length of character variables shall not get lost [PR113911]
On 2/16/24 1:40 PM, Harald Anlauf wrote: Dear all, this patch fixes a regression which was a side-effect of r14-8947, losing the length of a deferred-length character variable when passed as a dummy. The new testcase provides a workout for deferred length to improve coverage in the testsuite. Another temporarily disabled test was re-enabled. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Yes OK for mainline. Thanks, Jerry
[Bug middle-end/113959] Optimize `__builtin_isnan(x) || __builtin_isinf(x)` to `__builtin_isfinite(x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113959 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
--- Comment #8 from Jerry DeLisle ---
After a bit of sleuthing it turns out that the '(' in the name was being
ignored and the comma in '(1,2)' was being treated as a delimiter. Since the
following '=' was not seen yet, the 2 was seen as a repeat value and we get the
error.
This is fixed with the following patch:
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index f8ca64422de..0b7884fdda7 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -888,6 +888,14 @@ read_logical (st_parameter_dt *dtp, int length)
for(i = 0; i < 63; i++)
{
c = next_char (dtp);
+ if (c == '(')
+ {
+ l_push_char (dtp, c);
+ dtp->u.p.nml_read_error = 1;
+ dtp->u.p.line_buffer_enabled = 1;
+ dtp->u.p.line_buffer_pos = 0;
+ return;
+ }
if (is_separator(c))
{
/* All done if this is not a namelist read. */
Re: [PATCH] libgcc: fix Win32 CV abnormal spurious wakeups in timed wait [PR113850]
On 2/10/24 10:10, Matteo Italia wrote: Il 09/02/24 15:18, Matteo Italia ha scritto: The Win32 threading model uses __gthr_win32_abs_to_rel_time to convert the timespec used in gthreads to specify the absolute time for end of the condition variables timed wait to a milliseconds value relative to "now" to pass to the Win32 SleepConditionVariableCS function. Unfortunately, the conversion is incorrect, as, due to a typo, it returns the relative time _in seconds_, so SleepConditionVariableCS receives a timeout value 1000 times shorter than it should be, resulting in a huge amount of spurious wakeups in calls such as std::condition_variable::wait_for or wait_until. Re-reading the commit message I found a few typos, and it was generally a bit more obscure than I like; reworded it now, hope it's better. Thanks, pushed to master and 13.x branches.
ping: [PATCH] diagnostics: Fix behavior of permerror options after diagnostic pop [PR111918]
CCing some global reviewers as well, in case anyone has a minute to take a look please? Thanks! https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html On Thu, Jan 25, 2024 at 4:57 PM Lewis Hyatt wrote: > > May I please ask again about this one? It's just a couple lines, and I > think it fixes an important gap in the logic for #pragma GCC > diagnostic. The PR was not reported by me so I think at least one > other person does care about it :). Thanks! > > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html > > -Lewis > > On Mon, Jan 8, 2024 at 6:53 PM Lewis Hyatt wrote: > > > > Can I please ping this one again? It's 3 lines or so to fix the PR. Thanks! > > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html > > > > On Tue, Dec 19, 2023 at 6:20 PM Lewis Hyatt wrote: > > > > > > Hello- > > > > > > May I please ping this one? Thanks... > > > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html > > > > > > -Lewis > > > > > > On Wed, Nov 29, 2023 at 7:05 PM Lewis Hyatt wrote: > > > > > > > > On Thu, Nov 09, 2023 at 04:16:10PM -0500, Lewis Hyatt wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111918 > > > > > > > > > > This patch fixes the behavior of `#pragma GCC diagnostic pop' for > > > > > permissive > > > > > error diagnostics such as -Wnarrowing (in C++11). Those currently do > > > > > not > > > > > return to the correct state after the last pop; they become > > > > > effectively > > > > > simple warnings instead. Bootstrap + regtest all languages on x86-64, > > > > > does > > > > > it look OK please? Thanks! > > > > > > > > Hello- > > > > > > > > May I please ping this bug fix? > > > > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635871.html > > > > > > > > Please note, it requires a trivial rebase on top of recent changes to > > > > the class diagnostic_context public interface. I attached the rebased > > > > patch > > > > here as well. Thanks! > > > > > > > > -Lewis
[Bug libgcc/113850] condition variables timed wait does a lot of spurious wakeups on Win32 threading implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113850
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Yong
:
https://gcc.gnu.org/g:b5def8fd08976fc2514426ecb1f263f13ba3e2af
commit r13-8337-gb5def8fd08976fc2514426ecb1f263f13ba3e2af
Author: Matteo Italia
Date: Fri Feb 9 15:04:20 2024 +0100
libgcc: fix Win32 CV abnormal spurious wakeups in timed wait [PR113850]
Fix a typo in __gthr_win32_abs_to_rel_time that caused it to return a
relative time in seconds instead of milliseconds. As a consequence,
__gthr_win32_cond_timedwait called SleepConditionVariableCS with a
1000x shorter timeout; this caused ~1000x more spurious wakeups in
CV timed waits such as std::condition_variable::wait_for or wait_until,
resulting generally in much higher CPU usage.
This can be demonstrated by this sample program:
```
int main() {
std::condition_variable cv;
std::mutex mx;
bool pass = false;
auto thread_fn = [&](bool timed) {
int wakeups = 0;
using sc = std::chrono::system_clock;
auto before = sc::now();
std::unique_lock ml(mx);
if (timed) {
cv.wait_for(ml, std::chrono::seconds(2), [&]{
++wakeups;
return pass;
});
} else {
cv.wait(ml, [&]{
++wakeups;
return pass;
});
}
printf("pass: %d; wakeups: %d; elapsed: %d ms\n", pass, wakeups,
int((sc::now() - before) / std::chrono::milliseconds(1)));
pass = false;
};
{
// timed wait, let expire
std::thread t(thread_fn, true);
t.join();
}
{
// timed wait, wake up explicitly after 1 second
std::thread t(thread_fn, true);
std::this_thread::sleep_for(std::chrono::seconds(1));
{
std::unique_lock ml(mx);
pass = true;
}
cv.notify_all();
t.join();
}
{
// non-timed wait, wake up explicitly after 1 second
std::thread t(thread_fn, false);
std::this_thread::sleep_for(std::chrono::seconds(1));
{
std::unique_lock ml(mx);
pass = true;
}
cv.notify_all();
t.join();
}
return 0;
}
```
On builds based on non-affected threading models (e.g. POSIX on Linux,
or winpthreads or MCF on Win32) the output is something like
```
pass: 0; wakeups: 2; elapsed: 2000 ms
pass: 1; wakeups: 2; elapsed: 991 ms
pass: 1; wakeups: 2; elapsed: 996 ms
```
while with the Win32 threading model we get
```
pass: 0; wakeups: 1418; elapsed: 2000 ms
pass: 1; wakeups: 479; elapsed: 988 ms
pass: 1; wakeups: 2; elapsed: 992 ms
```
(notice the huge number of wakeups in the timed wait cases only).
This commit fixes the conversion, adjusting the final division by
NSEC100_PER_SEC to use NSEC100_PER_MSEC instead (already defined in the
file and not used in any other place, so probably just a typo).
libgcc/ChangeLog:
PR libgcc/113850
* config/i386/gthr-win32-cond.c (__gthr_win32_abs_to_rel_time):
fix absolute timespec to relative milliseconds count
conversion (it incorrectly returned seconds instead of
milliseconds); this avoids spurious wakeups in
__gthr_win32_cond_timedwait
(cherry picked from commit 05ad8fb55a55f1e201fd781c84682a7c0bbd4d97)
[Bug libgcc/113850] condition variables timed wait does a lot of spurious wakeups on Win32 threading implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113850
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:05ad8fb55a55f1e201fd781c84682a7c0bbd4d97
commit r14-9042-g05ad8fb55a55f1e201fd781c84682a7c0bbd4d97
Author: Matteo Italia
Date: Fri Feb 9 15:04:20 2024 +0100
libgcc: fix Win32 CV abnormal spurious wakeups in timed wait [PR113850]
Fix a typo in __gthr_win32_abs_to_rel_time that caused it to return a
relative time in seconds instead of milliseconds. As a consequence,
__gthr_win32_cond_timedwait called SleepConditionVariableCS with a
1000x shorter timeout; this caused ~1000x more spurious wakeups in
CV timed waits such as std::condition_variable::wait_for or wait_until,
resulting generally in much higher CPU usage.
This can be demonstrated by this sample program:
```
int main() {
std::condition_variable cv;
std::mutex mx;
bool pass = false;
auto thread_fn = [&](bool timed) {
int wakeups = 0;
using sc = std::chrono::system_clock;
auto before = sc::now();
std::unique_lock ml(mx);
if (timed) {
cv.wait_for(ml, std::chrono::seconds(2), [&]{
++wakeups;
return pass;
});
} else {
cv.wait(ml, [&]{
++wakeups;
return pass;
});
}
printf("pass: %d; wakeups: %d; elapsed: %d ms\n", pass, wakeups,
int((sc::now() - before) / std::chrono::milliseconds(1)));
pass = false;
};
{
// timed wait, let expire
std::thread t(thread_fn, true);
t.join();
}
{
// timed wait, wake up explicitly after 1 second
std::thread t(thread_fn, true);
std::this_thread::sleep_for(std::chrono::seconds(1));
{
std::unique_lock ml(mx);
pass = true;
}
cv.notify_all();
t.join();
}
{
// non-timed wait, wake up explicitly after 1 second
std::thread t(thread_fn, false);
std::this_thread::sleep_for(std::chrono::seconds(1));
{
std::unique_lock ml(mx);
pass = true;
}
cv.notify_all();
t.join();
}
return 0;
}
```
On builds based on non-affected threading models (e.g. POSIX on Linux,
or winpthreads or MCF on Win32) the output is something like
```
pass: 0; wakeups: 2; elapsed: 2000 ms
pass: 1; wakeups: 2; elapsed: 991 ms
pass: 1; wakeups: 2; elapsed: 996 ms
```
while with the Win32 threading model we get
```
pass: 0; wakeups: 1418; elapsed: 2000 ms
pass: 1; wakeups: 479; elapsed: 988 ms
pass: 1; wakeups: 2; elapsed: 992 ms
```
(notice the huge number of wakeups in the timed wait cases only).
This commit fixes the conversion, adjusting the final division by
NSEC100_PER_SEC to use NSEC100_PER_MSEC instead (already defined in the
file and not used in any other place, so probably just a typo).
libgcc/ChangeLog:
PR libgcc/113850
* config/i386/gthr-win32-cond.c (__gthr_win32_abs_to_rel_time):
fix absolute timespec to relative milliseconds count
conversion (it incorrectly returned seconds instead of
milliseconds); this avoids spurious wakeups in
__gthr_win32_cond_timedwait
Re: [PATCH] RISC-V: Adjust vec unit-stride load/store costs.
Can memrefs computed in analyze_loop_vinfo ?
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-02-13 21:42
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Adjust vec unit-stride load/store costs.
Hi,
scalar loads provide offset addressing while unit-stride vector
instructions cannot. The offset must be loaded into a general-purpose
register before it can be used. In order to account for this, this
patch adds an address arithmetic heuristic that keeps track of data
reference operands. If we haven't seen the operand before we add the
cost of a scalar statement.
This helps to get rid of an lbm regression when vectorizing (roughly
0.5% fewer dynamic instructions). gcc5 improves by 0.2% and deepsjeng
by 0.25%. wrf and nab degrade by 0.1%. This is because before we now
adjust the cost of SLP as well as loop-vectorized instructions whereas
we would only adjust loop-vectorized instructions before.
Considering higher scalar_to_vec costs (3 vs 1) for all vectorization
types causes some snippets not to get vectorized anymore. Given these
costs the decisions look correct but appear worse when just counting
dynamic instructions.
In total SPECint 2017 has 4 bn dynamic instructions less and SPECfp 0.7
bn less so not a whole lot.
Regtested on riscv64.
Regards
Robin
gcc/ChangeLog:
* config/riscv/riscv-vector-costs.cc (adjust_stmt_cost): Move...
(costs::adjust_stmt_cost): ... to here and add vec_load/vec_store
offset handling.
(costs::add_stmt_cost): Also adjust cost for statements without
stmt_info.
* config/riscv/riscv-vector-costs.h: Define zero constant.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/costmodel/riscv/rvv/vse-slp-1.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/vse-slp-2.c: New test.
---
gcc/config/riscv/riscv-vector-costs.cc| 86 ---
gcc/config/riscv/riscv-vector-costs.h | 10 +++
.../vect/costmodel/riscv/rvv/vse-slp-1.c | 51 +++
.../vect/costmodel/riscv/rvv/vse-slp-2.c | 53
4 files changed, 190 insertions(+), 10 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/vse-slp-1.c
create mode 100644 gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/vse-slp-2.c
diff --git a/gcc/config/riscv/riscv-vector-costs.cc
b/gcc/config/riscv/riscv-vector-costs.cc
index 7c9840df4e9..adf9c197df5 100644
--- a/gcc/config/riscv/riscv-vector-costs.cc
+++ b/gcc/config/riscv/riscv-vector-costs.cc
@@ -42,6 +42,7 @@ along with GCC; see the file COPYING3. If not see
#include "backend.h"
#include "tree-data-ref.h"
#include "tree-ssa-loop-niter.h"
+#include "tree-hash-traits.h"
/* This file should be included last. */
#include "riscv-vector-costs.h"
@@ -1047,18 +1048,81 @@ costs::better_main_loop_than_p (const vector_costs
*uncast_other) const
top of riscv_builtin_vectorization_cost handling which doesn't have any
information on statement operation codes etc. */
-static unsigned
-adjust_stmt_cost (enum vect_cost_for_stmt kind, tree vectype, int stmt_cost)
+unsigned
+costs::adjust_stmt_cost (enum vect_cost_for_stmt kind, loop_vec_info loop,
+ stmt_vec_info stmt_info,
+ slp_tree, tree vectype, int stmt_cost)
{
const cpu_vector_cost *costs = get_vector_costs ();
switch (kind)
{
case scalar_to_vec:
- return stmt_cost += (FLOAT_TYPE_P (vectype) ? costs->regmove->FR2VR
- : costs->regmove->GR2VR);
+ stmt_cost += (FLOAT_TYPE_P (vectype) ? costs->regmove->FR2VR
+ : costs->regmove->GR2VR);
+ break;
case vec_to_scalar:
- return stmt_cost += (FLOAT_TYPE_P (vectype) ? costs->regmove->VR2FR
- : costs->regmove->VR2GR);
+ stmt_cost += (FLOAT_TYPE_P (vectype) ? costs->regmove->VR2FR
+ : costs->regmove->VR2GR);
+ break;
+case vector_load:
+case vector_store:
+ {
+ /* Unit-stride vector loads and stores do not have offset addressing
+ as opposed to scalar loads and stores.
+ If the address depends on a variable we need an additional
+ add/sub for each load/store in the worst case. */
+ if (stmt_info && stmt_info->stmt)
+ {
+ data_reference *dr = STMT_VINFO_DATA_REF (stmt_info);
+ class loop *father = stmt_info->stmt->bb->loop_father;
+ if (!loop && father && !father->inner && father->superloops)
+ {
+ tree ref;
+ if (TREE_CODE (dr->ref) != MEM_REF
+ || !(ref = TREE_OPERAND (dr->ref, 0))
+ || TREE_CODE (ref) != SSA_NAME)
+ break;
+
+ if (SSA_NAME_IS_DEFAULT_DEF (ref))
+ break;
+
+ if (memrefs.contains ({ref, cst0}))
+ break;
+
+ memrefs.add ({ref, cst0});
+
+ /* In case we have not seen REF before and the base address
+ is a pointer operation try a bit harder. */
+ tree base = DR_BASE_ADDRESS (dr);
+ if (TREE_CODE (base) == POINTER_PLUS_EXPR
+ || TREE_CODE (base) == POINTER_DIFF_EXPR)
+ {
+ /* Deconstruct BASE's first operand. If it is a binary
+ operation, i.e. a base and an "offset" store this
+
[Patch] OpenMP/C++: Fix (first)private clause with member variables [PR110347] [was: [RFA/RFC] C++/OpenMP: Supporting (first)private for member variables [PR110347] - or VALUE_EXPR and gimplify]
Hi,
your suggestion almost did the trick, but caused regressions with
lambda closures in target regions.
Jakub Jelinek wrote:
Ah, and the reason why it doesn't work on target is that it has the
everything is mapped assumption:
if ((ctx->region_type & ORT_TARGET) != 0)
{
if (ctx->region_type & ORT_ACC)
/* For OpenACC, as remarked above, defer expansion. */
shared = false;
else
shared = true;
ret = lang_hooks.decls.omp_disregard_value_expr (decl, shared);
Perhaps shared = true; should be shared = (flags & GOVD_MAPPED) != 0;
now that we have private/firstprivate clauses on target?
Hence, I now use this code, but also pass a flag to distinguish target
regions (→ map) from shared usage, assuming that it is needed for the
latter (otherwise, there wouldn't be that code).
The issue only showed up for a compile-only testcase, which I have now
turned into a run-time testcase.
In order to do so, I had to fix a bogus test for is mapped (or at least
I think it is bogus) - and for sure it didn't handle shared memory.
I also modified it such that it iterates over devices. Changes to the
dump: the 'device' clause had to be added (3x) and for the long line:
'this' and 'iptr' swapped the order and 'map(from:mapped)' became
'firstprivate(mapped)' due to my changes.
I appended a patch which only shows the test-case differences as "git
diff" contains all lines as I move it to libgomp/.
Comments, remarks, suggestions?
TobiasOpenMP/C++: Fix (first)private clause with member variables [PR110347]
OpenMP permits '(first)private' for C++ member variables, which GCC handles
by tagging those by DECL_OMP_PRIVATIZED_MEMBER, adding a temporary VAR_DECL
and DECL_VALUE_EXPR pointing to the 'this->member_var' in the C++ front end.
The idea is that in omp-low.cc, the DECL_VALUE_EXPR is used before the
region (for 'firstprivate'; ignored for 'private') while in the region,
the DECL itself is used.
In gimplify, the value expansion is suppressed and deferred if the
lang_hooks.decls.omp_disregard_value_expr (decl, shared)
returns true - which is never the case if 'shared' is true. In OpenMP 4.5,
only 'map' and 'use_device_ptr' was permitted for the 'target' directive.
And when OpenMP 5.0's 'private'/'firstprivate' clauses was added, the
update that 'shared' is only true for 'map' was missed.
However, just enabling it for all '!shared' will cause issues with
Lambda closures ("__closure->this->...") for which also a DECL_VALUE_EXPR
exists but that is not related to DECL_OMP_PRIVATIZED_MEMBER. Solution:
Update the lang hook to take a Boolean argument, indicating whether it
is called for a target region or not.
2024-02-16 Tobias Burnus
Jakub Jelinek
PR c++/110347
gcc/cp/ChangeLog:
* cp-gimplify.cc (cxx_omp_disregard_value_expr): Add new
Boolean argument and use it.
* cp-tree.h (cxx_omp_disregard_value_expr): Update prototype.
gcc/fortran/ChangeLog:
* trans-openmp.cc (gfc_omp_disregard_value_expr): Add
unused Boolean argument.
* trans.h (gfc_omp_disregard_value_expr): Update
prototype.
gcc/ChangeLog:
* gimplify.cc (omp_notice_variable): Update call to
lang_hooks.decls.omp_disregard_value_expr.
(omp_notice_variable): Likewise; fix 'shared' arg for
(first)private in target regions.
* hooks.cc (hook_bool_tree_bool_bool_false): New.
* hooks.h (hook_bool_tree_bool_bool_false): New.
* langhooks-def.h (LANG_HOOKS_OMP_DISREGARD_VALUE_EXPR):
Use it.
* langhooks.h (struct lang_hooks_for_decls): Add second
Boolean argument.
* omp-low.cc (omp_member_access_dummy_var): Update
lang_hooks.decls.omp_disregard_value_expr call.
libgomp/ChangeLog:
* testsuite/libgomp.c++/target-lambda-3.C: Moved from
gcc/testsuite/g++.dg/gomp/ and fixed is-mapped handling.
* testsuite/libgomp.c++/firstprivate-c++-1.C: New test.
* testsuite/libgomp.c++/firstprivate-c++-2.C: New test.
* testsuite/libgomp.c++/private-c++-1.C: New test.
* testsuite/libgomp.c++/private-c++-2.C: New test.
* testsuite/libgomp.c++/use_device_ptr-c++-1.C: New test.
gcc/testsuite/ChangeLog:
* g++.dg/gomp/target-lambda-1.C: Moved to become a
run-time test under testsuite/libgomp.c++.
Co-authored-by: Jakub Jelinek
gcc/cp/cp-gimplify.cc | 7 +-
gcc/cp/cp-tree.h | 2 +-
gcc/fortran/trans-openmp.cc| 2 +-
gcc/fortran/trans.h| 2 +-
gcc/gimplify.cc| 12 +-
gcc/hooks.cc | 6 +
gcc/hooks.h| 1 +
gcc/langhooks-def.h| 2 +-
gcc/langhooks.h| 5 +-
gcc/omp-low.cc | 2 +-
gcc/testsuite/g++.dg/gomp/target-lambda-1.C| 94 ---
libgomp/testsuite/libgomp.c++/firstprivate-c++-1.C | 305 +
[Bug target/113913] [14] RISC-V: suboptimal code gen for intrinsic vcreate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113913 --- Comment #2 from JuzheZhong --- It's the known issue we are trying to fix it in GCC-15. My colleague Lehua is taking care of it. CCing Lehua.
gcc-12-20240216 is now available
Snapshot gcc-12-20240216 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20240216/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 602e77e02842d8bf40f757882f458b500ed74ffe You'll find: gcc-12-20240216.tar.xz Complete GCC SHA256=48296c4e34983069d27c84f431a649f35ad3ee38e16495dea76a4abd41b42f7a SHA1=d0e3146a9c913268a97d2bed4063aa2e00d2a73c Diffs from 12-20240209 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 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 c++/104836] ice in unify, at cp/pt.cc:24055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104836
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
// PR c++/104836
template struct X {};
template typename> struct Y {};
template struct Z {};
template struct A {
template A(X, Ts (*...qs)[Ns]);
};
int arr1[3], arr2[3];
short arr3[4];
A a(X<, >{}, , , );
using AT = decltype(a);
using AT = A;
[Bug c++/57527] [C++11] Nested variadic templates cause internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57527
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #6 from Marek Polacek ---
// PR c++/57527
template
struct X {};
template
struct Y {
template
Y(X... xs);
};
void
g ()
{
X x;
Y y(x);
}
Re: [PATCH] c++: Fix up parameter pack diagnostics on xobj vs. varargs functions [PR113802]
On Fri, Feb 16, 2024 at 10:47:47PM +0100, Jakub Jelinek wrote:
> The following patch works.
Or yet another option would be instead of (sometimes) clearing
declarator->parameter_pack_p when we diagnose this bug for error
recovery ignore the this specifier.
With the following patch (testsuite patch remains the same),
I get excess errors though:
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:30:25:
error: expansion pattern 'Selves' contains no parameter packs
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:42:26:
error: expansion pattern 'Selves' contains no parameter packs
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:56:26:
error: expansion pattern 'Selves&' contains no parameter packs
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:68:27:
error: expansion pattern 'Selves&' contains no parameter packs
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:82:27:
error: expansion pattern 'Selves&&' contains no parameter packs
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:94:28:
error: expansion pattern 'Selves&&' contains no parameter packs
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:108:32:
error: expansion pattern 'const Selves&' contains no parameter packs
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:120:33:
error: expansion pattern 'const Selves&' contains no parameter packs
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:134:33:
error: expansion pattern 'const Selves&&' contains no parameter packs
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:146:34:
error: expansion pattern 'const Selves&&' contains no parameter packs
though, that is e.g. on
struct S0 {
template
void g(this Selves... selves) {} // { dg-error "an explicit object parameter
cannot be a function parameter pack" }
}
where such an extra error would have been emitted if the this keyword was
omitted.
--- gcc/cp/parser.cc.jj 2024-02-16 17:38:27.802845433 +0100
+++ gcc/cp/parser.cc2024-02-16 23:08:40.835437740 +0100
@@ -25734,22 +25734,6 @@ cp_parser_parameter_declaration (cp_pars
decl_specifiers.locations[ds_this] = 0;
}
- if (xobj_param_p
- && ((declarator && declarator->parameter_pack_p)
- || cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS)))
-{
- location_t xobj_param
- = make_location (decl_specifiers.locations[ds_this],
-decl_spec_token_start->location,
-input_location);
- error_at (xobj_param,
- "an explicit object parameter cannot "
- "be a function parameter pack");
- /* Suppress errors that occur down the line. */
- if (declarator)
- declarator->parameter_pack_p = false;
-}
-
/* If a function parameter pack was specified and an implicit template
parameter was introduced during cp_parser_parameter_declaration,
change any implicit parameters introduced into packs. */
@@ -25762,9 +25746,10 @@ cp_parser_parameter_declaration (cp_pars
(INNERMOST_TEMPLATE_PARMS (current_template_parms));
if (latest_template_parm_idx != template_parm_idx)
- decl_specifiers.type = convert_generic_types_to_packs
- (decl_specifiers.type,
- template_parm_idx, latest_template_parm_idx);
+ decl_specifiers.type
+ = convert_generic_types_to_packs (decl_specifiers.type,
+ template_parm_idx,
+ latest_template_parm_idx);
}
if (cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS))
@@ -25794,6 +25779,21 @@ cp_parser_parameter_declaration (cp_pars
}
}
+ if (xobj_param_p
+ && (declarator ? declarator->parameter_pack_p
+: PACK_EXPANSION_P (decl_specifiers.type)))
+{
+ location_t xobj_param
+ = make_location (decl_specifiers.locations[ds_this],
+decl_spec_token_start->location,
+input_location);
+ error_at (xobj_param,
+ "an explicit object parameter cannot "
+ "be a function parameter pack");
+ xobj_param_p = false;
+ decl_specifiers.locations[ds_this] = 0;
+}
+
/* The restriction on defining new types applies only to the type
of the parameter, not to the default argument. */
parser->type_definition_forbidden_message = saved_message;
Jakub
[PATCH v3] c++: wrong looser excep spec for dep noexcept [PR113158]
On Fri, Feb 16, 2024 at 04:39:47PM -0500, Patrick Palka wrote:
> On Fri, 16 Feb 2024, Marek Polacek wrote:
> > + /* We also have to defer checking when we're in a template and couldn't
> > + instantiate & evaluate the noexcept to true/false. */
> > + if (processing_template_decl)
> > +if ((base_throw
> > +&& (base_throw != noexcept_true_spec
> > +|| base_throw != noexcept_false_spec))
>
> Shouldn't these innermost || be &&?
D'oh, yes, what a dumb mistake. But that shows that we could also just
always return true in a template ;).
Fixed. dg.exp passed so far.
-- >8 --
Here we find ourselves in maybe_check_overriding_exception_spec in
a template context where we can't instantiate a dependent noexcept.
That's OK, but we have to defer the checking otherwise we give wrong
errors.
PR c++/113158
gcc/cp/ChangeLog:
* search.cc (maybe_check_overriding_exception_spec): Defer checking
when a noexcept couldn't be instantiated & evaluated to false/true.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept83.C: New test.
---
gcc/cp/search.cc| 11
gcc/testsuite/g++.dg/cpp0x/noexcept83.C | 37 +
2 files changed, 48 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept83.C
diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
index c948839dc53..827f48e8604 100644
--- a/gcc/cp/search.cc
+++ b/gcc/cp/search.cc
@@ -1975,6 +1975,17 @@ maybe_check_overriding_exception_spec (tree overrider,
tree basefn)
|| UNPARSED_NOEXCEPT_SPEC_P (over_throw))
return true;
+ /* We also have to defer checking when we're in a template and couldn't
+ instantiate & evaluate the noexcept to true/false. */
+ if (processing_template_decl)
+if ((base_throw
+&& base_throw != noexcept_true_spec
+&& base_throw != noexcept_false_spec)
+ || (over_throw
+ && over_throw != noexcept_true_spec
+ && over_throw != noexcept_false_spec))
+ return true;
+
if (!comp_except_specs (base_throw, over_throw, ce_derived))
{
auto_diagnostic_group d;
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
b/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
new file mode 100644
index 000..47832bbb44d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
@@ -0,0 +1,37 @@
+// PR c++/113158
+// { dg-do compile { target c++11 } }
+
+template
+struct V {
+ static constexpr bool t = false;
+};
+struct base {
+virtual int f() = 0;
+};
+
+template
+struct derived : base {
+int f() noexcept(V::t) override;
+};
+
+struct base2 {
+virtual int f() noexcept = 0;
+};
+
+template
+struct W {
+ static constexpr bool t = B;
+};
+
+template
+struct derived2 : base2 {
+int f() noexcept(W::t) override; // { dg-error "looser exception
specification" }
+};
+
+void
+g ()
+{
+ derived d1;
+ derived2 d2; // { dg-message "required from here" }
+ derived2 d3;
+}
base-commit: cd503b0616462445381a8232fb753239d319af76
--
2.43.2
RE: [COMMITTED] c++: Add testcase for this PR [PR97990]
> -Original Message-
> From: Marek Polacek
> Sent: Friday, February 16, 2024 11:11 AM
> To: Andrew Pinski (QUIC)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [COMMITTED] c++: Add testcase for this PR [PR97990]
>
> On Fri, Feb 16, 2024 at 11:00:34AM -0800, Andrew Pinski wrote:
> > This testcase was fixed by r14-5934-gf26d68d5d128c8 but we should add
> > one to make sure it does not regress again.
> >
> > Committed as obvious after a quick test on the testcase.
> >
> > PR c++/97990
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/torture/vector-struct-1.C: New test.
> >
> > Signed-off-by: Andrew Pinski
> > ---
> > gcc/testsuite/g++.dg/torture/vector-struct-1.C | 18
> > ++
> > 1 file changed, 18 insertions(+)
> > create mode 100644 gcc/testsuite/g++.dg/torture/vector-struct-1.C
> >
> > diff --git a/gcc/testsuite/g++.dg/torture/vector-struct-1.C
> > b/gcc/testsuite/g++.dg/torture/vector-struct-1.C
> > new file mode 100644
> > index 000..e2747417e2d
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/torture/vector-struct-1.C
> > @@ -0,0 +1,18 @@
> > +/* PR c++/97990 */
> > +/* This used to crash with lto and strict aliasing enabled as the
> > + vector type variant still had TYPE_ALIAS_SET set on it. */
>
> You don't have -Wstrict-aliasing here without which the test didn't ICE.
Oh you are correct. This is what I committed after testing to make sure it even
ICEd before the reference commit.
Thanks,
Andrew Pinski
>
> > +typedef __attribute__((__vector_size__(sizeof(short short TSimd;
> > +TSimd hh(int); struct y6 {
> > + TSimd VALUE;
> > + ~y6();
> > +};
> > +template
> > +auto f2(T1 p1, T2){
> > + return hh(p1) <= 0;
> > +}
> > +void f1(){
> > + f2(0, y6{});
> > +}
> > --
> > 2.43.0
> >
>
> Marek
0001-Add-Wstrict-aliasing-to-vector-struct-1.C-testcase.patch
Description: 0001-Add-Wstrict-aliasing-to-vector-struct-1.C-testcase.patch
Re: [PATCH] c++: Fix up parameter pack diagnostics on xobj vs. varargs functions [PR113802]
On Fri, Feb 16, 2024 at 10:20:26PM +0100, Jakub Jelinek wrote:
> I've tried that (see below), but am getting
> Excess errors:
> /usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:33:29:
> error: parameter packs not expanded with '...':
And the reason for those is that e.g. on the reduced
struct S0 {
void j(this auto... selves) {} // { dg-error "an explicit object parameter
cannot be a function parameter pack" }
};
with the first posted patch we first do:
if (xobj_param_p && (declarator && declarator->parameter_pack_p))
and clear declarator->parameter_pack_p there.
Then comes
if (parser->implicit_template_parms
&& ((token->type == CPP_ELLIPSIS
&& declarator_can_be_parameter_pack (declarator))
|| (declarator && declarator->parameter_pack_p)))
which is true only with the second patch and not the first.
Adding
if (parser->implicit_template_parms
&& ((token->type == CPP_ELLIPSIS
&& declarator_can_be_parameter_pack (declarator))
- || (declarator && declarator->parameter_pack_p)))
+ || (declarator && declarator->parameter_pack_p && !xobj_param_p)))
{
int latest_template_parm_idx = TREE_VEC_LENGTH
(INNERMOST_TEMPLATE_PARMS (current_template_parms));
fixes some of the excess errors, but not all of them, e.g. on
struct S1 {
void h(this auto&...) {} // { dg-error "an explicit object parameter cannot
be a function parameter pack" }
};
it still remains. The problem in there is that apparently we
need declarator->parameter_pack_p cleared on the xobj diagnostics
iff it was previously set before the CPP_ELLIPSIS handling above it,
but not if it was set in that handling. I'm afraid I have no idea
why though.
The following patch works.
2024-02-16 Jakub Jelinek
PR c++/113802
* parser.cc (cp_parser_parameter_declaration): Move the xobj_param_p
pack diagnostics after ellipsis handling, but only clear
declarator->parameter_pack_p for it if it was set before CPP_ELLIPSIS
handling. Ignore declarator->parameter_pack_p if xobj_param_p.
Formatting fix.
* g++.dg/cpp23/explicit-obj-diagnostics3.C (S0, S1, S2, S3, S4): Don't
expect any diagnostics on f and fd member function templates, add
similar templates with ...Selves instead of Selves as k and kd and
expect diagnostics for those.
--- gcc/cp/parser.cc.jj 2024-02-16 17:38:27.802845433 +0100
+++ gcc/cp/parser.cc2024-02-16 22:42:38.393896067 +0100
@@ -25734,39 +25734,25 @@ cp_parser_parameter_declaration (cp_pars
decl_specifiers.locations[ds_this] = 0;
}
- if (xobj_param_p
- && ((declarator && declarator->parameter_pack_p)
- || cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS)))
-{
- location_t xobj_param
- = make_location (decl_specifiers.locations[ds_this],
-decl_spec_token_start->location,
-input_location);
- error_at (xobj_param,
- "an explicit object parameter cannot "
- "be a function parameter pack");
- /* Suppress errors that occur down the line. */
- if (declarator)
- declarator->parameter_pack_p = false;
-}
-
/* If a function parameter pack was specified and an implicit template
parameter was introduced during cp_parser_parameter_declaration,
change any implicit parameters introduced into packs. */
if (parser->implicit_template_parms
&& ((token->type == CPP_ELLIPSIS
&& declarator_can_be_parameter_pack (declarator))
- || (declarator && declarator->parameter_pack_p)))
+ || (declarator && declarator->parameter_pack_p && !xobj_param_p)))
{
int latest_template_parm_idx = TREE_VEC_LENGTH
(INNERMOST_TEMPLATE_PARMS (current_template_parms));
if (latest_template_parm_idx != template_parm_idx)
- decl_specifiers.type = convert_generic_types_to_packs
- (decl_specifiers.type,
- template_parm_idx, latest_template_parm_idx);
+ decl_specifiers.type
+ = convert_generic_types_to_packs (decl_specifiers.type,
+ template_parm_idx,
+ latest_template_parm_idx);
}
+ bool prev_parameter_pack_p = declarator && declarator->parameter_pack_p;
if (cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS))
{
tree type = decl_specifiers.type;
@@ -25794,6 +25780,22 @@ cp_parser_parameter_declaration (cp_pars
}
}
+ if (xobj_param_p
+ && (declarator ? declarator->parameter_pack_p
+: PACK_EXPANSION_P (decl_specifiers.type)))
+{
+ location_t xobj_param
+ = make_location (decl_specifiers.locations[ds_this],
+decl_spec_token_start->location,
+input_location);
+ error_at (xobj_param,
+ "an explicit object parameter cannot "
+
[Bug fortran/113911] [14 Regression] Length is lost passing deferred-length character to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-02-16 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #6 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-February/060233.html
[PATCH] Fortran: deferred length of character variables shall not get lost [PR113911]
Dear all,
this patch fixes a regression which was a side-effect of r14-8947,
losing the length of a deferred-length character variable when
passed as a dummy.
The new testcase provides a workout for deferred length to improve
coverage in the testsuite. Another temporarily disabled test was
re-enabled.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 07fcdf7c9f9272d8e4752c23f04795d02d4ad440 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 16 Feb 2024 22:33:16 +0100
Subject: [PATCH] Fortran: deferred length of character variables shall not get
lost [PR113911]
PR fortran/113911
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_trans_deferred_array): Do not clobber
deferred length for a character variable passed as dummy argument.
gcc/testsuite/ChangeLog:
* gfortran.dg/allocatable_length_2.f90: New test.
* gfortran.dg/bind_c_optional-2.f90: Enable deferred-length test.
---
gcc/fortran/trans-array.cc| 2 +-
.../gfortran.dg/allocatable_length_2.f90 | 107 ++
.../gfortran.dg/bind_c_optional-2.f90 | 3 +-
3 files changed, 109 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/allocatable_length_2.f90
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 2181990aa04..3673fa40720 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -11531,7 +11531,7 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
if (sym->ts.type == BT_CHARACTER
&& !INTEGER_CST_P (sym->ts.u.cl->backend_decl))
{
- if (sym->ts.deferred && !sym->ts.u.cl->length)
+ if (sym->ts.deferred && !sym->ts.u.cl->length && !sym->attr.dummy)
gfc_add_modify (, sym->ts.u.cl->backend_decl,
build_zero_cst (TREE_TYPE (sym->ts.u.cl->backend_decl)));
gfc_conv_string_length (sym->ts.u.cl, NULL, );
diff --git a/gcc/testsuite/gfortran.dg/allocatable_length_2.f90 b/gcc/testsuite/gfortran.dg/allocatable_length_2.f90
new file mode 100644
index 000..2fd64efdc25
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/allocatable_length_2.f90
@@ -0,0 +1,107 @@
+! { dg-do run }
+! PR fortran/113911
+!
+! Test that deferred length is not lost
+
+module m
+ integer, parameter:: n = 100, l = 10
+ character(l) :: a = 'a234567890', b(n) = 'bcdefghijk'
+ character(:), allocatable :: c1, c2(:)
+end
+
+program p
+ use m, only : l, n, a, b, x => c1, y => c2
+ implicit none
+ character(:), allocatable :: d, e(:)
+ allocate (d, source=a)
+ allocate (e, source=b)
+ if (len (d) /= l .or. len (e) /= l .or. size (e) /= n) stop 12
+ call plain_deferred (d, e)
+ call optional_deferred (d, e)
+ call optional_deferred_ar (d, e)
+ if (len (d) /= l .or. len (e) /= l .or. size (e) /= n) stop 13
+ deallocate (d, e)
+ call alloc (d, e)
+ if (len (d) /= l .or. len (e) /= l .or. size (e) /= n) stop 14
+ deallocate (d, e)
+ call alloc_host_assoc ()
+ if (len (d) /= l .or. len (e) /= l .or. size (e) /= n) stop 15
+ deallocate (d, e)
+ call alloc_use_assoc ()
+ if (len (x) /= l .or. len (y) /= l .or. size (y) /= n) stop 16
+ call indirect (x, y)
+ if (len (x) /= l .or. len (y) /= l .or. size (y) /= n) stop 17
+ deallocate (x, y)
+contains
+ subroutine plain_deferred (c1, c2)
+character(:), allocatable :: c1, c2(:)
+if (.not. allocated (c1) .or. .not. allocated (c2)) stop 1
+if (len (c1) /= l) stop 2
+if (len (c2) /= l) stop 3
+if (c1(1:3)/= "a23") stop 4
+if (c2(5)(1:3) /= "bcd") stop 5
+ end
+
+ subroutine optional_deferred (c1, c2)
+character(:), allocatable, optional :: c1, c2(:)
+if (.not. present (c1) .or. .not. present (c2)) stop 6
+if (.not. allocated (c1) .or. .not. allocated (c2)) stop 7
+if (len (c1) /= l) stop 8
+if (len (c2) /= l) stop 9
+if (c1(1:3)/= "a23") stop 10
+if (c2(5)(1:3) /= "bcd") stop 11
+ end
+
+ ! Assumed rank
+ subroutine optional_deferred_ar (c1, c2)
+character(:), allocatable, optional :: c1(..)
+character(:), allocatable, optional :: c2(..)
+if (.not. present (c1) .or. &
+.not. present (c2)) stop 21
+if (.not. allocated (c1) .or. &
+.not. allocated (c2)) stop 22
+
+select rank (c1)
+rank (0)
+if (len (c1) /= l) stop 23
+ if (c1(1:3) /= "a23") stop 24
+rank default
+ stop 25
+end select
+
+select rank (c2)
+rank (1)
+ if (len (c2) /= l) stop 26
+ if (c2(5)(1:3) /= "bcd") stop 27
+rank default
+ stop 28
+end select
+ end
+
+ ! Allocate dummy arguments
+ subroutine alloc (c1, c2)
+character(:), allocatable :: c1, c2(:)
+allocate (c1, source=a)
+allocate (c2, source=b)
+ end
+
+ ! Allocate host-associated variables
+ subroutine alloc_host_assoc ()
+allocate (d, source=a)
+allocate (e, source=b)
+ end
+
+ ! Allocate use-associated variables
+ subroutine alloc_use_assoc ()
+allocate (x, source=a)
+
Re: [PATCH v2] c++: wrong looser excep spec for dep noexcept [PR113158]
On Fri, 16 Feb 2024, Marek Polacek wrote:
> On Fri, Feb 16, 2024 at 03:58:02PM -0500, Jason Merrill wrote:
> > On 2/15/24 17:17, Marek Polacek wrote:
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> > > By the ??? below I mean that maybe_instantiate_noexcept could return
> > > a tristate, and then maybe_check_overriding_exception_spec could check
> > >
> > >if (maybe_instantiate_noexcept ().is_unknown ())
> > > return true;
> > >
> > > and we don't have to add any new checks to maybe_check_o_e_spec.
> > >
> > > -- >8 --
> > > Here we find ourselves in maybe_check_overriding_exception_spec in
> > > a template context where we can't instantiate a dependent noexcept.
> > > That's OK, but we have to defer the checking otherwise we give wrong
> > > errors.
> > >
> > > PR c++/113158
> > >
> > > gcc/cp/ChangeLog:
> > >
> > > * search.cc (maybe_check_overriding_exception_spec): Defer checking
> > > when a noexcept couldn't be instantiated.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > * g++.dg/cpp0x/noexcept83.C: New test.
> > > ---
> > > gcc/cp/search.cc| 7 +
> > > gcc/testsuite/g++.dg/cpp0x/noexcept83.C | 37 +
> > > 2 files changed, 44 insertions(+)
> > > create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept83.C
> > >
> > > diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
> > > index c948839dc53..73d254d6b84 100644
> > > --- a/gcc/cp/search.cc
> > > +++ b/gcc/cp/search.cc
> > > @@ -1975,6 +1975,13 @@ maybe_check_overriding_exception_spec (tree
> > > overrider, tree basefn)
> > > || UNPARSED_NOEXCEPT_SPEC_P (over_throw))
> > > return true;
> > > + /* We also have to defer checking when we're in a template and couldn't
> > > + instantiate the noexcept yet.
> > > + ??? maybe_instantiate_noexcept already checked these. Use
> > > tristate? */
> > > + if (type_dependent_expression_p (base_throw)
> > > + || type_dependent_expression_p (over_throw))
> >
> > I think we also want to avoid comparing value-dependent expressions, but
> > actually checking either one seems like more work than needed here; I'd
> > think we want to defer in a template if the specifiers aren't both exactly
> > true or false.
>
> Yeah, that'll work too. So like this?
>
> Bootstrap/regtest running; dg.exp passed. FWIW, the new check only
> triggered on the new test.
>
> Thanks,
>
> -- >8 --
> Here we find ourselves in maybe_check_overriding_exception_spec in
> a template context where we can't instantiate a dependent noexcept.
> That's OK, but we have to defer the checking otherwise we give wrong
> errors.
>
> PR c++/113158
>
> gcc/cp/ChangeLog:
>
> * search.cc (maybe_check_overriding_exception_spec): Defer checking
> when a noexcept couldn't be instantiated & evaluated to false/true.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp0x/noexcept83.C: New test.
> ---
> gcc/cp/search.cc| 11
> gcc/testsuite/g++.dg/cpp0x/noexcept83.C | 37 +
> 2 files changed, 48 insertions(+)
> create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept83.C
>
> diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
> index c948839dc53..554ba71f4a7 100644
> --- a/gcc/cp/search.cc
> +++ b/gcc/cp/search.cc
> @@ -1975,6 +1975,17 @@ maybe_check_overriding_exception_spec (tree overrider,
> tree basefn)
>|| UNPARSED_NOEXCEPT_SPEC_P (over_throw))
> return true;
>
> + /* We also have to defer checking when we're in a template and couldn't
> + instantiate & evaluate the noexcept to true/false. */
> + if (processing_template_decl)
> +if ((base_throw
> + && (base_throw != noexcept_true_spec
> + || base_throw != noexcept_false_spec))
Shouldn't these innermost || be &&?
> + || (over_throw
> + && (over_throw != noexcept_true_spec
> + || over_throw != noexcept_false_spec)))
> + return true;
> +
>if (!comp_except_specs (base_throw, over_throw, ce_derived))
> {
>auto_diagnostic_group d;
> diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
> b/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
> new file mode 100644
> index 000..47832bbb44d
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
> @@ -0,0 +1,37 @@
> +// PR c++/113158
> +// { dg-do compile { target c++11 } }
> +
> +template
> +struct V {
> + static constexpr bool t = false;
> +};
> +struct base {
> +virtual int f() = 0;
> +};
> +
> +template
> +struct derived : base {
> +int f() noexcept(V::t) override;
> +};
> +
> +struct base2 {
> +virtual int f() noexcept = 0;
> +};
> +
> +template
> +struct W {
> + static constexpr bool t = B;
> +};
> +
> +template
> +struct derived2 : base2 {
> +int f() noexcept(W::t) override; // { dg-error "looser exception
> specification" }
> +};
> +
> +void
> +g ()
> +{
> + derived d1;
> + derived2 d2; // { dg-message "required from here" }
> +
Re: [PATCH v6 0/5]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)
On Fri, Feb 16, 2024 at 07:47:18PM +, Qing Zhao wrote: > This is the 6th version of the patch. Thanks! I've tested this and it meets all the current behavioral expectations I've got: https://github.com/kees/kernel-tools/blob/trunk/fortify/array-bounds.c Additionally, this builds the Linux kernel where we have almost 300 instances of "counted_by" attributes. Yay! -Kees -- Kees Cook
[PATCH v2] c++: wrong looser excep spec for dep noexcept [PR113158]
On Fri, Feb 16, 2024 at 03:58:02PM -0500, Jason Merrill wrote:
> On 2/15/24 17:17, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > By the ??? below I mean that maybe_instantiate_noexcept could return
> > a tristate, and then maybe_check_overriding_exception_spec could check
> >
> >if (maybe_instantiate_noexcept ().is_unknown ())
> > return true;
> >
> > and we don't have to add any new checks to maybe_check_o_e_spec.
> >
> > -- >8 --
> > Here we find ourselves in maybe_check_overriding_exception_spec in
> > a template context where we can't instantiate a dependent noexcept.
> > That's OK, but we have to defer the checking otherwise we give wrong
> > errors.
> >
> > PR c++/113158
> >
> > gcc/cp/ChangeLog:
> >
> > * search.cc (maybe_check_overriding_exception_spec): Defer checking
> > when a noexcept couldn't be instantiated.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/cpp0x/noexcept83.C: New test.
> > ---
> > gcc/cp/search.cc| 7 +
> > gcc/testsuite/g++.dg/cpp0x/noexcept83.C | 37 +
> > 2 files changed, 44 insertions(+)
> > create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept83.C
> >
> > diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
> > index c948839dc53..73d254d6b84 100644
> > --- a/gcc/cp/search.cc
> > +++ b/gcc/cp/search.cc
> > @@ -1975,6 +1975,13 @@ maybe_check_overriding_exception_spec (tree
> > overrider, tree basefn)
> > || UNPARSED_NOEXCEPT_SPEC_P (over_throw))
> > return true;
> > + /* We also have to defer checking when we're in a template and couldn't
> > + instantiate the noexcept yet.
> > + ??? maybe_instantiate_noexcept already checked these. Use tristate?
> > */
> > + if (type_dependent_expression_p (base_throw)
> > + || type_dependent_expression_p (over_throw))
>
> I think we also want to avoid comparing value-dependent expressions, but
> actually checking either one seems like more work than needed here; I'd
> think we want to defer in a template if the specifiers aren't both exactly
> true or false.
Yeah, that'll work too. So like this?
Bootstrap/regtest running; dg.exp passed. FWIW, the new check only
triggered on the new test.
Thanks,
-- >8 --
Here we find ourselves in maybe_check_overriding_exception_spec in
a template context where we can't instantiate a dependent noexcept.
That's OK, but we have to defer the checking otherwise we give wrong
errors.
PR c++/113158
gcc/cp/ChangeLog:
* search.cc (maybe_check_overriding_exception_spec): Defer checking
when a noexcept couldn't be instantiated & evaluated to false/true.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept83.C: New test.
---
gcc/cp/search.cc| 11
gcc/testsuite/g++.dg/cpp0x/noexcept83.C | 37 +
2 files changed, 48 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept83.C
diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
index c948839dc53..554ba71f4a7 100644
--- a/gcc/cp/search.cc
+++ b/gcc/cp/search.cc
@@ -1975,6 +1975,17 @@ maybe_check_overriding_exception_spec (tree overrider,
tree basefn)
|| UNPARSED_NOEXCEPT_SPEC_P (over_throw))
return true;
+ /* We also have to defer checking when we're in a template and couldn't
+ instantiate & evaluate the noexcept to true/false. */
+ if (processing_template_decl)
+if ((base_throw
+&& (base_throw != noexcept_true_spec
+|| base_throw != noexcept_false_spec))
+ || (over_throw
+ && (over_throw != noexcept_true_spec
+ || over_throw != noexcept_false_spec)))
+ return true;
+
if (!comp_except_specs (base_throw, over_throw, ce_derived))
{
auto_diagnostic_group d;
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
b/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
new file mode 100644
index 000..47832bbb44d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
@@ -0,0 +1,37 @@
+// PR c++/113158
+// { dg-do compile { target c++11 } }
+
+template
+struct V {
+ static constexpr bool t = false;
+};
+struct base {
+virtual int f() = 0;
+};
+
+template
+struct derived : base {
+int f() noexcept(V::t) override;
+};
+
+struct base2 {
+virtual int f() noexcept = 0;
+};
+
+template
+struct W {
+ static constexpr bool t = B;
+};
+
+template
+struct derived2 : base2 {
+int f() noexcept(W::t) override; // { dg-error "looser exception
specification" }
+};
+
+void
+g ()
+{
+ derived d1;
+ derived2 d2; // { dg-message "required from here" }
+ derived2 d3;
+}
base-commit: 40b8d7b73ad2ce498758c1d9bd38ebdbc26b918b
--
2.43.2
[Bug analyzer/109802] [13 Regression] ICE using dubious flexible arrays in unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109802 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-02-16 Summary|[regression] during IPA |[13 Regression] ICE using |pass: analyzer: internal|dubious flexible arrays in |compiler error (using |unions |dubious flexible arrays in | |unions) | --- Comment #5 from David Malcolm --- Thanks for filing this bug report. (In reply to Alejandro Colomar from comment #2) > Here's a simplified version that will cause the same internal compiler error. Trunk (GCC 14): ok: https://godbolt.org/z/4cjf6Khh3 GCC 13.2: ICE: https://godbolt.org/z/K4j97a4eb GCC 12.3: ok: https://godbolt.org/z/1jfz8YTPj ...so it seems like this is fixed on trunk (for GCC 14) but still affects GCC 13.
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
On Thu, 15 Feb 2024, Florian Weimer wrote: >>> +GCC no longer casts all pointer types to all other pointer types. >> >> Do you mean it no longer does so implicitly, or not at all? That is, >> there are now cases where even an explicit cast such as >> >> foo_p = (foo_type*) bar_p >> >> no longer works? Or just >> >> foo_p = bar_p >> >> no longer works for all combinations? > The latter, other reviewers noted it as well, and I've got this now: > “GCC no longer [allows implicitly casting] all pointer types to all” Ah, got it. The wording above nicely clarifies it to me. I am wondering whether "...every point type to every other pointer type" might be even more clear? (Open question, "no" being a very valid answer.) >> I *think* we may need to use here instead of plain '>', though I may >> be wrong. > No, only needs to be quoted. This is true even for XML, not just > HTML5. Do you want me to change these to ? No, no; if it validates, we're good. :-) > What about this? > >These failed probes tend to disable program features [together with] >their tests[], resulting in silently dropping features. > > This what I meant with “consistently”: implementations and tests are > gone, so the testsuite doesn't flag it. I like it! >>> +In cases where this is a concern, generated config.log, >>> +config.h and other source code files can be compared >>> +using https://www.gnu.org/software/diffutils/;>diff, >>> +to ensure there are no unexpected differences. >> I wouldn't link to GNU diffutils here; just refer to the diff >> command - or even omit that aspect and leave it at "can be compared". > diff is really useful for that, manual comparison isn't. 8-) > I can drop the hyperlink. Yes, I never would compare manually myself. :) Let's drop the hyperlink then; people developing software would know diff. >>> +Some build systems do not pass the CFLAGS environment >>> +or make variable to all parts of the builds >> >> Is "make" a common variable? What is the context here? > Hmm, I meant to allude $(CFLAGS) here. > > “CFLAGS [] variable to all parts of the builds” should be > sufficient. Ah, reading this again I see it was "environment variable" or "make variable" - the beauty of natural languages and their ambiguity. Yes, your suggested edit looks good! > I need to add two more code examples to the Autoconf section, should I > post a v2 with that, or add that in a subsequent commit? Primarily as you prefer. My personal recommendation (not request) is to commit the current patch and then add on top. Thanks again for your work documenting all this! Gerald
Re: [PATCH] c++: Fix up parameter pack diagnostics on xobj vs. varargs functions [PR113802]
On Fri, Feb 16, 2024 at 03:47:41PM -0500, Jason Merrill wrote:
> Can we move all the xobj handling down here (where we can trust
> declarator->parameter_pack_p) instead of adding a new variable?
I've tried that (see below), but am getting
Excess errors:
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:33:29:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:45:30:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:58:23:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:59:30:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:62:25:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:70:24:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:71:31:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:74:26:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:84:24:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:85:31:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:88:26:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:96:25:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:97:32:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:100:27:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:110:29:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:111:36:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:114:31:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:122:30:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:123:37:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:126:32:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:136:30:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:137:37:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:140:32:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:148:31:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:149:38:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:152:33:
error: parameter packs not expanded with '...':
with it (the other errors are emitted as expected).
2024-02-16 Jakub Jelinek
PR c++/113802
* parser.cc (cp_parser_parameter_declaration): Move the xobj_param_p
pack diagnostics after ellipsis handling. Formatting fix.
* g++.dg/cpp23/explicit-obj-diagnostics3.C (S0, S1, S2, S3, S4): Don't
expect any diagnostics on f and fd member function templates, add
similar templates with ...Selves instead of Selves as k and kd and
expect diagnostics for those.
--- gcc/cp/parser.cc.jj 2024-02-16 17:38:27.802845433 +0100
+++ gcc/cp/parser.cc2024-02-16 22:10:32.904353402 +0100
@@ -25734,22 +25734,6 @@ cp_parser_parameter_declaration (cp_pars
decl_specifiers.locations[ds_this] = 0;
}
- if (xobj_param_p
- && ((declarator && declarator->parameter_pack_p)
- || cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS)))
-{
- location_t xobj_param
- = make_location (decl_specifiers.locations[ds_this],
-decl_spec_token_start->location,
-input_location);
- error_at (xobj_param,
- "an explicit object parameter cannot "
- "be a function parameter pack");
- /* Suppress errors that occur down the line. */
- if (declarator)
- declarator->parameter_pack_p = false;
-}
-
/* If a function parameter pack was specified and an implicit template
parameter was introduced during
Re: [PATCH] Fortran: fix passing array component to polymorphic argument [PR105658]
Hi Peter,
thanks for your contribution to gfortran! You've found indeed
a solution for a potentially annoying bug.
Am 15.02.24 um 18:50 schrieb Peter Hill:
Dear all,
The attached patch fixes PR105658 by forcing an array temporary to be
created. This is required when passing an array component, but this
didn't happen if the dummy argument was an unlimited polymorphic type.
The problem bit of code is in `gfc_conv_expr_descriptor`, near L7828:
subref_array_target = (is_subref_array (expr)
&& (se->direct_byref
|| expr->ts.type == BT_CHARACTER));
need_tmp = (gfc_ref_needs_temporary_p (expr->ref)
&& !subref_array_target);
where `need_tmp` is being evaluated to 0. The logic here isn't clear
to me, and this function is used in several places, which is why I
went with setting `parmse.force_tmp = 1` in `gfc_conv_procedure_call`
and using the same conditional as the later branch for the
non-polymorphic case (near the call to `gfc_conv_subref_array_arg`)
If this patch is ok, please could someone commit it for me? This is my
first patch for GCC, so apologies in advance if the commit message is
missing something.
Your patch mostly does the right thing. Note that when fsym is
an unlimited polymorphic, some of its attributes are buried deep
within its internal representation. I would also prefer to move
the code to gfc_conv_intrinsic_to_class where it seems to fit better,
like:
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index a0593b76f18..db906caa52e 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -1019,6 +1019,14 @@ gfc_conv_intrinsic_to_class (gfc_se *parmse,
gfc_expr *e,
tmp = gfc_typenode_for_spec (_ts);
var = gfc_create_var (tmp, "class");
+ /* Force a temporary for component or substring references. */
+ if (unlimited_poly
+ && class_ts.u.derived->components->attr.dimension
+ && !class_ts.u.derived->components->attr.class_pointer
+ && !class_ts.u.derived->components->attr.allocatable
+ && is_subref_array (e))
+parmse->force_tmp = 1;
+
/* Set the vptr. */
ctree = gfc_class_vptr_get (var);
(I am not entirely sure whether we need to exclude pointer and
allocatable attributes here explicitly, given the constraints
in F2023:15.5.2.6, but other may have an opinion, too.
The above should be safe anyway.)
Tested on x86_64-pc-linux-gnu.
The bug is present in gfortran back to 4.9, so should it also be backported?
I think we'll target 14-mainline and might consider a backport to
13-branch.
Cheers,
Peter
PR fortran/105658
gcc/fortran/ChangeLog
* trans-expr.cc (gfc_conv_procedure_call): When passing an
array component reference of intrinsic type to a procedure
with an unlimited polymorphic dummy argument, a temporary
should be created.
gcc/testsuite/ChangeLog
* gfortran.dg/PR105658.f90: New test.
---
gcc/fortran/trans-expr.cc | 8
gcc/testsuite/gfortran.dg/PR105658.f90 | 25 +
2 files changed, 33 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/PR105658.f90
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index a0593b76f18..7fd3047c4e9 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6439,6 +6439,14 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
CLASS object for the unlimited polymorphic formal. */
gfc_find_vtab (>ts);
gfc_init_se (, se);
+ /* The actual argument is a component reference to an array
+ of derived types, so we need to force creation of a
+ temporary */
+ if (e->expr_type == EXPR_VARIABLE
+ && is_subref_array (e)
+ && !(fsym && fsym->attr.pointer))
+ parmse.force_tmp = 1;
+
gfc_conv_intrinsic_to_class (, e, fsym->ts);
}
diff --git a/gcc/testsuite/gfortran.dg/PR105658.f90
b/gcc/testsuite/gfortran.dg/PR105658.f90
new file mode 100644
index 000..407ee25f77c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR105658.f90
@@ -0,0 +1,25 @@
+! { dg-do compile }
+! { dg-options "-Warray-temporaries" }
+! Test fix for incorrectly passing array component to unlimited
polymorphic procedure
+
+module test_PR105658_mod
+ implicit none
+ type :: foo
+integer :: member1
+integer :: member2
+ end type foo
+contains
+ subroutine print_poly(array)
+class(*), dimension(:), intent(in) :: array
+select type(array)
+type is (integer)
+ print*, array
+end select
+ end subroutine print_poly
+
+ subroutine do_print(thing)
+type(foo), dimension(3), intent(in) :: thing
+call print_poly(thing%member1) ! { dg-warning "array temporary" }
+ end subroutine do_print
+
+end module test_PR105658_mod
One could extend this testcase to cover substrings as well:
module test_PR105658_mod
implicit none
type :: foo
integer :: member1
integer :: member2
end type foo
contains
subroutine print_poly(array)
class(*),
getting start with GSoC
Hello All, I am Nada Elsayed, A fresh graduate from computer engineering at Cairo University. I have good knowledge in C/C++, and a basic knowledge in compilers. als I am interested in contributing to the GCC this year; I am interested in "*Extend the static analysis pass" *projects or "*Improve nothrow detection in GCC" * project*.* Till now I have built the code and I am trying to understand it more. So what should I do now? Also, are bugs in https://gcc.gnu.org/wiki/EasyHacks good beginning or not? Regards, Nada Elsayed
[PATCH] dwarf2out, v3: Emit DW_AT_export_symbols on anon unions/structs [PR113918]
On Fri, Feb 16, 2024 at 03:40:39PM -0500, Jason Merrill wrote:
> > --- gcc/cp/cp-objcp-common.cc.jj2024-02-13 12:50:21.666846296 +0100
> > +++ gcc/cp/cp-objcp-common.cc 2024-02-16 20:40:51.374763528 +0100
> > @@ -410,6 +410,15 @@ cp_type_dwarf_attribute (const_tree type
> > return 1;
> > break;
> > +case DW_AT_export_symbols:
>
> For C++ this can use ANON_AGGR_TYPE_P, so it doesn't need to involve the
> FIELD_DECL at all. But I suppose the C front-end doesn't have a similar
> flag?
Yes, using ANON_AGGR_TYPE_P there works for C++, but C doesn't have anything
like that. All it uses is DECL_NAME == NULL on FIELD_DECL +
RECORD_OR_UNION_TYPE_P on its type to determine anon struct/union.
The patch below has updated cp_type_dwarf_attribute, otherwise the same as
before.
2024-02-16 Jakub Jelinek
PR debug/113918
gcc/
* dwarf2out.cc (gen_field_die): Emit DW_AT_export_symbols
on anonymous unions or structs for -gdwarf-5 or -gno-strict-dwarf.
gcc/c/
* c-tree.h (c_type_dwarf_attribute): Declare.
* c-objc-common.h (LANG_HOOKS_TYPE_DWARF_ATTRIBUTE): Redefine.
* c-objc-common.cc: Include dwarf2.h.
(c_type_dwarf_attribute): New function.
gcc/cp/
* cp-objcp-common.cc (cp_type_dwarf_attribute): Return 1
for DW_AT_export_symbols on anonymous structs or unions.
gcc/testsuite/
* c-c++-common/dwarf2/pr113918.c: New test.
--- gcc/dwarf2out.cc.jj 2024-02-15 13:54:29.284358101 +0100
+++ gcc/dwarf2out.cc2024-02-16 20:38:19.718841259 +0100
@@ -25153,6 +25153,17 @@ gen_field_die (tree decl, struct vlr_con
add_accessibility_attribute (decl_die, decl);
+ /* Add DW_AT_export_symbols to anonymous unions or structs. */
+ if ((dwarf_version >= 5 || !dwarf_strict) && DECL_NAME (decl) == NULL_TREE)
+if (tree type = member_declared_type (decl))
+ if (lang_hooks.types.type_dwarf_attribute (TYPE_MAIN_VARIANT (type),
+DW_AT_export_symbols) != -1)
+ {
+ dw_die_ref type_die = lookup_type_die (TYPE_MAIN_VARIANT (type));
+ if (type_die && get_AT (type_die, DW_AT_export_symbols) == NULL)
+ add_AT_flag (type_die, DW_AT_export_symbols, 1);
+ }
+
/* Equate decl number to die, so that we can look up this decl later on. */
equate_decl_number_to_die (decl, decl_die);
}
--- gcc/c/c-tree.h.jj 2024-01-31 10:46:35.164761720 +0100
+++ gcc/c/c-tree.h 2024-02-16 20:43:45.993372908 +0100
@@ -731,6 +731,7 @@ extern bool c_warn_unused_global_decl (c
extern void c_initialize_diagnostics (diagnostic_context *);
extern bool c_var_mod_p (tree x, tree fn);
extern alias_set_type c_get_alias_set (tree);
+extern int c_type_dwarf_attribute (const_tree, int);
/* in c-typeck.cc */
extern int in_alignof;
--- gcc/c/c-objc-common.h.jj2024-01-03 12:06:52.973862999 +0100
+++ gcc/c/c-objc-common.h 2024-02-16 20:42:21.073535465 +0100
@@ -119,6 +119,9 @@ static const scoped_attribute_specs *con
#undef LANG_HOOKS_GIMPLIFY_EXPR
#define LANG_HOOKS_GIMPLIFY_EXPR c_gimplify_expr
+#undef LANG_HOOKS_TYPE_DWARF_ATTRIBUTE
+#define LANG_HOOKS_TYPE_DWARF_ATTRIBUTE c_type_dwarf_attribute
+
#undef LANG_HOOKS_OMP_PREDETERMINED_SHARING
#define LANG_HOOKS_OMP_PREDETERMINED_SHARING c_omp_predetermined_sharing
--- gcc/c/c-objc-common.cc.jj 2024-01-03 12:06:53.213859637 +0100
+++ gcc/c/c-objc-common.cc 2024-02-16 20:45:24.649022305 +0100
@@ -30,6 +30,7 @@ along with GCC; see the file COPYING3.
#include "gcc-rich-location.h"
#include "stringpool.h"
#include "attribs.h"
+#include "dwarf2.h"
static bool c_tree_printer (pretty_printer *, text_info *, const char *,
int, bool, bool, bool, bool *, const char **);
@@ -446,3 +447,25 @@ instantiation_dependent_expression_p (tr
{
return false;
}
+
+/* Return -1 if dwarf ATTR shouldn't be added for TYPE, or the attribute
+ value otherwise. */
+int
+c_type_dwarf_attribute (const_tree type, int attr)
+{
+ if (type == NULL_TREE)
+return -1;
+
+ switch (attr)
+{
+case DW_AT_export_symbols:
+ if (RECORD_OR_UNION_TYPE_P (type) && TYPE_NAME (type) == NULL_TREE)
+ return 1;
+ break;
+
+default:
+ break;
+}
+
+ return -1;
+}
--- gcc/cp/cp-objcp-common.cc.jj2024-02-13 12:50:21.666846296 +0100
+++ gcc/cp/cp-objcp-common.cc 2024-02-16 21:48:33.880458318 +0100
@@ -410,6 +410,11 @@ cp_type_dwarf_attribute (const_tree type
return 1;
break;
+case DW_AT_export_symbols:
+ if (ANON_AGGR_TYPE_P (type))
+ return 1;
+ break;
+
default:
break;
}
--- gcc/testsuite/c-c++-common/dwarf2/pr113918.c.jj 2024-02-16
20:27:13.996961811 +0100
+++ gcc/testsuite/c-c++-common/dwarf2/pr113918.c2024-02-16
20:27:13.996961811 +0100
@@ -0,0 +1,33 @@
+/* PR debug/113918 */
+/* { dg-do compile } */
+/* { dg-options "-gdwarf-5 -dA -fno-merge-debug-strings" } */
+
+struct S {
+
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
On 2/14/24 18:33, Iain Sandoe wrote: On 14 Feb 2024, at 22:59, Iain Sandoe wrote: On 12 Feb 2024, at 19:59, Jason Merrill wrote: On 2/10/24 07:30, Iain Sandoe wrote: On 10 Feb 2024, at 12:07, Jason Merrill wrote: On 2/10/24 05:46, Iain Sandoe wrote: On 9 Feb 2024, at 23:21, Iain Sandoe wrote: On 9 Feb 2024, at 10:56, Iain Sandoe wrote: On 8 Feb 2024, at 21:44, Jason Merrill wrote: On 2/8/24 12:55, Paolo Bonzini wrote: On 2/8/24 18:16, Jason Merrill wrote: Hmm. In stage 1, when we build with the system gcc, I'd think we want the just-built gnat1 to find the system libgcc. In stage 2, when we build with the stage 1 gcc, we want the just-built gnat1 to find the stage 1 libgcc. In neither case do we want it to find the libgcc from the current stage. So it seems to me that what we want is for stage2+ LD_LIBRARY_PATH to include the TARGET_LIB_PATH from the previous stage. Something like the below, on top of the earlier patch. Does this make sense? Does it work on Darwin? Oops, that was broken, please consider this one instead: Yes, this one makes sense (and the current code would not work since it lacks the prev- prefix on TARGET_LIB_PATH). Indeed, that seems like evidence that the only element of TARGET_LIB_PATH that has been useful in HOST_EXPORTS is the prev- part of HOST_LIB_PATH_gcc. So, here's another patch that just includes that for post-stage1: <0001-build-drop-target-libs-from-LD_LIBRARY_PATH-PR105688.patch> Hmm this still fails for me with gnat1 being unable to find libgcc_s. It seems I have to add the PREV_HOST_LIB_PATH_gcc to HOST_LIB_PATH for it to succeed so, presumably, the post stage1 exports are not being forwarded to that build. I’ll try to analyze what exactly is failing. The fail is occurring in the target libada build; so, I suppose, one might say it’s reasonable that it requires this host path to be added to the target exports since it’s a host library used during target builds (or do folks expect the host exports to be made for target lib builds as well?) Appending the prev-gcc dirctory to the HOST_LIB_PATH fixes this Hmm this is still not right, in this case, I think it should actually be the “just built” directory; - if we have a tool that depends on host libraries (that happen to be also target ones), then those libraries have to be built before the tool so that they can be linked to it. (we specially copy libgcc* and the CRTs to gcc/ to allow for this case) - there is no prev-gcc in cross and —disable-bootstrap builds, but the tool will still be linked to the just-built host libraries (which will also be installed). So, I think we have to add HOST_LIB_PATH_gcc to HOST_LIB_PATH and HOST_PREV_LIB_PATH_gcc to POSTSTAGE1_HOST_EXPORTS (as per this patch). I don't follow. In a cross build, host libraries are a different architecture from target libraries, and certainly can't be linked into host binaries. In a disable-bootstrap build, even before my change TARGET_LIB_PATH isn't added to RPATH_ENVVAR, since that has been guarded with @if gcc-bootstrap. So in a bootstrap build, it shouldn't be needed for stage1 either. And for stage2, the one we need is from stage1, that matches the compiler we're building host tools with. What am I missing? nothing, I was off on a tangent about the cross/non-bootstrap, sorry about that. However, when doing target builds (the previous point) it seems we do have to make provision for gnat1 to find libgcc_s, and, at present, it seems that only the target exports are active. Ah, I see: When building target libraries in stage2, we run the stage2 compiler that needs the stage1 libgcc_s, but we don't have the HOST_EXPORTS because we're building target code, so we also need to get the libgcc path into TARGET_EXPORTS. Since TARGET_LIB_PATH is only added when gcc-bootstrap, I guess the previous libgcc is the only piece needed in TARGET_EXPORTS as well. So, how about this version of the patch? I tested this one on an affected platform version with and without —enable-host-shared and for all languages (less go which is not yet supported). It works for me, thanks, Iain Incidentally, during my investigations I was looking into various parts of this and it seems that actually TARGET_LIB_PATH might well be effectively dead code now. Good point. Could you test this version as well? From 6cd188de23ba5b7ac38a7902580fd861af03d3aa Mon Sep 17 00:00:00 2001 From: Jason Merrill Date: Wed, 24 Jan 2024 07:47:26 -0500 Subject: [PATCH] build: drop target libs from LD_LIBRARY_PATH [PR105688] To: gcc-patches@gcc.gnu.org The patch for PR22340 (r104978) moved the adding of TARGET_LIB_PATH to RPATH_ENVVAR from POSTSTAGE1_HOST_EXPORTS to HOST_EXPORTS, but didn't mention that in the ChangeLog; it also wasn't part of the patch that was sent to gcc-patches. I suspect it was included accidentally? It also causes PR105688 when rebuilding stage1: once the stage1 libstdc++ has been built,
Re: [PATCH] c++: wrong looser excep spec for dep noexcept [PR113158]
On 2/15/24 17:17, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
By the ??? below I mean that maybe_instantiate_noexcept could return
a tristate, and then maybe_check_overriding_exception_spec could check
if (maybe_instantiate_noexcept ().is_unknown ())
return true;
and we don't have to add any new checks to maybe_check_o_e_spec.
-- >8 --
Here we find ourselves in maybe_check_overriding_exception_spec in
a template context where we can't instantiate a dependent noexcept.
That's OK, but we have to defer the checking otherwise we give wrong
errors.
PR c++/113158
gcc/cp/ChangeLog:
* search.cc (maybe_check_overriding_exception_spec): Defer checking
when a noexcept couldn't be instantiated.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept83.C: New test.
---
gcc/cp/search.cc| 7 +
gcc/testsuite/g++.dg/cpp0x/noexcept83.C | 37 +
2 files changed, 44 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept83.C
diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
index c948839dc53..73d254d6b84 100644
--- a/gcc/cp/search.cc
+++ b/gcc/cp/search.cc
@@ -1975,6 +1975,13 @@ maybe_check_overriding_exception_spec (tree overrider,
tree basefn)
|| UNPARSED_NOEXCEPT_SPEC_P (over_throw))
return true;
+ /* We also have to defer checking when we're in a template and couldn't
+ instantiate the noexcept yet.
+ ??? maybe_instantiate_noexcept already checked these. Use tristate? */
+ if (type_dependent_expression_p (base_throw)
+ || type_dependent_expression_p (over_throw))
I think we also want to avoid comparing value-dependent expressions, but
actually checking either one seems like more work than needed here; I'd
think we want to defer in a template if the specifiers aren't both
exactly true or false.
+return true;
+
if (!comp_except_specs (base_throw, over_throw, ce_derived))
{
auto_diagnostic_group d;
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
b/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
new file mode 100644
index 000..47832bbb44d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept83.C
@@ -0,0 +1,37 @@
+// PR c++/113158
+// { dg-do compile { target c++11 } }
+
+template
+struct V {
+ static constexpr bool t = false;
+};
+struct base {
+virtual int f() = 0;
+};
+
+template
+struct derived : base {
+int f() noexcept(V::t) override;
+};
+
+struct base2 {
+virtual int f() noexcept = 0;
+};
+
+template
+struct W {
+ static constexpr bool t = B;
+};
+
+template
+struct derived2 : base2 {
+int f() noexcept(W::t) override; // { dg-error "looser exception
specification" }
+};
+
+void
+g ()
+{
+ derived d1;
+ derived2 d2; // { dg-message "required from here" }
+ derived2 d3;
+}
base-commit: b3b3bd250f0a7c22b7d46d3522c8b94c6a35d22a
prerequisite-patch-id: 3beddc8cae6ef7f28cd7eac7240d5f4dad08e5f7
[Bug target/113934] Switch avr to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #2 from Segher Boessenkool --- LRA does not use LEGITIMIZE_RELOAD_ADDRESS. The LRA code knows how to make all addresses legal by itself.
Re: [PATCH] c++: wrong looser exception spec with deleted fn
On 2/15/24 17:16, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
IMHO trivial enough to go ahead now seeing as it doesn't introduce
new errors.
OK.
-- >8 --
I noticed we don't implement the "unless the overriding function is
defined as deleted" wording added to [except.spec] via CWG 1351.
DR 1351
gcc/cp/ChangeLog:
* search.cc (maybe_check_overriding_exception_spec): Don't error about
a looser exception specification if the overrider is deleted.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept82.C: New test.
---
gcc/cp/search.cc| 11 +--
gcc/testsuite/g++.dg/cpp0x/noexcept82.C | 14 ++
2 files changed, 23 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept82.C
diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
index 2b4ed5d024e..c948839dc53 100644
--- a/gcc/cp/search.cc
+++ b/gcc/cp/search.cc
@@ -1949,7 +1949,11 @@ locate_field_accessor (tree basetype_path, tree
field_decl, bool const_p)
}
/* Check throw specifier of OVERRIDER is at least as strict as
- the one of BASEFN. */
+ the one of BASEFN. This is due to [except.spec]: "If a virtual function
+ has a non-throwing exception specification, all declarations, including
+ the definition, of any function that overrides that virtual function in
+ any derived class shall have a non-throwing exception specification,
+ unless the overriding function is defined as deleted." */
bool
maybe_check_overriding_exception_spec (tree overrider, tree basefn)
@@ -1959,7 +1963,10 @@ maybe_check_overriding_exception_spec (tree overrider,
tree basefn)
tree base_throw = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (basefn));
tree over_throw = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (overrider));
- if (DECL_INVALID_OVERRIDER_P (overrider))
+ if (DECL_INVALID_OVERRIDER_P (overrider)
+ /* CWG 1351 added the "unless the overriding function is defined as
+deleted" wording. */
+ || DECL_DELETED_FN (overrider))
return true;
/* Can't check this yet. Pretend this is fine and let
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept82.C
b/gcc/testsuite/g++.dg/cpp0x/noexcept82.C
new file mode 100644
index 000..c996613139b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept82.C
@@ -0,0 +1,14 @@
+// DR 1351, Problems with implicitly-declared exception-specifications
+// { dg-do compile { target c++11 } }
+
+struct B {
+ virtual void f() noexcept;
+ virtual void g();
+ virtual void h() noexcept = delete;
+};
+
+struct D: B {
+ void f(); // { dg-error "looser" }
+ void g() noexcept;// OK
+ void h() = delete;// OK
+};
base-commit: 0d5d1c75f5c68b6064640c3154ae5f4c0b464905
Re: [PATCH] c++: Fix up parameter pack diagnostics on xobj vs. varargs functions [PR113802]
On 2/16/24 04:03, Jakub Jelinek wrote:
Hi!
The simple presence of ellipsis as next token after the parameter
declaration doesn't imply it is a parameter pack, it sometimes is, e.g.
if its type is a pack, but sometimes is not and in that case it acts
the same as if the next tokens were , ... instead of just ...
The xobj param cannot be a function parameter pack though treats both
the declarator->parameter_pack_p and token->type == CPP_ELLIPSIS as
sufficient conditions for the error. The conditions for CPP_ELLIPSIS
are done a little bit later in the same function and complex enough that
IMHO shouldn't be repeated, on the other side for the
declarator->parameter_pack_p case we clear that flag for xobj params
for error recovery reasons.
In order to avoid diagnosing this in two spots, one at the current spot
for declarator->parameter_pack_p and one for the ellipsis case after
we decide if it is parameter pack or varargs, the following patch instead
just sets a boolean flag whether we should emit this diagnostics, does it
early for declarator->parameter_pack_p case and clears the parameter_pack_p
flag in that case like the older patch did, and for the ellipsis case
sets the flag later, then emits the diagnostics.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-16 Jakub Jelinek
PR c++/113802
* parser.cc (cp_parser_parameter_declaration): Don't emit
PR113307 diagnostics too early, instead for the
declarator->parameter_pack_p case just set a flag it should be emitted
later. Set that flag also when consuming following ellipsis as part
of a parameter pack and diagnose either afterwards. Formatting fix.
* g++.dg/cpp23/explicit-obj-diagnostics3.C (S0, S1, S2, S3, S4): Don't
expect any diagnostics on f and fd member function templates, add
similar templates with ...Selves instead of Selves as k and kd and
expect diagnostics for those.
--- gcc/cp/parser.cc.jj 2024-02-14 14:26:19.0 +0100
+++ gcc/cp/parser.cc2024-02-15 11:58:27.033618967 +0100
@@ -25727,17 +25727,10 @@ cp_parser_parameter_declaration (cp_pars
bool const xobj_param_p
= decl_spec_seq_has_spec_p (_specifiers, ds_this);
- if (xobj_param_p
- && ((declarator && declarator->parameter_pack_p)
- || cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS)))
+ bool diag_xobj_parameter_pack = false;
+ if (xobj_param_p && (declarator && declarator->parameter_pack_p))
{
- location_t xobj_param
- = make_location (decl_specifiers.locations[ds_this],
-decl_spec_token_start->location,
-input_location);
- error_at (xobj_param,
- "an explicit object parameter cannot "
- "be a function parameter pack");
+ diag_xobj_parameter_pack = true;
/* Suppress errors that occur down the line. */
if (declarator)
declarator->parameter_pack_p = false;
@@ -25755,9 +25748,10 @@ cp_parser_parameter_declaration (cp_pars
(INNERMOST_TEMPLATE_PARMS (current_template_parms));
if (latest_template_parm_idx != template_parm_idx)
- decl_specifiers.type = convert_generic_types_to_packs
- (decl_specifiers.type,
- template_parm_idx, latest_template_parm_idx);
+ decl_specifiers.type
+ = convert_generic_types_to_packs (decl_specifiers.type,
+ template_parm_idx,
+ latest_template_parm_idx);
}
if (cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS))
@@ -25773,6 +25767,8 @@ cp_parser_parameter_declaration (cp_pars
|| (!type && template_parm_p))
&& declarator_can_be_parameter_pack (declarator))
{
+ if (xobj_param_p)
+ diag_xobj_parameter_pack = true;
/* Consume the `...'. */
cp_lexer_consume_token (parser->lexer);
maybe_warn_variadic_templates ();
@@ -25787,6 +25783,17 @@ cp_parser_parameter_declaration (cp_pars
}
}
+ if (diag_xobj_parameter_pack)
Can we move all the xobj handling down here (where we can trust
declarator->parameter_pack_p) instead of adding a new variable?
+{
+ location_t xobj_param
+ = make_location (decl_specifiers.locations[ds_this],
+decl_spec_token_start->location,
+input_location);
+ error_at (xobj_param,
+ "an explicit object parameter cannot "
+ "be a function parameter pack");
+}
+
/* The restriction on defining new types applies only to the type
of the parameter, not to the default argument. */
parser->type_definition_forbidden_message = saved_message;
--- gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C.jj 2024-01-17
10:34:49.812597960 +0100
+++ gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C 2024-02-15
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #47 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #46)
> (In reply to Jan Hubicka from comment #43)
> > > // See discussion here:
> > > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
> > Discussion says:
> >
> > "Once legacy evrp is removed, this won't be an issue, as ranges in the IL
> > will tell the truth. However, this will mean that we will no longer
> > remove the first __builtin_unreachable combo. But ISTM, that would be
> > correct behavior ??."
> >
> > So perhaps, we could remove that special case for default def and phi?
> > It is an odd thing and we clearly lose info here.
> >
>
> legacy VRP has been removed now. So in theory we are free to do as we
> want.. but I don't remember the specific details.
>
> So do you just want to always use get_range_global() ? and not do the check?
>
> I can try changing it to just get_global and see what happens.
FWIW,
diff --git a/gcc/value-query.cc b/gcc/value-query.cc
index 040c843c566..0ab10bc5a46 100644
--- a/gcc/value-query.cc
+++ b/gcc/value-query.cc
@@ -353,16 +353,9 @@ get_range_global (vrange , tree name, struct function
*fun = cfun)
void
gimple_range_global (vrange , tree name, struct function *fun)
{
- tree type = TREE_TYPE (name);
gcc_checking_assert (TREE_CODE (name) == SSA_NAME);
- if (SSA_NAME_IS_DEFAULT_DEF (name) || (fun && fun->after_inlining)
- || is_a (SSA_NAME_DEF_STMT (name)))
-{
- get_range_global (r, name, fun);
- return;
-}
- r.set_varying (type);
+ get_range_global (r, name, fun);
}
bootstraps and runs the testsuites clean on x86-64 now...
Re: [PATCH] dwarf2out, v2: Emit DW_AT_export_symbols on anon unions/structs [PR113918]
On 2/16/24 14:52, Jakub Jelinek wrote:
On Fri, Feb 16, 2024 at 04:52:20PM +0100, Jakub Jelinek wrote:
On Fri, Feb 16, 2024 at 10:48:28AM -0500, Jason Merrill wrote:
On 2/16/24 04:14, Jakub Jelinek wrote:
DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
we emit it), but also on anonymous unions/structs (and we didn't emit that
attribute there).
The following patch fixes it.
Should this involve cp_decl_dwarf_attribute like the namespace handling?
I wrote it in dwarf2out.cc because the same thing needs to be done for C and
C++ (admittedly dunno if other languages have something similar).
Sure, it could be done in cp_decl_dwarf_attribute too but then it has to be
done in c_decl_dwarf_attribute which doesn't exist. Though, it is slightly
complicated by DW_AT_export_symbols not actually going on the DW_TAG_member
die but on the DW_TAG_{structure,class,union}_type which DW_TAG_member uses
as its DW_AT_type. But in order to ask the langhook, we likely need to pass
the FIELD_DECL and not the type...
Anyway, here is a version of the patch that uses the langhook for it.
So that the langhook isn't totally abused and for performance reasons too
I've kept the DECL_NAME == NULL check on the dwarf2out.cc side and am
calling it on the type rather than decl, because type is where the attribute
should go.
2024-02-16 Jakub Jelinek
PR debug/113918
gcc/
* dwarf2out.cc (gen_field_die): Emit DW_AT_export_symbols
on anonymous unions or structs for -gdwarf-5 or -gno-strict-dwarf.
gcc/c/
* c-tree.h (c_type_dwarf_attribute): Declare.
* c-objc-common.h (LANG_HOOKS_TYPE_DWARF_ATTRIBUTE): Redefine.
* c-objc-common.cc: Include dwarf2.h.
(c_type_dwarf_attribute): New function.
gcc/cp/
* cp-objcp-common.cc (cp_type_dwarf_attribute): Return 1
for DW_AT_export_symbols on anonymous structs or unions.
gcc/testsuite/
* c-c++-common/dwarf2/pr113918.c: New test.
--- gcc/dwarf2out.cc.jj 2024-02-15 13:54:29.284358101 +0100
+++ gcc/dwarf2out.cc2024-02-16 20:38:19.718841259 +0100
@@ -25153,6 +25153,17 @@ gen_field_die (tree decl, struct vlr_con
add_accessibility_attribute (decl_die, decl);
+ /* Add DW_AT_export_symbols to anonymous unions or structs. */
+ if ((dwarf_version >= 5 || !dwarf_strict) && DECL_NAME (decl) == NULL_TREE)
+if (tree type = member_declared_type (decl))
+ if (lang_hooks.types.type_dwarf_attribute (TYPE_MAIN_VARIANT (type),
+DW_AT_export_symbols) != -1)
+ {
+ dw_die_ref type_die = lookup_type_die (TYPE_MAIN_VARIANT (type));
+ if (type_die && get_AT (type_die, DW_AT_export_symbols) == NULL)
+ add_AT_flag (type_die, DW_AT_export_symbols, 1);
+ }
+
/* Equate decl number to die, so that we can look up this decl later on. */
equate_decl_number_to_die (decl, decl_die);
}
--- gcc/c/c-tree.h.jj 2024-01-31 10:46:35.164761720 +0100
+++ gcc/c/c-tree.h 2024-02-16 20:43:45.993372908 +0100
@@ -731,6 +731,7 @@ extern bool c_warn_unused_global_decl (c
extern void c_initialize_diagnostics (diagnostic_context *);
extern bool c_var_mod_p (tree x, tree fn);
extern alias_set_type c_get_alias_set (tree);
+extern int c_type_dwarf_attribute (const_tree, int);
/* in c-typeck.cc */
extern int in_alignof;
--- gcc/c/c-objc-common.h.jj2024-01-03 12:06:52.973862999 +0100
+++ gcc/c/c-objc-common.h 2024-02-16 20:42:21.073535465 +0100
@@ -119,6 +119,9 @@ static const scoped_attribute_specs *con
#undef LANG_HOOKS_GIMPLIFY_EXPR
#define LANG_HOOKS_GIMPLIFY_EXPR c_gimplify_expr
+#undef LANG_HOOKS_TYPE_DWARF_ATTRIBUTE
+#define LANG_HOOKS_TYPE_DWARF_ATTRIBUTE c_type_dwarf_attribute
+
#undef LANG_HOOKS_OMP_PREDETERMINED_SHARING
#define LANG_HOOKS_OMP_PREDETERMINED_SHARING c_omp_predetermined_sharing
--- gcc/c/c-objc-common.cc.jj 2024-01-03 12:06:53.213859637 +0100
+++ gcc/c/c-objc-common.cc 2024-02-16 20:45:24.649022305 +0100
@@ -30,6 +30,7 @@ along with GCC; see the file COPYING3.
#include "gcc-rich-location.h"
#include "stringpool.h"
#include "attribs.h"
+#include "dwarf2.h"
static bool c_tree_printer (pretty_printer *, text_info *, const char *,
int, bool, bool, bool, bool *, const char **);
@@ -446,3 +447,25 @@ instantiation_dependent_expression_p (tr
{
return false;
}
+
+/* Return -1 if dwarf ATTR shouldn't be added for TYPE, or the attribute
+ value otherwise. */
+int
+c_type_dwarf_attribute (const_tree type, int attr)
+{
+ if (type == NULL_TREE)
+return -1;
+
+ switch (attr)
+{
+case DW_AT_export_symbols:
+ if (RECORD_OR_UNION_TYPE_P (type) && TYPE_NAME (type) == NULL_TREE)
+ return 1;
+ break;
+
+default:
+ break;
+}
+
+ return -1;
+}
--- gcc/cp/cp-objcp-common.cc.jj2024-02-13 12:50:21.666846296 +0100
+++ gcc/cp/cp-objcp-common.cc 2024-02-16 20:40:51.374763528
[PATCH] dwarf2out, v2: Emit DW_AT_export_symbols on anon unions/structs [PR113918]
On Fri, Feb 16, 2024 at 04:52:20PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 16, 2024 at 10:48:28AM -0500, Jason Merrill wrote:
> > On 2/16/24 04:14, Jakub Jelinek wrote:
> > > DWARF5 added DW_AT_export_symbols both for use on inline namespaces (where
> > > we emit it), but also on anonymous unions/structs (and we didn't emit that
> > > attribute there).
> > > The following patch fixes it.
> >
> > Should this involve cp_decl_dwarf_attribute like the namespace handling?
>
> I wrote it in dwarf2out.cc because the same thing needs to be done for C and
> C++ (admittedly dunno if other languages have something similar).
>
> Sure, it could be done in cp_decl_dwarf_attribute too but then it has to be
> done in c_decl_dwarf_attribute which doesn't exist. Though, it is slightly
> complicated by DW_AT_export_symbols not actually going on the DW_TAG_member
> die but on the DW_TAG_{structure,class,union}_type which DW_TAG_member uses
> as its DW_AT_type. But in order to ask the langhook, we likely need to pass
> the FIELD_DECL and not the type...
Anyway, here is a version of the patch that uses the langhook for it.
So that the langhook isn't totally abused and for performance reasons too
I've kept the DECL_NAME == NULL check on the dwarf2out.cc side and am
calling it on the type rather than decl, because type is where the attribute
should go.
2024-02-16 Jakub Jelinek
PR debug/113918
gcc/
* dwarf2out.cc (gen_field_die): Emit DW_AT_export_symbols
on anonymous unions or structs for -gdwarf-5 or -gno-strict-dwarf.
gcc/c/
* c-tree.h (c_type_dwarf_attribute): Declare.
* c-objc-common.h (LANG_HOOKS_TYPE_DWARF_ATTRIBUTE): Redefine.
* c-objc-common.cc: Include dwarf2.h.
(c_type_dwarf_attribute): New function.
gcc/cp/
* cp-objcp-common.cc (cp_type_dwarf_attribute): Return 1
for DW_AT_export_symbols on anonymous structs or unions.
gcc/testsuite/
* c-c++-common/dwarf2/pr113918.c: New test.
--- gcc/dwarf2out.cc.jj 2024-02-15 13:54:29.284358101 +0100
+++ gcc/dwarf2out.cc2024-02-16 20:38:19.718841259 +0100
@@ -25153,6 +25153,17 @@ gen_field_die (tree decl, struct vlr_con
add_accessibility_attribute (decl_die, decl);
+ /* Add DW_AT_export_symbols to anonymous unions or structs. */
+ if ((dwarf_version >= 5 || !dwarf_strict) && DECL_NAME (decl) == NULL_TREE)
+if (tree type = member_declared_type (decl))
+ if (lang_hooks.types.type_dwarf_attribute (TYPE_MAIN_VARIANT (type),
+DW_AT_export_symbols) != -1)
+ {
+ dw_die_ref type_die = lookup_type_die (TYPE_MAIN_VARIANT (type));
+ if (type_die && get_AT (type_die, DW_AT_export_symbols) == NULL)
+ add_AT_flag (type_die, DW_AT_export_symbols, 1);
+ }
+
/* Equate decl number to die, so that we can look up this decl later on. */
equate_decl_number_to_die (decl, decl_die);
}
--- gcc/c/c-tree.h.jj 2024-01-31 10:46:35.164761720 +0100
+++ gcc/c/c-tree.h 2024-02-16 20:43:45.993372908 +0100
@@ -731,6 +731,7 @@ extern bool c_warn_unused_global_decl (c
extern void c_initialize_diagnostics (diagnostic_context *);
extern bool c_var_mod_p (tree x, tree fn);
extern alias_set_type c_get_alias_set (tree);
+extern int c_type_dwarf_attribute (const_tree, int);
/* in c-typeck.cc */
extern int in_alignof;
--- gcc/c/c-objc-common.h.jj2024-01-03 12:06:52.973862999 +0100
+++ gcc/c/c-objc-common.h 2024-02-16 20:42:21.073535465 +0100
@@ -119,6 +119,9 @@ static const scoped_attribute_specs *con
#undef LANG_HOOKS_GIMPLIFY_EXPR
#define LANG_HOOKS_GIMPLIFY_EXPR c_gimplify_expr
+#undef LANG_HOOKS_TYPE_DWARF_ATTRIBUTE
+#define LANG_HOOKS_TYPE_DWARF_ATTRIBUTE c_type_dwarf_attribute
+
#undef LANG_HOOKS_OMP_PREDETERMINED_SHARING
#define LANG_HOOKS_OMP_PREDETERMINED_SHARING c_omp_predetermined_sharing
--- gcc/c/c-objc-common.cc.jj 2024-01-03 12:06:53.213859637 +0100
+++ gcc/c/c-objc-common.cc 2024-02-16 20:45:24.649022305 +0100
@@ -30,6 +30,7 @@ along with GCC; see the file COPYING3.
#include "gcc-rich-location.h"
#include "stringpool.h"
#include "attribs.h"
+#include "dwarf2.h"
static bool c_tree_printer (pretty_printer *, text_info *, const char *,
int, bool, bool, bool, bool *, const char **);
@@ -446,3 +447,25 @@ instantiation_dependent_expression_p (tr
{
return false;
}
+
+/* Return -1 if dwarf ATTR shouldn't be added for TYPE, or the attribute
+ value otherwise. */
+int
+c_type_dwarf_attribute (const_tree type, int attr)
+{
+ if (type == NULL_TREE)
+return -1;
+
+ switch (attr)
+{
+case DW_AT_export_symbols:
+ if (RECORD_OR_UNION_TYPE_P (type) && TYPE_NAME (type) == NULL_TREE)
+ return 1;
+ break;
+
+default:
+ break;
+}
+
+ return -1;
+}
--- gcc/cp/cp-objcp-common.cc.jj2024-02-13 12:50:21.666846296 +0100
+++ gcc/cp/cp-objcp-common.cc 2024-02-16 20:40:51.374763528 +0100
@@ -410,6
[PATCH v6 1/5] Provide counted_by attribute to flexible array member field (PR108896)
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as the flexible array member. GCC uses this
information to improve the results of the array bound sanitizer and
the '__builtin_dynamic_object_size'.
For instance, the following code:
struct P {
size_t count;
char other;
char array[] __attribute__ ((counted_by (count)));
} *p;
specifies that the 'array' is a flexible array member whose number
of elements is given by the field 'count' in the same structure.
The field that represents the number of the elements should have an
integer type. Otherwise, the compiler will report a warning and
ignore the attribute.
When the field that represents the number of the elements is assigned a
negative integer value, the compiler will treat the value as zero.
An explicit 'counted_by' annotation defines a relationship between
two objects, 'p->array' and 'p->count', and there are the following
requirementthat on the relationship between this pair:
* 'p->count' should be initialized before the first reference to
'p->array';
* 'p->array' has _at least_ 'p->count' number of elements
available all the time. This relationship must hold even
after any of these related objects are updated during the
program.
It's the user's responsibility to make sure the above requirements
to be kept all the time. Otherwise the compiler will report
warnings, at the same time, the results of the array bound
sanitizer and the '__builtin_dynamic_object_size' is undefined.
One important feature of the attribute is, a reference to the
flexible array member field will use the latest value assigned to
the field that represents the number of the elements before that
reference. For example,
p->count = val1;
p->array[20] = 0; // ref1 to p->array
p->count = val2;
p->array[30] = 0; // ref2 to p->array
in the above, 'ref1' will use 'val1' as the number of the elements
in 'p->array', and 'ref2' will use 'val2' as the number of elements
in 'p->array'.
gcc/c-family/ChangeLog:
PR C/108896
* c-attribs.cc (handle_counted_by_attribute): New function.
(attribute_takes_identifier_p): Add counted_by attribute to the list.
* c-common.cc (c_flexible_array_member_type_p): ...To this.
* c-common.h (c_flexible_array_member_type_p): New prototype.
gcc/c/ChangeLog:
PR C/108896
* c-decl.cc (flexible_array_member_type_p): Renamed and moved to...
(add_flexible_array_elts_to_size): Use renamed function.
(is_flexible_array_member_p): Use renamed function.
(verify_counted_by_attribute): New function.
(finish_struct): Use renamed function and verify counted_by
attribute.
* c-tree.h (lookup_field): New prototype.
* c-typeck.cc (lookup_field): Expose as extern function.
gcc/ChangeLog:
PR C/108896
* doc/extend.texi: Document attribute counted_by.
gcc/testsuite/ChangeLog:
PR C/108896
* gcc.dg/flex-array-counted-by.c: New test.
---
gcc/c-family/c-attribs.cc| 54 -
gcc/c-family/c-common.cc | 13 +++
gcc/c-family/c-common.h | 1 +
gcc/c/c-decl.cc | 85
gcc/c/c-tree.h | 1 +
gcc/c/c-typeck.cc| 3 +-
gcc/doc/extend.texi | 64 +++
gcc/testsuite/gcc.dg/flex-array-counted-by.c | 40 +
8 files changed, 241 insertions(+), 20 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/flex-array-counted-by.c
diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index 40a0cf90295d..4395c0656b14 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -105,6 +105,8 @@ static tree handle_warn_if_not_aligned_attribute (tree *,
tree, tree,
int, bool *);
static tree handle_strict_flex_array_attribute (tree *, tree, tree,
int, bool *);
+static tree handle_counted_by_attribute (tree *, tree, tree,
+ int, bool *);
static tree handle_weak_attribute (tree *, tree, tree, int, bool *) ;
static tree handle_noplt_attribute (tree *, tree, tree, int, bool *) ;
static tree handle_alias_ifunc_attribute (bool, tree *, tree, tree, bool *);
@@ -412,6 +414,8 @@ const struct attribute_spec c_common_gnu_attributes[] =
handle_warn_if_not_aligned_attribute, NULL },
[Bug analyzer/110285] [13/14 Regression] -Wanalyzer-infinite-recursion false positive involving floating-point values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110285 David Malcolm changed: What|Removed |Added Last reconfirmed||2024-02-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|-Wanalyzer-infinite-recursi |[13/14 Regression] |on false positive involving |-Wanalyzer-infinite-recursi |floating-point values |on false positive involving ||floating-point values
[PATCH v6 5/5] Add the 6th argument to .ACCESS_WITH_SIZE
to carry the TYPE of the flexible array.
Such information is needed during tree-object-size.cc.
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible type casting in the
source code.
gcc/c/ChangeLog:
* c-typeck.cc (build_access_with_size_for_counted_by): Add the 6th
argument to .ACCESS_WITH_SIZE.
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): Use the type
of the 6th argument for the type of the element.
gcc/testsuite/ChangeLog:
* gcc.dg/flex-array-counted-by-6.c: New test.
---
gcc/c/c-typeck.cc | 11 +++--
.../gcc.dg/flex-array-counted-by-6.c | 46 +++
gcc/tree-object-size.cc | 16 ---
3 files changed, 64 insertions(+), 9 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/flex-array-counted-by-6.c
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index a29a7d7ec029..c17ac6862546 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -2608,7 +2608,8 @@ build_counted_by_ref (tree datum, tree subdatum, tree
*counted_by_type)
to:
- (*.ACCESS_WITH_SIZE (REF, COUNTED_BY_REF, 1, (TYPE_OF_SIZE)0, -1))
+ (*.ACCESS_WITH_SIZE (REF, COUNTED_BY_REF, 1, (TYPE_OF_SIZE)0, -1,
+ (TYPE_OF_ARRAY *)0))
NOTE: The return type of this function is the POINTER type pointing
to the original flexible array type.
@@ -2620,6 +2621,9 @@ build_counted_by_ref (tree datum, tree subdatum, tree
*counted_by_type)
The 4th argument of the call is a constant 0 with the TYPE of the
object pointed by COUNTED_BY_REF.
+ The 6th argument of the call is a constant 0 with the pointer TYPE
+ to the original flexible array type.
+
*/
static tree
build_access_with_size_for_counted_by (location_t loc, tree ref,
@@ -2632,12 +2636,13 @@ build_access_with_size_for_counted_by (location_t loc,
tree ref,
tree call
= build_call_expr_internal_loc (loc, IFN_ACCESS_WITH_SIZE,
- result_type, 5,
+ result_type, 6,
array_to_pointer_conversion (loc, ref),
counted_by_ref,
build_int_cst (integer_type_node, 1),
build_int_cst (counted_by_type, 0),
- build_int_cst (integer_type_node, -1));
+ build_int_cst (integer_type_node, -1),
+ build_int_cst (result_type, 0));
/* Wrap the call with an INDIRECT_REF with the flexible array type. */
call = build1 (INDIRECT_REF, TREE_TYPE (ref), call);
SET_EXPR_LOCATION (call, loc);
diff --git a/gcc/testsuite/gcc.dg/flex-array-counted-by-6.c
b/gcc/testsuite/gcc.dg/flex-array-counted-by-6.c
new file mode 100644
index ..65a401796479
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/flex-array-counted-by-6.c
@@ -0,0 +1,46 @@
+/* test the attribute counted_by and its usage in
+ * __builtin_dynamic_object_size. when the type of the flexible array member
+ * is casting to another type. */
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+#include "builtin-object-size-common.h"
+
+typedef unsigned short u16;
+
+struct info {
+ u16 data_len;
+ char data[] __attribute__((counted_by(data_len)));
+};
+
+struct foo {
+ int a;
+ int b;
+};
+
+static __attribute__((__noinline__))
+struct info *setup ()
+{
+ struct info *p;
+ size_t bytes = 3 * sizeof(struct foo);
+
+ p = (struct info *)malloc (sizeof (struct info) + bytes);
+ p->data_len = bytes;
+
+ return p;
+}
+
+static void
+__attribute__((__noinline__)) report (struct info *p)
+{
+ struct foo *bar = (struct foo *)p->data;
+ EXPECT(__builtin_dynamic_object_size((char *)(bar + 1), 1), 16);
+ EXPECT(__builtin_dynamic_object_size((char *)(bar + 2), 1), 8);
+}
+
+int main(int argc, char *argv[])
+{
+ struct info *p = setup();
+ report(p);
+ return 0;
+}
diff --git a/gcc/tree-object-size.cc b/gcc/tree-object-size.cc
index 630b0a7aaa4b..c3098c521a43 100644
--- a/gcc/tree-object-size.cc
+++ b/gcc/tree-object-size.cc
@@ -763,17 +763,21 @@ addr_object_size (struct object_size_info *osi,
const_tree ptr,
2: the number of bytes;
4th argument TYPE_OF_SIZE: A constant 0 with the TYPE of the object
refed by REF_TO_SIZE
+ 6th argument: A constant 0 with the pointer TYPE to the original flexible
+ array type.
- the size of the element can be retrived from the result type of the call,
- which is the pointer to the array type. */
+ the size of the element can be retrived from the TYPE of the 6th argument
+ of the call, which is the pointer to the array type. */
static tree
access_with_size_object_size (const gcall *call, int object_size_type)
{
gcc_assert (gimple_call_internal_p (call,
[PATCH v6 4/5] Use the .ACCESS_WITH_SIZE in bound sanitizer.
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test.
* gcc.dg/ubsan/flex-array-counted-by-bounds-3.c: New test.
* gcc.dg/ubsan/flex-array-counted-by-bounds.c: New test.
---
gcc/c-family/c-ubsan.cc | 42 +
.../ubsan/flex-array-counted-by-bounds-2.c| 45 ++
.../ubsan/flex-array-counted-by-bounds-3.c| 34 ++
.../ubsan/flex-array-counted-by-bounds.c | 46 +++
4 files changed, 167 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/ubsan/flex-array-counted-by-bounds-2.c
create mode 100644 gcc/testsuite/gcc.dg/ubsan/flex-array-counted-by-bounds-3.c
create mode 100644 gcc/testsuite/gcc.dg/ubsan/flex-array-counted-by-bounds.c
diff --git a/gcc/c-family/c-ubsan.cc b/gcc/c-family/c-ubsan.cc
index 940982819ddf..164b29845b3a 100644
--- a/gcc/c-family/c-ubsan.cc
+++ b/gcc/c-family/c-ubsan.cc
@@ -376,6 +376,40 @@ ubsan_instrument_return (location_t loc)
return build_call_expr_loc (loc, t, 1, build_fold_addr_expr_loc (loc, data));
}
+/* Get the tree that represented the number of counted_by, i.e, the maximum
+ number of the elements of the object that the call to .ACCESS_WITH_SIZE
+ points to, this number will be the bound of the corresponding array. */
+static tree
+get_bound_from_access_with_size (tree call)
+{
+ if (!is_access_with_size_p (call))
+return NULL_TREE;
+
+ tree ref_to_size = CALL_EXPR_ARG (call, 1);
+ unsigned int type_of_size = TREE_INT_CST_LOW (CALL_EXPR_ARG (call, 2));
+ tree type = TREE_TYPE (CALL_EXPR_ARG (call, 3));
+ tree size = fold_build2 (MEM_REF, type, unshare_expr (ref_to_size),
+ build_int_cst (ptr_type_node, 0));
+ /* If size is negative value, treat it as zero. */
+ if (!TYPE_UNSIGNED (type))
+ {
+tree cond = fold_build2 (LT_EXPR, boolean_type_node,
+unshare_expr (size), build_zero_cst (type));
+size = fold_build3 (COND_EXPR, type, cond,
+ build_zero_cst (type), size);
+ }
+
+ /* Only when type_of_size is 1,i.e, the number of the elements of
+ the object type, return the size. */
+ if (type_of_size != 1)
+return NULL_TREE;
+ else
+size = fold_convert (sizetype, size);
+
+ return size;
+}
+
+
/* Instrument array bounds for ARRAY_REFs. We create special builtin,
that gets expanded in the sanopt pass, and make an array dimension
of it. ARRAY is the array, *INDEX is an index to the array.
@@ -401,6 +435,14 @@ ubsan_instrument_bounds (location_t loc, tree array, tree
*index,
&& COMPLETE_TYPE_P (type)
&& integer_zerop (TYPE_SIZE (type)))
bound = build_int_cst (TREE_TYPE (TYPE_MIN_VALUE (domain)), -1);
+ else if (INDIRECT_REF_P (array)
+ && is_access_with_size_p ((TREE_OPERAND (array, 0
+ {
+ bound = get_bound_from_access_with_size ((TREE_OPERAND (array, 0)));
+ bound = fold_build2 (MINUS_EXPR, TREE_TYPE (bound),
+ bound,
+ build_int_cst (TREE_TYPE (bound), 1));
+ }
else
return NULL_TREE;
}
diff --git a/gcc/testsuite/gcc.dg/ubsan/flex-array-counted-by-bounds-2.c
b/gcc/testsuite/gcc.dg/ubsan/flex-array-counted-by-bounds-2.c
new file mode 100644
index ..148934975ee5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ubsan/flex-array-counted-by-bounds-2.c
@@ -0,0 +1,45 @@
+/* test the attribute counted_by and its usage in
+ bounds sanitizer combined with VLA. */
+/* { dg-do run } */
+/* { dg-options "-fsanitize=bounds" } */
+/* { dg-output "index 11 out of bounds for type 'int
\\\[\\\*\\\]\\\[\\\*\\\]'\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*index 20 out of bounds for type 'int
\\\[\\\*\\\]\\\[\\\*\\\]\\\[\\\*\\\]'\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*index 11 out of bounds for type 'int
\\\[\\\*\\\]\\\[\\\*\\\]'\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*index 10 out of bounds for type 'int
\\\[\\\*\\\]'\[^\n\r]*(\n|\r\n|\r)" } */
+
+
+#include
+
+void __attribute__((__noinline__)) setup_and_test_vla (int n, int m)
+{
+ struct foo {
+ int n;
+ int p[][n] __attribute__((counted_by(n)));
+ } *f;
+
+ f = (struct foo *) malloc (sizeof(struct foo) + m*sizeof(int[n]));
+ f->n = m;
+ f->p[m][n-1]=1;
+ return;
+}
+
+void __attribute__((__noinline__)) setup_and_test_vla_1 (int n1, int n2, int m)
+{
+ struct foo {
+int n;
+int p[][n2][n1] __attribute__((counted_by(n)));
+ } *f;
+
+ f = (struct foo *) malloc (sizeof(struct foo) + m*sizeof(int[n2][n1]));
+ f->n = m;
+ f->p[m][n2][n1]=1;
+ return;
+}
+
+int main(int argc, char *argv[])
+{
+ setup_and_test_vla (10, 11);
+ setup_and_test_vla_1 (10, 11, 20);
+ return 0;
[PATCH v6 3/5] Use the .ACCESS_WITH_SIZE in builtin object size.
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
* gcc.dg/flex-array-counted-by-3.c: New test.
* gcc.dg/flex-array-counted-by-4.c: New test.
* gcc.dg/flex-array-counted-by-5.c: New test.
---
.../gcc.dg/builtin-object-size-common.h | 11 ++
.../gcc.dg/flex-array-counted-by-3.c | 63 +++
.../gcc.dg/flex-array-counted-by-4.c | 178 ++
.../gcc.dg/flex-array-counted-by-5.c | 48 +
gcc/tree-object-size.cc | 59 ++
5 files changed, 359 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/flex-array-counted-by-3.c
create mode 100644 gcc/testsuite/gcc.dg/flex-array-counted-by-4.c
create mode 100644 gcc/testsuite/gcc.dg/flex-array-counted-by-5.c
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-common.h
b/gcc/testsuite/gcc.dg/builtin-object-size-common.h
index 66ff7cdd953a..b677067c6e6b 100644
--- a/gcc/testsuite/gcc.dg/builtin-object-size-common.h
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-common.h
@@ -30,3 +30,14 @@ unsigned nfails = 0;
__builtin_abort ();\
return 0;\
} while (0)
+
+#define EXPECT(p, _v) do { \
+ size_t v = _v; \
+ if (p == v)\
+__builtin_printf ("ok: %s == %zd\n", #p, p);\
+ else \
+{\
+ __builtin_printf ("WAT: %s == %zd (expected %zd)\n", #p, p, v);\
+ FAIL (); \
+}\
+} while (0);
diff --git a/gcc/testsuite/gcc.dg/flex-array-counted-by-3.c
b/gcc/testsuite/gcc.dg/flex-array-counted-by-3.c
new file mode 100644
index ..0066c32ca808
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/flex-array-counted-by-3.c
@@ -0,0 +1,63 @@
+/* test the attribute counted_by and its usage in
+ * __builtin_dynamic_object_size. */
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+#include "builtin-object-size-common.h"
+
+struct flex {
+ int b;
+ int c[];
+} *array_flex;
+
+struct annotated {
+ int b;
+ int c[] __attribute__ ((counted_by (b)));
+} *array_annotated;
+
+struct nested_annotated {
+ struct {
+union {
+ int b;
+ float f;
+};
+int n;
+ };
+ int c[] __attribute__ ((counted_by (b)));
+} *array_nested_annotated;
+
+void __attribute__((__noinline__)) setup (int normal_count, int attr_count)
+{
+ array_flex
+= (struct flex *)malloc (sizeof (struct flex)
++ normal_count * sizeof (int));
+ array_flex->b = normal_count;
+
+ array_annotated
+= (struct annotated *)malloc (sizeof (struct annotated)
+ + attr_count * sizeof (int));
+ array_annotated->b = attr_count;
+
+ array_nested_annotated
+= (struct nested_annotated *)malloc (sizeof (struct nested_annotated)
++ attr_count * sizeof (int));
+ array_nested_annotated->b = attr_count;
+
+ return;
+}
+
+void __attribute__((__noinline__)) test ()
+{
+EXPECT(__builtin_dynamic_object_size(array_flex->c, 1), -1);
+EXPECT(__builtin_dynamic_object_size(array_annotated->c, 1),
+ array_annotated->b * sizeof (int));
+EXPECT(__builtin_dynamic_object_size(array_nested_annotated->c, 1),
+ array_nested_annotated->b * sizeof (int));
+}
+
+int main(int argc, char *argv[])
+{
+ setup (10,10);
+ test ();
+ DONE ();
+}
diff --git a/gcc/testsuite/gcc.dg/flex-array-counted-by-4.c
b/gcc/testsuite/gcc.dg/flex-array-counted-by-4.c
new file mode 100644
index ..3ce7f3545549
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/flex-array-counted-by-4.c
@@ -0,0 +1,178 @@
+/* test the attribute counted_by and its usage in
+__builtin_dynamic_object_size: what's the correct behavior when the
+allocation size mismatched with the value of counted_by attribute?
+we should always use the latest value that is hold by the counted_by
+field. */
+/* { dg-do run } */
+/* { dg-options "-O -fstrict-flex-arrays=3" } */
+
+#include "builtin-object-size-common.h"
+
+struct annotated {
+ size_t foo;
+ char others;
+ char array[] __attribute__((counted_by (foo)));
+};
+
+#define noinline __attribute__((__noinline__))
+#define SIZE_BUMP 10
+#define MAX(a, b) ((a) > (b) ? (a) : (b))
+
+/* In general, Due to type casting, the type for the pointee of a pointer
+ does not say
[PATCH v6 2/5] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
(build_component_ref in c_typeck.cc)
This includes the case when the object is statically allocated and
initialized.
In order to make this working, the routines initializer_constant_valid_p_1
and output_constant in varasm.cc are updated to handle calls to
.ACCESS_WITH_SIZE.
(initializer_constant_valid_p_1 and output_constant in varasm.c)
However, for the reference inside "offsetof", the "counted_by" attribute is
ignored since it's not useful at all.
(c_parser_postfix_expression in c/c-parser.cc)
In addtion to "offsetof", for the reference inside operator "typeof" and
"alignof", we ignore counted_by attribute too.
When building ADDR_EXPR for the .ACCESS_WITH_SIZE in C FE,
replace the call with its first argument.
* Convert every call to .ACCESS_WITH_SIZE to its first argument.
(expand_ACCESS_WITH_SIZE in internal-fn.cc)
* Adjust alias analysis to exclude the new internal from clobbering anything.
(ref_maybe_used_by_call_p_1 and call_may_clobber_ref_p_1 in tree-ssa-alias.cc)
* Adjust dead code elimination to eliminate the call to .ACCESS_WITH_SIZE when
it's LHS is eliminated as dead code.
(eliminate_unnecessary_stmts in tree-ssa-dce.cc)
* Provide the utility routines to check the call is .ACCESS_WITH_SIZE and
get the reference from the call to .ACCESS_WITH_SIZE.
(is_access_with_size_p and get_ref_from_access_with_size in tree.cc)
gcc/c/ChangeLog:
* c-parser.cc (c_parser_postfix_expression): Ignore the counted-by
attribute when build_component_ref inside offsetof operator.
* c-tree.h (build_component_ref): Add one more parameter.
* c-typeck.cc (build_counted_by_ref): New function.
(build_access_with_size_for_counted_by): New function.
(build_component_ref): Check the counted-by attribute and build
call to .ACCESS_WITH_SIZE.
(build_unary_op): When building ADDR_EXPR for
.ACCESS_WITH_SIZE, use its first argument.
(lvalue_p): Accept call to .ACCESS_WITH_SIZE.
gcc/ChangeLog:
* internal-fn.cc (expand_ACCESS_WITH_SIZE): New function.
* internal-fn.def (ACCESS_WITH_SIZE): New internal function.
* tree-ssa-alias.cc (ref_maybe_used_by_call_p_1): Special case
IFN_ACCESS_WITH_SIZE.
(call_may_clobber_ref_p_1): Special case IFN_ACCESS_WITH_SIZE.
* tree-ssa-dce.cc (eliminate_unnecessary_stmts): Eliminate the call
to .ACCESS_WITH_SIZE when its LHS is dead.
* tree.cc (process_call_operands): Adjust side effect for function
.ACCESS_WITH_SIZE.
(is_access_with_size_p): New function.
(get_ref_from_access_with_size): New function.
* tree.h (is_access_with_size_p): New prototype.
(get_ref_from_access_with_size): New prototype.
* varasm.cc (initializer_constant_valid_p_1): Handle call to
.ACCESS_WITH_SIZE.
(output_constant): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/flex-array-counted-by-2.c: New test.
---
gcc/c/c-parser.cc | 10 +-
gcc/c/c-tree.h| 2 +-
gcc/c/c-typeck.cc | 128 +-
gcc/internal-fn.cc| 36 +
gcc/internal-fn.def | 4 +
.../gcc.dg/flex-array-counted-by-2.c | 112 +++
gcc/tree-ssa-alias.cc | 2 +
gcc/tree-ssa-dce.cc | 5 +-
gcc/tree.cc | 25 +++-
gcc/tree.h| 8 ++
gcc/varasm.cc | 10 ++
11 files changed, 332 insertions(+), 10 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/flex-array-counted-by-2.c
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index c31349dae2ff..a6ed5ac43bb1 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -10850,9 +10850,12 @@ c_parser_postfix_expression (c_parser *parser)
if (c_parser_next_token_is (parser, CPP_NAME))
{
c_token *comp_tok = c_parser_peek_token (parser);
+ /* Ignore the counted_by attribute for reference inside
+ offsetof since the information is not useful at all. */
offsetof_ref
= build_component_ref (loc, offsetof_ref, comp_tok->value,
-comp_tok->location, UNKNOWN_LOCATION);
+comp_tok->location, UNKNOWN_LOCATION,
+false);
c_parser_consume_token (parser);
while (c_parser_next_token_is (parser, CPP_DOT)
||
[PATCH v6 0/5]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)
Hi, This is the 6th version of the patch. compare with the 5th version, the only difference is: 1. Add the 6th argument to .ACCESS_WITH_SIZE to carry the TYPE of the flexible array. Such information is needed during tree-object-size.cc. previously, we use the result type of the routine .ACCESS_WITH_SIZE to decide the element type of the original array, however, the result type of the routine might be changed during tree optimizations due to possible type casting in the source code. compare with the 4th version, the major difference are: 1. Change the return type of the routine .ACCESS_WITH_SIZE FROM: Pointer to the type of the element of the flexible array; TO: Pointer to the type of the flexible array; And then wrap the call with an indirection reference. 2. Adjust all other parts with this change, (this will simplify the bound sanitizer instrument); 3. Add the fixes to the kernel building failures, which include: A. The operator ???typeof??? cannot return correct type for a->array; B. The operator ???&??? cannot return correct address for a->array; 4. Correctly handle the case when the value of ???counted-by??? is zero or negative as following 4.1. Update the counted-by doc with the following: When the counted-by field is assigned a negative integer value, the compiler will treat the value as zero. 4.2. Adjust __bdos and array bound sanitizer to handle correctly when ???counted-by??? is zero. It based on the following proposal: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635884.html Represent the missing dependence for the "counted_by" attribute and its consumers **The summary of the proposal is: * Add a new internal function ".ACCESS_WITH_SIZE" to carry the size information for every reference to a FAM field; * In C FE, Replace every reference to a FAM field whose TYPE has the "counted_by" attribute with the new internal function ".ACCESS_WITH_SIZE"; * In every consumer of the size information, for example, BDOS or array bound sanitizer, query the size information or ACCESS_MODE information from the new internal function; * When expansing to RTL, replace the internal function with the actual reference to the FAM field; * Some adjustment to ipa alias analysis, and other SSA passes to mitigate the impact to the optimizer and code generation. **The new internal function .ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, CLASS_OF_SIZE, TYPE_OF_SIZE, ACCESS_MODE, TYPE_OF_REF) INTERNAL_FN (ACCESS_WITH_SIZE, ECF_LEAF | ECF_NOTHROW, NULL) which returns the "REF_TO_OBJ" same as the 1st argument; Both the return type and the type of the first argument of this function have been converted from the incomplete array type to the corresponding pointer type. The call to .ACCESS_WITH_SIZE is wrapped with an INDIRECT_REF, whose type is the original imcomplete array type. Please see the following link for why: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638793.html https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639605.html 1st argument "REF_TO_OBJ": The reference to the object; 2nd argument "REF_TO_SIZE": The reference to the size of the object, 3rd argument "CLASS_OF_SIZE": The size referenced by the REF_TO_SIZE represents 0: unknown; 1: the number of the elements of the object type; 2: the number of bytes; 4th argument "TYPE_OF_SIZE": A constant 0 with the TYPE of the object refed by REF_TO_SIZE 5th argument "ACCESS_MODE": -1: Unknown access semantics 0: none 1: read_only 2: write_only 3: read_write 6th argument "TYPE_OF_REF": A constant 0 with the pointer TYPE to the original flexible array type. ** The Patch sets included: 1. Provide counted_by attribute to flexible array member field; which includes: * "counted_by" attribute documentation; * C FE handling of the new attribute; syntax checking, error reporting; * testing cases; 2. Convert "counted_by" attribute to/from .ACCESS_WITH_SIZE. which includes: * The definition of the new internal function .ACCESS_WITH_SIZE in internal-fn.def. * C FE converts every reference to a FAM with "counted_by" attribute to a call to the internal function .ACCESS_WITH_SIZE. (build_component_ref in c_typeck.cc) This includes the case when the object is statically allocated and initialized. In order to make this working, we should update initializer_constant_valid_p_1 and output_constant in varasm.cc to include calls to .ACCESS_WITH_SIZE. However, for the reference inside "offsetof", ignore the "counted_by" attribute since it's not useful at all. (c_parser_postfix_expression in c/c-parser.cc) In addtion to "offsetof", for the reference inside operator "typeof" and "alignof", we ignore counted_by attribute too. When building ADDR_EXPR for the .ACCESS_WITH_SIZE in C FE, replace the call with its first
[Bug analyzer/108562] [meta-bug] tracker bug for issues with -Wanalyzer-null-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108562 Bug 108562 depends on bug 105755, which changed state. Bug 105755 Summary: -Wanalyzer-null-dereference regression compiling Emacs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |---
[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2024-02-16 Ever confirmed|0 |1 CC||iains at gcc dot gnu.org Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #7 from Iain Sandoe --- see comment #5 and #6
[Bug other/113961] [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961 --- Comment #5 from seurer at gcc dot gnu.org --- Indeed you did, thanks!
[Bug analyzer/109851] [13/14 Regression] False positive va_arg when iterating through format string with for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109851 David Malcolm changed: What|Removed |Added Summary|False positive va_arg when |[13/14 Regression] False |iterating through format|positive va_arg when |string with for-loop|iterating through format ||string with for-loop Last reconfirmed||2024-02-16 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks for filing this bug report. The analyzer isn't looking at the content of the string literal and assumes that any character is possible. In particular, it isn't attempting to correlate between the ordering of matches in the string and the ordering of the variadic arguments. Still affects trunk and gcc 13: Trunk: https://godbolt.org/z/bMP7sq3ea GCC 13.2: https://godbolt.org/z/e7eE8Eo4d
[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 --- Comment #6 from nightstrike --- (In reply to nightstrike from comment #5) > If I open your godbolt links, they aren't using a Windows target compiler, > so they aren't exercising an LLP64 target. For instance: https://godbolt.org/z/4Mx96Wjvd : In function 'XLI': :15:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 15 | return (EMACS_INT) o; | ^ ASM generation compiler returned: 0 ERROR: The inherited access control list (ACL) or access control entry (ACE) could not be built. : In function 'XLI': :15:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 15 | return (EMACS_INT) o; | ^ Execution build compiler returned: 0 Program returned: 254
[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755
--- Comment #5 from nightstrike ---
(In reply to David Malcolm from comment #4)
> Looks like this was fixed sometime in GCC 13; resolving as WORKSFORME.
>
> Feel free to reopen if you have a reproducer that triggers on a more recent
> GCC.
The testcase still fails. To be clear, I'm referring to null-deref-pr105755.c:
Executing on host: /tmp/gcc/src/gcc-git/_w/gcc/xgcc
-B/tmp/gcc/src/gcc-git/_w/gcc/ exceptions_enabled705865.cc
-fdiagnostics-plain-output -Wno-complain-wrong-lang -S -o
exceptions_enabled705865.s(timeout = 300)
spawn -ignore SIGHUP /tmp/gcc/src/gcc-git/_w/gcc/xgcc
-B/tmp/gcc/src/gcc-git/_w/gcc/ exceptions_enabled705865.cc
-fdiagnostics-plain-output -Wno-complain-wrong-lang -S -o
exceptions_enabled705865.s^M
FAIL: gcc.dg/analyzer/null-deref-pr105755.c (test for excess errors)
Excess errors:
/tmp/gcc/src/gcc-git/gcc/testsuite/gcc.dg/analyzer/null-deref-pr105755.c:19:10:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
testcase /tmp/gcc/src/gcc-git/gcc/testsuite/gcc.dg/analyzer/analyzer.exp
completed in 0 seconds
With this change:
--- a/gcc/testsuite/gcc.dg/analyzer/null-deref-pr105755.c
+++ b/gcc/testsuite/gcc.dg/analyzer/null-deref-pr105755.c
@@ -2,7 +2,7 @@
/* { dg-additional-options "-Wno-analyzer-too-complex
-Wno-analyzer-symbol-too-complex -O2" } */
typedef long int ptrdiff_t;
-typedef long int EMACS_INT;
+typedef __UINTPTR_TYPE__ EMACS_INT;
typedef long int intmax_t;
enum Lisp_Type
Then I get this:
PASS: gcc.dg/analyzer/null-deref-pr105755.c (test for excess errors)
If I open your godbolt links, they aren't using a Windows target compiler, so
they aren't exercising an LLP64 target.
Generally speaking, most of the analyzer testsuite assumes incorrect
definitions of things. For instance, in the diff I just posted, you can see
that the lines before and after also assume the underlying types of ptrdiff_t
and intmax_t instead of using compiler builtins or just including the relevant
headers. This is really needs to be fixed across the whole testsuite.
[Bug analyzer/109579] -Wanalyzer-out-of-bounds false positive in Emacs mapping stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109579 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from David Malcolm --- Thanks for filing this bug report. Trunk: unaffected: https://godbolt.org/z/EaeP1e1d5 GCC 13.2: affected: https://godbolt.org/z/WvcKh9s9Y Presumably fixed by one of my patches to trunk; marking as RESOLVED WORKSFORME. Feel free to reopen if you can reproduce it with GCC 14 or later.
[Bug analyzer/109628] -Wanalyzer-use-of-uninitialized-value false positive on static storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109628 David Malcolm changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #1 from David Malcolm --- Thanks for filing this bug. Seems to be fixed on trunk (for GCC 14): https://godbolt.org/z/ecYGxa3nh Affects GCC 13.2: https://godbolt.org/z/sxs3G1KEc Affects GCC 12.3: https://godbolt.org/z/v4nz19Mj1 I'm going to assume that one of my other fixes on trunk covered this; marking as RESOLVED WORKSFORME. Feel free to reopen if you still see it with GCC 14 onwards.
[Bug other/113961] [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- I think I got it right this time!
[committed] libstdc++: Fix FAIL: 26_numerics/random/pr60037-neg.cc again [PR113961]
I had another change to in my local tree which affected the second dg-error and I "fixed" it unnecessarily. I've tested with a clean tree this time. Tested aarch64-linux. Pushed to trunk. -- >8 -- PR libstdc++/87744 PR libstdc++/113961 libstdc++-v3/ChangeLog: * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line number. --- libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc b/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc index 9d6925fb416..3c5aa7feefc 100644 --- a/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc +++ b/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc @@ -12,4 +12,4 @@ auto x = std::generate_canonical
[Bug other/113961] [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961 --- Comment #3 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c74131e77f1a6b7afe700d3526a8992dc9744b0c commit r14-9038-gc74131e77f1a6b7afe700d3526a8992dc9744b0c Author: Jonathan Wakely Date: Wed Feb 7 11:31:10 2024 + libstdc++: Fix FAIL: 26_numerics/random/pr60037-neg.cc again [PR113961] PR libstdc++/87744 PR libstdc++/113961 libstdc++-v3/ChangeLog: * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line number.
[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744 --- Comment #17 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c74131e77f1a6b7afe700d3526a8992dc9744b0c commit r14-9038-gc74131e77f1a6b7afe700d3526a8992dc9744b0c Author: Jonathan Wakely Date: Wed Feb 7 11:31:10 2024 + libstdc++: Fix FAIL: 26_numerics/random/pr60037-neg.cc again [PR113961] PR libstdc++/87744 PR libstdc++/113961 libstdc++-v3/ChangeLog: * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line number.
Re: [COMMITTED] c++: Add testcase for this PR [PR97990]
On Fri, Feb 16, 2024 at 11:00:34AM -0800, Andrew Pinski wrote:
> This testcase was fixed by r14-5934-gf26d68d5d128c8 but we should add
> one to make sure it does not regress again.
>
> Committed as obvious after a quick test on the testcase.
>
> PR c++/97990
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/torture/vector-struct-1.C: New test.
>
> Signed-off-by: Andrew Pinski
> ---
> gcc/testsuite/g++.dg/torture/vector-struct-1.C | 18 ++
> 1 file changed, 18 insertions(+)
> create mode 100644 gcc/testsuite/g++.dg/torture/vector-struct-1.C
>
> diff --git a/gcc/testsuite/g++.dg/torture/vector-struct-1.C
> b/gcc/testsuite/g++.dg/torture/vector-struct-1.C
> new file mode 100644
> index 000..e2747417e2d
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/torture/vector-struct-1.C
> @@ -0,0 +1,18 @@
> +/* PR c++/97990 */
> +/* This used to crash with lto and strict aliasing enabled as the
> + vector type variant still had TYPE_ALIAS_SET set on it. */
You don't have -Wstrict-aliasing here without which the test didn't ICE.
> +typedef __attribute__((__vector_size__(sizeof(short short TSimd;
> +TSimd hh(int);
> +struct y6
> +{
> + TSimd VALUE;
> + ~y6();
> +};
> +template
> +auto f2(T1 p1, T2){
> + return hh(p1) <= 0;
> +}
> +void f1(){
> + f2(0, y6{});
> +}
> --
> 2.43.0
>
Marek
[Bug c++/97990] [11/12/13 Regression] ICE: ‘verify_type’ failed with vector types and non-PODs since r6-5222-gba6a6a1d44c17f25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97990 --- Comment #13 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:5f1438db419c9eb8901d1d1d7f98fb69082aec8e commit r14-9037-g5f1438db419c9eb8901d1d1d7f98fb69082aec8e Author: Andrew Pinski Date: Fri Feb 16 10:55:43 2024 -0800 c++: Add testcase for this PR [PR97990] This testcase was fixed by r14-5934-gf26d68d5d128c8 but we should add one to make sure it does not regress again. Committed as obvious after a quick test on the testcase. PR c++/97990 gcc/testsuite/ChangeLog: * g++.dg/torture/vector-struct-1.C: New test. Signed-off-by: Andrew Pinski
[Bug target/112103] [14 regression] gcc.target/powerpc/rlwinm-0.c fails after r14-4941-gd1bb9569d70304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- So, let's just adjust the testcase then?
[COMMITTED] c++: Add testcase for this PR [PR97990]
This testcase was fixed by r14-5934-gf26d68d5d128c8 but we should add
one to make sure it does not regress again.
Committed as obvious after a quick test on the testcase.
PR c++/97990
gcc/testsuite/ChangeLog:
* g++.dg/torture/vector-struct-1.C: New test.
Signed-off-by: Andrew Pinski
---
gcc/testsuite/g++.dg/torture/vector-struct-1.C | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/torture/vector-struct-1.C
diff --git a/gcc/testsuite/g++.dg/torture/vector-struct-1.C
b/gcc/testsuite/g++.dg/torture/vector-struct-1.C
new file mode 100644
index 000..e2747417e2d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/vector-struct-1.C
@@ -0,0 +1,18 @@
+/* PR c++/97990 */
+/* This used to crash with lto and strict aliasing enabled as the
+ vector type variant still had TYPE_ALIAS_SET set on it. */
+
+typedef __attribute__((__vector_size__(sizeof(short short TSimd;
+TSimd hh(int);
+struct y6
+{
+ TSimd VALUE;
+ ~y6();
+};
+template
+auto f2(T1 p1, T2){
+ return hh(p1) <= 0;
+}
+void f1(){
+ f2(0, y6{});
+}
--
2.43.0
[Bug c++/109859] [12/13/14 Regression] ICE on concept mis-typed as template type parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109859
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #4 from Marek Polacek ---
We're hitting the assert here:
/* In a template parameter list, a type-parameter can be introduced
by type-constraints alone. */
if (processing_template_parmlist && !placeholder)
{
/* In a default argument we may not be creating new parameters. */
if (parser->local_variables_forbidden_p & LOCAL_VARS_FORBIDDEN)
{
/* If this assert turns out to be false, do error() instead. */
gcc_assert (tentative);
return error_mark_node;
}
so presumably we should change it to error() as the comment says.
[Bug c++/97990] [11/12/13 Regression] ICE: ‘verify_type’ failed with vector types and non-PODs since r6-5222-gba6a6a1d44c17f25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97990 Andrew Pinski changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE: |ICE: ‘verify_type’ failed |‘verify_type’ failed with |with vector types and |vector types and non-PODs |non-PODs since |since |r6-5222-gba6a6a1d44c17f25 |r6-5222-gba6a6a1d44c17f25 Known to work||14.0 --- Comment #12 from Andrew Pinski --- (In reply to Marek Polacek from comment #11) > Looks like r14-5934-gf26d68d5d128c8: > > commit f26d68d5d128c86faaceeb81b1e8f22254ad53df > Author: Richard Biener > Date: Tue Nov 28 12:36:21 2023 +0100 > > middle-end/112732 - stray TYPE_ALIAS_SET in type variant > > fixed this. Yes that looks like the correct fix even and PR 112732 does look like the same issue here except a different path to create the type variant.
Re: [PATCH] testsuite: Fix up lra effective target
On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote: > > There is one special case, NVPTX, which is a TARGET_NO_REGISTER_ALLOCATION > target. I think claiming for it that it is a lra target is strange (even > though it effectively returns true for targetm.lra_p ()), unsure if it > supports asm goto with outputs or not, if it does and we want to test it, > perhaps we should introduce asm_goto_outputs effective target and use > lra || nvptx-*-* for that? Since the port people have to maintain that code in general, I usually leave it to them to try and select a cheap, maintainable way to manage it. If people want to pave the way, I'd tend to defer to them, having thought about more than I.
[Bug c++/97990] [11/12/13/14 Regression] ICE: ‘verify_type’ failed with vector types and non-PODs since r6-5222-gba6a6a1d44c17f25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97990 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #11 from Marek Polacek --- Looks like r14-5934-gf26d68d5d128c8: commit f26d68d5d128c86faaceeb81b1e8f22254ad53df Author: Richard Biener Date: Tue Nov 28 12:36:21 2023 +0100 middle-end/112732 - stray TYPE_ALIAS_SET in type variant fixed this.
Re: [PATCH] testsuite: Fix up lra effective target
On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote:
>
> Given the recent discussions on IRC started with Andrew P. mentioning that
> an asm goto outputs test should have { target lra } and the lra effective
> target in GCC 11/12 only returning 0 for PA and in 13/14 for PA/AVR, while
> we clearly have 14 other targets which don't support LRA and a couple of
> further ones which have an -mlra/-mno-lra switch (whatever default they
> have), seems to me the effective target is quite broken.
>
> Ok for trunk?
Ok.
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923
--- Comment #8 from Antoni ---
(In reply to David Malcolm from comment #2)
> inlined_call_event's ctor should probably assert that params
> tree apparent_callee_fndecl,
> tree apparent_caller_fndecl,
> are both non-NULL, which might catch the issue slightly early.
I added an assert and here's the stacktrace:
during IPA pass: analyzer
libgccjit.so: internal compiler error: : in inlined_call_event, at
analyzer/checker-event.h:578
0x73d4eafbf076 ana::inlined_call_event::inlined_call_event(unsigned int,
tree_node*, tree_node*, int, int)
../../../gcc/gcc/analyzer/checker-event.h:578
0x73d4eafbe7dd ana::checker_path::inject_any_inlined_call_events(ana::logger*)
../../../gcc/gcc/analyzer/checker-path.cc:319
0x73d4eafd415f
ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph const&,
ana::saved_diagnostic&)
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1599
0x73d4eafd981d ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1472
0x73d4eafd3dcb
ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph const&)
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1524
0x73d4e9a0327a ana::impl_run_checkers(ana::logger*)
../../../gcc/gcc/analyzer/engine.cc:6226
0x73d4e9a03613 ana::run_checkers()
../../../gcc/gcc/analyzer/engine.cc:6300
0x73d4e99f484c execute
../../../gcc/gcc/analyzer/analyzer-pass.cc:87
I can also confirm that this is related to always_inline as there are no
segfaults when removing the #[inline(always)] in the following example (see
comment):
#![no_std]
#![allow(internal_features)]
#![feature(core_intrinsics, lang_items, start)]
#![feature(transparent_unions)]
use core::mem::ManuallyDrop;
#[panic_handler]
fn panic_handler(_: ::panic::PanicInfo<'_>) -> ! {
core::intrinsics::abort();
}
#[lang="eh_personality"]
fn eh_personality(){}
#[derive(Clone, Copy)]
#[repr(transparent)]
pub union MaybeUninit {
uninit: (),
value: ManuallyDrop,
}
impl MaybeUninit {
// NOTE: there are no segfaults when removing the next line.
#[inline(always)]
pub const fn uninit() -> MaybeUninit {
MaybeUninit { uninit: () }
}
}
#[start]
fn main(_argc: isize, _argv: *const *const u8) -> isize {
let mut x = MaybeUninit::<>::uninit();
0
}
[Bug c++/111974] internal error: Segmentation fault on Ubuntu 23.10 (x86-64) - compiling RefPerSys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111974 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Marek Polacek --- No testcase; please reopen when/if you find one.
[Bug c++/89336] internal compiler error when compiling a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89336 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Marek Polacek --- Assuming fixed.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 89336, which changed state. Bug 89336 Summary: internal compiler error when compiling a constexpr function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89336 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 87536, which changed state. Bug 87536 Summary: Illegal recursive concept leads to compiler ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87536 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/87536] Illegal recursive concept leads to compiler ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87536 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- I no longer get any crashes here: $ xg++ -c -std=c++20 87536.C 87536.C:2:6: error: C++20 concept definition syntax is ‘concept = ’ 2 | bool concept X = X; | ^~~ $ xg++ -c -std=c++17 87536.C -fconcepts-ts cc1plus: note: ‘-fconcepts-ts’ is deprecated and will be removed in GCC 15; please convert your code to C++20 concepts
[Bug c++/87331] if delete "node->operator_type = kADD; " will report "internal compiler error: Segmentation fault"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87331 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug c++/85908] Internal error with concepts and polymorphic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85908 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Compiles fine with -std=c++17 -fconcepts-ts. There's error: the ‘bool’ keyword is not allowed in a C++20 concept definition [-fpermissive] so I'm not adding the test.
Re: [Committed] testsuite: Add support for scanning assembly with comparitor
Thanks! Committed
Edwin
On 2/15/2024 9:27 AM, Mike Stump wrote:
On Feb 12, 2024, at 11:38 AM, Edwin Lu wrote:
There is currently no support for matching at least x lines of assembly
(only scan-assembler-times). This patch would allow setting upper or lower
bounds.
Use case: using different scheduler descriptions and/or cost models will change
assembler output. Testing common functionality across tunes would require a
separate testcase per tune since each assembly output would be different. If we
know a base number of lines should appear across all tunes (i.e. testing return
values: we expect at minimum n stores into register x), we can lower-bound the
test to search for scan-assembler-bound {RE for storing into register x} >= n.
This avoids artificially inflating the scan-assembler-times expected count due
to the assembler choosing to perform extra stores into register x (using it as
a temporary register).
The testcase would be more robust to cpu/tune changes at the cost of not being
as granular towards specific cpu tuning.
I didn't see an Ok? Just in case you forgot, yes, this is ok.
