Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor
Hello Andre, I get a regression on this testcase with a patch that is otherwise regression-free. I think the testcase is invalid. It does: type(container), allocatable :: list(:) list = [list, new_elem(5)] so it's using the variable 'list' unallocated. The original testcase in the PR had an extra zero-sized allocate statement before the assignment. I think it's the only missing bit.
[PATCH] c++, v2: Pedwarn on invalid decl specifiers for for-range-declaration [PR84009]
On Sat, Jul 05, 2025 at 08:46:31AM -0400, Jason Merrill wrote:
> I think we want these diagnostics enabled by default; I don't feel strongly
> about unconditional pedwarn vs. permerror.
So like this then?
2025-07-05 Jakub Jelinek
PR c++/84009
* parser.cc (cp_parser_decomposition_declaration): Pedwarn
on thread_local, __thread or static in decl_specifiers for
for-range-declaration.
(cp_parser_init_declarator): Likewise, and also for extern
or register.
* g++.dg/cpp0x/range-for40.C: New test.
* g++.dg/cpp0x/range-for41.C: New test.
* g++.dg/cpp0x/range-for42.C: New test.
* g++.dg/cpp0x/range-for43.C: New test.
--- gcc/cp/parser.cc.jj 2025-07-04 19:49:14.702864248 +0200
+++ gcc/cp/parser.cc2025-07-05 18:41:28.248664302 +0200
@@ -16919,6 +16919,15 @@ cp_parser_decomposition_declaration (cp_
/* Ensure DECL_VALUE_EXPR is created for all the decls but
the underlying DECL. */
cp_finish_decomp (decl, &decomp);
+ if (decl_spec_seq_has_spec_p (decl_specifiers, ds_thread))
+ pedwarn (decl_specifiers->locations[ds_thread],
+0, "for-range-declaration cannot be %qs",
+decl_specifiers->gnu_thread_keyword_p
+? "__thread" : "thread_local");
+ else if (decl_specifiers->storage_class == sc_static)
+ pedwarn (decl_specifiers->locations[ds_storage_class],
+0, "for-range-declaration cannot be %qs",
+"static");
}
if (pushed_scope)
@@ -24162,7 +24171,26 @@ cp_parser_init_declarator (cp_parser* pa
&& token->type != CPP_SEMICOLON)
{
if (maybe_range_for_decl && *maybe_range_for_decl != error_mark_node)
- range_for_decl_p = true;
+ {
+ range_for_decl_p = true;
+ if (decl_spec_seq_has_spec_p (decl_specifiers, ds_thread))
+ pedwarn (decl_specifiers->locations[ds_thread],
+0, "for-range-declaration cannot be %qs",
+decl_specifiers->gnu_thread_keyword_p
+? "__thread" : "thread_local");
+ else if (decl_specifiers->storage_class == sc_static)
+ pedwarn (decl_specifiers->locations[ds_storage_class],
+0, "for-range-declaration cannot be %qs",
+"static");
+ else if (decl_specifiers->storage_class == sc_extern)
+ pedwarn (decl_specifiers->locations[ds_storage_class],
+0, "for-range-declaration cannot be %qs",
+"extern");
+ else if (decl_specifiers->storage_class == sc_register)
+ pedwarn (decl_specifiers->locations[ds_storage_class],
+0, "for-range-declaration cannot be %qs",
+"register");
+ }
else
{
if (!maybe_range_for_decl)
--- gcc/testsuite/g++.dg/cpp0x/range-for40.C.jj 2025-07-04 21:03:00.951729318
+0200
+++ gcc/testsuite/g++.dg/cpp0x/range-for40.C2025-07-04 21:11:29.426240713
+0200
@@ -0,0 +1,41 @@
+// PR c++/84009
+// { dg-do compile { target c++11 } }
+
+int z[64];
+
+void
+foo ()
+{
+ for (static auto a : z) // { dg-error "for-range-declaration
cannot be 'static'" }
+;
+ for (thread_local auto a : z)// { dg-error
"for-range-declaration cannot be 'thread_local'" }
+;
+ for (__thread auto a : z)// { dg-error "for-range-declaration
cannot be '__thread'" }
+; // { dg-error "function-scope 'a'
implicitly auto and declared '__thread'" "" { target *-*-* } .-1 }
+ for (register auto a : z)// { dg-error "for-range-declaration
cannot be 'register'" }
+; // { dg-error "does not allow
'register' storage class specifier" "" { target c++17 } .-1 }
+ for (extern auto a : z) // { dg-error "for-range-declaration
cannot be 'extern'" }
+; // { dg-error "'a' has both 'extern'
and initializer" "" { target *-*-* } .-1 }
+ for (mutable auto a : z) // { dg-error "non-member 'a' cannot be
declared 'mutable'" }
+;
+ for (virtual auto a : z) // { dg-error "'virtual' outside class
declaration" }
+;
+ for (explicit auto a : z)// { dg-error "'explicit' outside class
declaration" }
+;
+ for (friend auto a : z) // { dg-error "'friend' used outside of
class" }
+;
+ for (typedef auto a : z) // { dg-error "typedef declared 'auto'"
}
+; // { dg-error "typedef 'a' is
initialized \\\(use 'decltype' instead\\\)" "" { target *-*-* } .-1 }
+#if __cplusplus >= 202002L
+ for (consteval auto a : z) // { dg-error "a variable cannot be
declared 'consteval'" "" { target c++20 } }
+;
+ for (constinit a
[PATCH] libgfortran: add fallback for trigonometric pi-based functions
Hi all, This patch introduces a fallback implementation for trigonometric pi-based functions. This implementation supports float, double, and long double data types. I've revised the test cases for r4 and r8 types, and all tests passed successfully on the aarch64-linux platform. If this looks good, I will address f128/r16 in a subsequent patch. (A related patch concerning libquadmath is currently under review.) Thanks, YuaoFrom f8f2031e5e4bcd03e7382342907334cd33dd2ec6 Mon Sep 17 00:00:00 2001 From: Yuao Ma Date: Sat, 5 Jul 2025 17:06:18 +0800 Subject: [PATCH] libgfortran: add fallback for trigonometric pi-based functions This patch introduces a fallback implementation for pi-based trigonometric functions, ensuring broader compatibility and robustness. The new implementation supports float, double, and long double data types. Accordingly, the test cases for r4 and r8 have been revised to reflect these changes. libgfortran/ChangeLog: * Makefile.am: Add c23_functions.c to Makefile. * Makefile.in: Regenerate. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Check if trig-pi functions exist. * gfortran.map: Add a section for c23 functions. * libgfortran.h: Include c23 proto file. * c23_protos.h: Add c23 proto file and trig-pi funcs. * intrinsics/c23_functions.c: Add trig-pi fallback impls. gcc/testsuite/ChangeLog: * gfortran.dg/dec_math_5.f90: Revise test to use fallback. Signed-off-by: Yuao Ma Co-authored-by: Steven G. Kargl --- gcc/testsuite/gfortran.dg/dec_math_5.f90 | 36 +- libgfortran/Makefile.am |4 + libgfortran/Makefile.in |8 + libgfortran/c23_protos.h | 133 +++ libgfortran/config.h.in | 63 ++ libgfortran/configure| 1020 +- libgfortran/configure.ac | 23 + libgfortran/gfortran.map | 25 + libgfortran/intrinsics/c23_functions.c | 308 +++ libgfortran/libgfortran.h|1 + 10 files changed, 1598 insertions(+), 23 deletions(-) create mode 100644 libgfortran/c23_protos.h create mode 100644 libgfortran/intrinsics/c23_functions.c diff --git a/gcc/testsuite/gfortran.dg/dec_math_5.f90 b/gcc/testsuite/gfortran.dg/dec_math_5.f90 index a7ff3275236..7bcf07fce67 100644 --- a/gcc/testsuite/gfortran.dg/dec_math_5.f90 +++ b/gcc/testsuite/gfortran.dg/dec_math_5.f90 @@ -102,26 +102,26 @@ program p if (abs(c1 - 0.5) > e3) stop 39 if (abs(d1 - 0.5) > e4) stop 40 - a1 = acospi(0.5) - b1 = acospi(-0.5) + a1 = 0.5; a1 = acospi(a1) + b1 = -0.5; b1 = acospi(b1) c1 = acospi(0.5) d1 = acospi(-0.5) - if (abs(a1 - 1.0 / 3) > e1) stop 41 - if (abs(b1 - 2.0 / 3) > e2) stop 42 + if (abs(a1 - 1._4 / 3) > e1) stop 41 + if (abs(b1 - 2._8 / 3) > e2) stop 42 if (abs(c1 - 1.0 / 3) > e3) stop 43 if (abs(d1 - 2.0 / 3) > e4) stop 44 - a1 = asinpi(0.5) - b1 = asinpi(-0.5) + a1 = 0.5; a1 = asinpi(a1) + b1 = -0.5; b1 = asinpi(b1) c1 = asinpi(0.5) d1 = asinpi(-0.5) - if (abs(a1 - 1.0 / 6) > e1) stop 45 - if (abs(b1 + 1.0 / 6) > e2) stop 46 + if (abs(a1 - 1._4 / 6) > e1) stop 45 + if (abs(b1 + 1._8 / 6) > e2) stop 46 if (abs(c1 - 1.0 / 6) > e3) stop 47 if (abs(d1 + 1.0 / 6) > e4) stop 48 - a1 = atanpi(1.0) - b1 = atanpi(-1.0) + a1 = 1.0; a1 = atanpi(a1) + b1 = -1.0; b1 = atanpi(b1) c1 = atanpi(1.0) d1 = atanpi(-1.0) if (abs(a1 - 0.25) > e1) stop 49 @@ -129,8 +129,8 @@ program p if (abs(c1 - 0.25) > e3) stop 51 if (abs(d1 + 0.25) > e4) stop 52 - a1 = atan2pi(1.0, 1.0) - b1 = atan2pi(1.0, 1.0) + a1 = 1.0; a1 = atan2pi(a1, a1) + b1 = 1.0; b1 = atan2pi(b1, b1) c1 = atan2pi(1.0, 1.0) d1 = atan2pi(1.0, 1.0) if (abs(a1 - 0.25) > e1) stop 53 @@ -138,8 +138,8 @@ program p if (abs(c1 - 0.25) > e3) stop 55 if (abs(d1 - 0.25) > e4) stop 56 - a1 = cospi(1._4 / 3) - b1 = cospi(-1._8 / 3) + a1 = 1._4 / 3; a1 = cospi(a1) + b1 = -1._8 / 3; b1 = cospi(b1) c1 = cospi(4._ep / 3) d1 = cospi(-4._16 / 3) if (abs(a1 - 0.5) > e1) stop 57 @@ -147,8 +147,8 @@ program p if (abs(c1 + 0.5) > e3) stop 59 if (abs(d1 + 0.5) > e4) stop 60 - a1 = sinpi(1._4 / 6) - b1 = sinpi(-1._8 / 6) + a1 = 1._4 / 6; a1 = sinpi(a1) + b1 = -1._8 / 6; b1 = sinpi(b1) c1 = sinpi(5._ep / 6) d1 = sinpi(-7._16 / 6) if (abs(a1 - 0.5) > e1) stop 61 @@ -156,8 +156,8 @@ program p if (abs(c1 - 0.5) > e3) stop 63 if (abs(d1 - 0.5) > e4) stop 64 - a1 = tanpi(0.25) - b1 = tanpi(-0.25) + a1 = 0.25; a1 = tanpi(a1) + b1 = -0.25; b1 = tanpi(b1) c1 = tanpi(1.25) d1 = tanpi(-1.25) if (abs(a1 - 1.0) > e1) stop 65 diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am index 4f3b3033224..82cf51b6bcc 100644 --- a/libgfortran/Makefile.am +++ b/libgfortran/Makefile.am @@ -165,6 +165,7 @@ if !LIBGFOR_MINIMAL gfor_helper_src+= \ intrinsics/access.c \ +intrinsics/c
Re: [PATCH] LoongArch: Fix ICE caused by _alsl_reversesi_extended.
On Sat, 2025-07-05 at 11:20 +0800, Lulu Cheng wrote:
> For the gcc.target/loongarch/bitwise-shift-reassoc-clobber.c,
> some extensions are eliminated in ext_dce in commit r16-1835.
>
> This will result in the following rtx being generated in the
> combine pass:
> (insn 12 10 15 2 (set (reg/v:DI 23 $r23 [ x ])
> (sign_extend:DI (plus:SI
> (subreg:SI
> (and:DI (ashift:DI
> (reg/v:DI 23 $r23 [ x ])
> (const_int 3 [0x3]))
> (const_int 2208 [0x8a0])) 0)
> (reg:SI 23 $r23 [ x ]
> "test.c":7:7 266 {and_alsl_reversesi_extended}
> (nil))
>
> However, in the template '_alsl_reversesi_extended',
> operands[0] and operands[4] cannot be assigned to the same hardware
> register, which causes ICE during the reload pass.
Oops. We have:
Trying 10 -> 12:
10: r91:DI=sign_extend($r23:DI<<0x3&0x8a0#0+$r23:SI)
REG_DEAD $r23:DI
12: $r23:DI=r91:DI
REG_DEAD r91:DI
Successfully matched this instruction:
(set (reg/v:DI 23 $r23 [ x ])
(sign_extend:DI (plus:SI (subreg:SI (and:DI (ashift:DI (reg/v:DI 23 $r23 [
x ])
(const_int 3 [0x3]))
(const_int 2208 [0x8a0])) 0)
(reg:SI 23 $r23 [ x ]
allowing combination of insns 10 and 12
But the instruction description already has earlyclobber:
[(set (match_operand:DI 0 "register_operand" "=&r")
(sign_extend:DI
(plus:SI
(subreg:SI
(any_bitwise:DI
(ashift:DI
(match_operand:DI 1 "register_operand" "r0")
(match_operand:SI 2 "const_immalsl_operand" ""))
(match_operand:DI 3 "const_int_operand" "i"))
0)
(match_operand:SI 4 "register_operand" "r"]
To me if we need to "fix up" this in our machine description we'd need
to check REGNO everywhere we have an earlyclobber.
So Jeff & Richard: shouldn't combine simply reject those cases where
substitute a hard register in would violate the earlyclobber?
> Now add restrictions on hard registers in template conditions.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.md
> (_alsl_reversesi_extended): Add conditions.
>
> ---
> gcc/config/loongarch/loongarch.md | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/loongarch/loongarch.md
> b/gcc/config/loongarch/loongarch.md
> index f7005dee5b6..8c5f9066c5e 100644
> --- a/gcc/config/loongarch/loongarch.md
> +++ b/gcc/config/loongarch/loongarch.md
> @@ -3174,7 +3174,9 @@ (define_insn_and_split "_alsl_reversesi_extended"
> (match_operand:SI 4 "register_operand" "r"]
> "TARGET_64BIT
> && loongarch_reassoc_shift_bitwise (, operands[2], operands[3],
> - SImode)"
> + SImode)
> + && !(GP_REG_P (REGNO (operands[0]))
> + && REGNO (operands[0]) == REGNO (operands[4]))"
> "#"
> "&& reload_completed"
> [; r0 = r1 [&|^] r3 is emitted in PREPARATION-STATEMENTS because we
--
Xi Ruoyao
Re: [PATCH] LoongArch: Fix ICE caused by _alsl_reversesi_extended.
Hi! On Sat, Jul 05, 2025 at 11:10:05PM +0800, Xi Ruoyao wrote: > Possibly this is https://gcc.gnu.org/PR101882. Specifically comment 5 > from Segher: > > "The LRA change is correct AFAICS. But combine makes a change that > violates the earlyclobber... I need to do something about that, too." See my comment in that PR. The loongarch machine description explicitly allows operand 1 to be the same as operand 0. combine has notyhing to do with this, the pattern it ended up with is recognised by recog(), exactly as it should be (according to the pattern here, is that "_alsl_reversesi_extended"?) Segher
Re: [PATCH] tree-optimization/120929: Limit MEM_REF handling to .ACCESS_WITH_SIZE
On 2025-07-05 07:23, Richard Biener wrote:
OK, should I revert right away or can we wait till Qing returns on Monday?
Monday is OK with me.
Thanks, so I thought about this some more and I think when I said in
bugzilla:
"In fact, maybe the .ACCESS_WITH_SIZE handling in objsz probably needs
improvement to express it better, but that's an orthogonal matter."
I had the right intuition but I was completely wrong about it being an
orthogonal matter. That *is* the issue and it only becomes relevant
when the member being described is a pointer and not a FAM. e.g. for
the following:
```
struct A
{
int count;
#ifndef PTR
char c[] __attribute ((__counted_by__ (count)));
#else
char *c __attribute ((__counted_by__ (count)));
#endif
} a;
unsigned long
foo (struct A *a)
{
return __builtin_dynamic_object_size (a->c, 1);
}
```
the .ACCESS_WITH_SIZE abstraction records the size using &a->c:
_2 = &a->c;
_3 = &a->count;
_1 = .ACCESS_WITH_SIZE (_2, _3, 1, 0, -1, 0B);
D.2964 = __builtin_dynamic_object_size (_1, 1);
this doesn't make a difference when c is an array since the & operator
is a nop. However when the same is applied to the pointer a->c, it
becomes an additional dereference, which changes the semantic meaning:
_2 = &a->c;
_3 = &a->count;
_1 = .ACCESS_WITH_SIZE (_2, _3, 1, 0, -1, 0B);
_4 = *_1;
D.2964 = __builtin_dynamic_object_size (_4, 1);
Since the intent of the .ACCESS_WITH_SIZE was to associate the storage
of count with c to prevent reordering, maybe the semantically correct
solution here is that when c is a pointer, the frontend emits:
_2 = a->c;
_3 = &a->count;
_1 = .ACCESS_WITH_SIZE (_2, _3, 1, 0, -1, 0B);
D.2964 = __builtin_dynamic_object_size (_, 1);
so a->c instead of &a->c. In fact, maybe taking the address of a->c
doesn't make sense in general and .ACCESS_WITH_SIZE should always be the
above even for FAM? Does that sound correct?
Sid
Re: [PATCH] tree-optimization/120929: Limit MEM_REF handling to .ACCESS_WITH_SIZE
> Am 05.07.2025 um 12:19 schrieb Siddhesh Poyarekar : > > On 2025-07-05 02:45, Richard Biener wrote: Am 04.07.2025 um 19:57 schrieb Siddhesh Poyarekar : >>> >>> On 2025-07-04 08:12, Siddhesh Poyarekar wrote: > On 2025-07-04 08:08, Siddhesh Poyarekar wrote: > gcc/ChangeLog: > I forgot to add the PR number to the ChangeLog entries, I've fixed it in my commit message. > * tree-object-size.cc (is_access_with_size): New function. > (collect_object_sizes_for): Use it. > > gcc/testsuite/ChangeLog: > > * gcc.dg/pr120929.c: New test case. >>> >>> Testing: >>> >>> - x86_64 bootstrap and test, no new regressions >>> - i686 build and test, no new regressions >>> - ubsan config bootstrap OK >> My point in the PR still stands. > > OK, should I revert right away or can we wait till Qing returns on Monday? Monday is OK with me. Richard > > Thanks, > Sid
Re: [PATCH] c++: Pedwarn on invalid decl specifiers for for-range-declaration [PR84009]
On 7/5/25 2:20 AM, Jakub Jelinek wrote: Hi! https://eel.is/c++draft/stmt.ranged#2 says that in for-range-declaration only type-specifier or constexpr can appear. As the following testcases show, we've emitted some diagnostics in most cases, but not for static/thread_local (the patch handles __thread too) and register in the non-sb case. For extern there was an error that it is both extern and has an initializer (again, non-sb only, sb errors on extern). The following patch diagnoses those cases with pedwarn. I've used for-range-declaration in the diagnostics wording (there was already a case of that for the typedef), so that in the future we don't need to differentiate it between range for and expansion statements. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2025-07-05 Jakub Jelinek PR c++/84009 * parser.cc (cp_parser_decomposition_declaration): Pedwarn on thread_local, __thread or static in decl_specifiers for for-range-declaration. (cp_parser_init_declarator): Likewise, and also for extern or register. * g++.dg/cpp0x/range-for40.C: New test. * g++.dg/cpp0x/range-for41.C: New test. * g++.dg/cpp0x/range-for42.C: New test. * g++.dg/cpp0x/range-for43.C: New test. --- gcc/cp/parser.cc.jj 2025-07-04 19:49:14.702864248 +0200 +++ gcc/cp/parser.cc2025-07-04 21:29:46.568232075 +0200 @@ -16919,6 +16919,15 @@ cp_parser_decomposition_declaration (cp_ /* Ensure DECL_VALUE_EXPR is created for all the decls but the underlying DECL. */ cp_finish_decomp (decl, &decomp); + if (decl_spec_seq_has_spec_p (decl_specifiers, ds_thread)) + pedwarn (decl_specifiers->locations[ds_thread], +OPT_Wpedantic, "for-range-declaration cannot be %qs", +decl_specifiers->gnu_thread_keyword_p +? "__thread" : "thread_local"); + else if (decl_specifiers->storage_class == sc_static) + pedwarn (decl_specifiers->locations[ds_storage_class], +OPT_Wpedantic, "for-range-declaration cannot be %qs", I think we want these diagnostics enabled by default; I don't feel strongly about unconditional pedwarn vs. permerror. Jason
Re: [PATCH] c++: -fno-delete-null-pointer-checks constexpr addr comparison [PR71962]
On 7/3/25 10:43 AM, Patrick Palka wrote: On Thu, 3 Jul 2025, Jason Merrill wrote: On 7/2/25 7:58 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here the flag -fno-delete-null-pointer-checks causes the trivial address comparison in inline int a, b; static_assert(&a != &b); to be rejected as non-constant because with the flag we can't assume such weak symbols are non-NULL, which causes symtab/fold-const.cc to punt on such comparisons. Note this also affects -fsanitize=undefined since it implies -fno-delete-null-pointer-checks. Right, the underlying problem is that we use the one flag to mean two things: 1) a static storage duration decl can live at address 0 2) do more careful checking for null pointers/lvalues (i.e. in gimple_call_nonnull_result_p) Both cases are related to checking for null, but they are different situations and really shouldn't depend on the same flag. Your patch seems wrong for #1 targets; on such a target 'a' might end up allocated at address 0, so "&a != nullptr" is not decidable at compile time. OTOH such targets are a small minority, and I suspect they already have other C++ issues with e.g. a conversion to base not adjusting a null pointer. Yep, and normally I would not be so bold to propose making such a trade-off, but this seems to be exactly the trade-off we made in PR96862 for -frounding-math? The flag makes lossy floating-point operations depend on the run-time rounding mode and so not decidable at compile time, so we ended up disabling the flag during constexpr evaluation and using the default rounding mode. I don't immediately see why -frounding-math maybe be special. On a related note, I notice we accept [[gnu::weak]] inline int a, b; static_assert(&a != &b); with the default -fdelete-null-pointer-checks, which seems wrong, Hmm, it seems fine to me; if we define a and b in the current TU, we know they are defined, so their addresses aren't going to be null and thus won't compare equal. Jason
[PATCH] cdce: Fix non-call exceptions with signaling nans [PR120951]
The cdce code introduces a test for a NaN using the EQ_EXPR code.
The problem is EQ_EXPR can cause an exception with non-call exceptions
and signaling nans turned on. This is now correctly rejected by the verfier
since r16-241-g4c40e3d7b9152f.
The fix is seperate out the comparison into its own statement from the
GIMPLE_COND.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/120951
gcc/ChangeLog:
* tree-call-cdce.cc (use_internal_fn): For non-call exceptions
with EQ_EXPR can throw for floating point types, then create
the EQ_EXPR seperately.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr120951-1.c: New test.
Signed-off-by: Andrew Pinski
---
gcc/testsuite/gcc.dg/torture/pr120951-1.c | 12
gcc/tree-call-cdce.cc | 17 +++--
2 files changed, 27 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/torture/pr120951-1.c
diff --git a/gcc/testsuite/gcc.dg/torture/pr120951-1.c
b/gcc/testsuite/gcc.dg/torture/pr120951-1.c
new file mode 100644
index 000..4e2b41deb52
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr120951-1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-fnon-call-exceptions -fsignaling-nans" } */
+
+/* PR tree-optimization/120951 */
+
+/* cdce would create a trapping comparison inside a condition.
+ tests to make sure that does not happen. */
+
+double f(double r, double i) {
+ return __builtin_fmod(r, i);
+}
+
diff --git a/gcc/tree-call-cdce.cc b/gcc/tree-call-cdce.cc
index 649c1e2b9f9..3edea754ee4 100644
--- a/gcc/tree-call-cdce.cc
+++ b/gcc/tree-call-cdce.cc
@@ -36,6 +36,7 @@ along with GCC; see the file COPYING3. If not see
#include "builtins.h"
#include "internal-fn.h"
#include "tree-dfa.h"
+#include "tree-eh.h"
/* This pass serves two closely-related purposes:
@@ -1222,8 +1223,20 @@ use_internal_fn (gcall *call)
{
/* Skip the call if LHS == LHS. If we reach here, EDOM is the only
valid errno value and it is used iff the result is NaN. */
- conds.quick_push (gimple_build_cond (EQ_EXPR, lhs, lhs,
- NULL_TREE, NULL_TREE));
+ /* In the case of non call exceptions, with signaling NaNs, EQ_EXPR
+can throw an exception and that can't be part of the GIMPLE_COND. */
+ if (flag_exceptions
+ && cfun->can_throw_non_call_exceptions
+ && operation_could_trap_p (EQ_EXPR, true, false, NULL_TREE))
+ {
+ tree b = make_ssa_name (boolean_type_node);
+ conds.quick_push (gimple_build_assign (b, EQ_EXPR, lhs, lhs));
+ conds.quick_push (gimple_build_cond (NE_EXPR, b, boolean_false_node,
+ NULL_TREE, NULL_TREE));
+ }
+ else
+ conds.quick_push (gimple_build_cond (EQ_EXPR, lhs, lhs,
+NULL_TREE, NULL_TREE));
nconds++;
/* Try replacing the original call with a direct assignment to
--
2.43.0
Re: [PATCH] LoongArch: Fix ICE caused by _alsl_reversesi_extended.
On Sat, 2025-07-05 at 17:55 +0800, Xi Ruoyao wrote:
> On Sat, 2025-07-05 at 11:20 +0800, Lulu Cheng wrote:
> > For the gcc.target/loongarch/bitwise-shift-reassoc-clobber.c,
> > some extensions are eliminated in ext_dce in commit r16-1835.
> >
> > This will result in the following rtx being generated in the
> > combine pass:
> > (insn 12 10 15 2 (set (reg/v:DI 23 $r23 [ x ])
> > (sign_extend:DI (plus:SI
> > (subreg:SI
> > (and:DI (ashift:DI
> > (reg/v:DI 23 $r23 [ x ])
> > (const_int 3 [0x3]))
> > (const_int 2208 [0x8a0])) 0)
> > (reg:SI 23 $r23 [ x ]
> > "test.c":7:7 266 {and_alsl_reversesi_extended}
> > (nil))
> >
> > However, in the template '_alsl_reversesi_extended',
> > operands[0] and operands[4] cannot be assigned to the same hardware
> > register, which causes ICE during the reload pass.
>
> Oops. We have:
>
> Trying 10 -> 12:
> 10: r91:DI=sign_extend($r23:DI<<0x3&0x8a0#0+$r23:SI)
> REG_DEAD $r23:DI
> 12: $r23:DI=r91:DI
> REG_DEAD r91:DI
> Successfully matched this instruction:
> (set (reg/v:DI 23 $r23 [ x ])
> (sign_extend:DI (plus:SI (subreg:SI (and:DI (ashift:DI (reg/v:DI
> 23 $r23 [ x ])
> (const_int 3 [0x3]))
> (const_int 2208 [0x8a0])) 0)
> (reg:SI 23 $r23 [ x ]
> allowing combination of insns 10 and 12
>
> But the instruction description already has earlyclobber:
>
> [(set (match_operand:DI 0 "register_operand" "=&r")
> (sign_extend:DI
> (plus:SI
> (subreg:SI
> (any_bitwise:DI
> (ashift:DI
> (match_operand:DI 1 "register_operand" "r0")
> (match_operand:SI 2 "const_immalsl_operand" ""))
> (match_operand:DI 3 "const_int_operand" "i"))
> 0)
> (match_operand:SI 4 "register_operand" "r"]
>
> To me if we need to "fix up" this in our machine description we'd need
> to check REGNO everywhere we have an earlyclobber.
>
> So Jeff & Richard: shouldn't combine simply reject those cases where
> substitute a hard register in would violate the earlyclobber?
Possibly this is https://gcc.gnu.org/PR101882. Specifically comment 5
from Segher:
"The LRA change is correct AFAICS. But combine makes a change that
violates the earlyclobber... I need to do something about that, too."
--
Xi Ruoyao
Re: [PATCH] libgfortran: add fallback for trigonometric pi-based functions
On Sat, Jul 05, 2025 at 05:20:02PM +0800, Yuao Ma wrote: > > diff --git a/libgfortran/configure b/libgfortran/configure > index 9898a94a372..971f1e9df5e 100755 > --- a/libgfortran/configure > +++ b/libgfortran/configure > @@ -16413,7 +16413,7 @@ else > We can't simply define LARGE_OFF_T to be 9223372036854775807, > since some C++ compilers masquerading as C compilers > incorrectly reject 9223372036854775807. */ > -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) > +#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << > 31)) What is the purpose of this change? -- Steve
[pushed] wwwdocs: readings: compilerconnection.com is gone
Pushed. Gerald --- htdocs/readings.html | 3 --- 1 file changed, 3 deletions(-) diff --git a/htdocs/readings.html b/htdocs/readings.html index 3b0556e6..251011e0 100644 --- a/htdocs/readings.html +++ b/htdocs/readings.html @@ -604,9 +604,6 @@ names. - http://compilerconnection.com";>Links related to many - compiler topics - https://compilers.iecc.com";>comp.compilers archive Steven Muchnick (1997) "Advanced Compiler Design and Implementation". -- 2.50.0
Re: [PATCH] libstdc++: Make debug iterator pointer sequence const [PR116369]
On 01/07/2025 22:51, Jonathan Wakely wrote: On Mon, 16 Jun 2025 at 18:36, François Dumont wrote: I eventually wonder if it is such a big deal to add the new symbols for _GLIBCXX_DEBUG mode. I like this version much more than the one trying to duplicate symbols with asm. Here is the patch doing this. It avoids to add many const_cast which is what we are trying to achieve here. I'm still not really sure if this is worth it though - is it fixing a bug or a correctness problem? (using const_cast is safe if the objects aren't actually const) All the new tests already pass, even without this patch. Are these just tests for const member functions that we aren't currently testing at all? Those tests are showing the same UB that you fixed as part of your PR116369 patch but this time with local_iterator. Even if tests are passing without this patch it's still UB before it, do you prefer to remove those tests then ? Globally this patch is following your recommendations on PR116369 commit where you were saying: Ideally we would not need the const_cast at all. Instead, the _M_attach member (and everything it calls) should be const-qualified. That would work fine now, because the members that it ends up modifying are mutable. Making that change would require a number of new exports from the shared library, and would require retaining the old non-const member functions (maybe as symbol aliases) for backwards compatibility. That might be worth changing at some point, but isn't done here. In addition to what is said here I made the sequence pointer const too as the added mutable allows that. It was also the occasion to fix some types used in std::forward_list in Debug mode. Do you think it is useless eventually ? I've updated the PR keeping 2 commits so that if this last step is not good I can just drop it. I even updated the versioned namespace mode breaking this mode abi, I think it's fine, no ? Yes that's fine. François On 08/06/2025 22:00, François Dumont wrote: Here is a new attempt preserving symbols. libstdc++: Make debug iterator pointer sequence const [PR116369] In revision a35dd276cbf6236e08bcf6e56e62c2be41cf6e3c the debug sequence have been made mutable to allow attach iterators to const containers. This change completes this fix by also declaring debug unordered container members mutable. Additionally the debug iterator sequence is now a pointer-to-const and so _Safe_sequence_base _M_attach and all other methods are const qualified. Not-const methods exported are preserved for abi backward compatibility. The new const methods are calling the latter thanks to a safe use of const_cast. libstdc++-v3/ChangeLog: PR c++/116369 * include/debug/safe_base.h (_Safe_iterator_base::_M_sequence): Declare as pointer-to-const. (_Safe_iterator_base::_M_attach, _M_attach_single): New, take pointer-to-const _Safe_sequence_base. (_Safe_sequence_base::_M_detach_all, _M_detach_singular, _M_revalidate_singular) (_M_swap, _M_get_mutex): New, const qualified. (_Safe_sequence_base::_M_attach, _M_attach_single, _M_detach, _M_detach_single): const qualify. * include/debug/safe_container.h (_Safe_container<>::_M_cont): Add const qualifier. (_Safe_container<>::_M_swap_base): New. (_Safe_container(_Safe_container&&, const _Alloc&, std::false_type)): Adapt to use latter. (_Safe_container<>::operator=(_Safe_container&&)): Likewise. (_Safe_container<>::_M_swap): Likewise and take parameter as const reference. * include/debug/safe_unordered_base.h (_Safe_local_iterator_base::_M_safe_container): New. (_Safe_local_iterator_base::_Safe_local_iterator_base): Take _Safe_unordered_container_base as pointer-to-const. (_Safe_unordered_container_base::_M_attach, _M_attach_single): New, take container as _Safe_unordered_container_base pointer-to-const. (_Safe_unordered_container_base::_M_local_iterators, _M_const_local_iterators): Add mutable. (_Safe_unordered_container_base::_M_detach_all, _M_swap): New, const qualify. (_Safe_unordered_container_base::_M_attach_local, _M_attach_local_single) (_M_detach_local, _M_detach_local_single): Add const qualifier. * include/debug/safe_iterator.h (_Safe_iterator<>::_M_attach, _M_attach_single): Take _Safe_sequence_base as pointer-to-const. (_Safe_iterator<>::_M_get_sequence): Add const_cast and comment about it. * include/debug/safe_local_iterator.h (_Safe_local_iterator<>): Replace usages of _M_sequence member by _M_safe_container(). (_Safe_local_iterator<>::_M_
Re: [Patch, fortran] PR106135 - Implement F2018 IMPORT statements
Paul,
Either resolve.cc has sufficiently evolved since you
submitted your patch or the patch is somehow mangled.
When I apply it to my tree for resolve.cc, I see
Hunk #1 succeeded at 3919.
Hunk #2 succeeded at 4223.
Hunk #3 succeeded at 7940 (offset -28 lines).
Hunk #4 succeeded at 8068 (offset -28 lines).
Hunk #5 succeeded at 10752 (offset 17 lines).
Hunk #6 succeeded at 11299 with fuzz 2 (offset 276 lines).
Hmm... The next patch looks like a unified diff to me...
Hunk #5 puts
+ gfc_code *old_code = code;
into resolve_select_type().
while Hunk #6 puts this piece of code in resolve_select_rank()
+ /* Check the symbol itself. */
+
+ if (gfc_current_ns->import_state != IMPORT_NOT_SET
+ && (c->ts.type == BT_DERIVED || c->ts.type == BT_CLASS))
+ {
+ st = gfc_find_symtree (gfc_current_ns->sym_root,
+ c->ts.u.derived->name);
+ if (!check_sym_import_status (c->ts.u.derived, st, NULL, old_code,
+ gfc_current_ns))
+ error++;
+ }
Based on the error++ line, I've moved the code up into
resolve_select_type() where I believe it belongs.
--
steve
On Mon, Jun 23, 2025 at 05:43:31PM +0100, Paul Richard Thomas wrote:
> Hello All,
>
> I was mulling over the F2018 status of gfortran, when I came across the
> additions to the IMPORT statement. This seemed like such a useful addition
> to fortran that I set about an implementation; thinking that this would be
> low hanging fruit. Parsing and checking the constraints C897-8100 turned
> out to be straightforward. C8101 was already implemented for F2008 IMPORT.
> C8102 required a lot more work! (Please see the patch for the constraints.)
>
> Steve K got in touch, when he found out that we had been working in
> parallel on the new IMPORT features. Thus encouraged by our exchanges, I
> ground on until the patch reached its present state. I think that the
> ChangeLog is clear enough, even if the patch came out a bit long winded.
>
> Of the existing IMPORT tests, only import3.f90 needed modification by
> setting -std=f2008 because of the change in the wording of the error
> messages. The new test, import12.f90, is complete IMHO but I am open to
> suggestions for additions. I cannot return to working on this until the
> second week of July so you have plenty of time to test and comment.
>
> Regtests fine with x86_64 on FC42. OK for mainline?
>
> Paul
Re: [PATCH] tree-optimization/120929: Limit MEM_REF handling to .ACCESS_WITH_SIZE
On 2025-07-05 02:45, Richard Biener wrote: Am 04.07.2025 um 19:57 schrieb Siddhesh Poyarekar : On 2025-07-04 08:12, Siddhesh Poyarekar wrote: On 2025-07-04 08:08, Siddhesh Poyarekar wrote: gcc/ChangeLog: I forgot to add the PR number to the ChangeLog entries, I've fixed it in my commit message. * tree-object-size.cc (is_access_with_size): New function. (collect_object_sizes_for): Use it. gcc/testsuite/ChangeLog: * gcc.dg/pr120929.c: New test case. Testing: - x86_64 bootstrap and test, no new regressions - i686 build and test, no new regressions - ubsan config bootstrap OK My point in the PR still stands. OK, should I revert right away or can we wait till Qing returns on Monday? Thanks, Sid
Re: [PATCH] libgfortran: add fallback for trigonometric pi-based functions
On 7/6/2025 12:49 PM, Steve Kargl wrote: On Sun, Jul 06, 2025 at 08:43:06AM +0800, Yuao Ma wrote: Hi Steve, On 7/6/2025 12:25 AM, Steve Kargl wrote: On Sat, Jul 05, 2025 at 05:20:02PM +0800, Yuao Ma wrote: diff --git a/libgfortran/configure b/libgfortran/configure index 9898a94a372..971f1e9df5e 100755 --- a/libgfortran/configure +++ b/libgfortran/configure @@ -16413,7 +16413,7 @@ else We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) +#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) What is the purpose of this change? Since I don't have root/sudo permissions on my devbox, I manually downloaded and compiled the autoconf 2.69 tarball. This means there might be some minor discrepancies compared to the version shipped with OS distributions. I suspect the issue could be related to platforms where `off_t` is 32-bit, causing a left shift of 62 to result in undefined behavior. The commit at https://cgit.git.savannah.gnu.org/cgit/autoconf.git/commit/?id=a1d8293f3bfa2516f9a0424e3a6e63c2f8e93c6e seems to support my theory. This patch is not okay to commit with this change. Changing LARGE_OFF_T has nothing to do with implementing the half-cycle trig functions. Would it be possible to regenerate the configure file in a separate patch first, before we address the trig-pi patch? I believe this regeneration is a bug fix originating from autoconf 2.69, and it would be beneficial for GCC to incorporate this modification. Beyond libgfortran, libcpp and libiberty are also affected by this issue. This is indeed the direct output from my autoconf 2.69, and manually reverting parts of the generated file seems odd. Additionally, besides the LARGE_OFF_T issue, are there any other issues this patch needs to address? Yuao
Re: [PATCH] LoongArch: Fix ICE caused by _alsl_reversesi_extended.
On Sat, 2025-07-05 at 14:10 -0500, Segher Boessenkool wrote: > Hi! > > On Sat, Jul 05, 2025 at 11:10:05PM +0800, Xi Ruoyao wrote: > > Possibly this is https://gcc.gnu.org/PR101882. Specifically comment 5 > > from Segher: > > > > "The LRA change is correct AFAICS. But combine makes a change that > > violates the earlyclobber... I need to do something about that, too." > > See my comment in that PR. The loongarch machine description explicitly > allows operand 1 to be the same as operand 0. combine has notyhing to > do with this, the pattern it ended up with is recognised by recog(), > exactly as it should be (according to the pattern here, is that > "_alsl_reversesi_extended"?) We don't allow operand **4** to be same as operand 0 here, but combine makes them same :(. -- Xi Ruoyao
[pushed] wwwdocs: codingconventions: Move git.savannah.gnu.org to https
Pushed. Gerald --- htdocs/codingconventions.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html index 81bf6bbb..0bf70895 100644 --- a/htdocs/codingconventions.html +++ b/htdocs/codingconventions.html @@ -724,19 +724,19 @@ symlink-tree and ylwrap: These are copied from mainline automake, using move-if-change: gnulib hosts this now. The latest version can be retrieved from -http://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/move-if-change";>http://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/move-if-change. +https://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/move-if-change";>https://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/move-if-change. Top-level config.rpath: This comes originally from gettext, but gnulib can be considered upstream. The latest version can be retrieved from -http://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/config.rpath";>http://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/config.rpath. +https://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/config.rpath";>https://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/config.rpath. Contents should be kept in sync with relevant parts of libtool.m4 from Libtool. gcc/doc/include/texinfo.tex: This file is copied from texinfo, the latest version is at -http://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/texinfo.tex";>http://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/texinfo.tex. +https://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/texinfo.tex";>https://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/texinfo.tex. gcc/config/soft-fp: The master sources (except for t-softfp) are in git glibc, and changes should go there -- 2.50.0
Re: [PATCH] cdce: Fix non-call exceptions with signaling nans [PR120951]
> Am 05.07.2025 um 17:41 schrieb Andrew Pinski :
>
> The cdce code introduces a test for a NaN using the EQ_EXPR code.
> The problem is EQ_EXPR can cause an exception with non-call exceptions
> and signaling nans turned on. This is now correctly rejected by the verfier
> since r16-241-g4c40e3d7b9152f.
> The fix is seperate out the comparison into its own statement from the
> GIMPLE_COND.
>
> Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Ok
Richard
>PR tree-optimization/120951
>
> gcc/ChangeLog:
>
>* tree-call-cdce.cc (use_internal_fn): For non-call exceptions
>with EQ_EXPR can throw for floating point types, then create
>the EQ_EXPR seperately.
>
> gcc/testsuite/ChangeLog:
>
>* gcc.dg/torture/pr120951-1.c: New test.
>
> Signed-off-by: Andrew Pinski
> ---
> gcc/testsuite/gcc.dg/torture/pr120951-1.c | 12
> gcc/tree-call-cdce.cc | 17 +++--
> 2 files changed, 27 insertions(+), 2 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/torture/pr120951-1.c
>
> diff --git a/gcc/testsuite/gcc.dg/torture/pr120951-1.c
> b/gcc/testsuite/gcc.dg/torture/pr120951-1.c
> new file mode 100644
> index 000..4e2b41deb52
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr120951-1.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-fnon-call-exceptions -fsignaling-nans" } */
> +
> +/* PR tree-optimization/120951 */
> +
> +/* cdce would create a trapping comparison inside a condition.
> + tests to make sure that does not happen. */
> +
> +double f(double r, double i) {
> + return __builtin_fmod(r, i);
> +}
> +
> diff --git a/gcc/tree-call-cdce.cc b/gcc/tree-call-cdce.cc
> index 649c1e2b9f9..3edea754ee4 100644
> --- a/gcc/tree-call-cdce.cc
> +++ b/gcc/tree-call-cdce.cc
> @@ -36,6 +36,7 @@ along with GCC; see the file COPYING3. If not see
> #include "builtins.h"
> #include "internal-fn.h"
> #include "tree-dfa.h"
> +#include "tree-eh.h"
>
>
> /* This pass serves two closely-related purposes:
> @@ -1222,8 +1223,20 @@ use_internal_fn (gcall *call)
> {
> /* Skip the call if LHS == LHS. If we reach here, EDOM is the only
> valid errno value and it is used iff the result is NaN. */
> - conds.quick_push (gimple_build_cond (EQ_EXPR, lhs, lhs,
> - NULL_TREE, NULL_TREE));
> + /* In the case of non call exceptions, with signaling NaNs, EQ_EXPR
> + can throw an exception and that can't be part of the GIMPLE_COND. */
> + if (flag_exceptions
> + && cfun->can_throw_non_call_exceptions
> + && operation_could_trap_p (EQ_EXPR, true, false, NULL_TREE))
> +{
> + tree b = make_ssa_name (boolean_type_node);
> + conds.quick_push (gimple_build_assign (b, EQ_EXPR, lhs, lhs));
> + conds.quick_push (gimple_build_cond (NE_EXPR, b, boolean_false_node,
> + NULL_TREE, NULL_TREE));
> +}
> + else
> +conds.quick_push (gimple_build_cond (EQ_EXPR, lhs, lhs,
> + NULL_TREE, NULL_TREE));
> nconds++;
>
> /* Try replacing the original call with a direct assignment to
> --
> 2.43.0
>
Re: [PATCH] tree-cfg: Reject constants and addr on lhs for assign single [PR120921]
> Am 06.07.2025 um 02:22 schrieb Andrew Pinski :
>
> For GIMPLE_SINGLE_RHS, we don't currently test LHS for some invalid cases.
> In this case all constants and ADDR_EXPR should be invalid on the LHS.
> Also for vector (non-empty) constructors, the LHS needs to be an
> is_gimple_reg.
>
> This adds the checks.
> Also this fixes the following gimple testcase so it no longer ICEs, all
> functions are correctly rejected:
> ```
> typedef vector int vi;
>
> void __GIMPLE b1(int t) {
> 1 = t;
> }
> void __GIMPLE b2() {
> 1 = 2;
> }
> void __GIMPLE b3(int t, int t1) {
> &t1 = &t;
> }
> void __GIMPLE b4(vi t, vi t1) {
> _Literal(vi){0} = _Literal(vi){1};
> }
> void __GIMPLE b5(vi t, vi t1) {
> _Literal(vi){t} = _Literal(vi){t1};
> }
> ```
>
> Bootstrapped and tested on x86_64-linux-gnu.
Ok
Thanks,
Richard
>PR middle-end/120921
> gcc/ChangeLog:
>
>* tree-cfg.cc (verify_gimple_assign_single): Reject constant and address
> expression LHS.
>For non-empty vector constructors, make sure the LHS is an is_gimple_reg.
>
> Signed-off-by: Andrew Pinski
> ---
> gcc/tree-cfg.cc | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
> index 72763fd5a55..9a5479a2d38 100644
> --- a/gcc/tree-cfg.cc
> +++ b/gcc/tree-cfg.cc
> @@ -4623,6 +4623,14 @@ verify_gimple_assign_single (gassign *stmt)
> return true;
> }
>
> + /* LHS can't be a constant or an address expression. */
> + if (CONSTANT_CLASS_P (lhs)|| TREE_CODE (lhs) == ADDR_EXPR)
> +{
> + error ("invalid LHS (%qs) for assignment: %qs",
> + get_tree_code_name (TREE_CODE (lhs)), code_name);
> + return true;
> +}
> +
> if (gimple_clobber_p (stmt)
> && !(DECL_P (lhs) || TREE_CODE (lhs) == MEM_REF))
> {
> @@ -4745,6 +4753,11 @@ verify_gimple_assign_single (gassign *stmt)
>
> if (CONSTRUCTOR_NELTS (rhs1) == 0)
>return res;
> + if (!is_gimple_reg (lhs))
> +{
> + error ("non-register as LHS with vector constructor");
> + return true;
> +}
> /* For vector CONSTRUCTORs we require that either it is empty
> CONSTRUCTOR, or it is a CONSTRUCTOR of smaller vector elements
> (then the element count must be correct to cover the whole
> --
> 2.43.0
>
[pushed] wwwdocs: news: Move GCC Resource Center to https
Pushed. Gerald --- htdocs/news.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/news.html b/htdocs/news.html index df1a969c..f2d16c08 100644 --- a/htdocs/news.html +++ b/htdocs/news.html @@ -493,7 +493,7 @@ GCC internals documentation [2013-01-23] wwwdocs: The -http://www.cse.iitb.ac.in/grc/";>GCC Resource Center +https://www.cse.iitb.ac.in/grc/";>GCC Resource Center at IITB is providing documentation, tutorials and videos about GCC internals with support from the Government of India. -- 2.50.0
[PATCH] tree-cfg: Reject constants and addr on lhs for assign single [PR120921]
For GIMPLE_SINGLE_RHS, we don't currently test LHS for some invalid cases.
In this case all constants and ADDR_EXPR should be invalid on the LHS.
Also for vector (non-empty) constructors, the LHS needs to be an is_gimple_reg.
This adds the checks.
Also this fixes the following gimple testcase so it no longer ICEs, all
functions are correctly rejected:
```
typedef vector int vi;
void __GIMPLE b1(int t) {
1 = t;
}
void __GIMPLE b2() {
1 = 2;
}
void __GIMPLE b3(int t, int t1) {
&t1 = &t;
}
void __GIMPLE b4(vi t, vi t1) {
_Literal(vi){0} = _Literal(vi){1};
}
void __GIMPLE b5(vi t, vi t1) {
_Literal(vi){t} = _Literal(vi){t1};
}
```
Bootstrapped and tested on x86_64-linux-gnu.
PR middle-end/120921
gcc/ChangeLog:
* tree-cfg.cc (verify_gimple_assign_single): Reject constant and
address expression LHS.
For non-empty vector constructors, make sure the LHS is an
is_gimple_reg.
Signed-off-by: Andrew Pinski
---
gcc/tree-cfg.cc | 13 +
1 file changed, 13 insertions(+)
diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
index 72763fd5a55..9a5479a2d38 100644
--- a/gcc/tree-cfg.cc
+++ b/gcc/tree-cfg.cc
@@ -4623,6 +4623,14 @@ verify_gimple_assign_single (gassign *stmt)
return true;
}
+ /* LHS can't be a constant or an address expression. */
+ if (CONSTANT_CLASS_P (lhs)|| TREE_CODE (lhs) == ADDR_EXPR)
+{
+ error ("invalid LHS (%qs) for assignment: %qs",
+get_tree_code_name (TREE_CODE (lhs)), code_name);
+ return true;
+}
+
if (gimple_clobber_p (stmt)
&& !(DECL_P (lhs) || TREE_CODE (lhs) == MEM_REF))
{
@@ -4745,6 +4753,11 @@ verify_gimple_assign_single (gassign *stmt)
if (CONSTRUCTOR_NELTS (rhs1) == 0)
return res;
+ if (!is_gimple_reg (lhs))
+ {
+ error ("non-register as LHS with vector constructor");
+ return true;
+ }
/* For vector CONSTRUCTORs we require that either it is empty
CONSTRUCTOR, or it is a CONSTRUCTOR of smaller vector elements
(then the element count must be correct to cover the whole
--
2.43.0
Re: [PATCH] libgfortran: add fallback for trigonometric pi-based functions
Hi Steve, On 7/6/2025 12:25 AM, Steve Kargl wrote: On Sat, Jul 05, 2025 at 05:20:02PM +0800, Yuao Ma wrote: diff --git a/libgfortran/configure b/libgfortran/configure index 9898a94a372..971f1e9df5e 100755 --- a/libgfortran/configure +++ b/libgfortran/configure @@ -16413,7 +16413,7 @@ else We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) +#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) What is the purpose of this change? Since I don't have root/sudo permissions on my devbox, I manually downloaded and compiled the autoconf 2.69 tarball. This means there might be some minor discrepancies compared to the version shipped with OS distributions. I suspect the issue could be related to platforms where `off_t` is 32-bit, causing a left shift of 62 to result in undefined behavior. The commit at https://cgit.git.savannah.gnu.org/cgit/autoconf.git/commit/?id=a1d8293f3bfa2516f9a0424e3a6e63c2f8e93c6e seems to support my theory. Thanks, Yuao
Re: [PATCH] libgfortran: add fallback for trigonometric pi-based functions
On Sun, Jul 06, 2025 at 08:43:06AM +0800, Yuao Ma wrote: > Hi Steve, > > On 7/6/2025 12:25 AM, Steve Kargl wrote: > > On Sat, Jul 05, 2025 at 05:20:02PM +0800, Yuao Ma wrote: > > > diff --git a/libgfortran/configure b/libgfortran/configure > > > index 9898a94a372..971f1e9df5e 100755 > > > --- a/libgfortran/configure > > > +++ b/libgfortran/configure > > > @@ -16413,7 +16413,7 @@ else > > > We can't simply define LARGE_OFF_T to be 9223372036854775807, > > > since some C++ compilers masquerading as C compilers > > > incorrectly reject 9223372036854775807. */ > > > -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) > > > +#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) > > > << 31)) > > > > What is the purpose of this change? > > > > Since I don't have root/sudo permissions on my devbox, I manually downloaded > and compiled the autoconf 2.69 tarball. This means there might be some minor > discrepancies compared to the version shipped with OS distributions. > > I suspect the issue could be related to platforms where `off_t` is 32-bit, > causing a left shift of 62 to result in undefined behavior. The commit at > https://cgit.git.savannah.gnu.org/cgit/autoconf.git/commit/?id=a1d8293f3bfa2516f9a0424e3a6e63c2f8e93c6e > seems to support my theory. > This patch is not okay to commit with this change. Changing LARGE_OFF_T has nothing to do with implementing the half-cycle trig functions. -- Steve
