[Bug fortran/120431] SPREAD does not handle scalar argument and NCOPIES=-1 correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120431 --- Comment #1 from kargls at comcast dot net --- (In reply to kargls from comment #0) > Consider, > > real :: arr > arr = 1 > print *, spread(arr, 1, -1) > end > Small update. The above should be handled in simplification, but currently is not. The issue is in the runtime library, which is demonstrated with integer dm, ncpy real :: arr arr = 1 dm = 1 ncpy = -1 print *, spread(arr, dm, ncpy) end
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 --- Comment #16 from GCC Commits --- The releases/gcc-14 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:9c21d7eaf8383749d1a9cd266709ec9ed04e3a00 commit r14-11804-g9c21d7eaf8383749d1a9cd266709ec9ed04e3a00 Author: Harald Anlauf Date: Thu Aug 29 22:17:07 2024 +0200 Fortran: default-initialization of derived-type function results [PR98454] gcc/fortran/ChangeLog: PR fortran/98454 * resolve.cc (resolve_symbol): Add default-initialization of non-allocatable, non-pointer derived-type function results. gcc/testsuite/ChangeLog: PR fortran/98454 * gfortran.dg/alloc_comp_class_4.f03: Remove bogus pattern. * gfortran.dg/pdt_26.f03: Adjust expected count. * gfortran.dg/derived_result_3.f90: New test. (cherry picked from commit b222122d4e93de2238041a01b1886c7dfd9944da)
[Bug fortran/85750] [12/13/14 Regression] Default initialization of derived type array missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750 --- Comment #18 from GCC Commits --- The releases/gcc-14 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:0100ea2b4eb1c83972e0db07503a7cfe8a38932e commit r14-11805-g0100ea2b4eb1c83972e0db07503a7cfe8a38932e Author: Harald Anlauf Date: Thu May 15 21:07:07 2025 +0200 Fortran: default-initialization and functions returning derived type [PR85750] Functions with non-pointer, non-allocatable result and of derived type did not always get initialized although the type had default-initialization, and a derived type component had the allocatable or pointer attribute. Rearrange the logic when to apply default-initialization. PR fortran/85750 gcc/fortran/ChangeLog: * resolve.cc (resolve_symbol): Reorder conditions when to apply default-initializers. gcc/testsuite/ChangeLog: * gfortran.dg/alloc_comp_auto_array_3.f90: Adjust scan counts. * gfortran.dg/alloc_comp_class_3.f03: Remove bogus warnings. * gfortran.dg/alloc_comp_class_4.f03: Likewise. * gfortran.dg/allocate_with_source_14.f03: Adjust scan count. * gfortran.dg/derived_constructor_comps_6.f90: Likewise. * gfortran.dg/derived_result_5.f90: New test. (cherry picked from commit d31ab498b12ebbe4f50acb2aa240ff92c73f310c)
[Bug target/120417] gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120417 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #6 from Sam James --- ``` module->statement = STMT_CALL; cob_glob_ptr->cob_call_params = 0; cob_glob_ptr->cob_stmt_exception = 0; b_2 = callee (); /* oops */ module->statement = STMT_CALL; module->module_stmt = 0x0015; cob_procedure_params[0] = NULL; cob_procedure_params[1] = NULL; cob_procedure_params[2] = NULL; cob_procedure_params[3] = NULL; cob_glob_ptr->cob_call_params = 4; cob_glob_ptr->cob_stmt_exception = 0; b_2 = callee (NULL, NULL, NULL, NULL); ``` Can you give me a testcase without the UB here please (i.e. callee being called with no arguments, when it takes 4)?
[Bug c/120433] New: RISC-V:Unexpected Sign-Extension Behavior for uint32_t Return Values in RV64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120433
Bug ID: 120433
Summary: RISC-V:Unexpected Sign-Extension Behavior for uint32_t
Return Values in RV64
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bigmagicreadsun at gmail dot com
Target Milestone: ---
I encountered an inconsistency with sign-extension of uint32_t return values in
RV64 when comparing values in C code versus inline assembly. Below is a minimal
reproducer:
-march=rv64gc -mabi=lp64d -O2
https://godbolt.org/z/qPbj1dWfz
#include
#include
#define TEST_NUM 0x0231
__attribute__((noinline)) uint32_t a0_in_asm() {
asm volatile (
"lui a0, 0x\n"
"slli a0, a0, 0x4\n"
"addi a0, a0, 0x231\n"
"ecall\n"
);
}
int main(void) {
uint32_t res = a0_in_asm();
uint32_t val = (res != TEST_NUM) ? 20 : 30; // Fails unexpectedly
printf("val is %d\n", val); // Outputs 20 (unexpected)
return 0;
Assembly Output:
a0_in_asm:
lui a0, 0x
slli a0, a0, 0x4
addi a0, a0, 0x231
ecall
ret
.LC0:
.string "val is %d\n"
main:
addisp,sp,-16
sd ra,8(sp)
calla0_in_asm
li a5,-65536
addia5,a5,561
li a1,20
bne a0,a5,.L4
li a1,30
.L4:
lui a0,%hi(.LC0)
addia0,a0,%lo(.LC0)
callprintf
ld ra,8(sp)
li a0,0
addisp,sp,16
jr ra
The function a0_in_asm loads 0x0231 into a0 (as expected):
However, the comparison res != TEST_NUM evaluates to true because:
res (from a0_in_asm) is not sign-extended: 0x0231 (RV64 a0
post-call).
TEST_NUM is sign-extended to 0x0231 due to RISC-V calling
conventions (treating uint32_t as sign-extended).
The comparison in main shows:
li a5, -65536 # a5 = 0x
addi a5, a5, 561 # a5 = 0x0231 (sign-extended TEST_NUM)
bne a0, a5, .L4 # Mismatch due to lack of sign-extension in `a0`
Why does the toolchain not automatically sign-extend the uint32_t return value
from a0_in_asm, even though the calling convention mandates it? Is this a
compiler bug or intended behavior?
[Bug ada/120430] New: Bogus formal object is not referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120430 Bug ID: 120430 Summary: Bogus formal object is not referenced Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: liam at liampwll dot com CC: dkm at gcc dot gnu.org Target Milestone: ---
[Bug target/120433] RISC-V:Unexpected Sign-Extension Behavior for uint32_t Return Values in RV64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120433
--- Comment #2 from fujin zhao ---
I've refactored a0_in_asm() as requested, but the result remains unchanged.
Here’s the updated implementation:
__attribute__((noinline)) uint32_t a0_in_asm() {
uint32_t result;
asm volatile (
"lui %0, 0x\n"// Load upper 20 bits
"slli %0, %0, 0x4\n" // Shift left by 4
"addi %0, %0, 0x231\n"// Add lower 12 bits
: "=r" (result) // Output to 'result'
: // No input operands
: "a0"// Clobber list (a0 modified)
);
return result;// Explicit return
}
Here's the complete example:
https://godbolt.org/z/eTK5bna3o
[Bug target/120433] RISC-V:Unexpected Sign-Extension Behavior for uint32_t Return Values in RV64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120433 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2025-05-26 --- Comment #1 from Andrew Pinski --- a0_in_asm() looks like invalid inline asm in the first place. It does not clobber r0. And a0_in_asm() has no return statement. Can you fix up the a0_in_asm function to have the correct code in thr first place and try again?
[Bug target/120433] RISC-V:Unexpected Sign-Extension Behavior for uint32_t Return Values in RV64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120433
--- Comment #3 from fujin zhao ---
(In reply to fujin zhao from comment #2)
> I've refactored a0_in_asm() as requested, but the result remains unchanged.
> Here’s the updated implementation:
>
>
> __attribute__((noinline)) uint32_t a0_in_asm() {
> uint32_t result;
> asm volatile (
> "lui %0, 0x\n"// Load upper 20 bits
> "slli %0, %0, 0x4\n" // Shift left by 4
> "addi %0, %0, 0x231\n"// Add lower 12 bits
> : "=r" (result) // Output to 'result'
> : // No input operands
> : "a0"// Clobber list (a0 modified)
> );
> return result;// Explicit return
> }
>
> Here's the complete example:
>
> https://godbolt.org/z/eTK5bna3o
Apologies, I misread earlier — the result is actually correct now.
[Bug target/120433] RISC-V:Unexpected Sign-Extension Behavior for uint32_t Return Values in RV64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120433
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Keywords||inline-asm
Status|WAITING |RESOLVED
--- Comment #4 from Andrew Pinski ---
What are you trying to implement?
inline-asm to an system call?
Or something else?
If then this is the correct inline-asm for what you want:
```
__attribute__((noinline)) uint32_t a0_in_asm() {
register uint32_t a0 asm("a0");
asm volatile (
"lui a0, 0x\n"
"slli a0, a0, 0x4\n"
"addi a0, a0, 0x231\n"
"ecall\n" :"=&r"(a0) : : "memory"
);
return a0;
}
```
Anything else is undefined as you don't specify the return value of a0_in_asm
and you don't specify that a0 usage will change the register, etc.
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 --- Comment #6 from GCC Commits --- The releases/gcc-15 branch has been updated by Michael Eager : https://gcc.gnu.org/g:4ac1fb51c7b780159837e951bd893954d7d8803a commit r15-9727-g4ac1fb51c7b780159837e951bd893954d7d8803a Author: Michael J. Eager Date: Sun May 25 09:25:27 2025 -0700 MicroBlaze does not support speculative execution (CVE-2017-5753) gcc/ PR target/86772 Tracking CVE-2017-5753 * config/microblaze/microblaze.cc (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_save_value_not_needed
[Bug target/120427] [12/13/14/15/16 Regression] "and $0,mem" is generated without -Oz since r12-6106-gef26c151c14a87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120427
--- Comment #2 from H.J. Lu ---
Another issue with the commit:
+;; With -Oz, transform mov $imm,reg to the shorter push $imm; pop reg.
+(define_peephole2
+ [(set (match_operand:SWI248 0 "general_reg_operand")
+ (match_operand:SWI248 1 "const_int_operand"))]
+ "optimize_insn_for_size_p () && optimize_size > 1
+ && operands[1] != const0_rtx
&& operands[1] != constm1_rtx
is missing. We shouldn't transform "mov $-1,reg" to "push $-1; pop reg".
We should transform "mov $-1,reg" to "or $-1,reg" instead.
+ && IN_RANGE (INTVAL (operands[1]), -128, 127)
+ && !ix86_red_zone_used"
+ [(set (match_dup 2) (match_dup 1))
+ (set (match_dup 0) (match_dup 3))]
+{
+ if (GET_MODE (operands[0]) != word_mode)
+operands[0] = gen_rtx_REG (word_mode, REGNO (operands[0]));
+
+ operands[2] = gen_rtx_MEM (word_mode,
+ gen_rtx_PRE_DEC (Pmode, stack_pointer_rtx));
+ operands[3] = gen_rtx_MEM (word_mode,
+ gen_rtx_POST_INC (Pmode, stack_pointer_rtx));
+})
[Bug ada/120430] Bogus "formal object is not referenced" when a generic parameter is used in a child package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120430 --- Comment #1 from Liam Powell --- When a generic parameter of a package is used in a child package but not the parent package a bogus warning is generated. Example below: generic Foo : Integer; package A is end A; generic package A.B is function F return Integer is (Foo); end A.B; a.ads:2:04: warning: formal object "Foo" is not referenced [-gnatwu]
[Bug tree-optimization/52171] memcmp/strcmp/strncmp can be optimized when the result is tested for [in]equality with 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52171
Kael Franco changed:
What|Removed |Added
CC||kaelfandrew at gmail dot com
--- Comment #18 from Kael Franco ---
GCC and Clang does not optimize still for switch strcmp():
https://godbolt.org/z/MvdYTaWjc
```
#include
int f0_slow (const char *arg0)
{
if (strcmp (arg0, "llvm.") == 0)
return 0;
if (strcmp (arg0, "assume") == 0)
return 1;
if (strcmp (arg0, "gcroot") == 0)
return 2;
if (strcmp (arg0, "llvm.assume") == 0)
return 3;
if (strcmp (arg0, "llvm.memcpy.inline") == 0)
return 4;
return -1;
}
```
Assembly shows they both output many strcmp().
If tracking strlen() was implemented per bug 90625#c1 , it would most likely do
the following:
```
#include
int f0_fast (const char *arg0)
{
const size_t arg0_len = strnlen (arg0, strlen ("llvm.memcpy.inline") + 1);
switch (arg0_len)
{
case 5:
if (memcmp (arg0, "llvm.", 5) == 0)
return 0;
break;
case 6:
if (memcmp (arg0, "assume", 6) == 0)
return 1;
if (memcmp (arg0, "gcroot", 6) == 0)
return 2;
break;
case 11:
if (memcmp (arg0, "llvm.assume", 11) == 0)
return 3;
break;
case 18:
if (memcmp (arg0, "llvm.memcpy.inline", 18) == 0)
return 4;
break;
default:
break;
}
return 0;
}
```
After detecting switch strcmp(), we create a const local variable arg0_len that
strnlen(arg0, LONGEST_STRING + 1). LONGEST_STRING + 1 so GCC knows arg0 doesn't
start with LONGEST_STRING but strcmp() == 0. Then we switch on arg0_len and
memcmp (arg0, STRING, STRING_LEN) == 0. GCC and Clang remove all strcmp() uses.
This could optimize in GCC source like this example at gcc/passes.cc at line
2554:
```
static void
skip_pass (opt_pass *pass)
{
/* Pass "reload" sets the global "reload_completed", and many
things depend on this (e.g. instructions in .md files). */
if (strcmp (pass->name, "reload") == 0)
reload_completed = 1;
/* Similar for pass "pro_and_epilogue" and the "epilogue_completed" global
variable. */
if (strcmp (pass->name, "pro_and_epilogue") == 0)
epilogue_completed = 1;
/* The INSN_ADDRESSES vec is normally set up by
shorten_branches; set it up for the benefit of passes that
run after this. */
if (strcmp (pass->name, "shorten") == 0)
INSN_ADDRESSES_ALLOC (get_max_uid ());
/* Update the cfg hooks as appropriate. */
if (strcmp (pass->name, "into_cfglayout") == 0)
{
cfg_layout_rtl_register_cfg_hooks ();
cfun->curr_properties |= PROP_cfglayout;
}
if (strcmp (pass->name, "outof_cfglayout") == 0)
{
rtl_register_cfg_hooks ();
cfun->curr_properties &= ~PROP_cfglayout;
}
}
```
[Bug c/99526] Casts should retain typedef information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99526 --- Comment #1 from Andrew Pinski --- https://github.com/FRRouting/frr/tree/master/tools/gcc-plugins https://github.com/FRRouting/frr/blob/master/tools/gcc-plugins/gcc-retain-typeinfo.patch seems like the patch which will fix this.
[Bug c/99526] Casts should retain typedef information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99526 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-05-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Wait I just noticed the patch comes from David too :).
[Bug libstdc++/111250] __glibcxx_requires_subscript assertions are not checked during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111250 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|14.4|15.0 --- Comment #7 from Jonathan Wakely --- I'm not planning to backport this now, so fixed for 15.1
[Bug libstdc++/112349] ranges::min/max make unnecessary copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|14.4|14.3 Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- That's not a release, it was fixed for 14.3.0
[Bug fortran/85750] [12/13 Regression] Default initialization of derived type array missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Summary|[12/13/14 Regression] |[12/13 Regression] Default |Default initialization of |initialization of derived |derived type array missing |type array missing Target Milestone|12.5|14.4 Status|NEW |RESOLVED --- Comment #19 from anlauf at gcc dot gnu.org --- Backporting to 14-branch required backporting of r15-3323 (which went ok) and - in theory - r15-8945 before this patch. However, although the part to resolve.cc of r15-8945 is required but the testcase fails (likely due to missing backports of finalization fixes), I skipped that one except for the fixup in resolve.cc which was applied manually. I'll stop the backport here and declare this PR fixed in 14.4, 15.2, and 16. This minimizes the risk of potentially unknown regressions in 12- and 13-branch. A workaround for those staying with <= 13 is given in comment#4. Closing.
[Bug target/119966] [16 regression] pru: Invalid register in RTL expression starting with r16-160-ge6f89d78c1a752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119966 --- Comment #11 from Andrew Pinski --- (In reply to Dimitar Dimitrov from comment #10) > This issue was fixed with r16-809-gf725d6765373f7. That commit was not even supposed to fix this either. Even though that did fix the issue that exposed by the same patch as this one. I suspect the reason how r16-809 fixed it is the same way r16-809 fixed the missed optimization; that is causing combine to optimize back the same way it was doing before r16-160 and not exposing the issue that late combine with r16-160 exposes. So maybe it became latent again.
[Bug libstdc++/120432] New: flat_map operator[] is broken for const lvalue keys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120432
Bug ID: 120432
Summary: flat_map operator[] is broken for const lvalue keys
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
As reported by Rufei Zhao on the cpplang Slack: https://godbolt.org/z/fa48dvnoq
std::flat_map m;
int main(void) {
const double e { 3.14 };
std::flat_map m;
m[e] = 1.0; // bogus error
}
The problem is that
https://github.com/gcc-mirror/gcc/blob/aa93272/libstdc%2B%2B-v3/include/std/flat_map#L1145
says:
mapped_type&
operator[](const key_type& __x)
{ return operator[](__x); }
when it means:
mapped_type&
operator[](const key_type& __x)
{ return operator[](__x); }
I'd strongly recommend that you use a different name than `operator[]` for
the helper function anyway, because I'm sure there will be additional problems
around that that I'm not seeing off the top of my head. ...Actually, I see
another easy one off the top of my head.
https://godbolt.org/z/ea4WGcbz3
template
concept C = requires (M& m, T t) { m[t]; };
static_assert(!C, volatile int>);
static_assert(!C, volatile int>);
static_assert(!C, volatile int>); // bogus error
You need that helper function to stay out of the overload set of operator[] so
that it doesn't contribute to overload resolution in cases like this.
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 --- Comment #5 from GCC Commits --- The trunk branch has been updated by Michael Eager : https://gcc.gnu.org/g:2159f024f63c12fd356748ae8fc106bb9b355688 commit r16-871-g2159f024f63c12fd356748ae8fc106bb9b355688 Author: Michael J. Eager Date: Sun May 25 07:12:14 2025 -0700 MicroBlaze does not support speculative execution (CVE-2017-5753) gcc/ PR target/86772 Tracking CVE-2017-5753 * config/microblaze/microblaze.cc (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_save_value_not_needed
[Bug target/120417] gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120417 Sam James changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2025-05-26 Ever confirmed|0 |1
[Bug target/120070] [15/16 regression] m68k-linux-gnu-gcc -Os ICE segfault compiling xfs_trans_ail.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120070 --- Comment #6 from Adam Sampson --- Created attachment 61518 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61518&action=edit Minimised example 2 I've just run into a second example of this while crossbuilding libzip 1.11.4 - the attached pr120070b.c is minimised from zip_hash.c. "m68k-linux-gnu-gcc -O2 -c pr120070b.c" produces an ICE in the same place, and looking at -fdump-rtl-all output shows that reload is producing "(reg:DI -1 [+-4 ])" as above. Adding -mrla fixes it.
[Bug target/120417] gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120417 --- Comment #5 from Andrew Pinski --- (In reply to Simon Sobisch from comment #4) > @sjames: What do you mean with "needs reduction"? And do you intend to do it > on your own? Yes this is more of a keyword for GCC developers rather than for the user. > > [Note: I've reduced the original program that was generated from as much as > possible, then also reduced the amount of C code passed to GCC] > > In any case: can someone please confirm this issue so we have a reasonable > status (as noted: two people were already able to reproduce it in different > environments using GCC versions 9-12 + 14)? > It also would be interesting to see if trunk still has this issue (I guess > "yes")... I can't speak for Sam here but I suspect until a GCC developer (or bugzilla triager) reproduces it, it will sit in the unconfirmed state. The dependency on a library does make it harder in general.
[Bug fortran/120431] New: SPREAD does not handle scalar argument and NCOPIES=-1 correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120431 Bug ID: 120431 Summary: SPREAD does not handle scalar argument and NCOPIES=-1 correctly Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargls at comcast dot net Target Milestone: --- Consider, real :: arr arr = 1 print *, spread(arr, 1, -1) end % gfcx -o z a.f90 && ./z Operating system error: Cannot allocate memory Integer overflow in xmallocarray >From F2023, 16.9.197 Result Characteristics. The result is an array of the same type and type parameters as SOURCE and of rank n + 1, where n is the rank of SOURCE. Case (i): If SOURCE is scalar, the shape of the result is (MAX(NCOPIES,0)). So, the result is a rank 1 zero-sized array.
[Bug target/120434] (x86-64) GCC uses 'movsxd' for positive variables larger code than 'mov'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120434
--- Comment #1 from Kang-Che Sung ---
For signed integers that GCC can detect to be always positive, it uses signed
extension instead of zero extension, even in the "-Os" optimization mode.
For x86-64, sometimes zero extension can produce smaller code.
Test code:
```c
#include
extern uint64_t subroutine(uint64_t x);
uint64_t func1a(int32_t x) {
if (x < 50)
return 0;
return subroutine(x);
}
uint64_t func1b(int32_t x) {
if (x < 50)
return 0;
__asm__ ("" : "+r" (x)); // Break the (x >= 50) assumption
return subroutine((uint64_t)(uint32_t)x);
}
```
x86_64 gcc 15.1 with "-Os" option produces:
```x86asm
func1a:
cmpl $49, %edi
jle .L2
movslq %edi, %rdi
jmp subroutine
.L2:
xorl %eax, %eax
ret
func1b:
cmpl $49, %edi
jle .L5
movl %edi, %edi
jmp subroutine
.L5:
xorl %eax, %eax
ret
```
[Bug middle-end/120434] GCC uses signed extend (movsxd) for known positive variables rather than zero extend 'mov'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120434 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-05-26 Severity|normal |enhancement Status|UNCONFIRMED |NEW Summary|(x86-64) GCC uses 'movsxd' |GCC uses signed extend |for positive variables |(movsxd) for known positive |which is larger code than |variables rather than zero |'mov' |extend 'mov' Ever confirmed|0 |1 CC||pinskia at gcc dot gnu.org Component|target |middle-end --- Comment #3 from Andrew Pinski --- Right now GCC don't change extensions. There was an idea to introduce ZERO_EXTEND/SIGN_EXTEND to the gimple and use those explicitly to improve middle-end but I don't know what happened to that. We do some signed vs unsigned changes for division currently though. I am going to change this to middle-end because in some cases zero-extends (like in this case) can be "free" even without worrying about size (aarch64 it is true too for zeroing extending from 32bit to 64bit too). There might be another bug requesting a similar thing too.
[Bug target/120417] gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120417 --- Comment #7 from Simon Sobisch --- UB may be necessary to trigger that (and with GCC+libc that _does_ work on all environments but GNU/Linux 32bit [in theory it could also be multiarch -m32, but I think that should not make a difference]) :-/
[Bug target/120434] (x86-64) GCC uses 'movsxd' for positive variables which is larger code than 'mov'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120434 --- Comment #2 from Kang-Che Sung --- (Sorry I didn't know what happened with the bug report system, but I submitted an empty report by accident. I added the report in comment 1.)
[Bug middle-end/120434] GCC uses signed extend (movsxd) for known positive variables rather than zero extend 'mov'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120434 --- Comment #4 from Andrew Pinski --- Interesting clang/LLVM only does this for -Os and only on x86_64. I am agreeing it should be done at -O2 because it is almost always better to zero extend rather than sign extend on MOST if not all targets.
[Bug target/120434] New: (x86-64) GCC uses 'movsxd' for positive variables larger code than 'mov'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120434 Bug ID: 120434 Summary: (x86-64) GCC uses 'movsxd' for positive variables larger code than 'mov' Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: ---
[Bug target/120424] [arm] -fnon-call-exceptions -fstack-clash-protection triggers lra-eliminations bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120424 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Eric Botcazou --- Yes, that's a duplicate. Glad to see that you found a generic fix. *** This bug has been marked as a duplicate of bug 118989 ***
[Bug middle-end/118989] Missing explanation for switch-lower-slow-alg-max-cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118989 Eric Botcazou changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- *** Bug 120424 has been marked as a duplicate of this bug. ***
[Bug middle-end/118939] [14/15/16 Regression] ada: executable segfaults on arm-linux-gnueabi when assigning an access to controlled type since r14-2653-g2971ff7b1d564a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939 --- Comment #24 from Eric Botcazou --- *** Bug 120424 has been marked as a duplicate of this bug. ***
[Bug target/120424] [arm] -fnon-call-exceptions -fstack-clash-protection triggers lra-eliminations bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120424 --- Comment #5 from Eric Botcazou --- *** This bug has been marked as a duplicate of bug 118939 ***
[Bug target/120417] gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120417 --- Comment #4 from Simon Sobisch --- @sjames: What do you mean with "needs reduction"? And do you intend to do it on your own? [Note: I've reduced the original program that was generated from as much as possible, then also reduced the amount of C code passed to GCC] In any case: can someone please confirm this issue so we have a reasonable status (as noted: two people were already able to reproduce it in different environments using GCC versions 9-12 + 14)? It also would be interesting to see if trunk still has this issue (I guess "yes")...
[Bug c++/104177] coroutine frame is not being allocated with the correct alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177 --- Comment #24 from Janko Dedic --- It seems like P2014 is no longer being pursued. https://github.com/cplusplus/papers/issues/750#issuecomment-2657897866
[Bug c++/104177] coroutine frame is not being allocated with the correct alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177 --- Comment #25 from Iain Sandoe --- (In reply to Janko Dedic from comment #24) > It seems like P2014 is no longer being pursued. > > https://github.com/cplusplus/papers/issues/750#issuecomment-2657897866 I spoke with the author, the paper has not been abandoned for any technical reason, but for lack of available time to sort out the necessary core wording. Hopefully, we might find someone else to pick it up. (we can still fix the frame alignment without this - and there is a patch in progress to do so).
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 --- Comment #31 from GCC Commits --- The master branch has been updated by Jonathan Yong : https://gcc.gnu.org/g:5840bf969e2bfdf4f6c51d04aeb1a96a87727d80 commit r16-867-g5840bf969e2bfdf4f6c51d04aeb1a96a87727d80 Author: LIU Hao Date: Sat Feb 22 13:11:51 2025 +0800 i386: Quote user-defined symbols in assembly in Intel syntax With `-masm=intel`, GCC generates registers without % prefixes. If a user-declared symbol happens to match a register, it will confuse the assembler. User-defined symbols should be quoted, so they are not to be mistaken for registers or operators. Support for quoted symbols were added in Binutils 2.26, originally for ARM assembly, where registers are also unprefixed: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d02603dc201f80cd9d2a1f4b1a16110b1e04222b This change is required for `@SECREL32` to work in Intel syntax when targeting Windows, where `@` is allowed as part of a symbol. GNU AS fails to parse a plain symbol with that suffix: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881#c79 gcc/ChangeLog: PR target/53929 PR target/80881 * config/i386/i386-protos.h (ix86_asm_output_labelref): Declare new function for quoting user-defined symbols in Intel syntax. * config/i386/i386.cc (ix86_asm_output_labelref): Implement it. * config/i386/i386.h (ASM_OUTPUT_LABELREF): Use it. * config/i386/cygming.h (ASM_OUTPUT_LABELREF): Use it.
[Bug target/80881] Implement Windows native TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881 --- Comment #107 from GCC Commits --- The master branch has been updated by Jonathan Yong : https://gcc.gnu.org/g:5840bf969e2bfdf4f6c51d04aeb1a96a87727d80 commit r16-867-g5840bf969e2bfdf4f6c51d04aeb1a96a87727d80 Author: LIU Hao Date: Sat Feb 22 13:11:51 2025 +0800 i386: Quote user-defined symbols in assembly in Intel syntax With `-masm=intel`, GCC generates registers without % prefixes. If a user-declared symbol happens to match a register, it will confuse the assembler. User-defined symbols should be quoted, so they are not to be mistaken for registers or operators. Support for quoted symbols were added in Binutils 2.26, originally for ARM assembly, where registers are also unprefixed: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d02603dc201f80cd9d2a1f4b1a16110b1e04222b This change is required for `@SECREL32` to work in Intel syntax when targeting Windows, where `@` is allowed as part of a symbol. GNU AS fails to parse a plain symbol with that suffix: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881#c79 gcc/ChangeLog: PR target/53929 PR target/80881 * config/i386/i386-protos.h (ix86_asm_output_labelref): Declare new function for quoting user-defined symbols in Intel syntax. * config/i386/i386.cc (ix86_asm_output_labelref): Implement it. * config/i386/i386.h (ASM_OUTPUT_LABELREF): Use it. * config/i386/cygming.h (ASM_OUTPUT_LABELREF): Use it.
