[Bug fortran/107397] [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397 --- Comment #8 from CVS Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:09710f9934969dcb07131e1ed78b72e648123a3a commit r13-4764-g09710f9934969dcb07131e1ed78b72e648123a3a Author: Steve Kargl Date: Sat Dec 17 19:15:43 2022 -0800 Add a check for invalid use of BOZ with a derived type. PR fortran/107397 gcc/fortran/ChangeLog: * decl.cc (add_init_expr_to_sym): Add check with new error message. gcc/testsuite/ChangeLog: * gfortran.dg/pr107397.f90: New test.
[Bug target/108163] mesa LTO compiling ICEs with unable to generate reloads for neon_vld4qav16qi on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108163 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2022-12-18 --- Comment #1 from Andrew Pinski --- Definitely needs a testcase really.
[Bug middle-end/108162] Missed optimization opportunity. Complex function that starts with if (param == 0) return 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108162
--- Comment #4 from Andrew Pinski ---
(In reply to Levo DeLellis from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > Round 4 is because of this heuriheuristics. Name the function something
> > besides main and try again.
>
> I couldn't reproduce. fn has more than xor eax/ret. godbolt shows the same.
> x86-64 12.2 https://gcc.godbolt.org/z/WdacrE788
>
> #include
> int fn() { std::vector v; v.push_back(1000); return 0; }
> int main(int argc, char *argv[]) { fn(); }
Right that is not inlining either. Anyways there are another bugs about not
removing operator new/operator delete in some cases.
[Bug c++/108163] New: LTO crosscompilation for arm fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108163
Bug ID: 108163
Summary: LTO crosscompilation for arm fails
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at ixit dot cz
Target Milestone: ---
Whole log: https://gitlab.freedesktop.org/okias/mesa/-/jobs/33700498
I'll test with more recent compiler soon, but this one is Debian default,
reporting just for sure.
FAILED: src/util/tests/format/u_format_test
/usr/lib/ccache/arm-linux-gnueabihf-g++ -o src/util/tests/format/u_format_test
src/util/tests/format/u_format_test.p/u_format_test.c.o -flto -Wl,--as-needed
-Wl,--no-undefined -Wl,--start-group src/util/libmesa_util.a
src/util/format/libmesa_format.a src/util/libmesa_util_sse41.a
src/c11/impl/libmesa_util_c11.a /usr/lib/arm-linux-gnueabihf/libz.so -pthread
-lm -ldl -Wl,--end-group
../src/util/format/u_format_unpack_neon.c: In function
'util_format_b8g8r8a8_unorm_unpack_rgba_8unorm_neon':
../src/util/format/u_format_unpack_neon.c:53:1: error: unable to generate
reloads for:
53 | }
| ^
(insn 30 78 34 4 (set (reg:XI 124 [ _19 ])
(unspec:XI [
(mem:OI (post_inc:SI (reg/f:SI 147)) [0 MEM[(const
__builtin_neon_qi[64] *)src_67]+0 S32 A8])
(unspec:V16QI [
(const_int 0 [0])
] UNSPEC_VSTRUCTDUMMY)
] UNSPEC_VLD4A))
"/usr/lib/gcc-cross/arm-linux-gnueabihf/10/include/arm_neon.h":13069:14 2673
{neon_vld4qav16qi}
(expr_list:REG_INC (reg/f:SI 147)
(nil)))
during RTL pass: reload
../src/util/format/u_format_unpack_neon.c:53:1: internal compiler error: in
curr_insn_transform, at lra-constraints.c:4017
0x5927ef _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0x892df7 curr_insn_transform
../../src/gcc/lra-constraints.c:4017
0x8939b7 lra_constraints(bool)
../../src/gcc/lra-constraints.c:5036
0x8820cf lra(_IO_FILE*)
../../src/gcc/lra.c:2443
0x840657 do_reload
../../src/gcc/ira.c:5527
0x840657 execute
../../src/gcc/ira.c:5713
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
lto-wrapper: fatal error: /usr/bin/arm-linux-gnueabihf-g++ returned 1 exit
status
compilation terminated.
mold: fatal: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug middle-end/108162] Missed optimization opportunity. Complex function that starts with if (param == 0) return 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108162
--- Comment #3 from Levo DeLellis ---
(In reply to Andrew Pinski from comment #2)
> Round 4 is because of this heuriheuristics. Name the function something
> besides main and try again.
I couldn't reproduce. fn has more than xor eax/ret. godbolt shows the same.
x86-64 12.2 https://gcc.godbolt.org/z/WdacrE788
#include
int fn() { std::vector v; v.push_back(1000); return 0; }
int main(int argc, char *argv[]) { fn(); }
1160 <_Z2fnv>:
1160: 48 83 ec 08 subrsp,0x8
1164: bf 04 00 00 00 movedi,0x4
1169: e8 c2 fe ff ff call 1030 <_Znwm@plt>
116e: be 04 00 00 00 movesi,0x4
1173: 48 89 c7movrdi,rax
1176: c7 00 e8 03 00 00 movDWORD PTR [rax],0x3e8
117c: e8 bf fe ff ff call 1040 <_ZdlPvm@plt>
1181: 31 c0 xoreax,eax
1183: 48 83 c4 08 addrsp,0x8
1187: c3 ret
[Bug middle-end/108162] Missed optimization opportunity. Complex function that starts with if (param == 0) return 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108162 --- Comment #2 from Andrew Pinski --- Round 4 is because of this heuriheuristics. Name the function something besides main and try again.
[Bug middle-end/108162] Missed optimization opportunity. Complex function that starts with if (param == 0) return 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108162 Andrew Pinski changed: What|Removed |Added Component|c++ |middle-end --- Comment #1 from Andrew Pinski --- Gcc knows main is only called once and has heuristics not to inline as much into it.
[Bug c++/108162] New: Missed optimization opportunity. Complex function that starts with if (param == 0) return 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108162 Bug ID: 108162 Summary: Missed optimization opportunity. Complex function that starts with if (param == 0) return 0; Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: levo.delellis at gmail dot com Target Milestone: --- I had a lot of fun writing https://bolinlang.com/does-it-inline I was intentionally trying to break the optimizer. I found a few cases in clang and two cases I don't think should apply but I think both can gain from the last one. Skipping a function call when the function starts with `if (param == 0) return 0;`. I tested with a recursive fibonacci. If you scroll to the very bottom you'll see it. Cases that clang optimizes but gcc did not A) Round 3 a and b. I don't think locale will affect it and clang optimizes it. All of round 4 clang optimizes. I suspect there's something getting in the way of peeking through push and size. I vaguely remember thinking std::forward may get in the way in the past but it was long enough ago that I don't remember what I was doing to think that
[Bug testsuite/108161] New: gcc.dg/ipa/pr96040.c fails with incorrect size_t assumption (snprintf, strspn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108161
Bug ID: 108161
Summary: gcc.dg/ipa/pr96040.c fails with incorrect size_t
assumption (snprintf, strspn)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
gcc.dg/ipa/pr96040.c assumes that size_t is unsigned long, which it isn't for
LLP64. The following definitions are therefor incorrect:
int snprintf(char *, unsigned long, const char *, ...);
unsigned long strspn(const char *, const char *);
Changing "unsigned long" in both instances to "__SIZE_TYPE__" makes the test
pass:
int snprintf(char *, __SIZE_TYPE__, const char *, ...);
__SIZE_TYPE__ strspn(const char *, const char *);
However, it's also possible, and perhaps more maintainable, to just use
__builtin_*, or to include and . Both of the following
options work, though there are many ways to skin this cat:
diff --git a/gcc/testsuite/gcc.dg/ipa/pr96040.c
b/gcc/testsuite/gcc.dg/ipa/pr96040.c
index af7e9c4ed94..9c9b76269a6 100644
--- a/gcc/testsuite/gcc.dg/ipa/pr96040.c
+++ b/gcc/testsuite/gcc.dg/ipa/pr96040.c
@@ -3,8 +3,8 @@
int puts(const char *);
-int snprintf(char *, unsigned long, const char *, ...);
-unsigned long strspn(const char *, const char *);
+int snprintf(char *, __SIZE_TYPE__, const char *, ...);
+__SIZE_TYPE__ strspn(const char *, const char *);
struct TValue {
union {
diff --git a/gcc/testsuite/gcc.dg/ipa/pr96040.c
b/gcc/testsuite/gcc.dg/ipa/pr96040.c
index af7e9c4ed94..2c8d405ff9b 100644
--- a/gcc/testsuite/gcc.dg/ipa/pr96040.c
+++ b/gcc/testsuite/gcc.dg/ipa/pr96040.c
@@ -3,8 +3,8 @@
int puts(const char *);
-int snprintf(char *, unsigned long, const char *, ...);
-unsigned long strspn(const char *, const char *);
+#define snprintf __builtin_snprintf
+#define strspn __builtin_strspn
struct TValue {
union {
[Bug testsuite/108160] gcc.dg/format/ms_attr-3.c testsuite failure, missed update from r9-4163-g1d24950977c730
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108160 --- Comment #1 from nightstrike --- It looks like the other testsuite changes (attr-8.c, the objc/c++ tests, etc.) should be evaluated and ported over also, so this isn't a complete fix. Alternatively, maybe this would scale better in the future if the ms_ tests were integrated into the non-ms_ tests, with a macro to set the format checking attribute between gnu_attr_printf and ms_printf.
[Bug testsuite/108160] New: gcc.dg/format/ms_attr-3.c testsuite failure, missed update from r9-4163-g1d24950977c730
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108160 Bug ID: 108160 Summary: gcc.dg/format/ms_attr-3.c testsuite failure, missed update from r9-4163-g1d24950977c730 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Created attachment 54120 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54120=edit Suggested changes r9-4163-g1d24950977c730 changed the output of certain messages and adjusted the non-ms-printf cases, but missed the windows version of attr-3.c. FAIL: gcc.dg/format/ms_attr-3.cbad number (test for errors, line 44) FAIL: gcc.dg/format/ms_attr-3.cbad number (test for errors, line 45) FAIL: gcc.dg/format/ms_attr-3.cbad format_arg number (test for errors, line 47) FAIL: gcc.dg/format/ms_attr-3.cformat int string (test for errors, line 59) FAIL: gcc.dg/format/ms_attr-3.csigned char string (test for errors, line 60) FAIL: gcc.dg/format/ms_attr-3.cunsigned char string (test for errors, line 61) FAIL: gcc.dg/format/ms_attr-3.cnot ... (test for errors, line 63) FAIL: gcc.dg/format/ms_attr-3.cformat_arg int string (test for errors, line 66) FAIL: gcc.dg/format/ms_attr-3.cformat_arg signed char string (test for errors, line 67) FAIL: gcc.dg/format/ms_attr-3.cformat_arg unsigned char string (test for errors, line 68) FAIL: gcc.dg/format/ms_attr-3.c(test for excess errors) Excess errors: gcc.dg/format/ms_attr-3.c:44:1: warning: 'format' attribute argument 2 value 'foo' is not an integer constant [-Wattributes] gcc.dg/format/ms_attr-3.c:45:1: warning: 'format' attribute argument 3 value 'foo' is not an integer constant [-Wattributes] gcc.dg/format/ms_attr-3.c:47:1: warning: 'format_arg' attribute argument value 'foo' is not an integer constant [-Wattributes] gcc.dg/format/ms_attr-3.c:59:1: error: 'format' attribute argument 2 value '1' refers to parameter type 'int' gcc.dg/format/ms_attr-3.c:60:1: error: 'format' attribute argument 2 value '1' refers to parameter type 'signed char *' gcc.dg/format/ms_attr-3.c:61:1: error: 'format' attribute argument 2 value '1' refers to parameter type 'unsigned char *' gcc.dg/format/ms_attr-3.c:63:1: error: 'format' attribute argument 3 value '2' does not refer to a variable argument list gcc.dg/format/ms_attr-3.c:66:1: error: 'format_arg' attribute argument value '1' refers to parameter type 'int' gcc.dg/format/ms_attr-3.c:67:1: error: 'format_arg' attribute argument value '1' refers to parameter type 'signed char *' gcc.dg/format/ms_attr-3.c:68:1: error: 'format_arg' attribute argument value '1' refers to parameter type 'unsigned char *' Applying the changes to attr-3.c directly to ms_attr-3.c isn't exactly right, though. First, gnu_attr_printf needs to change to ms_printf. Second, there are followup changes from r9-5404-g23db6ced33c245 to fix the remaining issues. The resulting diff is a bit big, so I uploaded suggested changes as an attachment.
[Bug modula2/108153] Profiled lto bootstrap failure with modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153 --- Comment #2 from Jakub Jelinek --- Note, non-lto profiledbootstrap with modula2 passed on i686, x86_64, aarch64, s390x and ppc64le (all with the PR108147 patch). It is just lto profiledbootstrap that doesn't work.
[Bug c++/108158] [11/12/13 Regression] modification of '...' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid Known to work||11.2.0 Summary|modification of '...' is|[11/12/13 Regression] |not a constant expression |modification of '...' is ||not a constant expression Target Milestone|--- |11.4 Known to fail||11.3.0, 12.1.0, 13.0
[Bug c++/108158] modification of '...' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 --- Comment #1 from Andrew Pinski --- Created attachment 54119 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54119=edit testcase Next text attach the testcase rather than just doing a link to godbolt .
[Bug testsuite/108159] gcc.dg/format/ms-format2.c fails due to warning message change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108159
--- Comment #1 from nightstrike ---
Andrew pointed out that this is the better fix, and it does indeed work:
diff --git a/gcc/testsuite/gcc.dg/format/ms-format2.c
b/gcc/testsuite/gcc.dg/format/ms-format2.c
index 5c950522a7c..9d21d108642 100644
--- a/gcc/testsuite/gcc.dg/format/ms-format2.c
+++ b/gcc/testsuite/gcc.dg/format/ms-format2.c
@@ -3,7 +3,7 @@
*/
/* Origin: Kai Tietz */
/* { dg-do compile { target { *-*-mingw* } } } */
-/* { dg-options "-std=iso9899:1999 -pedantic -Wformat -Wno-pedantic-ms-format"
} */
+/* { dg-options "-std=iso9899:1999 -pedantic -Wformat -Wno-pedantic-ms-format
-ftrack-macro-expansion=0" } */
#define USE_SYSTEM_FORMATS
#include "format.h"
[Bug testsuite/108159] New: gcc.dg/format/ms-format2.c fails due to warning message change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108159
Bug ID: 108159
Summary: gcc.dg/format/ms-format2.c fails due to warning
message change
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
This is presumably a regression, as the test worked when it first went in.
However, the warning message being tested for has since changed the line that
gets reported:
printf (XXX, p); /* { dg-warning "format" "bad argument types" } */
printf ("%I32x", f); /* { dg-warning "format" "bad argument types" } */
printf ("%I64x", d); /* { dg-warning "format" "bad argument types" } */
gcc.dg/format/ms-format2.c: In function 'foo':
gcc.dg/format/ms-format2.c:12:13: warning: format '%I64x' expects argument of
type 'long long unsigned int', but argument 2 has type 'void *' [-Wformat=]
gcc.dg/format/ms-format2.c:20:11: note: in expansion of macro 'XXX'
gcc.dg/format/ms-format2.c:12:18: note: format string is defined here
gcc.dg/format/ms-format2.c:21:16: warning: format '%I32x' expects argument of
type 'long unsigned int', but argument 2 has type 'double' [-Wformat=]
gcc.dg/format/ms-format2.c:22:16: warning: format '%I64x' expects argument of
type 'long long unsigned int', but argument 2 has type 'double' [-Wformat=]
FAIL: gcc.dg/format/ms-format2.c -DWIDE bad argument types (test for
warnings, line 20)
PASS: gcc.dg/format/ms-format2.c -DWIDE bad argument types (test for
warnings, line 21)
PASS: gcc.dg/format/ms-format2.c -DWIDE bad argument types (test for
warnings, line 22)
FAIL: gcc.dg/format/ms-format2.c -DWIDE (test for excess errors)
Excess errors:
gcc.dg/format/ms-format2.c:12:13: warning: format '%I64x' expects argument of
type 'long long unsigned int', but argument 2 has type 'void *' [-Wformat=]
I assume the fix is to move the dg-warning to the macro definition line, but I
don't know how to distinguish between the 32 and 64-bit cases in dejagnu. To
be clear, the following change makes the test work for the 64-bit case:
diff --git a/gcc/testsuite/gcc.dg/format/ms-format2.c
b/gcc/testsuite/gcc.dg/format/ms-format2.c
index 5c950522a7c..e56bfc4a9c4 100644
--- a/gcc/testsuite/gcc.dg/format/ms-format2.c
+++ b/gcc/testsuite/gcc.dg/format/ms-format2.c
@@ -9,7 +9,7 @@
#include "format.h"
#ifdef _WIN64
-#define XXX "%I64x"
+#define XXX "%I64x" /* { dg-warning "format" "bad argument types" } */
#else
#define XXX "%I32x"
#endif
@@ -17,7 +17,7 @@
void
foo (float f, double d, void *p)
{
- printf (XXX, p); /* { dg-warning "format" "bad argument types" } */
+ printf (XXX, p);
printf ("%I32x", f); /* { dg-warning "format" "bad argument types" } */
printf ("%I64x", d); /* { dg-warning "format" "bad argument types" } */
}
But that won't address the 32-bit case. I suppose there's some other "{}"
thing to put on both #define XXX lines to choose which architecture, but I
don't know what that would be. Hopefully this is enough diagnosis for someone
more knowledgeable to pick it up and run with it.
[Bug fortran/108131] [10/11/12/13 Regression] Incorrect bound calculation when bound intrinsic used in size expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108131 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||10.3.0 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-December/058653.html
[Bug c++/108158] New: modification of '...' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 Bug ID: 108158 Summary: modification of '...' is not a constant expression Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: serge.guel...@telecom-bretagne.eu Target Milestone: --- Since version 11.3, gcc fails on compiling a (complex) constant expression from the frozen[0] library. gcc 11.2 is fine, and so are clang and msvc. I've reduced the code to the following: https://godbolt.org/z/e5bje7v35 It's still a relatively large piece of code, I failed to reduce it more significantly, sorry about that. The error message is ``` :458:39: in 'constexpr' expansion of 'ze_set.frozen::unordered_set::lookup >(4, frozen::elsa())' :453:32: in 'constexpr' expansion of '((const frozen::unordered_set*)this)->frozen::unordered_set::tables_.frozen::bits::pmh_tables<8, frozen::elsa >::lookup >((* & key), (* & hash))' :458:67: in 'constexpr' expansion of 'frozen::bits::seed_or_index()' :458:67: error: modification of 'ze_set' is not a constant expression 458 | constexpr auto nocount = ze_set.lookup(4, frozen::elsa()); | ``` But I don't see where such a modification would happen, and the fact that older version of gcc and clang and msvc correctly evaluate that expression makes me think it could be a GCC bug. Maybe bisecting between 11.2 and 11.3 would help understanding the origin of the regression? [0] https://github.com/serge-sans-paille/frozen
[Bug ada/108157] New: [12/13 regression] object subtype doesn't statically match designated subtype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108157 Bug ID: 108157 Summary: [12/13 regression] object subtype doesn't statically match designated subtype Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 54118 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54118=edit Demonstrator The attached code fails with $ /opt/gcc-12.2.0/bin/gcc -c g-socser.adb g-socser.adb:13:22: error: object subtype must statically match designated subtype The relevant part of g-socser.adb: 9. Connect_Socket 10. (Socket => Client.Socket, 11. Server => Client.Client_Address, 12. Timeout => 0.0, 13. Selector => Listener.Selector'Unchecked_Access, | >>> error: object subtype must statically match designated subtype The relevant part of g-socser.ads: 20.type Connections_Server is tagged limited record 21. -- limited because Selector_Type is limited 22. Selector : aliased Selector_Type; 23.end record; The relevant part of the GNAT standard library GNAT.Sockets is procedure Connect_Socket (Socket : Socket_Type; Server : Sock_Addr_Type; Timeout : Selector_Duration; Selector : access Selector_Type := null; Status : out Selector_Status); and it’s the same Selector_Type all the way. I’ve looked at Annotated Ada Reference Manual (Ada 2022 Draft 34) 4.9.1[1] and I can’t see what the problem is. Note, I don’t know why the code uses 'Unchecked_Access; 'Access gives the same error, 'Unrestricted_Access compiles OK. [1] http://www.ada-auth.org/standards/22aarm/html/AA-4-9-1.html
[Bug c/107831] Missed optimization: -fclash-stack-protection causes unnecessary code generation for dynamic stack allocations that are clearly less than a page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #9 from Petr Skocik ---
Regarding the size of alloca/VLA-generated code under -fstack-clash-protection.
I've played with this a little bit and while I love the feature, the code size
increases seem quite significant and unnecessarily so.
Take a simple
void ALLOCA_C(size_t Sz){ char buf[Sz]; asm volatile ("" : : "r"([0])); }
gcc -fno-stack-clash-protection: 17 bytes
gcc -fstack-clash-protection: 72 bytes
clang manages with less of an increase:
-fno-stack-clash_protection: 26 bytes
-stack-clash-protection: 45 bytes
Still this could be as low as 11 bytes for the -fclash-stack-protection
version (less than for the unprotected one!) all by using a simple call to an
assembly function, whose code can be no-clobber without much extra effort.
Linked in compiler explorer is a crack at the idea along with benchmarks:
https://godbolt.org/z/f8rhG1ozs
The performance impact of the call seems negligible (practically less than 1ns,
though in the above quick-and-dirty benchmark it fluctuates a tiny bit,
sometimes even giving the non-inline version an edge).
I originally suggested popping the address of the stack and repushing before
calling returning. Ended up just repushing -- the old return address becomes
part of the alloca allocation. The concern that this could mess up the return
stack buffer of the CPU seems valid but all the benchmarks indicate it
doesn't--not even when the ret address is popped--just as long as the return
target address is the same.
(When it isn't, the performance penalty is rather significant: measured a 19
times slowdown of that for comparison (it's also in the linked benchmarks)).
The (x86-64) assembly function:
#define STR(...) STR__(__VA_ARGS__) //{{{
#define STR__(...) #__VA_ARGS__ //}}}
asm(STR(
.global safeAllocaAsm;
safeAllocaAsm: //no clobber, though does expect 16-byte aligned at entry as
usual
push %r10;
cmp $16, %rdi;
ja .LsafeAllocaAsm__test32;
push 8(%rsp);
ret;
.LsafeAllocaAsm__test32:
push %r10;
push %rdi;
mov %rsp, %r10;
sub $17, %rdi;
and $-16, %rdi; //(-32+15)&(-16) //substract the 32 and 16-align, rounding
up
jnz .LsafeAllocaAsm__probes;
.LsafeAllocaAsm__ret:
lea (3*8)(%r10,%rdi,1), %rdi;
push (%rdi);
mov -8(%rdi), %r10;
mov -16(%rdi), %rdi;
ret;
.LsafeAllocaAsm__probes:
sub %rdi, %r10; //r10 is the desired rsp
.LsafeAllocaAsm__probedPastDesiredSpEh:
cmp %rsp, %r10; jge .LsafeAllocaAsm__pastDesiredSp;
orl $0x0,(%rsp);
sub $0x1000,%rsp;
jmp .LsafeAllocaAsm__probedPastDesiredSpEh;
.LsafeAllocaAsm__pastDesiredSp:
mov %r10, %rsp; //set the desired sp
jmp .LsafeAllocaAsm__ret;
.size safeAllocaAsm, .-safeAllocaAsm;
));
Cheers,
Petr Skocik
[Bug fortran/97345] FE passes do_subscript leaks gmp memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Richard Biener from comment #0) > ==15138== 8 bytes in 1 blocks are definitely lost in loss record 5 of 742 > ==15138==at 0x4C2E2DF: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==15138==by 0x568C698: __gmp_default_allocate (in > /usr/lib64/libgmp.so.10.3.2) > ==15138==by 0x569CA22: __gmpz_init_set (in /usr/lib64/libgmp.so.10.3.2) > ==15138==by 0xC04033: do_subscript(gfc_expr**) (frontend-passes.c:2861) > ==15138==by 0xC03C58: do_function(gfc_expr**, int*, void*) > (frontend-passes.c:2699) > ==15138==by 0xC0A1CD: gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, > int*, void*), void*) (frontend-passes.c:5189) > > the code is doing mpz_init_set (...) but no where freeing the memory > associated with mpz_t do_start, do_step, do_end While I can find reporting of the above, I see % valgrind -s ~/work/libexec/gcc/x86_64-unknown-freebsd14.0/13.0.0/f951 a.f90 ... ==46939== 183 errors in context 102 of 102: ==46939== Mismatched free() / delete / delete [] ==46939==at 0x484F55C: operator delete[](void*) (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==46939==by 0xADF6E2: (anonymous namespace)::dom_info::~dom_info() (dominance.cc:284) ==46939==by 0xAE127C: verify_dominators(cdi_direction) (dominance.cc:1185) ==46939==by 0xA76D5C: verify_loop_structure() (cfgloop.cc:1419) ==46939==by 0xD85B64: checking_verify_loop_structure (cfgloop.h:646) ==46939==by 0xD85B64: loop_optimizer_init(unsigned int) (loop-init.cc:130) ==46939==by 0xF9C25E: execute_build_cfg (tree-cfg.cc:382) ==46939==by 0xF9C25E: (anonymous namespace)::pass_build_cfg::execute(function*) (tree-cfg.cc:412) ==46939==by 0xE6C281: execute_one_pass(opt_pass*) (passes.cc:2644) ==46939==by 0xE6CBA7: execute_pass_list_1(opt_pass*) (passes.cc:2753) ==46939==by 0xE6CBF0: execute_pass_list(function*, opt_pass*) (passes.cc:2764) ==46939==by 0xAA9863: cgraph_node::analyze() (cgraphunit.cc:686) ==46939==by 0xAAC597: analyze_functions(bool) (cgraphunit.cc:1240) ==46939==by 0xAAD2D5: symbol_table::finalize_compilation_unit() (cgraphunit.cc:2514) ==46939== Address 0x5d4e6a0 is 0 bytes inside a block of size 56 alloc'd ==46939==at 0x484D064: operator new(unsigned long) (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==46939==by 0xADFBF9: new_zero_array (dominance.cc:153) ==46939==by 0xADFBF9: (anonymous namespace)::dom_info::dom_init() (dominance.cc:166) ==46939==by 0xADFD18: (anonymous namespace)::dom_info::dom_info(function*, cdi_direction) (dominance.cc:195) ==46939==by 0xAE11AC: verify_dominators(cdi_direction) (dominance.cc:1159) ==46939==by 0xA76D5C: verify_loop_structure() (cfgloop.cc:1419) ==46939==by 0xD85B64: checking_verify_loop_structure (cfgloop.h:646) ==46939==by 0xD85B64: loop_optimizer_init(unsigned int) (loop-init.cc:130) ==46939==by 0xF9C25E: execute_build_cfg (tree-cfg.cc:382) ==46939==by 0xF9C25E: (anonymous namespace)::pass_build_cfg::execute(function*) (tree-cfg.cc:412) ==46939==by 0xE6C281: execute_one_pass(opt_pass*) (passes.cc:2644) ==46939==by 0xE6CBA7: execute_pass_list_1(opt_pass*) (passes.cc:2753) ==46939==by 0xE6CBF0: execute_pass_list(function*, opt_pass*) (passes.cc:2764) ==46939==by 0xAA9863: cgraph_node::analyze() (cgraphunit.cc:686) ==46939==by 0xAAC597: analyze_functions(bool) (cgraphunit.cc:1240) ==46939== ==46939== ERROR SUMMARY: 2511 errors from 102 contexts (suppressed: 0 from 0)
[Bug c++/108138] g++ 9+ takes 7-10x longer compiling constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108138 --- Comment #13 from Peter Hurley --- Thanks everyone! We're really grateful for the rapid response and backports! Happy holidays!
[Bug c++/108155] no warning for for (int i = 1; 1 <= 12; ++i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108155 --- Comment #3 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #2) > Clang and EDG don't warn for this either, so maybe I'm the only person dumb > enough to write this. It still seems useful, if we can define the right > semantics without false positives, but it's not a priority. No I have accidently written this too before. The only false positive I can think of is with macros really.
[Bug c++/108155] no warning for for (int i = 1; 1 <= 12; ++i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108155 --- Comment #2 from Jonathan Wakely --- Clang and EDG don't warn for this either, so maybe I'm the only person dumb enough to write this. It still seems useful, if we can define the right semantics without false positives, but it's not a priority.
[Bug c++/108155] no warning for for (int i = 1; 1 <= 12; ++i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108155 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-17 Ever confirmed|0 |1 Severity|normal |enhancement Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c/44677] Warn for variables incremented but not used (+=, ++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677 Andrew Pinski changed: What|Removed |Added Summary|Warn for variables |Warn for variables |incremented but not used|incremented but not used ||(+=, ++) --- Comment #16 from Andrew Pinski --- "set but not used" (just for future searches)
[Bug c/44677] Warn for variables incremented but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677 Andrew Pinski changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #15 from Andrew Pinski --- *** Bug 108156 has been marked as a duplicate of this bug. ***
[Bug c/108156] missing set but not used warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108156 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 44677. *** This bug has been marked as a duplicate of bug 44677 ***
[Bug c/108156] New: missing set but not used warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108156
Bug ID: 108156
Summary: missing set but not used warning
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
We are missing a set but not used warning for:
void foo(int value)
{
value += 42;
}
This would be used for mistakes such as the following:
void foo(int* value)
{
value += 42;
}
[Bug c++/107437] nested generic lambdas fail requiring unneded captures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107437
--- Comment #5 from Patrick Palka ---
Reduced version of the original testcase:
struct integral_constant {
constexpr operator int() const { return 42; }
};
template
struct A {
static constexpr int value = N;
};
template
struct B {
static constexpr int value = T::value;
};
template
void f(T t) {
using alias = A;
[](auto) {
B a; // { dg-bogus "'t' is not captured" }
return a.value;
}(0);
}
template void f(integral_constant);
[Bug c++/107437] nested generic lambdas fail requiring unneded captures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107437 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-12-17 --- Comment #4 from Patrick Palka --- The capturing version of the testcase is now accepted on trunk, unfortunately we still reject the original non-capturing version. Another workaround that's accepted by GCC 9+ is to avoid using N in an evaluated context in the definition of vector_type: using vector_type = std::array;
[Bug c++/87765] Internal compiler error: coerce_template_parms (8.2) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87765 Patrick Palka changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #9 from Patrick Palka --- Fixed for GCC 13
[Bug c++/107437] nested generic lambdas fail requiring unneded captures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107437 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:982629bea416df976686467f235e09cb1a5531cc commit r13-4761-g982629bea416df976686467f235e09cb1a5531cc Author: Patrick Palka Date: Sat Dec 17 11:24:44 2022 -0500 c++: constantness of non-dependent NTTP argument [PR107437] Here we're rejecting the use of the lambda capture of 't' (of empty type) as a template argument ultimately because convert_nontype_argument checks constantness using is_constant_expression, which returns false for lambda captures since want_rval=false. But in this case I believe an lvalue-to-rvalue conversion of the argument is implied, so we should be using is_rvalue_constant_expression instead (which would return true here). However, it doesn't seem necessary to consider constantness at all when deciding whether to instantiate a non-dependent argument in convert_nontype_argument. So this patch gets rid of the problematic constantness test altogether, which incidentally also fixes the similar dg-ice'd testcase from PR87765. This is in line with a similar change we made to finish_decltype_type in r12-7564-gec0f53a3a542e7. PR c++/107437 PR c++/87765 gcc/cp/ChangeLog: * pt.cc (convert_nontype_argument): Relax is_nondep_const_expr test to !inst_dep_expr_p. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-generic-107437.C: New test. * g++.dg/cpp1z/constexpr-lambda26.C: Remove dg-ice.
[Bug c++/87765] Internal compiler error: coerce_template_parms (8.2) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87765 --- Comment #8 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:982629bea416df976686467f235e09cb1a5531cc commit r13-4761-g982629bea416df976686467f235e09cb1a5531cc Author: Patrick Palka Date: Sat Dec 17 11:24:44 2022 -0500 c++: constantness of non-dependent NTTP argument [PR107437] Here we're rejecting the use of the lambda capture of 't' (of empty type) as a template argument ultimately because convert_nontype_argument checks constantness using is_constant_expression, which returns false for lambda captures since want_rval=false. But in this case I believe an lvalue-to-rvalue conversion of the argument is implied, so we should be using is_rvalue_constant_expression instead (which would return true here). However, it doesn't seem necessary to consider constantness at all when deciding whether to instantiate a non-dependent argument in convert_nontype_argument. So this patch gets rid of the problematic constantness test altogether, which incidentally also fixes the similar dg-ice'd testcase from PR87765. This is in line with a similar change we made to finish_decltype_type in r12-7564-gec0f53a3a542e7. PR c++/107437 PR c++/87765 gcc/cp/ChangeLog: * pt.cc (convert_nontype_argument): Relax is_nondep_const_expr test to !inst_dep_expr_p. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-generic-107437.C: New test. * g++.dg/cpp1z/constexpr-lambda26.C: Remove dg-ice.
[Bug modula2/108122] gcc/testsuite/gm2/pimcoroutines/run/pass/testtime.mod runs too long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108122 --- Comment #1 from Gaius Mulley --- Created attachment 54117 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54117=edit Decrease sleep values in testtime.mod tested on amd64
[Bug c/108154] Inappropriate -Wstringop-overread in the C99 [static n] func param decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108154 --- Comment #1 from Roman Žilka --- If the object size derivation procedure, which considers 's' to be 0-1 bytes here, isn't specific just to Wstringop-overread, there's one more issue in gcc, of course.
[Bug c++/108155] New: no warning for for (int i = 1; 1 <= 12; ++i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108155
Bug ID: 108155
Summary: no warning for for (int i = 1; 1 <= 12; ++i)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 87403
Target Milestone: ---
Somehow I typed a 1 instead of i for the loop condition, and so the loop ran
forever.
It seems like we should warn for logical-or-expression that only involves
constant expressions. I don't see why anybody would write `1 != 12` or `x || 1
< y`.
void foo(int) { }
int main()
{
for (int i = 1; 1 <= 12; ++i)
foo(i);
}
Even better would be to warn for expressions like `1 < y` where y is not a
constant, but is known to be unchanged by the loop.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug tree-optimization/102556] equality comparison of a [static N] parameter to null not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102556 Roman Žilka changed: What|Removed |Added CC||roman.zilka at gmail dot com --- Comment #1 from Roman Žilka --- This'd be helpful.
[Bug middle-end/108154] New: Inappropriate -Wstringop-overread in the C99 [static n] func decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108154
Bug ID: 108154
Summary: Inappropriate -Wstringop-overread in the C99 [static
n] func decl
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: roman.zilka at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
Created attachment 54116
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54116=edit
gcc -v
GCC issues Wstringop-overread when a function declared with "buffer[static n]"
reads past the n-th item of the buffer.
$ cat test.c
#include
void f(char s[static 1]) {
++s;
if (strchr(s, 'a')) ++*s;
}
int main() {
char s[10] = {0};
f(s);
}
$ gcc -O1 test.c
test.c: In function ‘f’:
test.c:4:13: warning: ‘strchr’ reading 1 or more bytes from a region of size 0
[-Wstringop-overread]
4 | if (strchr(s, 'a')) ++*s;
| ^~
test.c:2:13: note: at offset 1 into source object ‘s’ of size [0, 1]
2 | void f(char s[static 1]) {
|~^~~
That may be a correct read, though, as 'n' is the size lower bound. Sure, it's
idiomatic to understand the phrase "the size of 'buffer' is at least 'n'" (as
C99 defines this type of declaration) as "this function operates on up to 'n'
items and doesn't care what's after that bound". This syntax is useful,
however, as "buffer[static 1]" to advertise to the compiler and the function
user that a non-NULL ptr must be passed.
I have a few functions in a sourcefile that handle 0-term. strings and make use
of that. The string length is not passed in another argument, so I can't use
"f(size_t n, char buffer[static n])". The amount of false-positive
Wstringop-overreads is so large it's not even helpful to use "pragma diagnostic
ignored" and I just disable the warning altogether, which is sub-ideal. As much
as I hate the syntax, after 23 years it looks like it's in the language to stay
and it's just too damn useful for documentation and code optimization (bug
102556). I'm actually surprised that so few people make use of it, although the
ugliness of it does provide a lead.
Please consider exempting this kind of declaration from Wstringop-overread.
Similar: bug 104854.
[Bug modula2/108153] Profiled lto bootstrap failure with modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153 --- Comment #1 from Jakub Jelinek --- One of the build is without my PR108147 fix, 2 of them are with it. I don't see m2rte plugin stuff anywhere in the backtrace (two intermingled ones).
