Re: [PATCH 12/12] testsuite, s390: fix broken dg directives
David Malcolm writes: > Found by dg-lint. > > gcc/testsuite/ChangeLog: > * gcc.target/s390/target-attribute/tattr-1.c: Fix missing trailing > close brace on dg-do directive. > * gcc.target/s390/target-attribute/tattr-2.c: Likewise. I've cherry-picked the remaining ones and resolved conflicts (sorry about that, as mentioned on IRC before, I thought you'd pushed them all) and pushed. Thanks!
[PATCH v5] libcpp: Fix incorrect line numbers in large files [PR108900]
From: Jeremy Bettis
This patch addresses an issue in the C preprocessor where incorrect
line number information is generated when processing files with a
large number of lines. The problem arises from improper handling
of location intervals in the line map, particularly when locations
exceed LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES.
By ensuring that the highest location is not decremented if it
would move to a different ordinary map, this fix resolves
the line number discrepancies observed in certain test cases.
This change improves the accuracy of line number reporting, benefiting
users relying on precise code coverage and debugging information.
libcpp/ChangeLog:
PR preprocessor/108900
* files.cc (_cpp_stack_file): Do not decrement highest_location
across distinct maps.
Signed-off-by: Jeremy Bettis
Signed-off-by: Yash Shinde
---
libcpp/files.cc | 9 +
1 file changed, 9 insertions(+)
diff --git a/libcpp/files.cc b/libcpp/files.cc
index 1ed19ca..c1abde6639f 100644
--- a/libcpp/files.cc
+++ b/libcpp/files.cc
@@ -1046,6 +1046,15 @@ _cpp_stack_file (cpp_reader *pfile, _cpp_file *file,
include_type type,
&& type < IT_DIRECTIVE_HWM
&& (pfile->line_table->highest_location
!= LINE_MAP_MAX_LOCATION - 1));
+
+ if (decrement && LINEMAPS_ORDINARY_USED (pfile->line_table))
+{
+ const line_map_ordinary *map
+ = LINEMAPS_LAST_ORDINARY_MAP (pfile->line_table);
+ if (map && map->start_location == pfile->line_table->highest_location)
+ decrement = false;
+}
+
if (decrement)
pfile->line_table->highest_location--;
--
2.43.0
Re: [committed] i386: Fix offset calculation in ix86_redzone_clobber
On Thu, Mar 27, 2025 at 11:24 PM Jakub Jelinek wrote:
>
> On Thu, Mar 27, 2025 at 09:28:31PM +0100, Uros Bizjak wrote:
> > plus_constant expects integer as its third argument, not rtx.
> >
> > gcc/ChangeLog:
> >
> > * config/i386/i386.cc (ix86_redzone_clobber): Use integer, not rtx
> > as the third argument of plus_constant.
>
> Oops, thanks for catching this.
>
> And guess we should improve the poly-int.h ctors so that it rejects mistakes
> like this, rather than doing something really weird.
>
> If I read it right, I think it was just casting the rtx (i.e. a pointer)
> to HOST_WIDE_INT:
Yes, and the resulting RTX was:
(insn:TI 6 3 12 2 (parallel [
(asm_operands/v ("#") ("") 0 []
[]
[] clob.c:3)
(clobber (mem:BLK (plus:DI (reg/f:DI 7 sp)
(const_int 139695828545120 [0x7f0d783cae60]))
[0 S128 A8]))
(clobber (reg:CC 17 flags))
instead of:
(insn:TI 6 3 12 2 (parallel [
(asm_operands/v ("#") ("") 0 []
[]
[] clob.c:3)
(clobber (mem:BLK (plus:DI (reg/f:DI 7 sp)
(const_int -128 [0xff80])) [0 S128 A8]))
(clobber (reg:CC 17 flags))
Uros.
Re: [PATCH] Further use of mod_scope in modified_type_die
On Thu, Mar 27, 2025 at 5:31 PM Tom Tromey wrote: > > > "Richard" == Richard Biener writes: > > Sorry about the delay on this. > > >> - mod_type_die = subrange_type_die (type, low, high, bias, > >> context_die); > >> + mod_type_die = subrange_type_die (type, low, high, bias, mod_scope); > > Richard> that looks good. But why not for the ARRAY_TYPE case dircetly > Richard> above? > > I think I just didn't happen to need it. > > I can make this change if you think it's desirable. I think so, for consistency. > >> - add_child_die_after (comp_unit_die (), mod_type_die, after_die); > >> + add_child_die_after (mod_scope, mod_type_die, after_die); > > Richard> For the next DW_AT_endianity there's an assert for the correct > Richard> placement but not here So I'm not positive this change is > Richard> according to the comment. In fact we're realing with base-type > Richard> DIEs here, and those are usually directly at comp_unit_die (), > Richard> no? > > In C/C++, I think base types are normally only emitted at comp-unit > scope. > > Ada (with my patches that are still in progress) may emit base types > that have a different scope. For a type like: > > package body Pck is >type My_Other_Int is mod 2**8; > > <1><9a>: Abbrev Number: 1 (DW_TAG_base_type) > <9b> DW_AT_byte_size : 1 > <9c> DW_AT_encoding: 7(unsigned) > <9d> DW_AT_name: (indirect string, offset: 0xf): > pck__my_other_int > > This is the "encoded" (non-hierarchical) form, which is why it's > currently a child of the CU DIE and why that "pkg__" prefix is in there. > > My patches will change this to emit a DW_TAG_module named "pck" that > contains a base type named "my_other_int". Let's involve Eric here, I have no idea what was intended here. Richard. > > thanks, > Tom
Re: [PATCH] ipa-sra: Don't change return type to void if there are musttail calls [PR119484]
On Thu, 27 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is rejected, because IPA-SRA decides to
> turn bar.constprop call into bar.constprop.isra which returns void.
> While there is no explicit lhs on the call, as it is a musttail call
> the tailc pass checks if IPA-VRP returns singleton from that function
> and the function returns the same value and in that case it still turns
> it into a tail call. This can't work with IPA-SRA changing it into
> void returning function though.
>
> The following patch fixes this by forcing returning the original type
> if there are musttail calls.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
LGTM.
Richard.
> 2025-03-27 Jakub Jelinek
>
> PR ipa/119484
> * ipa-sra.cc (isra_analyze_call): Don't set m_return_ignored if
> gimple_call_must_tail_p even if it doesn't have lhs.
>
> * c-c++-common/pr119484.c: New test.
>
> --- gcc/ipa-sra.cc.jj 2025-03-01 09:13:17.736075042 +0100
> +++ gcc/ipa-sra.cc2025-03-27 14:23:43.884552767 +0100
> @@ -2242,7 +2242,11 @@ isra_analyze_call (cgraph_edge *cs)
> BITMAP_FREE (analyzed);
> }
> }
> - else
> + /* Don't set m_return_ignored for musttail calls. The tailc/musttail
> passes
> + compare the returned value against the IPA-VRP return value range if
> + it is a singleton, but if the call is changed to something which doesn't
> + return anything, it will always fail. */
> + else if (!gimple_call_must_tail_p (call_stmt))
> csum->m_return_ignored = true;
> }
>
> --- gcc/testsuite/c-c++-common/pr119484.c.jj 2025-03-27 14:30:32.988976396
> +0100
> +++ gcc/testsuite/c-c++-common/pr119484.c 2025-03-27 14:31:17.074375485
> +0100
> @@ -0,0 +1,21 @@
> +/* PR ipa/119484 */
> +/* { dg-do compile { target musttail } } */
> +/* { dg-options "-O2 -fdump-tree-optimized" } */
> +/* { dg-final { scan-tree-dump-times "bar\[.a-z0-9]* \\\(\[^\n\r]*\\\);
> \\\[tail call\\\] \\\[must tail call\\\]" 1 "optimized" } } */
> +
> +void foo (int);
> +
> +[[gnu::noinline]] static int
> +bar (int x)
> +{
> + foo (x);
> + return 0;
> +}
> +
> +int
> +baz (int x)
> +{
> + if (x == 1)
> +[[gnu::musttail]] return bar (x);
> + return 0;
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
[pushed] wwwdocs: cxx-dr-status: Use over
My validator flagged this. Modern HTML avoid physical markup like , and is a good fit here. Pushed. Gerald --- htdocs/projects/cxx-dr-status.html | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/htdocs/projects/cxx-dr-status.html b/htdocs/projects/cxx-dr-status.html index 6ff9497c..e794734c 100644 --- a/htdocs/projects/cxx-dr-status.html +++ b/htdocs/projects/cxx-dr-status.html @@ -20209,7 +20209,7 @@ https://wg21.link/cwg2882";>2882 DRWP - Unclear treatment of conversion to void + Unclear treatment of conversion to void ? @@ -20286,7 +20286,7 @@ https://wg21.link/cwg2893";>2893 NAD - Instantiations in discarded if constexpr substatements + Instantiations in discarded if constexpr substatements ? @@ -20321,7 +20321,7 @@ https://wg21.link/cwg2898";>2898 open - Clarify implicit conversion sequence from cv T to T + Clarify implicit conversion sequence from cv T to T - @@ -20349,14 +20349,14 @@ https://wg21.link/cwg2902";>2902 review - Implicit this transformation outside of permitted contexts + Implicit this transformation outside of permitted contexts ? https://wg21.link/cwg2903";>2903 drafting - Can we omit the template disambiguator in nested-name-specifiers in type-only contexts? + Can we omit the template disambiguator in nested-name-specifiers in type-only contexts? - @@ -20384,14 +20384,14 @@ https://wg21.link/cwg2907";>2907 DR - Constant lvalue-to-rvalue conversion on uninitialized std::nullptr_t + Constant lvalue-to-rvalue conversion on uninitialized std::nullptr_t ? https://wg21.link/cwg2908";>2908 DR - Counting physical source lines for __LINE__ + Counting physical source lines for __LINE__ ? @@ -20440,14 +20440,14 @@ https://wg21.link/cwg2915";>2915 DR - Explicit object parameters of type void + Explicit object parameters of type void ? https://wg21.link/cwg2916";>2916 review - Variable template partial specializations should not be declared static + Variable template partial specializations should not be declared static ? @@ -20475,7 +20475,7 @@ https://wg21.link/cwg2920";>2920 open - The template keyword for base classes + The template keyword for base classes - @@ -20524,7 +20524,7 @@ https://wg21.link/cwg2927";>2927 DR - Unclear status of translation unit with module keyword + Unclear status of translation unit with module keyword ? @@ -20573,7 +20573,7 @@ https://wg21.link/cwg2934";>2934 open - Unclear semantics of exception escaping from unhandled_exception + Unclear semantics of exception escaping from unhandled_exception - @@ -20608,7 +20608,7 @@ https://wg21.link/cwg2939";>2939 DR - Do not allow reinterpret_cast from prvalue to rvalue reference + Do not allow reinterpret_cast from prvalue to rvalue reference ? @@ -20797,7 +20797,7 @@ https://wg21.link/cwg2966";>2966 open - Alignment and value representation of std::nullptr_t + Alignment and value representation of std::nullptr_t - @@ -20825,7 +20825,7 @@ https://wg21.link/cwg2970";>2970 open - Races with volatile sig_atomic_t bit-fields + Races with volatile sig_atomic_t bit-fields - -- 2.48.1
[COMMITTED 096/144] gccrs: imports: Create ImportData class and use it in import_mappings
From: Arthur Cohen
gcc/rust/ChangeLog:
* resolve/rust-early-name-resolver-2.0.cc (Early::resolve_glob_import):
Use ImportData class.
(Early::resolve_simple_import): Likewise.
(Early::resolve_rebind_import): Likewise.
(Early::build_import_mapping): Likewise.
* resolve/rust-early-name-resolver-2.0.h: Likewise.
* resolve/rust-finalize-imports-2.0.cc (finalize_simple_import):
Likewise.
(finalize_glob_import): Likewise.
(finalize_rebind_import): Likewise.
(FinalizeImports::go): Likewise.
* resolve/rust-finalize-imports-2.0.h: Likewise.
* resolve/rust-name-resolution-context.h: Likewise.
* resolve/rust-rib.h: Define ImportData class.
---
.../resolve/rust-early-name-resolver-2.0.cc | 91 +++
.../resolve/rust-early-name-resolver-2.0.h| 37 +++-
gcc/rust/resolve/rust-finalize-imports-2.0.cc | 35 ---
gcc/rust/resolve/rust-finalize-imports-2.0.h | 6 +-
.../resolve/rust-name-resolution-context.h| 27 ++
gcc/rust/resolve/rust-rib.h | 2 +-
6 files changed, 102 insertions(+), 96 deletions(-)
diff --git a/gcc/rust/resolve/rust-early-name-resolver-2.0.cc
b/gcc/rust/resolve/rust-early-name-resolver-2.0.cc
index 41d0a075bbb..ba73a54d412 100644
--- a/gcc/rust/resolve/rust-early-name-resolver-2.0.cc
+++ b/gcc/rust/resolve/rust-early-name-resolver-2.0.cc
@@ -83,7 +83,8 @@ Early::resolve_glob_import (TopLevel::ImportKind &&glob)
// here, we insert the module's NodeId into the import_mappings and will look
// up the module proper in `FinalizeImports`
- import_mappings.insert ({std::move (glob), resolved->get_node_id ()});
+ // The namespace does not matter here since we are dealing with a glob
+ import_mappings.insert ({std::move (glob), ImportData::Glob (*resolved)});
return true;
}
@@ -91,89 +92,21 @@ Early::resolve_glob_import (TopLevel::ImportKind &&glob)
bool
Early::resolve_simple_import (TopLevel::ImportKind &&import)
{
- // TODO: Fix documentation - the function has changed slightly
-
- const auto &path = import.to_resolve;
- // auto locus = path.get_final_segment ().get_locus ();
- // auto declared_name = path.get_final_segment ().as_string ();
-
- // In that function, we only need to declare a new definition - the use path.
- // the resolution needs to happpen in the EarlyNameResolver. So the
- // definitions we'll add will be the path's NodeId - that makes sense, as we
- // need one definition per path declared in a Use tree. so all good.
- // alright, now in what namespace do we declare them? all of them? do we only
- // declare them in the EarlyNameResolver? this is dodgy
-
- // in what namespace do we perform path resolution? All of them? see which
one
- // matches? Error out on ambiguities?
- // so, apparently, for each one that matches, add it to the proper namespace
- // :(
-
- return ctx.values.resolve_path (path.get_segments ())
-.or_else ([&] () { return ctx.types.resolve_path (path.get_segments ()); })
-.or_else ([&] () { return ctx.macros.resolve_path (path.get_segments ());
})
-.map ([&] (Rib::Definition def) {
- import_mappings.insert ({std::move (import), def.get_node_id ()});
+ return ctx.resolve_path (import.to_resolve)
+.map ([&] (std::pair def_ns) {
+ import_mappings.insert (
+ {std::move (import), ImportData::Simple (def_ns)});
})
.has_value ();
-
- //switch (ns)
- // {
- // case Namespace::Values:
- // resolved = ctx.values.resolve_path (path.get_segments ());
- // break;
- // case Namespace::Types:
- // resolved = ctx.types.resolve_path (path.get_segments ());
- // break;
- // case Namespace::Macros:
- // resolved = ctx.macros.resolve_path (path.get_segments ());
- // break;
- // case Namespace::Labels:
- // // TODO: Is that okay?
- // rust_unreachable ();
- // }
-
- // FIXME: Ugly
- // (void) resolved.map ([this, &found, path, import] (Rib::Definition
- // def) {
- // found = true;
-
- // import_mappings.insert ({std::move (import), def.get_node_id
- // ()});
-
- // // what do we do with the id?
- // // insert_or_error_out (declared_name, locus, def.get_node_id (),
- // // ns); auto result = node_forwarding.find (def.get_node_id ());
- // if
- // // (result != node_forwarding.cend ()
- // // && result->second != path.get_node_id ())
- // // rust_error_at (path.get_locus (), "%qs defined multiple
- // times",
- // //declared_name.c_str ());
- // // else // No previous thing has inserted this into our scope
- // // node_forwarding.insert ({def.get_node_id (),
- // path.get_node_id
- // // ()});
-
- // return def.get_node_id ();
- // });
- // };
-
- // resolve_and_insert (path);
-
- // return found;
}
bool
Early::resolve_rebind_import (TopLevel::ImportKind &&rebind_import)
{
- auto &path
Re: [PATCH] testsuite: aarch64: fix another unbalanced }
On 27/03/2025 15:37, Sam James wrote:
In r15-8956-ge90d6c2639c392, I missed one, so while it did fix a problem,
it also exposed another because the braces were now unbalanced.
There's IMO more to do here with ideally whitespace before the } when
using scan-assembler-times but let's do that later.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/atomic-inst-ldlogic.c: Add another closing brace.
OK.
---
Pushed.
gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c
b/gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c
index 1927ebc10e28..11f9bfe7194b 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c
@@ -145,7 +145,7 @@ TEST (xor_load_notreturn, XOR_LOAD_NORETURN)
/* { dg-final { scan-assembler-times "ldeorlh\t" 8} } */
/* { dg-final { scan-assembler-times "ldeoralh\t" 16} } */
-/* { dg-final { scan-assembler-times "ldeor\t" 16} */
+/* { dg-final { scan-assembler-times "ldeor\t" 16} } */
/* { dg-final { scan-assembler-times "ldeora\t" 32} } */
/* { dg-final { scan-assembler-times "ldeorl\t" 16} } */
/* { dg-final { scan-assembler-times "ldeoral\t" 32} } */
Re: [PATCH] [COBOL] use native_encode_real
On Fri, 28 Mar 2025, Jakub Jelinek wrote:
> On Fri, Mar 28, 2025 at 08:54:53AM +0100, Richard Biener wrote:
> > The following avoids the round-trip through a newly built tree and
> > instead directly uses the now exported native_encode_real.
> >
> > Tested on x86_64-unknown-linux-gnu.
> >
> > OK?
> >
> > gcc/cobol/
> > * genapi.cc (initial_from_float128): Use native_encode_real.
>
> LGTM.
Will push later.
> Note, we still have at least
> /* ??? Use native_encode_* below. */
> retval = (char *)xmalloc(field->data.capacity);
> switch(field->data.capacity)
> {
> case 1:
> *(signed char *)retval = (signed char)i.slow ();
> break;
> case 2:
> *(signed short *)retval = (signed short)i.slow ();
> break;
> case 4:
> *(signed int *)retval = (signed int)i.slow ();
> break;
> case 8:
> *(signed long *)retval = (signed long)i.slow ();
> break;
> case 16:
> *(unsigned long *)retval = (unsigned long)i.ulow ();
> *((signed long *)retval + 1) = (signed long)i.shigh ();
> break;
> that needs some endian handling (and is also wrong for
> hosts which don't have 1 byte chars, 2 byte shorts, 4 byte ints
> and 8 byte longs), dunno if we want a round-trip through wide_int_to_tree
> and native_encode_expr in that case or if we do similar hack with exporting
> native_encode_int's helper or native_encode_int itself which will accept
> wide_int + type rather than tree.
IMO exporting a native_encode_wide would be nice.
> And I'm sure trying to do a cross from powerpc-linux to x86_64-linux
> will show up tons of other problems.
For sure.
Richard.
Re: [PATCH] Fortran: fix spelling of flag -fallow-invalid-boz
Am 28.03.25 um 20:35 schrieb Harald Anlauf: Dear all, I am going to commit the attached patch as obvious. Pushed as r15-9016-gfb132276d17390. Harald
Re: [PATCH] cobol: Fix up cobol/{charmaps,valconv}.cc rules
Hi Bob
note that the sed -i does not work on Darwin’s BDS-derived sed without also
using ‘-e’ to inroduce the scripts… so I am looking for a solution we all like
too.
> On 28 Mar 2025, at 16:40, Robert Dubner wrote:
>
> I am not fully following what's going on.
>
> The way this grew is because Jim and I once had a solution in Make-lang.in
> that put a "-I ../libgcobol" into CPPFLAGS.
>
> Then it turned out I couldn't use CPPFLAGS, because it wasn't available on
> all architectures.
>
> But I nonetheless needed to use valconv.cc and charmaps.cc in both
> libgcobol and gcc/cobol. So I copied them to the build directory. Then
> it turned out that compilations have to be possible on read-only file
> systems. And the various cdf.y parse.y and scan.l builds cause .cc files
> to be created in the build directory.
>
> But I don't know where the build directory is, so I couldn't statically
> establish the relative path to libgcobol in those source code modules.
>
> So, I didn't know how to set -I, and I didn't know where the build
> directory is, so I came up with the SED solution. It was hateful, and Jim
> and I had words about it, but I did it to be able to keep going. (You may
> have noted that I have a "keep going" ethic.)
>
> If there is a solution whereby the gcc/cobol build process can have a "-I
> $(srcdir)/../libgcobol" established, then by all means, we should do so.
> I just wasn't able figure out how to do it.
1) An alternate solution is to rename the actual content “valconv.inc” and
“charmaps.inc” and to include it explicitly from the two use sites. That
makes the intent clear - and allows all the paths to be defined at commit-
time (i.e. no violation of read-only source trees)
2) It is also possible to do
CFLAGS-xxx.o: -I
for each source that needs the libgcobol includes …
Which is still repetitive perhaps but more readable than the sed, but does
not solve the copying part.
I do have sympathy for the idea that the actual paths should be readable
in the source that the user deals with - it makes intentions clear.
Iain
>
>
>> -Original Message-
>> From: Jakub Jelinek
>> Sent: Friday, March 28, 2025 10:40
>> To: Robert Dubner ; James K. Lowden
>> ; Richard Biener
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: [PATCH] cobol: Fix up cobol/{charmaps,valconv}.cc rules
>>
>> Hi!
>>
>> sed -i is not portable, it is supported by GNU sed and perhaps some
> BSDs,
>> but not elsewhere.
>> Furthermore, I think it is far better to always use
>> #include "../../libgcobol/something.h"
>> paths rather than something depending on the build directory.
>> And because we require GNU make, we don't have to have two different
>> rules for those, can use just one for both.
>> The l variable in there is just to make it fit into 80 columns.
>>
>> Ok for trunk?
>>
>> 2025-03-28 Jakub Jelinek
>>
>> * Make-lang.in (cobol/charmaps.cc, cobol/valconv.cc): Used sed -e
>> instead of cp and multiple sed -i commands. Always prefix
> libgcobol
>> header names in #include directives with ../../libgcobol/ rather
>> than
>> something depending on $(LIB_SOURCE).
>>
>> --- gcc/cobol/Make-lang.in.jj2025-03-28 15:08:29.431543005 +0100
>> +++ gcc/cobol/Make-lang.in 2025-03-28 15:31:14.886182633 +0100
>> @@ -87,29 +87,10 @@ cobol1_OBJS =\
>> # Various #includes in the files copied from gcc/libgcobol need to be
>> modified
>> # so that the .h files can be found.
>>
>> -cobol/charmaps.cc: $(LIB_SOURCE)/charmaps.cc
>> -cp $^ $@
>> -sed -i "s|\"ec[.]h\"|\"$(LIB_SOURCE)/ec.h\"|g" $@
>> -sed -i "s|\"common-defs[.]h\"|\"$(LIB_SOURCE)/common-defs.h\"|g"
> $@
>> -sed -i "s|\"io[.]h\"|\"$(LIB_SOURCE)/io.h\"|g" $@
>> -sed -i "s|\"gcobolio[.]h\"|\"$(LIB_SOURCE)/gcobolio.h\"|g" $@
>> -sed -i "s|\"libgcobol[.]h\"|\"$(LIB_SOURCE)/libgcobol.h\"|g" $@
>> -sed -i "s|\"gfileio[.]h\"|\"$(LIB_SOURCE)/gfileio.h\"|g" $@
>> -sed -i "s|\"charmaps[.]h\"|\"$(LIB_SOURCE)/charmaps.h\"|g" $@
>> -sed -i "s|\"valconv[.]h\"|\"$(LIB_SOURCE)/valconv.h\"|g" $@
>> -sed -i "s|\"exceptl[.]h\"|\"$(LIB_SOURCE)/exceptl.h\"|g" $@
>> -
>> -cobol/valconv.cc: $(LIB_SOURCE)/valconv.cc
>> -cp $^ $@
>> -sed -i "s|\"ec[.]h\"|\"$(LIB_SOURCE)/ec.h\"|g" $@
>> -sed -i "s|\"common-defs[.]h\"|\"$(LIB_SOURCE)/common-defs.h\"|g"
> $@
>> -sed -i "s|\"io[.]h\"|\"$(LIB_SOURCE)/io.h\"|g" $@
>> -sed -i "s|\"gcobolio[.]h\"|\"$(LIB_SOURCE)/gcobolio.h\"|g" $@
>> -sed -i "s|\"libgcobol[.]h\"|\"$(LIB_SOURCE)/libgcobol.h\"|g" $@
>> -sed -i "s|\"gfileio[.]h\"|\"$(LIB_SOURCE)/gfileio.h\"|g" $@
>> -sed -i "s|\"charmaps[.]h\"|\"$(LIB_SOURCE)/charmaps.h\"|g" $@
>> -sed -i "s|\"valconv[.]h\"|\"$(LIB_SOURCE)/valconv.h\"|g" $@
>> -sed -i "s|\"exceptl[.]h\"|\"$(LIB_SOURCE)/exceptl.h\"|g" $@
>> +cobol/charmaps.cc cobol/valconv.cc: cobol/%.cc: $(LIB_SOURCE)/%.cc
>> +-l='ec\|common-defs\|io\|gcobolio\|libgcobol\|gfileio\|charmaps';
> \
>> +l=$$l'\|valcon
[COMMITTED 103/144] gccrs: Loop on expansion if a new export has been defined
From: Pierre-Emmanuel Patry
When a use statement requires a reexported item it cannot find it in
the same pass, an additional pass shall be performed. This means we need
to detect whether a new item has been reexported and resolve until the
end.
gcc/rust/ChangeLog:
* resolve/rust-early-name-resolver-2.0.cc (Early::Early): Add dirty
flag initialization.
(Early::go): Set dirty flag using top level resolver.
* resolve/rust-early-name-resolver-2.0.h: Add dirty flag.
* resolve/rust-toplevel-name-resolver-2.0.cc (TopLevel::TopLevel):
Initialize dirty flag.
(TopLevel::insert_or_error_out): Set dirty flag on successful
namespace modification.
* resolve/rust-toplevel-name-resolver-2.0.h: Add dirty flag.
* rust-session-manager.cc (Session::expansion): Modify fixed point
condition to include name resolution modifications.
Signed-off-by: Pierre-Emmanuel Patry
---
gcc/rust/resolve/rust-early-name-resolver-2.0.cc| 4 +++-
gcc/rust/resolve/rust-early-name-resolver-2.0.h | 4
gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc | 7 ---
gcc/rust/resolve/rust-toplevel-name-resolver-2.0.h | 6 ++
gcc/rust/rust-session-manager.cc| 5 -
5 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/gcc/rust/resolve/rust-early-name-resolver-2.0.cc
b/gcc/rust/resolve/rust-early-name-resolver-2.0.cc
index c4f9b27e297..55330487fd7 100644
--- a/gcc/rust/resolve/rust-early-name-resolver-2.0.cc
+++ b/gcc/rust/resolve/rust-early-name-resolver-2.0.cc
@@ -26,7 +26,8 @@
namespace Rust {
namespace Resolver2_0 {
-Early::Early (NameResolutionContext &ctx) : DefaultResolver (ctx) {}
+Early::Early (NameResolutionContext &ctx) : DefaultResolver (ctx), dirty
(false)
+{}
void
Early::insert_once (AST::MacroInvocation &invocation, NodeId resolved)
@@ -61,6 +62,7 @@ Early::go (AST::Crate &crate)
// Once this is done, we finalize their resolution
FinalizeImports (std::move (import_mappings), toplevel, ctx).go (crate);
+ dirty = toplevel.is_dirty ();
// We now proceed with resolving macros, which can be nested in almost any
// items
textual_scope.push ();
diff --git a/gcc/rust/resolve/rust-early-name-resolver-2.0.h
b/gcc/rust/resolve/rust-early-name-resolver-2.0.h
index ec1d914c05d..a7ad0f78fb8 100644
--- a/gcc/rust/resolve/rust-early-name-resolver-2.0.h
+++ b/gcc/rust/resolve/rust-early-name-resolver-2.0.h
@@ -34,9 +34,13 @@ class Early : public DefaultResolver
{
using DefaultResolver::visit;
+ bool dirty;
+
public:
Early (NameResolutionContext &ctx);
+ bool is_dirty () { return dirty; }
+
void go (AST::Crate &crate);
const std::vector &get_macro_resolve_errors () const
diff --git a/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc
b/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc
index 47f3adee14c..6a54978a67c 100644
--- a/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc
+++ b/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc
@@ -27,7 +27,7 @@ namespace Rust {
namespace Resolver2_0 {
TopLevel::TopLevel (NameResolutionContext &resolver)
- : DefaultResolver (resolver)
+ : DefaultResolver (resolver), dirty (false)
{}
template
@@ -47,8 +47,9 @@ TopLevel::insert_or_error_out (const Identifier &identifier,
node_locations.emplace (node_id, locus);
auto result = ctx.insert (identifier, node_id, ns);
-
- if (!result && result.error ().existing != node_id)
+ if (result)
+dirty = true;
+ else if (result.error ().existing != node_id)
{
rich_location rich_loc (line_table, locus);
rich_loc.add_range (node_locations[result.error ().existing]);
diff --git a/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.h
b/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.h
index acb60d36e13..99ed65398c6 100644
--- a/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.h
+++ b/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.h
@@ -43,6 +43,8 @@ public:
void go (AST::Crate &crate);
+ bool is_dirty () { return dirty; }
+
// Each import will be transformed into an instance of `ImportKind`, a class
// representing some of the data we need to resolve in the
// `EarlyNameResolver`. Basically, for each `UseTree` that we see in
@@ -129,6 +131,10 @@ public:
Namespace ns);
private:
+ // If a new export has been defined whilst visiting the visitor is considered
+ // dirty
+ bool dirty;
+
// FIXME: Do we move these to our mappings?
std::unordered_map node_locations;
diff --git a/gcc/rust/rust-session-manager.cc b/gcc/rust/rust-session-manager.cc
index a5cd97f18d7..5668d4d65d3 100644
--- a/gcc/rust/rust-session-manager.cc
+++ b/gcc/rust/rust-session-manager.cc
@@ -928,18 +928,21 @@ Session::expansion (AST::Crate &crate,
Resolver2_0::NameResolutionContext &ctx)
if (saw_errors ())
break;
+ bool visitor_dirty = false;
+
if (flag_name_resolution_2_0)
{
RE: [PATCH] cobol: Fix up cobol/{charmaps,valconv}.cc rules
I am not fully following what's going on.
The way this grew is because Jim and I once had a solution in Make-lang.in
that put a "-I ../libgcobol" into CPPFLAGS.
Then it turned out I couldn't use CPPFLAGS, because it wasn't available on
all architectures.
But I nonetheless needed to use valconv.cc and charmaps.cc in both
libgcobol and gcc/cobol. So I copied them to the build directory. Then
it turned out that compilations have to be possible on read-only file
systems. And the various cdf.y parse.y and scan.l builds cause .cc files
to be created in the build directory.
But I don't know where the build directory is, so I couldn't statically
establish the relative path to libgcobol in those source code modules.
So, I didn't know how to set -I, and I didn't know where the build
directory is, so I came up with the SED solution. It was hateful, and Jim
and I had words about it, but I did it to be able to keep going. (You may
have noted that I have a "keep going" ethic.)
If there is a solution whereby the gcc/cobol build process can have a "-I
$(srcdir)/../libgcobol" established, then by all means, we should do so.
I just wasn't able figure out how to do it.
> -Original Message-
> From: Jakub Jelinek
> Sent: Friday, March 28, 2025 10:40
> To: Robert Dubner ; James K. Lowden
> ; Richard Biener
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PATCH] cobol: Fix up cobol/{charmaps,valconv}.cc rules
>
> Hi!
>
> sed -i is not portable, it is supported by GNU sed and perhaps some
BSDs,
> but not elsewhere.
> Furthermore, I think it is far better to always use
> #include "../../libgcobol/something.h"
> paths rather than something depending on the build directory.
> And because we require GNU make, we don't have to have two different
> rules for those, can use just one for both.
> The l variable in there is just to make it fit into 80 columns.
>
> Ok for trunk?
>
> 2025-03-28 Jakub Jelinek
>
> * Make-lang.in (cobol/charmaps.cc, cobol/valconv.cc): Used sed -e
> instead of cp and multiple sed -i commands. Always prefix
libgcobol
> header names in #include directives with ../../libgcobol/ rather
> than
> something depending on $(LIB_SOURCE).
>
> --- gcc/cobol/Make-lang.in.jj 2025-03-28 15:08:29.431543005 +0100
> +++ gcc/cobol/Make-lang.in2025-03-28 15:31:14.886182633 +0100
> @@ -87,29 +87,10 @@ cobol1_OBJS =\
> # Various #includes in the files copied from gcc/libgcobol need to be
> modified
> # so that the .h files can be found.
>
> -cobol/charmaps.cc: $(LIB_SOURCE)/charmaps.cc
> - cp $^ $@
> - sed -i "s|\"ec[.]h\"|\"$(LIB_SOURCE)/ec.h\"|g" $@
> - sed -i "s|\"common-defs[.]h\"|\"$(LIB_SOURCE)/common-defs.h\"|g"
$@
> - sed -i "s|\"io[.]h\"|\"$(LIB_SOURCE)/io.h\"|g" $@
> - sed -i "s|\"gcobolio[.]h\"|\"$(LIB_SOURCE)/gcobolio.h\"|g" $@
> - sed -i "s|\"libgcobol[.]h\"|\"$(LIB_SOURCE)/libgcobol.h\"|g" $@
> - sed -i "s|\"gfileio[.]h\"|\"$(LIB_SOURCE)/gfileio.h\"|g" $@
> - sed -i "s|\"charmaps[.]h\"|\"$(LIB_SOURCE)/charmaps.h\"|g" $@
> - sed -i "s|\"valconv[.]h\"|\"$(LIB_SOURCE)/valconv.h\"|g" $@
> - sed -i "s|\"exceptl[.]h\"|\"$(LIB_SOURCE)/exceptl.h\"|g" $@
> -
> -cobol/valconv.cc: $(LIB_SOURCE)/valconv.cc
> - cp $^ $@
> - sed -i "s|\"ec[.]h\"|\"$(LIB_SOURCE)/ec.h\"|g" $@
> - sed -i "s|\"common-defs[.]h\"|\"$(LIB_SOURCE)/common-defs.h\"|g"
$@
> - sed -i "s|\"io[.]h\"|\"$(LIB_SOURCE)/io.h\"|g" $@
> - sed -i "s|\"gcobolio[.]h\"|\"$(LIB_SOURCE)/gcobolio.h\"|g" $@
> - sed -i "s|\"libgcobol[.]h\"|\"$(LIB_SOURCE)/libgcobol.h\"|g" $@
> - sed -i "s|\"gfileio[.]h\"|\"$(LIB_SOURCE)/gfileio.h\"|g" $@
> - sed -i "s|\"charmaps[.]h\"|\"$(LIB_SOURCE)/charmaps.h\"|g" $@
> - sed -i "s|\"valconv[.]h\"|\"$(LIB_SOURCE)/valconv.h\"|g" $@
> - sed -i "s|\"exceptl[.]h\"|\"$(LIB_SOURCE)/exceptl.h\"|g" $@
> +cobol/charmaps.cc cobol/valconv.cc: cobol/%.cc: $(LIB_SOURCE)/%.cc
> + -l='ec\|common-defs\|io\|gcobolio\|libgcobol\|gfileio\|charmaps';
\
> + l=$$l'\|valconv\|exceptl'; \
> + sed -e '/^#include/s,"\('$$l'\)\.h","../../libgcobol/\1.h",' $^ >
$@
>
> LIB_SOURCE_H=$(wildcard $(LIB_SOURCE)/*.h)
>
>
> Jakub
[committed] Regenerate common.opt.urls
Hi! The r15-8947 commit has not regenerate-opt-urls. Here is a fix for that, committed to trunk as obvious. 2025-03-28 Jakub Jelinek * common.opt.urls: Regenerate. --- gcc/common.opt.urls.jj +++ gcc/common.opt.urls @@ -289,6 +289,12 @@ UrlSuffix(gcc/Warning-Options.html#index-Wcoverage-invalid-line-number) Wcoverage-too-many-conditions UrlSuffix(gcc/Warning-Options.html#index-Wcoverage-too-many-conditions) +fpath-coverage-limit= +UrlSuffix(gcc/Instrumentation-Options.html#index-fpath-coverage-limit) + +Wcoverage-too-many-paths +UrlSuffix(gcc/Warning-Options.html#index-Wcoverage-too-many-paths) + Wmissing-profile UrlSuffix(gcc/Warning-Options.html#index-Wmissing-profile) @@ -1037,6 +1043,9 @@ UrlSuffix(gcc/Optimize-Options.html#index-foptimize-crc) foptimize-sibling-calls UrlSuffix(gcc/Optimize-Options.html#index-foptimize-sibling-calls) +fpath-coverage +UrlSuffix(gcc/Instrumentation-Options.html#index-fpath-coverage) + fpartial-inlining UrlSuffix(gcc/Optimize-Options.html#index-fpartial-inlining) Jakub
[PATCH v3] c++: fix reporting routines re-entered [PR119303]
On Fri, Mar 28, 2025 at 11:49:48AM -0400, Jason Merrill wrote:
> On 3/27/25 5:00 PM, Marek Polacek wrote:
> > On Wed, Mar 19, 2025 at 12:00:00PM -0400, Jason Merrill wrote:
> > > On 3/17/25 6:55 PM, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > >
> > > > -- >8 --
> > > > We crash while we call warning_at ("inline function used but never
> > > > defined")
> > > > since it invokes dump_template_bindings -> tsubst -> ... ->
> > > > convert_like ->
> > > > ... -> c_common_truthvalue_conversion -> warning_at ("enum constant in
> > > > boolean
> > > > context")
> > > >
> > > > cp_truthvalue_conversion correctly gets complain=0 but it calls
> > > > c_common_truthvalue_conversion from c-family which doesn't have
> > > > a similar parameter.
> > >
> > > It seems that we try to prevent this in cp_convert_and_check with
> > >
> > >warning_sentinel c (warn_int_in_bool_context);
> > >
> > > which is why we don't get a warning when we first instantiate the
> > > template.
> > >
> > > But that doesn't help when we rebuild the expression for
> > > dump_template_bindings because the recursion check in report_diagnostic
> > > comes before the check whether the diagnostic is actually enabled.
> > >
> > > I think rather than adding another mechanism for suppressing warnings, I'd
> > > like to make the existing ones work better by moving the recursion check
> > > after the checks for disabled diagnostics.
> >
> > Fair enough. That happens to fix c++/116960 et al too. Note that my
> > adding a complain parameter into c-family isn't entirely novel:
> > c_sizeof_or_alignof_type also has one.
> >
> >
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > We crash while we call warning_at ("inline function used but never defined")
> > since it invokes dump_template_bindings -> tsubst -> ... -> convert_like ->
> > ... -> c_common_truthvalue_conversion -> warning_at ("enum constant in
> > boolean
> > context")
> >
> > cp_truthvalue_conversion correctly gets complain=0 but it calls
> > c_common_truthvalue_conversion from c-family which doesn't have
> > a similar parameter.
> >
> > We can fix this by tweaking diagnostic_context::report_diagnostic to
> > check for recursion after checking if the diagnostic was enabled.
> >
> > PR c++/116960
> > PR c++/119303
> >
> > gcc/ChangeLog:
> >
> > * diagnostic.cc (diagnostic_context::report_diagnostic): Check for
> > non-zero m_lock only after diagnostic_enabled.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/cpp2a/lambda-uneval26.C: New test.
> > * g++.dg/warn/undefined2.C: New test.
> > ---
> > gcc/diagnostic.cc| 24 ++--
> > gcc/testsuite/g++.dg/cpp2a/lambda-uneval26.C | 10
> > gcc/testsuite/g++.dg/warn/undefined2.C | 14
> > 3 files changed, 36 insertions(+), 12 deletions(-)
> > create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-uneval26.C
> > create mode 100644 gcc/testsuite/g++.dg/warn/undefined2.C
> >
> > diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
> > index 82d7f946818..425477ea5b2 100644
> > --- a/gcc/diagnostic.cc
> > +++ b/gcc/diagnostic.cc
> > @@ -1398,18 +1398,6 @@ diagnostic_context::report_diagnostic
> > (diagnostic_info *diagnostic)
> > if (diagnostic->kind == DK_NOTE && m_inhibit_notes_p)
> > return false;
> > - if (m_lock > 0)
> > -{
> > - /* If we're reporting an ICE in the middle of some other error,
> > -try to flush out the previous error, then let this one
> > -through. Don't do this more than once. */
> > - if ((diagnostic->kind == DK_ICE || diagnostic->kind == DK_ICE_NOBT)
> > - && m_lock == 1)
> > - pp_newline_and_flush (m_reference_printer);
> > - else
> > - error_recursion ();
> > -}
> > -
> > /* If the user requested that warnings be treated as errors, so be
> >it. Note that we do this before the next block so that
> >individual warnings can be overridden back to warnings with
> > @@ -1426,6 +1414,18 @@ diagnostic_context::report_diagnostic
> > (diagnostic_info *diagnostic)
> > if (!diagnostic_enabled (diagnostic))
> > return false;
> > + if (m_lock > 0)
> > +{
> > + /* If we're reporting an ICE in the middle of some other error,
> > +try to flush out the previous error, then let this one
> > +through. Don't do this more than once. */
> > + if ((diagnostic->kind == DK_ICE || diagnostic->kind == DK_ICE_NOBT)
> > + && m_lock == 1)
> > + pp_newline_and_flush (m_reference_printer);
> > + else
> > + error_recursion ();
> > +}
>
> Let's move this a little farther down, past...
>
> > if ((was_warning || diagnostic->kind == DK_WARNING)
> > && ((!m_warn_system_headers
> >&& diagnostic->m_iinfo.m_a
[PATCH] Fortran: fix spelling of flag -fallow-invalid-boz
Dear all,
I am going to commit the attached patch as obvious.
Harald
From 8ea7254f7042582afd4a9dba5a1dd379467f30ff Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 28 Mar 2025 20:31:08 +0100
Subject: [PATCH] Fortran: fix spelling of flag -fallow-invalid-boz
gcc/fortran/ChangeLog:
* check.cc (gfc_invalid_boz): Correct spelling of compiler flag in
hint to -fallow-invalid-boz.
---
gcc/fortran/check.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index d2c8816da2b..9c66c25e059 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -67,7 +67,7 @@ gfc_invalid_boz (const char *msg, locus *loc)
return false;
}
- const char *hint = _(" [see %<-fno-allow-invalid-boz%>]");
+ const char *hint = _(" [see %<-fallow-invalid-boz%>]");
size_t len = strlen (msg) + strlen (hint) + 1;
char *msg2 = (char *) alloca (len);
strcpy (msg2, msg);
--
2.43.0
[PATCH 1/2] libstdc++: Fix -Wstringop-overread warning in std::vector [PR114758]
As in r13-4393-gcca06f0d6d76b0 and a few other commits, we can avoid
bogus warnings in std::vector by hoisting some loads to before the
allocation that calls operator new. This means that the compiler has
enough info to remove the dead branches that trigger bogus warnings.
On trunk this is only needed with -fno-assume-sane-operators-new-delete
but it will help on the branches where that option doesn't exist.
libstdc++-v3/ChangeLog:
PR libstdc++/114758
* include/bits/vector.tcc (vector::_M_fill_insert):
Hoist loads of begin() and end() before allocation.
* testsuite/23_containers/vector/bool/capacity/114758.cc: New
test.
---
Tested x86_64-linux.
libstdc++-v3/include/bits/vector.tcc | 5 +++--
.../23_containers/vector/bool/capacity/114758.cc | 10 ++
2 files changed, 13 insertions(+), 2 deletions(-)
create mode 100644
libstdc++-v3/testsuite/23_containers/vector/bool/capacity/114758.cc
diff --git a/libstdc++-v3/include/bits/vector.tcc
b/libstdc++-v3/include/bits/vector.tcc
index f197278d52e..29aa63e4742 100644
--- a/libstdc++-v3/include/bits/vector.tcc
+++ b/libstdc++-v3/include/bits/vector.tcc
@@ -1134,11 +1134,12 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
{
const size_type __len =
_M_check_len(__n, "vector::_M_fill_insert");
+ iterator __begin = begin(), __end = end();
_Bit_pointer __q = this->_M_allocate(__len);
iterator __start(std::__addressof(*__q), 0);
- iterator __i = _M_copy_aligned(begin(), __position, __start);
+ iterator __i = _M_copy_aligned(__begin, __position, __start);
std::fill(__i, __i + difference_type(__n), __x);
- iterator __finish = std::copy(__position, end(),
+ iterator __finish = std::copy(__position, __end,
__i + difference_type(__n));
this->_M_deallocate();
this->_M_impl._M_end_of_storage = __q + _S_nword(__len);
diff --git
a/libstdc++-v3/testsuite/23_containers/vector/bool/capacity/114758.cc
b/libstdc++-v3/testsuite/23_containers/vector/bool/capacity/114758.cc
new file mode 100644
index 000..d069db86bc6
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/vector/bool/capacity/114758.cc
@@ -0,0 +1,10 @@
+// { dg-options "-O3 -Werror=stringop-overread
-fno-assume-sane-operators-new-delete" }
+// { dg-do compile }
+
+#include
+
+void pr114758(std::vector& v)
+{
+ v.resize(3);
+ v = std::vector(3, false);
+}
--
2.49.0
[PATCH 2/2] libstdc++: Fix -Warray-bounds warning in std::vector [PR110498]
In this case, we need to tell the compiler that the current size is not
larger than the new size so that all the existing elements can be copied
to the new storage. This avoids bogus warnings about overflowing the new
storage when the compiler can't tell that that cannot happen.
We might as well also hoist the loads of begin() and end() before the
allocation too. All callers will have loaded at least begin() before
calling _M_reallocate.
libstdc++-v3/ChangeLog:
PR libstdc++/110498
* include/bits/vector.tcc (vector::_M_reallocate):
Hoist loads of begin() and end() before allocation and use them
to state an unreachable condition.
* testsuite/23_containers/vector/bool/capacity/110498.cc: New
test.
---
Tested x86_64-linux.
libstdc++-v3/include/bits/vector.tcc | 5 -
.../23_containers/vector/bool/capacity/110498.cc | 14 ++
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644
libstdc++-v3/testsuite/23_containers/vector/bool/capacity/110498.cc
diff --git a/libstdc++-v3/include/bits/vector.tcc
b/libstdc++-v3/include/bits/vector.tcc
index 29aa63e4742..7a92f34ec64 100644
--- a/libstdc++-v3/include/bits/vector.tcc
+++ b/libstdc++-v3/include/bits/vector.tcc
@@ -1106,9 +1106,12 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
vector::
_M_reallocate(size_type __n)
{
+ const iterator __begin = begin(), __end = end();
+ if (size_type(__end - __begin) > __n)
+ __builtin_unreachable();
_Bit_pointer __q = this->_M_allocate(__n);
iterator __start(std::__addressof(*__q), 0);
- iterator __finish(_M_copy_aligned(begin(), end(), __start));
+ iterator __finish(_M_copy_aligned(__begin, __end, __start));
this->_M_deallocate();
this->_M_impl._M_start = __start;
this->_M_impl._M_finish = __finish;
diff --git
a/libstdc++-v3/testsuite/23_containers/vector/bool/capacity/110498.cc
b/libstdc++-v3/testsuite/23_containers/vector/bool/capacity/110498.cc
new file mode 100644
index 000..70c4bf6a954
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/vector/bool/capacity/110498.cc
@@ -0,0 +1,14 @@
+// { dg-options "-O3 -Werror=array-bounds
-fno-assume-sane-operators-new-delete" }
+// { dg-do compile }
+
+#include
+
+void f(std::vector& v)
+{
+ // Warning emitted when set to any number in the range [1,64].
+ const std::size_t reserve_size = 30;
+
+ v.reserve(reserve_size);
+ v.push_back(0);
+}
+
--
2.49.0
Re: [PATCH 2/2] c++: constrained auto NTTP vs associated constraints
On Tue, 5 Nov 2024, Jason Merrill wrote:
> On 10/17/24 1:10 PM, Patrick Palka wrote:
> > On Thu, 17 Oct 2024, Patrick Palka wrote:
> >
> > > On Tue, 15 Oct 2024, Patrick Palka wrote:
> > >
> > > > On Tue, 15 Oct 2024, Patrick Palka wrote:
> > > >
> > > > > According to [temp.param]/11, the constraint on an auto NTTP is an
> > > > > associated constraint and so should be checked as part of satisfaction
> > > > > of the overall associated constraints rather than checked individually
> > > > > during coerion/deduction.
> > > >
> > > > By the way, I wonder if such associated constraints should be relevant
> > > > for
> > > > subsumption now?
> > > >
> > > > template concept C = true;
> > > >
> > > > template concept D = C && true;
> > > >
> > > > template void f(); // #1
> > > > template void f(); // #2
> > > >
> > > > int main() {
> > > >f<0>(); // still ambiguous?
> > > > }
> > > >
> > > > With this patch the above call is still ambiguous despite #2 now being
> > > > more constrained than #1 because "more constrained" is only considered
> > > > for
> > > > function templates with the same signatures as per
> > > > https://eel.is/c++draft/temp.func.order#6.2.2 and we deem their
> > > > signatures
> > > > to be different due to the different type-constraint.
> > >
> > > I think I convinced myself that this example should be accepted, and the
> > > way to go about that is to replace the constrained auto in the NTTP type
> > > with an ordinary auto once we set its TEMPLATE_PARM_CONSTRAINTS. That
> > > way both templates have the same signature modulo associated constraints.
> >
> > Here is v2 which implements this in finish_constrained_parameter. Now
> > we can assert that do_auto_deduction doesn't see a constrained auto
> > during adc_unify deduction!
> >
> > -- >8 --
> >
> > Subject: [PATCH v2 2/2] c++: constrained auto NTTP vs associated constraints
> >
> > According to [temp.param]/11, the constraint on an auto NTTP is an
> > associated constraint and so should be checked as part of satisfaction
> > of the overall associated constraints rather than checked individually
> > during coerion/deduction.
> >
> > In order to implement this we mainly need to make handling of
> > constrained auto NTTPs go through finish_constrained_parameter so that
> > TEMPLATE_PARM_CONSTRAINTS gets set on them, and teach
> > finish_shorthand_constraint how to build an associated constraint
> > corresponding to the written type-constraint.
> >
> > @@ -18637,24 +18609,43 @@ finish_constrained_parameter (cp_parser *parser,
> > cp_parameter_declarator *parmdecl,
> > bool *is_non_type)
> > {
> > - tree decl = parmdecl->decl_specifiers.type;
> > + tree constr = parmdecl->decl_specifiers.type;
> > tree id = get_unqualified_id (parmdecl->declarator);
> > tree def = parmdecl->default_argument;
> > - tree proto = DECL_INITIAL (decl);
> > /* Build the parameter. Return an error if the declarator was invalid.
> > */
> > tree parm;
> > - if (TREE_CODE (proto) == TYPE_DECL)
> > -parm = cp_parser_constrained_type_template_parm (parser, id, parmdecl);
> > + if (is_constrained_auto (constr))
> > +{
> > + /* Constrained non-type parameter. */
> > + *is_non_type = true;
>
> Why not replace constr with an unconstrained auto here...
>
> > + parm = grokdeclarator (parmdecl->declarator,
> > +&parmdecl->decl_specifiers,
> > +TPARM, /*initialized=*/0, /*attrlist=*/NULL);
> > + /* Replace the type of this constrained (auto) NTTP with an ordinary
> > +auto; its constraint gets saved in TEMPLATE_PARM_CONSTRAINTS to be
> > +associated with the template. */
> > + if (parm != error_mark_node)
> > + TREE_TYPE (parm) = (AUTO_IS_DECLTYPE (constr)
> > + ? make_decltype_auto ()
> > + : make_auto ());
>
> ...rather than here? Doing it here seems unlikely to work for e.g.
>
> template concept C = __is_same(T,int);
> template struct A { };
> int i;
> A<&i> a;
>
> Hmm, I suspect finish_shorthand_constraint just taking decltype(P) will also
> break.
Good point, it does break. It's not clear how to express and ultimately
mangle the constraint on P as an associated constraint. I guess we
could do C for C auto*, but then what about for C auto&
(where we must check C on the referred-to type)?
>
> Jason
>
>
Re: [PATCH] doc: document incremental LTO flags
On Thu, 2025-03-27 at 15:33:44 +, Sam James wrote: > > One thing I wasn't quite sure on yet: is -flto-partition=cache automatic > with -flto-incremental? Or is it just an optional flag I can pass for > more effective incremental LTO? > > If it's the latter, should we mention that in the -flto-incremental > documentation? > It is not automatic, because different partitioning will result in different executable. Most of the time this should not matter, but for example a performance bug depending on instruction alignment would not be reproduced. The cache partitioning is most useful with large amount of divergences per diverging partition. Which was very useful at the start, but it happens less with each divergence I remove. Last time I measured it, the improvement was no longer noticeable without debug symbols and only a few percent improvement with debug symbols, with one outlier case being ~50 % worse. The benefits are minor, a bit unclear, and caveats are hard to properly explain. So I do not want to actively recommend the option for now. > > [...] > > Thanks for working on incremental LTO. I had the opportunity to use it > for a bug for the first time last weekend and enjoyed it. Thanks, glad it is already useful. Michal
RE: [PATCH] [COBOL] use native_encode_real
> -Original Message-
> From: Richard Biener
> Sent: Friday, March 28, 2025 08:12
> To: Jakub Jelinek
> Cc: gcc-patches@gcc.gnu.org; rdub...@symas.com
> Subject: Re: [PATCH] [COBOL] use native_encode_real
>
> On Fri, 28 Mar 2025, Jakub Jelinek wrote:
>
> > On Fri, Mar 28, 2025 at 08:54:53AM +0100, Richard Biener wrote:
> > > The following avoids the round-trip through a newly built tree and
> > > instead directly uses the now exported native_encode_real.
> > >
> > > Tested on x86_64-unknown-linux-gnu.
> > >
> > > OK?
> > >
> > > gcc/cobol/
> > > * genapi.cc (initial_from_float128): Use native_encode_real.
> >
> > LGTM.
>
> Will push later.
I see it has been pushed. I just ran it through my existing test gamut on
x86_64. It behaves as expected.
>
> > Note, we still have at least
> > /* ??? Use native_encode_* below. */
> > retval = (char *)xmalloc(field->data.capacity);
> > switch(field->data.capacity)
> > {
> > case 1:
> > *(signed char *)retval = (signed char)i.slow ();
> > break;
> > case 2:
> > *(signed short *)retval = (signed short)i.slow ();
> > break;
> > case 4:
> > *(signed int *)retval = (signed int)i.slow ();
> > break;
> > case 8:
> > *(signed long *)retval = (signed long)i.slow ();
> > break;
> > case 16:
> > *(unsigned long *)retval = (unsigned long)i.ulow ();
> > *((signed long *)retval + 1) = (signed long)i.shigh ();
> > break;
> > that needs some endian handling (and is also wrong for
> > hosts which don't have 1 byte chars, 2 byte shorts, 4 byte ints
> > and 8 byte longs), dunno if we want a round-trip through
> wide_int_to_tree
> > and native_encode_expr in that case or if we do similar hack with
> exporting
> > native_encode_int's helper or native_encode_int itself which will
accept
> > wide_int + type rather than tree.
>
> IMO exporting a native_encode_wide would be nice.
>
> > And I'm sure trying to do a cross from powerpc-linux to x86_64-linux
> > will show up tons of other problems.
>
> For sure.
>
> Richard.
Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language
> On Mar 28, 2025, at 5:51 AM, Yeoul Na wrote:
>
>
>
>> On Mar 27, 2025, at 9:17 AM, Qing Zhao wrote:
>>
>> Yeoul,
>>
>> Thanks for the writeup.
>>
>> So, basically, This writeup insisted on introducing a new “structure scope”
>> (similar as the instance scope in C++) into C language ONLY for counted_by
>> attribute:
>>
>> 1. Inside counted_by attribute, the name lookup starts:
>>
>>A. Inside the current structure first (the NEW structure scope added to
>> C);
>>B. Then outside the structure; (other current C scopes, local scope or
>> global scope)
>>
>> 2. When trying to reference a variable outside of the structure scope that
>> name_conflicts with
>>a structure member, a new builtin function “__builtin_global_ref” is
>> introduced for such
>>purpose.
>>
>> ( I think that __builtin_global_ref might not accurate, because the outer
>> scope might be either global scope or local scope)
>
> Clarification: __builtin_global_ref will see the global scope directly. This
> is similar to global scope resolution syntax (‘::’) in C++.
>
> constexpr int len = 10;
>
> void foo (void)
> {
> const int len = 20;
>
> struct s {
> int len;
> int *__counted_by(__builtin_global_ref(len)) buf; // refers to global
> ‘len'
> };
> }
>
> Here are some reasons why we chose to provide a global scope resolution
> builtin, not a builtin to see an outer scope or just a local scope:
>
> 1) The builtin is a substitute for some “scope resolution specifier”. Scope
> specifiers typically meant to choose a “specific" scope.
> 2) To the best of my knowledge there is no precedence in any other C family
> language to provide a scope resolution for local scopes.
> 3) Name conflicts with local variables can be easily renamed.
> 4) If we provide a builtin that selects outer scope instead, there is no way
> to choose a global ‘len' if it’s shadowed by a local variable, so then the
> member name has to be renamed anyway in order to choose a global `len`.
> 5) This way, code can be written compatibly both in C and C++.
>
>>
>> 3. Where there is confliction between counted_by and VLA such as:
>>
>> constexpr int len = 10;
>>
>> struct s {
>> int len;
>> int *__counted_by(len) buf; // refers to struct member `len`.
>> int arr[len]; // refers to global constexpr `len`
>> };
>>
>> Issue compiler warning to user to ask the user to use __builtin_global_ref
>> to distinguish.
>
> Additionally, our proposal suggests __builtin_member_ref to explicitly use a
> member in a similar situation.
> The builtin could be replaced by ‘__self' or some other syntax once the
> standard committee decides in the future, but earlier in the thread JeanHeyd
> pointed out that:
>
> "I would like to gently push back about __self__, or __self, or self,
> because all of these identifiers are fairly common identifiers in code. When
> I writing the paper for __self_func (
> https://thephd.dev/_vendor/future_cxx/papers/C%20-%20__self_func.html ), I
> searched GitHub and other source code indexing and repository services:
> __self, __self__, and self has a substantial amount of uses. If there's an
> alternative spelling to consider, I think that would be helpful."
Additionally, the above being said, once we agreed on what is the right syntax
to use to access a member, our proposal doesn’t object to introducing it and
using it optionally.
>
> Thus, I think instead of trying to stick to a certain syntax right now, using
> some builtin will allow us to easily migrate to a new syntax by guarding the
> current usage under a macro.
>
> Writing the builtin could be cumbersome but this shall be written only when
> there is an ambiguity. Btw, I’m open to any other name suggestions for the
> builtins!
>
>>
>> Are the above the correct understanding of your writeup?
>
> Yes, it’s mostly correct, except some clarifications I made above. Thank you!
>
>>
>>
>> From my understanding:
>>
>> 1. This design started from the C++’s point of view by adding a new
>> “structure scope” to C;
>> 2. This design conflicts with the current VLA default scope rule (which
>> based on the default C scopes) in C.
>> In the above example that mixes counted_by and VLA, it’s so weird that
>> there are two difference name
>> lookup rules inside the same structure.
>> It’s clearly a design bug. Either VLA or counted_by need to be fixed to
>> make them consistent.
>>
>>
>> I personally do not completely object to introduce a new “structure scope”
>> into C, but it’s so hard for me to accept
>> that there are two different name lookup rules inside the same structure:
>> one rule for VLA, another rule for counted_by
>> attribute. (If introducing a new “structure scope” to C, I think it’s
>> better to change VLA to “structure scope” too, not sure
>> whether this is feasible or not)
>>
>> I still think that introduce a new keyword “__self” for referring member
>> variable inside structure
Re: [PATCH] bootstrap/119513 - fix cobol bootstrap with --enable-generated-files-in-srcdir
On Fri, Mar 28, 2025 at 01:51:23PM +0100, Richard Biener wrote:
> This adds gcc/cobol/parse.o to compare_exclusions and makes sure to
> ignore errors when copying generated files, like it's done when
> copying gengtype-lex.cc.
>
> Bootstrapped on x86_64-unknown-linux-gnu.
>
> OK?
>
> PR bootstrap/119513
> * configure.ac (compare_exclusions): Add gcc/cobol/parse\$(objext).
> * configure: Regenerated.
>
> gcc/cobol/
> * Make-lang.in (cobol.srcextra): Use cp instead of ln, ignore
> errors.
IMHO sed would still be better, but because we don't do that for
gengtype-lex.{l,cc} either, this is ok for now.
Looking at the gcc-14.2.0 tarball (which was rolled by me), I see
/d/gcc-14.2.0/gcc-14.2.0
paths (I use -d /d so that it is short where /d is just a symlink somewhere
/else), the only place where
/d/gcc-14.2.0/gcc-14.2.0
appears in the tarball is 59x in gcc/gengtype-lex.cc
all in
#line NN "/d/gcc-14.2.0/gcc-14.2.0/gcc/gengtype-lex.l"
So, changing that to
#line NN "gengtype-lex.l"
would be IMHO quite useful.
For cobol/parse.cc perhaps go with
#line NN "cobol/parse.y"
and similarly for cobol/cdf.cc and cobol/scan.cc.
Maybe best to do that in the
gcc.srcextra: gengtype-lex.cc
-cp -p $^ $(srcdir)
and
cobol.srcextra: cobol/parse.cc cobol/cdf.cc cobol/scan.cc
-cp -p $^ cobol/parse.h cobol/cdf.h $(srcdir)/cobol/
rules?
The relative or absolute paths from build directories to source directories
perhaps make sense in the build directories, but certainly not in the source
directories.
Jakub
[COMMITTED, PATCH] s390: Accept only Pmode for registers AP/FP/RA [PR119235]
gcc/ChangeLog: PR target/119235 * config/s390/s390.cc (s390_hard_regno_mode_ok): Accept only Pmode for registers AP/FP/RA. --- gcc/config/s390/s390.cc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc index 9df3c4edb0b..0ff3fd54dc3 100644 --- a/gcc/config/s390/s390.cc +++ b/gcc/config/s390/s390.cc @@ -11173,8 +11173,8 @@ s390_hard_regno_mode_ok (unsigned int regno, machine_mode mode) } break; case ADDR_REGS: - if (FRAME_REGNO_P (regno) && mode == Pmode) - return true; + if (FRAME_REGNO_P (regno)) + return mode == Pmode; /* fallthrough */ case GENERAL_REGS: -- 2.48.1
Re: [PATCH] bootstrap/119513 - fix cobol bootstrap with --enable-generated-files-in-srcdir
On Fri, 28 Mar 2025, Jakub Jelinek wrote:
> On Fri, Mar 28, 2025 at 01:51:23PM +0100, Richard Biener wrote:
> > This adds gcc/cobol/parse.o to compare_exclusions and makes sure to
> > ignore errors when copying generated files, like it's done when
> > copying gengtype-lex.cc.
> >
> > Bootstrapped on x86_64-unknown-linux-gnu.
> >
> > OK?
> >
> > PR bootstrap/119513
> > * configure.ac (compare_exclusions): Add gcc/cobol/parse\$(objext).
> > * configure: Regenerated.
> >
> > gcc/cobol/
> > * Make-lang.in (cobol.srcextra): Use cp instead of ln, ignore
> > errors.
>
> IMHO sed would still be better, but because we don't do that for
> gengtype-lex.{l,cc} either, this is ok for now.
>
> Looking at the gcc-14.2.0 tarball (which was rolled by me), I see
> /d/gcc-14.2.0/gcc-14.2.0
> paths (I use -d /d so that it is short where /d is just a symlink somewhere
> /else), the only place where
> /d/gcc-14.2.0/gcc-14.2.0
> appears in the tarball is 59x in gcc/gengtype-lex.cc
> all in
> #line NN "/d/gcc-14.2.0/gcc-14.2.0/gcc/gengtype-lex.l"
> So, changing that to
> #line NN "gengtype-lex.l"
> would be IMHO quite useful.
> For cobol/parse.cc perhaps go with
> #line NN "cobol/parse.y"
> and similarly for cobol/cdf.cc and cobol/scan.cc.
>
> Maybe best to do that in the
> gcc.srcextra: gengtype-lex.cc
> -cp -p $^ $(srcdir)
> and
> cobol.srcextra: cobol/parse.cc cobol/cdf.cc cobol/scan.cc
> -cp -p $^ cobol/parse.h cobol/cdf.h $(srcdir)/cobol/
> rules?
Note I have not tried to figure where the different relative path
comes from since it is for libgcobol/exceptl.h. There's
#include "../../libgcobol/exceptl.h"
in the generated sources, maybe we should use -I to pick up
libgcobol headers rather than using relative paths in the cobol/ sources.
> The relative or absolute paths from build directories to source directories
> perhaps make sense in the build directories, but certainly not in the source
> directories.
I've pushed the patch for now and will try generating a release
tarball again now.
Richard.
Re: [PATCH v2] c++/modules: Fix modules and LTO with header units [PR118961]
On Thu, Mar 27, 2025 at 10:38:02AM -0400, Jason Merrill wrote:
> On 3/27/25 3:35 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested (so far just dg.exp and modules.exp) on
> > x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
> >
> > Rather than updating copy_fndecl_with_name, we could also just fix
> > modules specifically by overwriting DECL_ABSTRACT_P before calling
> > build_cdtor_clones in trees_in::decl_value, or by forcing it to 0 for
> > DECL_MAYBE_IN_CHARGE_CDTOR during tree streaming, if you prefer, since
> > it'll always be set again by expand_or_defer_fn anyway.
> >
> > -- >8 --
> >
> > This patch makes some adjustments required to get a simple modules
> > testcase working with LTO. There are two main issues fixed.
> >
> > Firstly, modules only streams the maybe-in-charge constructor, and any
> > clones are recreated on stream-in. These clones are copied from the
> > existing function decl and then adjusted. This caused issues because
> > the clones were getting incorrectly marked as abstract, since after
> > clones have been created (in the imported file) the maybe-in-charge decl
> > gets marked as abstract. So this patch just ensures that clones are
> > always created as non-abstract.
>
> Sounds good.
>
> > The second issue is that we need to explicitly tell cgraph that explicit
> > instantiations need to be emitted, otherwise LTO will elide them (as
> > they don't necessarily appear to be used directly) and cause link
> > errors.
>
> Makes sense. Maybe you want to check get_importer_interface == always_emit
> instead of specifically for explicit inst?
>
> ...except I see that it returns that value for internal decls, which don't
> actually always need to be emitted; there seems to be a missing distinction
> between "considered to be defined in this TU" and actually "always emit".
>
Right; I've reworked this function a little for future-proofing, but I
didn't end up using it, so I'll send that as a separate change.
> > Additionally, expand_or_defer_fn doesn't setup comdat groups
> > for explicit instantiations, so we need to do that here as well.
>
> Hmm, that inconsistency seems worth fixing in expand_or_defer_fn, though
> it's fine to leave that for later and just add a FIXME comment to your
> change.
>
Added a comment. That existing logic makes sense since the only place
that explicit instantiations can occur is 'mark_decl_instantiated' which
does all the linkage handling itself, but maybe it would be reasonable
to generalise in the future; I've split out the relevant parts of that
function to reduce code duplication at least for now.
> > PR c++/118961
> >
> > gcc/cp/ChangeLog:
> >
> > * class.cc (copy_fndecl_with_name): Mark clones as non-abstract.
> > * module.cc (trees_in::read_var_def): Explicit instantiation
> > definitions of variables must be emitted, and are COMDAT.
> > (module_state::read_cluster): Likewise for functions.
> >
> > diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> > index 2cded878c64..f9f48bb2421 100644
> > --- a/gcc/cp/module.cc
> > +++ b/gcc/cp/module.cc
> > @@ -12684,6 +12684,13 @@ trees_in::read_var_def (tree decl, tree
> > maybe_template)
> > if (maybe_dup && DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P
> > (maybe_dup))
> > DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (decl) = true;
> > tentative_decl_linkage (decl);
>
> Doesn't this handle the comdat for variables?
>
Not for external instantiations, for two reasons: it doesn't do anything
if DECL_INTERFACE_KNOWN is set (as is the case here), and even if it
did, maybe_commonize_var only sets comdat for function-scope variables
or variables declared 'inline' (which an explicit instantiation is not
necessarily).
In some ways I think explicit instantiations are quite special with
needing to be emitted in a translation unit without necessarily being
referenced, but also needing COMDAT linkage, so I think it's OK for now
to keep them as special cases until we find another case that this is
needed for. Thoughts?
> > + if (DECL_EXPLICIT_INSTANTIATION (decl)
> > + && !DECL_EXTERNAL (decl))
> > + {
> > + mark_needed (decl);
> > + if (TREE_PUBLIC (decl))
> > + maybe_make_one_only (decl);
> > + }
> > if (DECL_IMPLICIT_INSTANTIATION (decl)
> > || (DECL_EXPLICIT_INSTANTIATION (decl)
> > && !DECL_EXTERNAL (decl))
>
> Jason
>
Here's an updated version of the patch; bootstrapped and regtested on
x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk if full
regtest succeeds?
-- >8 --
This patch makes some adjustments required to get a simple modules
testcase working with LTO. There are two main issues fixed.
Firstly, modules only streams the maybe-in-charge constructor, and any
clones are recreated on stream-in. These clones are copied from the
existing function decl and then adjusted. This caused issues because
the clones were getting incorrectly mark
Re: [PATCH] testsuite: Don't cycle through option list for gfortran.dg and libgomp.fortran dg-do run tests with -O in dg*options
Hi Jabuk!
Am 28.03.25 um 13:42 schrieb Jakub Jelinek:
Hi!
Ok, here is a new version of the patch.
The current behavior in gfortran.dg/ and libgomp.fortran/libgomp.oacc-fortran
is that tests without any dg-do directive are implicitly dg-do compile
and tests with dg-do compile or without dg-do don't cycle through options
(-O is implicitly added but can be overridden), while test with dg-do run
cycle through the optimization options.
The following patch modifies this, so that even tests with dg-do run
with -O in dg-options or dg-additional-options (after [ \t"{]) don't cycle
either and also get implicit -O which is overridden by that
-O{,0,1,2,3,s,z,g,fast} in dg-{,additional-}options. Previously we were
mostly wasting test time on those, because e.g.
-O0 -O2
-O1 -O2
-O2 -O2
-Os -O2
are still effectively -O2 and so the same thing, while
-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions -O2
and
-O3 -g -O2
are not the same thing (effectively
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -O2
and
-g -O2) I think it isn't worth to test those combinations (especially when
with e.g. -O0 in dg-options it mostly doesn't do much).
I think this is the most reasonable solution, and it is more transparent
than current behavior. OK from my side, and thanks for the patch!
Harald
Tested with make check-gfortran where this results in slight decrease of
tests:
# of expected passes73809
# of expected failures 343
# of unsupported tests 78
with unmodified trunk vs.
# of expected passes72734
# of expected failures 343
# of unsupported tests 73
with the patch, and on the libgomp side
# of expected passes11162
# of expected failures 238
# of unsupported tests 274
to
# of expected passes11092
# of expected failures 238
# of unsupported tests 274
(when counting just fortran.exp tests).
Before the patch I see
grep -- '-O[^ ].*-O' testsuite/gfortran/gfortran.log | grep -v
'/vect/\|/graphite/' | wc -l
1008
and with the patch
grep -- '-O[^ ].*-O' testsuite/gfortran/gfortran.log | grep -v
'/vect/\|/graphite/' | wc -l
0
(vect and graphite have a few occurrences, but not too much).
Ok for trunk?
2025-03-28 Jakub Jelinek
* lib/gfortran-dg.exp: Don't cycle through the option list if
dg-options or dg-additional-options contains -O after space, tab,
double quote or open curly bracket.
* gfortran.dg/cray_pointers_2.f90: Remove extraneous space between
dg-do and run and remove comment about it.
--- gcc/testsuite/lib/gfortran-dg.exp.jj2025-01-02 11:47:41.416065957
+0100
+++ gcc/testsuite/lib/gfortran-dg.exp 2025-03-28 12:32:02.413256582 +0100
@@ -149,7 +149,13 @@ proc gfortran-dg-runtest { testcases fla
# look if this is dg-do run test, in which case
# we cycle through the option list, otherwise we don't
if [expr [search_for $test "dg-do run"]] {
- set option_list $torture_with_loops
+ if { [ expr [search_for $test "dg-options*\[ \t\"\{]-O"] ] \
+|| [ expr [search_for $test \
+ "dg-additional-options*\[ \t\"\{]-O"] ] } {
+ set option_list [list { -O } ]
+ } else {
+ set option_list $torture_with_loops
+ }
} else {
set option_list [list { -O } ]
}
--- gcc/testsuite/gfortran.dg/cray_pointers_2.f90.jj2025-03-27
21:21:24.084411693 +0100
+++ gcc/testsuite/gfortran.dg/cray_pointers_2.f90 2025-03-28
12:26:10.129071424 +0100
@@ -1,6 +1,4 @@
-! Using two spaces between dg-do and run is a hack to keep gfortran-dg-runtest
-! from cycling through optimization options for this expensive test.
-! { dg-do run }
+! { dg-do run }
! { dg-options "-O3 -fcray-pointer -fbounds-check -fno-inline" }
! { dg-timeout-factor 4 }
!
Jakub
[PATCH] testsuite: Don't cycle through option list for gfortran.dg and libgomp.fortran dg-do run tests with -O in dg*options
Hi!
Ok, here is a new version of the patch.
The current behavior in gfortran.dg/ and libgomp.fortran/libgomp.oacc-fortran
is that tests without any dg-do directive are implicitly dg-do compile
and tests with dg-do compile or without dg-do don't cycle through options
(-O is implicitly added but can be overridden), while test with dg-do run
cycle through the optimization options.
The following patch modifies this, so that even tests with dg-do run
with -O in dg-options or dg-additional-options (after [ \t"{]) don't cycle
either and also get implicit -O which is overridden by that
-O{,0,1,2,3,s,z,g,fast} in dg-{,additional-}options. Previously we were
mostly wasting test time on those, because e.g.
-O0 -O2
-O1 -O2
-O2 -O2
-Os -O2
are still effectively -O2 and so the same thing, while
-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions -O2
and
-O3 -g -O2
are not the same thing (effectively
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -O2
and
-g -O2) I think it isn't worth to test those combinations (especially when
with e.g. -O0 in dg-options it mostly doesn't do much).
Tested with make check-gfortran where this results in slight decrease of
tests:
# of expected passes73809
# of expected failures 343
# of unsupported tests 78
with unmodified trunk vs.
# of expected passes72734
# of expected failures 343
# of unsupported tests 73
with the patch, and on the libgomp side
# of expected passes11162
# of expected failures 238
# of unsupported tests 274
to
# of expected passes11092
# of expected failures 238
# of unsupported tests 274
(when counting just fortran.exp tests).
Before the patch I see
grep -- '-O[^ ].*-O' testsuite/gfortran/gfortran.log | grep -v
'/vect/\|/graphite/' | wc -l
1008
and with the patch
grep -- '-O[^ ].*-O' testsuite/gfortran/gfortran.log | grep -v
'/vect/\|/graphite/' | wc -l
0
(vect and graphite have a few occurrences, but not too much).
Ok for trunk?
2025-03-28 Jakub Jelinek
* lib/gfortran-dg.exp: Don't cycle through the option list if
dg-options or dg-additional-options contains -O after space, tab,
double quote or open curly bracket.
* gfortran.dg/cray_pointers_2.f90: Remove extraneous space between
dg-do and run and remove comment about it.
--- gcc/testsuite/lib/gfortran-dg.exp.jj2025-01-02 11:47:41.416065957
+0100
+++ gcc/testsuite/lib/gfortran-dg.exp 2025-03-28 12:32:02.413256582 +0100
@@ -149,7 +149,13 @@ proc gfortran-dg-runtest { testcases fla
# look if this is dg-do run test, in which case
# we cycle through the option list, otherwise we don't
if [expr [search_for $test "dg-do run"]] {
- set option_list $torture_with_loops
+ if { [ expr [search_for $test "dg-options*\[ \t\"\{]-O"] ] \
+|| [ expr [search_for $test \
+ "dg-additional-options*\[ \t\"\{]-O"] ] } {
+ set option_list [list { -O } ]
+ } else {
+ set option_list $torture_with_loops
+ }
} else {
set option_list [list { -O } ]
}
--- gcc/testsuite/gfortran.dg/cray_pointers_2.f90.jj2025-03-27
21:21:24.084411693 +0100
+++ gcc/testsuite/gfortran.dg/cray_pointers_2.f90 2025-03-28
12:26:10.129071424 +0100
@@ -1,6 +1,4 @@
-! Using two spaces between dg-do and run is a hack to keep gfortran-dg-runtest
-! from cycling through optimization options for this expensive test.
-! { dg-do run }
+! { dg-do run }
! { dg-options "-O3 -fcray-pointer -fbounds-check -fno-inline" }
! { dg-timeout-factor 4 }
!
Jakub
[PATCH] bootstrap/119513 - fix cobol bootstrap with --enable-generated-files-in-srcdir
This adds gcc/cobol/parse.o to compare_exclusions and makes sure to ignore errors when copying generated files, like it's done when copying gengtype-lex.cc. Bootstrapped on x86_64-unknown-linux-gnu. OK? PR bootstrap/119513 * configure.ac (compare_exclusions): Add gcc/cobol/parse\$(objext). * configure: Regenerated. gcc/cobol/ * Make-lang.in (cobol.srcextra): Use cp instead of ln, ignore errors. --- configure | 1 + configure.ac | 1 + gcc/cobol/Make-lang.in | 2 +- 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/configure b/configure index e1063ccd9c3..036142a8d06 100755 --- a/configure +++ b/configure @@ -20030,6 +20030,7 @@ compare_exclusions="gcc/cc*-checksum\$(objext) | gcc/ada/*tools/*" compare_exclusions="$compare_exclusions | gcc/m2/gm2-compiler-boot/M2Version*" compare_exclusions="$compare_exclusions | gcc/m2/gm2-compiler-boot/SYSTEM*" compare_exclusions="$compare_exclusions | gcc/m2/gm2version*" +compare_exclusions="$compare_exclusions | gcc/cobol/parse\$(objext)" case "$target" in hppa*64*-*-hpux*) ;; powerpc*-ibm-aix*) compare_exclusions="$compare_exclusions | *libgomp*\$(objext)" ;; diff --git a/configure.ac b/configure.ac index eec6f817a4b..6cf9893cab0 100644 --- a/configure.ac +++ b/configure.ac @@ -4207,6 +4207,7 @@ compare_exclusions="gcc/cc*-checksum\$(objext) | gcc/ada/*tools/*" compare_exclusions="$compare_exclusions | gcc/m2/gm2-compiler-boot/M2Version*" compare_exclusions="$compare_exclusions | gcc/m2/gm2-compiler-boot/SYSTEM*" compare_exclusions="$compare_exclusions | gcc/m2/gm2version*" +compare_exclusions="$compare_exclusions | gcc/cobol/parse\$(objext)" case "$target" in hppa*64*-*-hpux*) ;; powerpc*-ibm-aix*) compare_exclusions="$compare_exclusions | *libgomp*\$(objext)" ;; diff --git a/gcc/cobol/Make-lang.in b/gcc/cobol/Make-lang.in index 7f5b24cad95..5e7e505440f 100644 --- a/gcc/cobol/Make-lang.in +++ b/gcc/cobol/Make-lang.in @@ -272,7 +272,7 @@ cobol/scan.o: cobol/scan.cc \ # output, and do not require those tools to be installed. # cobol.srcextra: cobol/parse.cc cobol/cdf.cc cobol/scan.cc - ln -f $^ cobol/parse.h cobol/cdf.h $(srcdir)/cobol/ + -cp -p $^ cobol/parse.h cobol/cdf.h $(srcdir)/cobol/ # And the cobol1 front end -- 2.43.0
Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language
> On Mar 27, 2025, at 9:17 AM, Qing Zhao wrote:
>
> Yeoul,
>
> Thanks for the writeup.
>
> So, basically, This writeup insisted on introducing a new “structure scope”
> (similar as the instance scope in C++) into C language ONLY for counted_by
> attribute:
>
> 1. Inside counted_by attribute, the name lookup starts:
>
>A. Inside the current structure first (the NEW structure scope added to C);
>B. Then outside the structure; (other current C scopes, local scope or
> global scope)
>
> 2. When trying to reference a variable outside of the structure scope that
> name_conflicts with
>a structure member, a new builtin function “__builtin_global_ref” is
> introduced for such
>purpose.
>
> ( I think that __builtin_global_ref might not accurate, because the outer
> scope might be either global scope or local scope)
Clarification: __builtin_global_ref will see the global scope directly. This is
similar to global scope resolution syntax (‘::’) in C++.
constexpr int len = 10;
void foo (void)
{
const int len = 20;
struct s {
int len;
int *__counted_by(__builtin_global_ref(len)) buf; // refers to global ‘len'
};
}
Here are some reasons why we chose to provide a global scope resolution
builtin, not a builtin to see an outer scope or just a local scope:
1) The builtin is a substitute for some “scope resolution specifier”. Scope
specifiers typically meant to choose a “specific" scope.
2) To the best of my knowledge there is no precedence in any other C family
language to provide a scope resolution for local scopes.
3) Name conflicts with local variables can be easily renamed.
4) If we provide a builtin that selects outer scope instead, there is no way to
choose a global ‘len' if it’s shadowed by a local variable, so then the member
name has to be renamed anyway in order to choose a global `len`.
5) This way, code can be written compatibly both in C and C++.
>
> 3. Where there is confliction between counted_by and VLA such as:
>
> constexpr int len = 10;
>
> struct s {
> int len;
> int *__counted_by(len) buf; // refers to struct member `len`.
> int arr[len]; // refers to global constexpr `len`
> };
>
> Issue compiler warning to user to ask the user to use __builtin_global_ref to
> distinguish.
Additionally, our proposal suggests __builtin_member_ref to explicitly use a
member in a similar situation.
The builtin could be replaced by ‘__self' or some other syntax once the
standard committee decides in the future, but earlier in the thread JeanHeyd
pointed out that:
"I would like to gently push back about __self__, or __self, or self,
because all of these identifiers are fairly common identifiers in code. When I
writing the paper for __self_func (
https://thephd.dev/_vendor/future_cxx/papers/C%20-%20__self_func.html ), I
searched GitHub and other source code indexing and repository services: __self,
__self__, and self has a substantial amount of uses. If there's an alternative
spelling to consider, I think that would be helpful."
Thus, I think instead of trying to stick to a certain syntax right now, using
some builtin will allow us to easily migrate to a new syntax by guarding the
current usage under a macro.
Writing the builtin could be cumbersome but this shall be written only when
there is an ambiguity. Btw, I’m open to any other name suggestions for the
builtins!
>
> Are the above the correct understanding of your writeup?
Yes, it’s mostly correct, except some clarifications I made above. Thank you!
>
>
> From my understanding:
>
> 1. This design started from the C++’s point of view by adding a new
> “structure scope” to C;
> 2. This design conflicts with the current VLA default scope rule (which based
> on the default C scopes) in C.
> In the above example that mixes counted_by and VLA, it’s so weird that
> there are two difference name
> lookup rules inside the same structure.
> It’s clearly a design bug. Either VLA or counted_by need to be fixed to
> make them consistent.
>
>
> I personally do not completely object to introduce a new “structure scope”
> into C, but it’s so hard for me to accept
> that there are two different name lookup rules inside the same structure: one
> rule for VLA, another rule for counted_by
> attribute. (If introducing a new “structure scope” to C, I think it’s
> better to change VLA to “structure scope” too, not sure
> whether this is feasible or not)
>
> I still think that introduce a new keyword “__self” for referring member
> variable inside structure without adding
> a new “structure scope" should be the best approach to resolve this issue in
> C.
>
> However, I am really hoping that the discussion can be converged soon. So, I
> am okay with adding a new “structure scope”
> If most of people agreed on that approach.
Thanks for the flexibility!
>
> Qing
>
>
>> On Mar 26, 2025, at 12:59, Yeoul Na wrote:
>>
>> Hi all,
>>
>> Thanks for all the discuss
[committed] cobol: Confine all __int128/_Float128 references to libgcobol
I didn't have to add any additional files. I was able to move
declarations needed by both libgcobol and gcc/cobol to more appropriate .h
files that already existed.
This change means that none of the gcc/cobol source code modules refer to
libgcobol.h any longer.
>From ea7c3a4f98ae58b446c7280c01a8ba3e2ff5ef1e Mon Sep 17 00:00:00 2001
From: Bob Dubner mailto:rdub...@symas.com
Date: Fri, 28 Mar 2025 12:09:39 -0400
Subject: [PATCH] cobol: Confine all __int128/_Float128 references to
libgcobol.
These changes are part of the effort to make possible cross compilation
for
hosts that don't support __int128 or _Float128.
gcc/cobol
* Make-lang.in: Eliminate libgcobol.h from gcc/cobol files.
* genapi.cc: Eliminate "#include libgcobol.h".
(parser_display_internal): Change comment.
* genmath.cc: Eliminate "#include libgcobol.h".
* genutil.cc: Likewise.
(get_power_of_ten): Change comment.
* structs.cc: Eliminate cblc_int128_type_node.
* structs.h: Likewise.
* symbols.h: Receive comment from libgcobol.h
libgcobol
* charmaps.cc:Eliminate "#include libgcobol.h".
Change comment about _Float128.
* common-defs.h: Change comment about _Float128. Receive
#defines from libgcobol.h.
* constants.cc: Eliminate #include libgcobol.h. Eliminate other
unneeded #includes.
* ec.h: Receive declarations from libgcobol.h.
* gcobolio.h: Likewise.
* gfileio.cc: (__gg__file_init): Use file_flag_none_e instead of
zero in assignment. (__gg__file_reopen): Likewise.
(__io__file_open): Likewise.
* gfileio.h: Receive declarations from libgcobol.h.
* libgcobol.h: Numerous declarations moved elsewhere.
---
gcc/cobol/Make-lang.in | 2 -
gcc/cobol/genapi.cc | 8 +-
gcc/cobol/genmath.cc| 1 -
gcc/cobol/genutil.cc| 3 +-
gcc/cobol/structs.cc| 30
gcc/cobol/structs.h | 1 -
gcc/cobol/symbols.h | 8 ++
libgcobol/charmaps.cc | 1 -
libgcobol/common-defs.h | 24 +-
libgcobol/constants.cc | 9 ---
libgcobol/ec.h | 60 +++
libgcobol/gcobolio.h| 38 ++
libgcobol/gfileio.cc| 8 +-
libgcobol/gfileio.h | 24 ++
libgcobol/libgcobol.h | 157 +++-
15 files changed, 169 insertions(+), 205 deletions(-)
diff --git a/gcc/cobol/Make-lang.in b/gcc/cobol/Make-lang.in
index 5b61ae912192..d939c62e780a 100644
--- a/gcc/cobol/Make-lang.in
+++ b/gcc/cobol/Make-lang.in
@@ -93,7 +93,6 @@ cobol/charmaps.cc: $(LIB_SOURCE)/charmaps.cc
sed -i "s|\"common-defs[.]h\"|\"$(LIB_SOURCE)/common-defs.h\"|g"
$@
sed -i "s|\"io[.]h\"|\"$(LIB_SOURCE)/io.h\"|g" $@
sed -i "s|\"gcobolio[.]h\"|\"$(LIB_SOURCE)/gcobolio.h\"|g" $@
- sed -i "s|\"libgcobol[.]h\"|\"$(LIB_SOURCE)/libgcobol.h\"|g" $@
sed -i "s|\"gfileio[.]h\"|\"$(LIB_SOURCE)/gfileio.h\"|g" $@
sed -i "s|\"charmaps[.]h\"|\"$(LIB_SOURCE)/charmaps.h\"|g" $@
sed -i "s|\"valconv[.]h\"|\"$(LIB_SOURCE)/valconv.h\"|g" $@
@@ -105,7 +104,6 @@ cobol/valconv.cc: $(LIB_SOURCE)/valconv.cc
sed -i "s|\"common-defs[.]h\"|\"$(LIB_SOURCE)/common-defs.h\"|g"
$@
sed -i "s|\"io[.]h\"|\"$(LIB_SOURCE)/io.h\"|g" $@
sed -i "s|\"gcobolio[.]h\"|\"$(LIB_SOURCE)/gcobolio.h\"|g" $@
- sed -i "s|\"libgcobol[.]h\"|\"$(LIB_SOURCE)/libgcobol.h\"|g" $@
sed -i "s|\"gfileio[.]h\"|\"$(LIB_SOURCE)/gfileio.h\"|g" $@
sed -i "s|\"charmaps[.]h\"|\"$(LIB_SOURCE)/charmaps.h\"|g" $@
sed -i "s|\"valconv[.]h\"|\"$(LIB_SOURCE)/valconv.h\"|g" $@
diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
index 8adc07ec57fa..be463f26bdfd 100644
--- a/gcc/cobol/genapi.cc
+++ b/gcc/cobol/genapi.cc
@@ -48,7 +48,6 @@
#include "genmath.h"
#include "structs.h"
#include "../../libgcobol/gcobolio.h"
-#include "../../libgcobol/libgcobol.h"
#include "../../libgcobol/charmaps.h"
#include "../../libgcobol/valconv.h"
#include "show_parse.h"
@@ -4800,14 +4799,13 @@ parser_display_internal(tree file_descriptor,
else if( refer.field->type == FldLiteralN )
{
// The parser found the string of digits from the source code and
converted
-// it to a _Float128.
+// it to a 128-bit binary floating point number.
// The bad news is that something like 555.55 can't be expressed
exactly;
// internally it is 555.54
-// The good news is that we know any string of 33 or fewer digits is
-// converted to _Float128 and then converted back again, you get the
same
-// string.
+// The good news is that we know any string of 33 or fewer decimal
digits
+// can be converted to and from IEEE 754 binary128 without being
changes
// We make use of that here
diff --git a/gcc/cobol/genmath.cc b/gcc/cobol/genmath.cc
index 56254e88cc6c..9725754eae15 100644
--- a/gcc/cobol/genmath.cc
+++ b/gcc/cobol/genmath.cc
@@ -42,7 +42,6 @@
#incl
[committed] libstdc++: Add testcase for bogus -Wstringop-overflow in std::vector [PR117983]
This was fixed on trunk by r15-4473-g3abe751ea86e34, just add the
testcase.
libstdc++-v3/ChangeLog:
PR libstdc++/117983
* testsuite/23_containers/vector/modifiers/insert/117983.cc: New
test.
---
Tested x86_64-linux. Pushed to trunk.
I have a fix for the branches, so will backport this test and fix the
std::vector code.
.../vector/modifiers/insert/117983.cc | 17 +
1 file changed, 17 insertions(+)
create mode 100644
libstdc++-v3/testsuite/23_containers/vector/modifiers/insert/117983.cc
diff --git
a/libstdc++-v3/testsuite/23_containers/vector/modifiers/insert/117983.cc
b/libstdc++-v3/testsuite/23_containers/vector/modifiers/insert/117983.cc
new file mode 100644
index 000..e6027a677ee
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/vector/modifiers/insert/117983.cc
@@ -0,0 +1,17 @@
+// { dg-options "-O3 -Werror=stringop-overflow" }
+// { dg-do compile }
+
+// PR libstdc++/117983
+// -Wstringop-overflow false positive for __builtin_memmove from vector::insert
+
+#include
+
+typedef std::vector bytes;
+
+void push(bytes chunk, bytes& data) {
+ if (data.empty()) {
+data.swap(chunk);
+ } else {
+data.insert(data.end(), chunk.begin(), chunk.end());
+ }
+}
--
2.49.0
Re: [PATCH v3] c++: fix reporting routines re-entered [PR119303]
On 3/28/25 12:46 PM, Marek Polacek wrote:
On Fri, Mar 28, 2025 at 11:49:48AM -0400, Jason Merrill wrote:
On 3/27/25 5:00 PM, Marek Polacek wrote:
On Wed, Mar 19, 2025 at 12:00:00PM -0400, Jason Merrill wrote:
On 3/17/25 6:55 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We crash while we call warning_at ("inline function used but never defined")
since it invokes dump_template_bindings -> tsubst -> ... -> convert_like ->
... -> c_common_truthvalue_conversion -> warning_at ("enum constant in boolean
context")
cp_truthvalue_conversion correctly gets complain=0 but it calls
c_common_truthvalue_conversion from c-family which doesn't have
a similar parameter.
It seems that we try to prevent this in cp_convert_and_check with
warning_sentinel c (warn_int_in_bool_context);
which is why we don't get a warning when we first instantiate the template.
But that doesn't help when we rebuild the expression for
dump_template_bindings because the recursion check in report_diagnostic
comes before the check whether the diagnostic is actually enabled.
I think rather than adding another mechanism for suppressing warnings, I'd
like to make the existing ones work better by moving the recursion check
after the checks for disabled diagnostics.
Fair enough. That happens to fix c++/116960 et al too. Note that my
adding a complain parameter into c-family isn't entirely novel:
c_sizeof_or_alignof_type also has one.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We crash while we call warning_at ("inline function used but never defined")
since it invokes dump_template_bindings -> tsubst -> ... -> convert_like ->
... -> c_common_truthvalue_conversion -> warning_at ("enum constant in boolean
context")
cp_truthvalue_conversion correctly gets complain=0 but it calls
c_common_truthvalue_conversion from c-family which doesn't have
a similar parameter.
We can fix this by tweaking diagnostic_context::report_diagnostic to
check for recursion after checking if the diagnostic was enabled.
PR c++/116960
PR c++/119303
gcc/ChangeLog:
* diagnostic.cc (diagnostic_context::report_diagnostic): Check for
non-zero m_lock only after diagnostic_enabled.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval26.C: New test.
* g++.dg/warn/undefined2.C: New test.
---
gcc/diagnostic.cc| 24 ++--
gcc/testsuite/g++.dg/cpp2a/lambda-uneval26.C | 10
gcc/testsuite/g++.dg/warn/undefined2.C | 14
3 files changed, 36 insertions(+), 12 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-uneval26.C
create mode 100644 gcc/testsuite/g++.dg/warn/undefined2.C
diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index 82d7f946818..425477ea5b2 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -1398,18 +1398,6 @@ diagnostic_context::report_diagnostic (diagnostic_info
*diagnostic)
if (diagnostic->kind == DK_NOTE && m_inhibit_notes_p)
return false;
- if (m_lock > 0)
-{
- /* If we're reporting an ICE in the middle of some other error,
-try to flush out the previous error, then let this one
-through. Don't do this more than once. */
- if ((diagnostic->kind == DK_ICE || diagnostic->kind == DK_ICE_NOBT)
- && m_lock == 1)
- pp_newline_and_flush (m_reference_printer);
- else
- error_recursion ();
-}
-
/* If the user requested that warnings be treated as errors, so be
it. Note that we do this before the next block so that
individual warnings can be overridden back to warnings with
@@ -1426,6 +1414,18 @@ diagnostic_context::report_diagnostic (diagnostic_info
*diagnostic)
if (!diagnostic_enabled (diagnostic))
return false;
+ if (m_lock > 0)
+{
+ /* If we're reporting an ICE in the middle of some other error,
+try to flush out the previous error, then let this one
+through. Don't do this more than once. */
+ if ((diagnostic->kind == DK_ICE || diagnostic->kind == DK_ICE_NOBT)
+ && m_lock == 1)
+ pp_newline_and_flush (m_reference_printer);
+ else
+ error_recursion ();
+}
Let's move this a little farther down, past...
if ((was_warning || diagnostic->kind == DK_WARNING)
&& ((!m_warn_system_headers
&& diagnostic->m_iinfo.m_allsyslocs)
...this early exit, as well.
The m_lock check used to be right before the increment, until DJ's r109907
that added #pragma GCC diagnostic; it would make sense to me for them to be
together again. I don't suppose it matters whether the check_max_errors is
before or after the m_lock handling.
Sure, thanks.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK, thanks.
-- >8 --
We cras
[PATCH] except: Don't use the cached value of the gcc_except_table section for comdat functions [PR119507]
This has been broken since GCC started to put the comdat functions'
gcc_except_table into their
own section; r0-118218-g3e6011cfebedfb. What would happen is after a non-comdat
function is processed,
the cached value would always be used even for comdat function. Instead we
should create a new
section for comdat functions.
OK for GCC 16? Bootstrapped and tested on x86_64-linux-gnu.
PR middle-end/119507
gcc/ChangeLog:
* except.cc (switch_to_exception_section): Don't use the cached section
if
the current function is in comdat.
gcc/testsuite/ChangeLog:
* g++.dg/eh/pr119507.C: New test.
Signed-off-by: Andrew Pinski
---
gcc/except.cc | 9 -
gcc/testsuite/g++.dg/eh/pr119507.C | 17 +
2 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/eh/pr119507.C
diff --git a/gcc/except.cc b/gcc/except.cc
index d5eb9274a62..8bd16c1dd69 100644
--- a/gcc/except.cc
+++ b/gcc/except.cc
@@ -2935,7 +2935,14 @@ switch_to_exception_section (const char * ARG_UNUSED
(fnname))
{
section *s;
- if (exception_section)
+ if (exception_section
+ /* Don't use the cached section for comdat if it will be different. */
+#ifdef HAVE_LD_EH_GC_SECTIONS
+ && !(targetm_common.have_named_sections
+ && DECL_COMDAT_GROUP (current_function_decl)
+ && HAVE_COMDAT_GROUP)
+#endif
+ )
s = exception_section;
else
{
diff --git a/gcc/testsuite/g++.dg/eh/pr119507.C
b/gcc/testsuite/g++.dg/eh/pr119507.C
new file mode 100644
index 000..50afa75a43f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/eh/pr119507.C
@@ -0,0 +1,17 @@
+// { dg-do compile { target comdat_group } }
+// Force off function sections
+// Force on exceptions
+// { dg-options "-fno-function-sections -fexceptions" }
+// PR middle-end/119507
+
+
+inline int comdat() { try { throw 1; } catch (int) { return 1; } return 0; }
+int another_func_with_exception() { try { throw 1; } catch (int) { return 1; }
return 0; }
+inline int comdat1() { try { throw 1; } catch (int) { return 1; } return 0; }
+int foo() { return comdat() + comdat1(); }
+
+// Make sure the gcc puts the exception table for both comdat and comdat1 in
their own section
+// { dg-final { scan-assembler-times ".section\[\t
\]\[^\n\]*.gcc_except_table._Z6comdatv" 1 } }
+// { dg-final { scan-assembler-times ".section\[\t
\]\[^\n\]*.gcc_except_table._Z7comdat1v" 1 } }
+// There should be 3 exception tables,
+// { dg-final { scan-assembler-times ".section\[\t
\]\[^\n\]*.gcc_except_table" 3 } }
--
2.43.0
Re:[pushed] [PATCH 2/2] LoongArch: doc: Add same-address constraint to the description of '-mld-seq-sa'.
Pushed to r15-9023.
在 2025/3/27 下午3:01, Lulu Cheng 写道:
gcc/ChangeLog:
* doc/invoke.texi: Modify the description of '-mld-seq-sa'.
---
gcc/doc/invoke.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b3f7f0479cc..4cdef8938dd 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -27963,8 +27963,8 @@ Use (do not use) @code{amcas[_db].@{b/h/w/d@}}
instructions. When build with
@opindex mno-ld-seq-sa
@item -mld-seq-sa
@itemx -mno-ld-seq-sa
-Whether a load-load barrier (@code{dbar 0x700}) is needed. When build with
-@option{-march=la664}, it is enabled by default. The default is
+Whether a same-address load-load barrier (@code{dbar 0x700}) is needed. When
+build with @option{-march=la664}, it is enabled by default. The default is
@option{-mno-ld-seq-sa}, the load-load barrier is needed.
@opindex mtls-dialect
Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language
> On Mar 26, 2025, at 1:52 PM, Yeoul Na wrote:
>
> Hi Joseph,
>
>> On Mar 26, 2025, at 12:07 PM, Joseph Myers wrote:
>>
>> On Wed, 26 Mar 2025, Yeoul Na wrote:
>>
>>> Hi all,
>>>
>>> Thanks for all the discussions.
>>>
>>> I posted the design rationale for our current approach in
>>> https://discourse.llvm.org/t/rfc-forward-referencing-a-struct-member-within-bounds-annotations/85510.
>>>
>>> This clarifies some of the questions that are asked in this thread. The
>>> document also proposes diagnostics to mitigate potential ambiguity, and
>>> propose new builtins that can be used as a suppression and
>>> disambiguation mechanism.
>>
>> That doesn't say anything about the handling of ambiguity between
>> structure members and typedef names.
>>
>> typedef char T;
>>
>> struct foo {
>> int T;
>> int U;
>> int *__counted_by((T)+U) buf;
>> };
>>
>> Is T interpreted as a typedef name inside __counted_by? Or does even the
>> interpretation of which identifiers are typedef names and which are
>> expressions depend on membership of the structure?
>>
>> --
>> Joseph S. Myers
>> josmy...@redhat.com
>>
>
> Inside `__counted_by` will see the struct scope, so a typedef will also be
> shadowed by a member declaration. Thus, `T` would be interpreted as a member
> inside `__counted_by`.
We can also add diagnostics in such a situation where the name conflicts with a
typedef.
> Thanks,
> Yeoul
Re: [PATCH] doc: document incremental LTO flags
Michal Jires writes: > On Thu, 2025-03-27 at 15:33:44 +, Sam James wrote: >> >> One thing I wasn't quite sure on yet: is -flto-partition=cache automatic >> with -flto-incremental? Or is it just an optional flag I can pass for >> more effective incremental LTO? >> >> If it's the latter, should we mention that in the -flto-incremental >> documentation? >> > > It is not automatic, because different partitioning will result in > different executable. Most of the time this should not matter, but for > example a performance bug depending on instruction alignment would not > be reproduced. Thanks! That makes sense. > > The cache partitioning is most useful with large amount of divergences > per diverging partition. Which was very useful at the start, but it > happens less with each divergence I remove. > Last time I measured it, the improvement was no longer noticeable > without debug symbols and only a few percent improvement with debug > symbols, with one outlier case being ~50 % worse. > > The benefits are minor, a bit unclear, and caveats are hard to properly > explain. So I do not want to actively recommend the option for now. ACK. Appreciate the explanation. > [...] sam
Re: [gcc-14 PATCH] Reuse scratch registers generated by LRA
On 3/27/25 7:49 AM, Xi Ruoyao wrote:
I'm proposing the backport to fix an ICE building gegl on powerpc64le:
https://gcc.gnu.org/PR119340. Bootstrapped and regtested on
powerpc64le-linux-gnu, OK for releases/gcc-14?
OK for me. Thank you for working on PR119340.
gcc/lra-constraints.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index dbc5129ae0a..0065f46f1f0 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -679,7 +679,8 @@ get_reload_reg (enum op_type type, machine_mode mode, rtx
original,
used by reload instructions. */
if (REG_P (original)
&& (int) REGNO (original) >= new_regno_start
- && INSN_UID (curr_insn) >= new_insn_uid_start
+ && (INSN_UID (curr_insn) >= new_insn_uid_start
+ || ira_former_scratch_p (REGNO (original)))
&& in_class_p (original, rclass, &new_class, true))
{
unsigned int regno = REGNO (original);
Re: [PATCH] cobol: Fix up cobol/{charmaps,valconv}.cc rules
+cobol/charmaps.cc cobol/valconv.cc: cobol/%.cc: $(LIB_SOURCE)/%.cc
+ -l='ec\|common-defs\|io\|gcobolio\|libgcobol\|gfileio\|charmaps'; \
+ l=$$l'\|valconv\|exceptl'; \
+ sed -e '/^#include/s,"\('$$l'\)\.h","../../libgcobol/\1.h",' $^ > $@
The proposed rule is much better than the old one - but is there a
technical reason to not just add -I ../../libgcobol or, possibly better,
-I $(LIB_SOURCE) to appropriate CPPFLAGS?
Simon
Re: [PATCH] cobol: Fix up cobol/{charmaps,valconv}.cc rules
On Fri, Mar 28, 2025 at 04:28:53PM +0100, Simon Sobisch wrote:
> +cobol/charmaps.cc cobol/valconv.cc: cobol/%.cc: $(LIB_SOURCE)/%.cc
> + -l='ec\|common-defs\|io\|gcobolio\|libgcobol\|gfileio\|charmaps'; \
> + l=$$l'\|valconv\|exceptl'; \
> + sed -e '/^#include/s,"\('$$l'\)\.h","../../libgcobol/\1.h",' $^ > $@
>
>
> The proposed rule is much better than the old one - but is there a technical
> reason to not just add -I ../../libgcobol or, possibly better, -I
> $(LIB_SOURCE) to appropriate CPPFLAGS?
I think it is better to make it clear in the sources what headers come from
the library and what comes from the FE.
I believe this has been discussed earlier already.
Jakub
[PATCH] libstdc++: Constrain formatters for chrono types [PR119517]
The formatters for chrono types defined the parse/format methods
as accepting unconstrained types, this in combination with lack
of constrain on _CharT lead to them falsy statisfying formattable
requirements for any type used as character.
This patch adjust the fromatter::parse signature to:
constexpr typename basic_format_parse_context<_CharT>::iterator
parse(basic_format_parse_context<_CharT>& __pc);
And formatter::format to:
template
typename basic_format_context<_Out, _CharT>::iterator
format(const T& __t,
basic_format_context<_Out, _CharT>& __fc) const;
Furthermore we _CharT with __format::__char (char or wchar_t),
PR libstdc++/119517
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (formatter):
Add __format::__char for _CharT and adjust parse and format
method signatures.
* testsuite/std/time/format/pr119517.cc: New test.
---
Testing on x86_64-linux, std/time/format tests passed.
OK for trunk?
libstdc++-v3/include/bits/chrono_io.h | 448 +-
.../testsuite/std/time/format/pr119517.cc | 44 ++
2 files changed, 262 insertions(+), 230 deletions(-)
create mode 100644 libstdc++-v3/testsuite/std/time/format/pr119517.cc
diff --git a/libstdc++-v3/include/bits/chrono_io.h
b/libstdc++-v3/include/bits/chrono_io.h
index c55b651d049..3a5bc5695fb 100644
--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -1785,277 +1785,272 @@ namespace __format
__format::__formatter_chrono<_CharT> _M_f;
};
- template
+ template<__format::__char _CharT>
struct formatter
{
- template
- constexpr typename _ParseContext::iterator
- parse(_ParseContext& __pc)
- { return _M_f._M_parse(__pc, __format::_Day); }
+ constexpr typename basic_format_parse_context<_CharT>::iterator
+ parse(basic_format_parse_context<_CharT>& __pc)
+ { return _M_f._M_parse(__pc, __format::_Day); }
- template
- typename _FormatContext::iterator
- format(const chrono::day& __t, _FormatContext& __fc) const
+ template
+ typename basic_format_context<_Out, _CharT>::iterator
+ format(const chrono::day& __t,
+ basic_format_context<_Out, _CharT>& __fc) const
{ return _M_f._M_format(__t, __fc); }
private:
__format::__formatter_chrono<_CharT> _M_f;
};
- template
+ template<__format::__char _CharT>
struct formatter
{
- template
- constexpr typename _ParseContext::iterator
- parse(_ParseContext& __pc)
- { return _M_f._M_parse(__pc, __format::_Month); }
+ constexpr typename basic_format_parse_context<_CharT>::iterator
+ parse(basic_format_parse_context<_CharT>& __pc)
+ { return _M_f._M_parse(__pc, __format::_Month); }
- template
- typename _FormatContext::iterator
- format(const chrono::month& __t, _FormatContext& __fc) const
+ template
+ typename basic_format_context<_Out, _CharT>::iterator
+ format(const chrono::month& __t,
+ basic_format_context<_Out, _CharT>& __fc) const
{ return _M_f._M_format(__t, __fc); }
private:
__format::__formatter_chrono<_CharT> _M_f;
};
- template
+ template<__format::__char _CharT>
struct formatter
{
- template
- constexpr typename _ParseContext::iterator
- parse(_ParseContext& __pc)
- { return _M_f._M_parse(__pc, __format::_Year); }
+ constexpr typename basic_format_parse_context<_CharT>::iterator
+ parse(basic_format_parse_context<_CharT>& __pc)
+ { return _M_f._M_parse(__pc, __format::_Year); }
- template
- typename _FormatContext::iterator
- format(const chrono::year& __t, _FormatContext& __fc) const
+ template
+ typename basic_format_context<_Out, _CharT>::iterator
+ format(const chrono::year& __t,
+ basic_format_context<_Out, _CharT>& __fc) const
{ return _M_f._M_format(__t, __fc); }
private:
__format::__formatter_chrono<_CharT> _M_f;
};
- template
+ template<__format::__char _CharT>
struct formatter
{
- template
- constexpr typename _ParseContext::iterator
- parse(_ParseContext& __pc)
- { return _M_f._M_parse(__pc, __format::_Weekday); }
+ constexpr typename basic_format_parse_context<_CharT>::iterator
+ parse(basic_format_parse_context<_CharT>& __pc)
+ { return _M_f._M_parse(__pc, __format::_Weekday); }
- template
- typename _FormatContext::iterator
- format(const chrono::weekday& __t, _FormatContext& __fc) const
+ template
+ typename basic_format_context<_Out, _CharT>::iterator
+ format(const chrono::weekday& __t,
+ basic_format_context<_Out, _CharT>& __fc) const
{ return _M_f._M_format(__t, __fc); }
private:
__format::__formatter_chrono<_CharT> _M_f;
};
- template
+ template<__form
Re: [PATCH v2] c++/modules: Fix modules and LTO with header units [PR118961]
On 3/28/25 8:54 AM, Nathaniel Shead wrote:
On Thu, Mar 27, 2025 at 10:38:02AM -0400, Jason Merrill wrote:
On 3/27/25 3:35 AM, Nathaniel Shead wrote:
Bootstrapped and regtested (so far just dg.exp and modules.exp) on
x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
Rather than updating copy_fndecl_with_name, we could also just fix
modules specifically by overwriting DECL_ABSTRACT_P before calling
build_cdtor_clones in trees_in::decl_value, or by forcing it to 0 for
DECL_MAYBE_IN_CHARGE_CDTOR during tree streaming, if you prefer, since
it'll always be set again by expand_or_defer_fn anyway.
-- >8 --
This patch makes some adjustments required to get a simple modules
testcase working with LTO. There are two main issues fixed.
Firstly, modules only streams the maybe-in-charge constructor, and any
clones are recreated on stream-in. These clones are copied from the
existing function decl and then adjusted. This caused issues because
the clones were getting incorrectly marked as abstract, since after
clones have been created (in the imported file) the maybe-in-charge decl
gets marked as abstract. So this patch just ensures that clones are
always created as non-abstract.
Sounds good.
The second issue is that we need to explicitly tell cgraph that explicit
instantiations need to be emitted, otherwise LTO will elide them (as
they don't necessarily appear to be used directly) and cause link
errors.
Makes sense. Maybe you want to check get_importer_interface == always_emit
instead of specifically for explicit inst?
...except I see that it returns that value for internal decls, which don't
actually always need to be emitted; there seems to be a missing distinction
between "considered to be defined in this TU" and actually "always emit".
Right; I've reworked this function a little for future-proofing, but I
didn't end up using it, so I'll send that as a separate change.
Additionally, expand_or_defer_fn doesn't setup comdat groups
for explicit instantiations, so we need to do that here as well.
Hmm, that inconsistency seems worth fixing in expand_or_defer_fn, though
it's fine to leave that for later and just add a FIXME comment to your
change.
Added a comment. That existing logic makes sense since the only place
that explicit instantiations can occur is 'mark_decl_instantiated' which
does all the linkage handling itself, but maybe it would be reasonable
to generalise in the future; I've split out the relevant parts of that
function to reduce code duplication at least for now.
PR c++/118961
gcc/cp/ChangeLog:
* class.cc (copy_fndecl_with_name): Mark clones as non-abstract.
* module.cc (trees_in::read_var_def): Explicit instantiation
definitions of variables must be emitted, and are COMDAT.
(module_state::read_cluster): Likewise for functions.
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 2cded878c64..f9f48bb2421 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -12684,6 +12684,13 @@ trees_in::read_var_def (tree decl, tree maybe_template)
if (maybe_dup && DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P
(maybe_dup))
DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (decl) = true;
tentative_decl_linkage (decl);
Doesn't this handle the comdat for variables?
Not for external instantiations, for two reasons: it doesn't do anything
if DECL_INTERFACE_KNOWN is set (as is the case here), and even if it
did, maybe_commonize_var only sets comdat for function-scope variables
or variables declared 'inline' (which an explicit instantiation is not
necessarily).
In some ways I think explicit instantiations are quite special with
needing to be emitted in a translation unit without necessarily being
referenced, but also needing COMDAT linkage, so I think it's OK for now
to keep them as special cases until we find another case that this is
needed for. Thoughts?
+ if (DECL_EXPLICIT_INSTANTIATION (decl)
+ && !DECL_EXTERNAL (decl))
+ {
+ mark_needed (decl);
+ if (TREE_PUBLIC (decl))
+ maybe_make_one_only (decl);
+ }
if (DECL_IMPLICIT_INSTANTIATION (decl)
|| (DECL_EXPLICIT_INSTANTIATION (decl)
&& !DECL_EXTERNAL (decl))
Jason
Here's an updated version of the patch; bootstrapped and regtested on
x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk if full
regtest succeeds?
-- >8 --
This patch makes some adjustments required to get a simple modules
testcase working with LTO. There are two main issues fixed.
Firstly, modules only streams the maybe-in-charge constructor, and any
clones are recreated on stream-in. These clones are copied from the
existing function decl and then adjusted. This caused issues because
the clones were getting incorrectly marked as abstract, since after
clones have been created (in the imported file) the maybe-in-charge decl
gets marked as abstract. So this patc
Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language
> On Mar 28, 2025, at 08:51, Yeoul Na wrote:
>
>
>
>> On Mar 27, 2025, at 9:17 AM, Qing Zhao wrote:
>>
>> Yeoul,
>>
>> Thanks for the writeup.
>>
>> So, basically, This writeup insisted on introducing a new “structure scope”
>> (similar as the instance scope in C++) into C language ONLY for counted_by
>> attribute:
>>
>> 1. Inside counted_by attribute, the name lookup starts:
>>
>>A. Inside the current structure first (the NEW structure scope added to
>> C);
>>B. Then outside the structure; (other current C scopes, local scope or
>> global scope)
>>
>> 2. When trying to reference a variable outside of the structure scope that
>> name_conflicts with
>>a structure member, a new builtin function “__builtin_global_ref” is
>> introduced for such
>>purpose.
>>
>> ( I think that __builtin_global_ref might not accurate, because the outer
>> scope might be either global scope or local scope)
>
>
> Clarification: __builtin_global_ref will see the global scope directly. This
> is similar to global scope resolution syntax (‘::’) in C++.
Yes, that’s my thought too.
Then, you still need another builtin to refer to the local variable with the
same name as the structure member, for example,
In the below example, if the “len” inside the counted_by refers to the “const
int len = 20”, how do you specify this?
>
> constexpr int len = 10;
>
> void foo (void)
> {
> const int len = 20;
>
> struct s {
> int len;
> int *__counted_by(__builtin_global_ref(len)) buf; // refers to global
> ‘len'
> };
> }
>
> Here are some reasons why we chose to provide a global scope resolution
> builtin, not a builtin to see an outer scope or just a local scope:
>
> 1) The builtin is a substitute for some “scope resolution specifier”. Scope
> specifiers typically meant to choose a “specific" scope.
> 2) To the best of my knowledge there is no precedence in any other C family
> language to provide a scope resolution for local scopes.
However, there is possibility that in the above example, the “len” might refer
to the local variable len, not the global one. How do you specify that?
> 3) Name conflicts with local variables can be easily renamed.
Then more source code change in different places is needed, I am not sure
whether this is easy to do in some cases.
> 4) If we provide a builtin that selects outer scope instead, there is no way
> to choose a global ‘len' if it’s shadowed by a local variable, so then the
> member name has to be renamed anyway in order to choose a global `len`.
Yes, that’s true. So maybe two builtins are needed?
> 5) This way, code can be written compatibly both in C and C++.
>
>>
>> 3. Where there is confliction between counted_by and VLA such as:
>>
>> constexpr int len = 10;
>>
>> struct s {
>> int len;
>> int *__counted_by(len) buf; // refers to struct member `len`.
>> int arr[len]; // refers to global constexpr `len`
>> };
>>
>> Issue compiler warning to user to ask the user to use __builtin_global_ref
>> to distinguish.
>
> Additionally, our proposal suggests __builtin_member_ref to explicitly use a
> member in a similar situation.
> The builtin could be replaced by ‘__self' or some other syntax once the
> standard committee decides in the future, but earlier in the thread JeanHeyd
> pointed out that:
>
> "I would like to gently push back about __self__, or __self, or self, because
> all of these identifiers are fairly common identifiers in code. When I
> writing the paper for __self_func (
> https://thephd.dev/_vendor/future_cxx/papers/C%20-%20__self_func.html ), I
> searched GitHub and other source code indexing and repository services:
> __self, __self__, and self has a substantial amount of uses. If there's an
> alternative spelling to consider, I think that would be helpful."
>
> Thus, I think instead of trying to stick to a certain syntax right now, using
> some builtin will allow us to easily migrate to a new syntax by guarding the
> current usage under a macro.
>
> Writing the builtin could be cumbersome but this shall be written only when
> there is an ambiguity. Btw, I’m open to any other name suggestions for the
> builtins!
I think that it’s better to stick to one approach:
A. Add a new keyword “__self”/ or __builtin_self() to explicitly refer to the
member variable, keep all other no changes.
OR:
A. Add one new instance scope into C, lookup the name inside the new scope
first, then outer scope. If try to refer to variables outside the instance
scope, using new added “scope resolution specifier”, such as __builtin_global_…
__builtin_local_… for that purpose.
For A, fixing the VLA inside structure to have the same lookup rule as
counted-by.
Anything mixing these two is not good to me...
>
>>
>> Are the above the correct understanding of your writeup?
>
> Yes, it’s mostly correct, except some clarifications I made above. Thank you!
Thank you for the clarifications.
Qing
>
>>
>>
Re: [PATCH v2] c++: fix reporting routines re-entered [PR119303]
On 3/27/25 5:00 PM, Marek Polacek wrote:
On Wed, Mar 19, 2025 at 12:00:00PM -0400, Jason Merrill wrote:
On 3/17/25 6:55 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We crash while we call warning_at ("inline function used but never defined")
since it invokes dump_template_bindings -> tsubst -> ... -> convert_like ->
... -> c_common_truthvalue_conversion -> warning_at ("enum constant in boolean
context")
cp_truthvalue_conversion correctly gets complain=0 but it calls
c_common_truthvalue_conversion from c-family which doesn't have
a similar parameter.
It seems that we try to prevent this in cp_convert_and_check with
warning_sentinel c (warn_int_in_bool_context);
which is why we don't get a warning when we first instantiate the template.
But that doesn't help when we rebuild the expression for
dump_template_bindings because the recursion check in report_diagnostic
comes before the check whether the diagnostic is actually enabled.
I think rather than adding another mechanism for suppressing warnings, I'd
like to make the existing ones work better by moving the recursion check
after the checks for disabled diagnostics.
Fair enough. That happens to fix c++/116960 et al too. Note that my
adding a complain parameter into c-family isn't entirely novel:
c_sizeof_or_alignof_type also has one.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We crash while we call warning_at ("inline function used but never defined")
since it invokes dump_template_bindings -> tsubst -> ... -> convert_like ->
... -> c_common_truthvalue_conversion -> warning_at ("enum constant in boolean
context")
cp_truthvalue_conversion correctly gets complain=0 but it calls
c_common_truthvalue_conversion from c-family which doesn't have
a similar parameter.
We can fix this by tweaking diagnostic_context::report_diagnostic to
check for recursion after checking if the diagnostic was enabled.
PR c++/116960
PR c++/119303
gcc/ChangeLog:
* diagnostic.cc (diagnostic_context::report_diagnostic): Check for
non-zero m_lock only after diagnostic_enabled.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval26.C: New test.
* g++.dg/warn/undefined2.C: New test.
---
gcc/diagnostic.cc| 24 ++--
gcc/testsuite/g++.dg/cpp2a/lambda-uneval26.C | 10
gcc/testsuite/g++.dg/warn/undefined2.C | 14
3 files changed, 36 insertions(+), 12 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-uneval26.C
create mode 100644 gcc/testsuite/g++.dg/warn/undefined2.C
diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index 82d7f946818..425477ea5b2 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -1398,18 +1398,6 @@ diagnostic_context::report_diagnostic (diagnostic_info
*diagnostic)
if (diagnostic->kind == DK_NOTE && m_inhibit_notes_p)
return false;
- if (m_lock > 0)
-{
- /* If we're reporting an ICE in the middle of some other error,
-try to flush out the previous error, then let this one
-through. Don't do this more than once. */
- if ((diagnostic->kind == DK_ICE || diagnostic->kind == DK_ICE_NOBT)
- && m_lock == 1)
- pp_newline_and_flush (m_reference_printer);
- else
- error_recursion ();
-}
-
/* If the user requested that warnings be treated as errors, so be
it. Note that we do this before the next block so that
individual warnings can be overridden back to warnings with
@@ -1426,6 +1414,18 @@ diagnostic_context::report_diagnostic (diagnostic_info
*diagnostic)
if (!diagnostic_enabled (diagnostic))
return false;
+ if (m_lock > 0)
+{
+ /* If we're reporting an ICE in the middle of some other error,
+try to flush out the previous error, then let this one
+through. Don't do this more than once. */
+ if ((diagnostic->kind == DK_ICE || diagnostic->kind == DK_ICE_NOBT)
+ && m_lock == 1)
+ pp_newline_and_flush (m_reference_printer);
+ else
+ error_recursion ();
+}
Let's move this a little farther down, past...
if ((was_warning || diagnostic->kind == DK_WARNING)
&& ((!m_warn_system_headers
&& diagnostic->m_iinfo.m_allsyslocs)
...this early exit, as well.
The m_lock check used to be right before the increment, until DJ's
r109907 that added #pragma GCC diagnostic; it would make sense to me for
them to be together again. I don't suppose it matters whether the
check_max_errors is before or after the m_lock handling.
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-uneval26.C
b/gcc/testsuite/g++.dg/cpp2a/lambda-uneval26.C
new file mode 100644
index 000..3e3097bedcb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-uneval2
Re: [PATCH] cobol: Fix up cobol/{charmaps,valconv}.cc rules
On Fri, 28 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> sed -i is not portable, it is supported by GNU sed and perhaps some BSDs,
> but not elsewhere.
> Furthermore, I think it is far better to always use
> #include "../../libgcobol/something.h"
> paths rather than something depending on the build directory.
> And because we require GNU make, we don't have to have two different
> rules for those, can use just one for both.
> The l variable in there is just to make it fit into 80 columns.
>
> Ok for trunk?
OK if this passes build.
Richard.
> 2025-03-28 Jakub Jelinek
>
> * Make-lang.in (cobol/charmaps.cc, cobol/valconv.cc): Used sed -e
> instead of cp and multiple sed -i commands. Always prefix libgcobol
> header names in #include directives with ../../libgcobol/ rather than
> something depending on $(LIB_SOURCE).
>
> --- gcc/cobol/Make-lang.in.jj 2025-03-28 15:08:29.431543005 +0100
> +++ gcc/cobol/Make-lang.in2025-03-28 15:31:14.886182633 +0100
> @@ -87,29 +87,10 @@ cobol1_OBJS =\
> # Various #includes in the files copied from gcc/libgcobol need to be
> modified
> # so that the .h files can be found.
>
> -cobol/charmaps.cc: $(LIB_SOURCE)/charmaps.cc
> - cp $^ $@
> - sed -i "s|\"ec[.]h\"|\"$(LIB_SOURCE)/ec.h\"|g" $@
> - sed -i "s|\"common-defs[.]h\"|\"$(LIB_SOURCE)/common-defs.h\"|g" $@
> - sed -i "s|\"io[.]h\"|\"$(LIB_SOURCE)/io.h\"|g" $@
> - sed -i "s|\"gcobolio[.]h\"|\"$(LIB_SOURCE)/gcobolio.h\"|g" $@
> - sed -i "s|\"libgcobol[.]h\"|\"$(LIB_SOURCE)/libgcobol.h\"|g" $@
> - sed -i "s|\"gfileio[.]h\"|\"$(LIB_SOURCE)/gfileio.h\"|g" $@
> - sed -i "s|\"charmaps[.]h\"|\"$(LIB_SOURCE)/charmaps.h\"|g" $@
> - sed -i "s|\"valconv[.]h\"|\"$(LIB_SOURCE)/valconv.h\"|g" $@
> - sed -i "s|\"exceptl[.]h\"|\"$(LIB_SOURCE)/exceptl.h\"|g" $@
> -
> -cobol/valconv.cc: $(LIB_SOURCE)/valconv.cc
> - cp $^ $@
> - sed -i "s|\"ec[.]h\"|\"$(LIB_SOURCE)/ec.h\"|g" $@
> - sed -i "s|\"common-defs[.]h\"|\"$(LIB_SOURCE)/common-defs.h\"|g" $@
> - sed -i "s|\"io[.]h\"|\"$(LIB_SOURCE)/io.h\"|g" $@
> - sed -i "s|\"gcobolio[.]h\"|\"$(LIB_SOURCE)/gcobolio.h\"|g" $@
> - sed -i "s|\"libgcobol[.]h\"|\"$(LIB_SOURCE)/libgcobol.h\"|g" $@
> - sed -i "s|\"gfileio[.]h\"|\"$(LIB_SOURCE)/gfileio.h\"|g" $@
> - sed -i "s|\"charmaps[.]h\"|\"$(LIB_SOURCE)/charmaps.h\"|g" $@
> - sed -i "s|\"valconv[.]h\"|\"$(LIB_SOURCE)/valconv.h\"|g" $@
> - sed -i "s|\"exceptl[.]h\"|\"$(LIB_SOURCE)/exceptl.h\"|g" $@
> +cobol/charmaps.cc cobol/valconv.cc: cobol/%.cc: $(LIB_SOURCE)/%.cc
> + -l='ec\|common-defs\|io\|gcobolio\|libgcobol\|gfileio\|charmaps'; \
> + l=$$l'\|valconv\|exceptl'; \
> + sed -e '/^#include/s,"\('$$l'\)\.h","../../libgcobol/\1.h",' $^ > $@
>
> LIB_SOURCE_H=$(wildcard $(LIB_SOURCE)/*.h)
>
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
[PATCH] cobol: Fix up cobol/{charmaps,valconv}.cc rules
Hi!
sed -i is not portable, it is supported by GNU sed and perhaps some BSDs,
but not elsewhere.
Furthermore, I think it is far better to always use
#include "../../libgcobol/something.h"
paths rather than something depending on the build directory.
And because we require GNU make, we don't have to have two different
rules for those, can use just one for both.
The l variable in there is just to make it fit into 80 columns.
Ok for trunk?
2025-03-28 Jakub Jelinek
* Make-lang.in (cobol/charmaps.cc, cobol/valconv.cc): Used sed -e
instead of cp and multiple sed -i commands. Always prefix libgcobol
header names in #include directives with ../../libgcobol/ rather than
something depending on $(LIB_SOURCE).
--- gcc/cobol/Make-lang.in.jj 2025-03-28 15:08:29.431543005 +0100
+++ gcc/cobol/Make-lang.in 2025-03-28 15:31:14.886182633 +0100
@@ -87,29 +87,10 @@ cobol1_OBJS =\
# Various #includes in the files copied from gcc/libgcobol need to be modified
# so that the .h files can be found.
-cobol/charmaps.cc: $(LIB_SOURCE)/charmaps.cc
- cp $^ $@
- sed -i "s|\"ec[.]h\"|\"$(LIB_SOURCE)/ec.h\"|g" $@
- sed -i "s|\"common-defs[.]h\"|\"$(LIB_SOURCE)/common-defs.h\"|g" $@
- sed -i "s|\"io[.]h\"|\"$(LIB_SOURCE)/io.h\"|g" $@
- sed -i "s|\"gcobolio[.]h\"|\"$(LIB_SOURCE)/gcobolio.h\"|g" $@
- sed -i "s|\"libgcobol[.]h\"|\"$(LIB_SOURCE)/libgcobol.h\"|g" $@
- sed -i "s|\"gfileio[.]h\"|\"$(LIB_SOURCE)/gfileio.h\"|g" $@
- sed -i "s|\"charmaps[.]h\"|\"$(LIB_SOURCE)/charmaps.h\"|g" $@
- sed -i "s|\"valconv[.]h\"|\"$(LIB_SOURCE)/valconv.h\"|g" $@
- sed -i "s|\"exceptl[.]h\"|\"$(LIB_SOURCE)/exceptl.h\"|g" $@
-
-cobol/valconv.cc: $(LIB_SOURCE)/valconv.cc
- cp $^ $@
- sed -i "s|\"ec[.]h\"|\"$(LIB_SOURCE)/ec.h\"|g" $@
- sed -i "s|\"common-defs[.]h\"|\"$(LIB_SOURCE)/common-defs.h\"|g" $@
- sed -i "s|\"io[.]h\"|\"$(LIB_SOURCE)/io.h\"|g" $@
- sed -i "s|\"gcobolio[.]h\"|\"$(LIB_SOURCE)/gcobolio.h\"|g" $@
- sed -i "s|\"libgcobol[.]h\"|\"$(LIB_SOURCE)/libgcobol.h\"|g" $@
- sed -i "s|\"gfileio[.]h\"|\"$(LIB_SOURCE)/gfileio.h\"|g" $@
- sed -i "s|\"charmaps[.]h\"|\"$(LIB_SOURCE)/charmaps.h\"|g" $@
- sed -i "s|\"valconv[.]h\"|\"$(LIB_SOURCE)/valconv.h\"|g" $@
- sed -i "s|\"exceptl[.]h\"|\"$(LIB_SOURCE)/exceptl.h\"|g" $@
+cobol/charmaps.cc cobol/valconv.cc: cobol/%.cc: $(LIB_SOURCE)/%.cc
+ -l='ec\|common-defs\|io\|gcobolio\|libgcobol\|gfileio\|charmaps'; \
+ l=$$l'\|valconv\|exceptl'; \
+ sed -e '/^#include/s,"\('$$l'\)\.h","../../libgcobol/\1.h",' $^ > $@
LIB_SOURCE_H=$(wildcard $(LIB_SOURCE)/*.h)
Jakub
Re: [PATCH] srcextra fixes
On Fri, 28 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> Here is a patch which uses sed to fix up the copies of the generated
> files by flex/bison in the source directories (i.e. what we ship in
> release tarballs).
> In that case the generated files are in the same directory as the
> files they are generated from, so there should be no absolute or relative
> directories, just the filenames.
>
> Furthermore, c.srcextra was duplicating the work of gcc.srcextra, there is
> nothing C FE specific on gengtype-lex.l.
>
> Tested on x86_64-linux, ok for trunk?
LGTM, but I'm not good in spotting issues with regexes ;)
Richard.
> 2025-03-28 Jakub Jelinek
>
> gcc/
> * Makefile.in (gcc.srcextra): Use sed to turn .../gcc/gengtype-lex.l
> in #line directives into just gengtype-lex.l.
> gcc/c/
> * Make-lang.in (c.srcextra): Don't depend on anything and don't copy
> anything.
> gcc/cobol/
> * Make-lang.in (cobol.srcextra): Use sed to turn
> .../gcc/cobol/*.{y,l,h,cc} and cobol/*.{y,l,h,cc} in #line directives
> into just *.{y,l,h,cc}.
>
> --- gcc/Makefile.in.jj2025-03-27 09:29:36.938576746 +0100
> +++ gcc/Makefile.in 2025-03-28 14:45:00.960408922 +0100
> @@ -2508,7 +2508,7 @@ s-mlib: $(srcdir)/genmultilib Makefile
> srcextra: gcc.srcextra lang.srcextra
>
> gcc.srcextra: gengtype-lex.cc
> - -cp -p $^ $(srcdir)
> + -sed -e '/^#line/s,".*/gcc/gengtype-lex\.l","gengtype-lex.l",' $^ >
> $(srcdir)/$^
>
> AR_OBJS = file-find.o
> AR_LIBS = @COLLECT2_LIBS@
> --- gcc/c/Make-lang.in.jj 2025-01-02 11:47:22.032336564 +0100
> +++ gcc/c/Make-lang.in2025-03-28 14:48:43.601409373 +0100
> @@ -131,8 +131,7 @@ c.all.cross:
> c.start.encap:
> c.rest.encap:
> c.srcinfo:
> -c.srcextra: gengtype-lex.cc
> - -cp -p $^ $(srcdir)
> +c.srcextra:
> c.tags: force
> cd $(srcdir)/c; $(ETAGS) -o TAGS.sub *.cc *.h; \
> $(ETAGS) --include TAGS.sub --include ../TAGS.sub
> --- gcc/cobol/Make-lang.in.jj 2025-03-28 14:30:28.251174728 +0100
> +++ gcc/cobol/Make-lang.in2025-03-28 15:08:29.431543005 +0100
> @@ -272,8 +272,9 @@ cobol/scan.o: cobol/scan.cc \
> # output, and do not require those tools to be installed.
> #
> cobol.srcextra: cobol/parse.cc cobol/cdf.cc cobol/scan.cc
> - -cp -p $^ cobol/parse.h cobol/cdf.h $(srcdir)/cobol/
> -
> + -for i in $^ cobol/parse.h cobol/cdf.h; do \
> + sed -e '/^#line/s,"\(.*gcc/\)\?cobol/\([^/]*\.\([ylh]\|cc\)\)","\2",'
> $$i \
> + > $(srcdir)/$$i; done
>
> # And the cobol1 front end
>
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Re: [PATCH] PR tree-optimization/119471 - If the LHS does not contain zero, neither do multiply operands.
On 3/28/25 03:19, Richard Biener wrote: On Fri, Mar 28, 2025 at 12:28 AM Andrew MacLeod wrote: This patch fixes both 119471 and the remainder of 110992. At issue is we do not recognize that if "a * b != 0" , then neither "a" nor "b" can be zero. This is fairly trivial with range-ops. op1_range and op2_range for operator_mult are taught that if the LHS does not contain zero, than neither does either operand. Included are patches for trunk (gcc15), gcc14, and gcc13. All are basically the same few lines. I presume we want to wait for stage 1 to check this into trunk . Bootstraps with no regressions on x86_64-pc-linux-gnu on all 3 branches. OK for gcc13 and gcc14 branches? This is OK for branches only after it was on trunk. Since one of the PRs is a regression it's technically OK for trunk now. Richard. OK, it should be perfectly safe. Committed to trunk. Andrew
Re: [PATCH] cobol: Fix up cobol/{charmaps,valconv}.cc rules
Thanks, I agree that the explicit include of library headers from frontend should include the library folder explicitly.
Re: [PATCH] testsuite: Add options for float16 for test [PR119133]
On 27/03/2025 14:48, Christophe Lyon wrote:
Some targets (like arm) need some flags to enable _Float16 support.
gcc/testsuite/ChangeLog:
PR target/119133
* gcc.dg/torture/pr119133.c: Add options for float16.
---
gcc/testsuite/gcc.dg/torture/pr119133.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/torture/pr119133.c
b/gcc/testsuite/gcc.dg/torture/pr119133.c
index 5369becd350..f0c8f734c86 100644
--- a/gcc/testsuite/gcc.dg/torture/pr119133.c
+++ b/gcc/testsuite/gcc.dg/torture/pr119133.c
@@ -1,5 +1,6 @@
/* { dg-additional-options "-fno-tree-ter" } */
/* { dg-require-effective-target float16 } */
+/* { dg-add-options float16 } */
int
foo(_Float16 f, int i)
OK.
I'm not sure that add_options_for_float16 is really doing the right
thing on arm. But that's a different issue.
R.
[PATCH] avoid-store-forwarding: Fix reg init on load-elimination [PR119160]
In the case that we are eliminating the load instruction, we use zero_extend
for the initialization of the base register for the zero-offset store.
This causes issues when the store and the load use the same mode,
as we are trying to generate a zero_extend with the same inner and
outer modes.
This patch fixes the issue by zero-extending the value stored in the
base register only when the load's mode is wider than the store's mode.
PR rtl-optimization/119160
gcc/ChangeLog:
* avoid-store-forwarding.cc (process_store_forwarding):
Zero-extend the value stored in the base register, in case
of load-elimination, only when the mode of the destination
is wider.
gcc/testsuite/ChangeLog:
* gcc.dg/pr119160.c: New test.
---
gcc/avoid-store-forwarding.cc | 11 ---
gcc/testsuite/gcc.dg/pr119160.c | 26 ++
2 files changed, 34 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr119160.c
diff --git a/gcc/avoid-store-forwarding.cc b/gcc/avoid-store-forwarding.cc
index 34a7bba4043..ded8d7e596e 100644
--- a/gcc/avoid-store-forwarding.cc
+++ b/gcc/avoid-store-forwarding.cc
@@ -238,10 +238,15 @@ process_store_forwarding (vec &stores,
rtx_insn *load_insn,
{
start_sequence ();
- rtx ext0 = gen_rtx_ZERO_EXTEND (GET_MODE (dest), it->mov_reg);
- if (ext0)
+ machine_mode dest_mode = GET_MODE (dest);
+ rtx base_reg = it->mov_reg;
+ if (known_gt (GET_MODE_BITSIZE (dest_mode),
+ GET_MODE_BITSIZE (GET_MODE (it->mov_reg
+ base_reg = gen_rtx_ZERO_EXTEND (dest_mode, it->mov_reg);
+
+ if (base_reg)
{
- rtx_insn *move0 = emit_move_insn (dest, ext0);
+ rtx_insn *move0 = emit_move_insn (dest, base_reg);
if (recog_memoized (move0) >= 0)
{
insns = get_insns ();
diff --git a/gcc/testsuite/gcc.dg/pr119160.c b/gcc/testsuite/gcc.dg/pr119160.c
new file mode 100644
index 000..b4629a11d9d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr119160.c
@@ -0,0 +1,26 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -finstrument-functions-once -favoid-store-forwarding
-fnon-call-exceptions -fschedule-insns -mgeneral-regs-only -Wno-psabi" } */
+
+typedef __attribute__((__vector_size__ (32))) int V;
+
+void
+foo (V v, V, V, V *r)
+{
+ V u = (V){} + v[0];
+ *r = u;
+}
+
+__attribute__((__noipa__)) void
+bar(int x)
+{
+ if (x != 2) __builtin_abort();
+}
+
+int
+main ()
+{
+ V x;
+ foo ((V){ 2, 3 }, (V){ }, (V){ }, &x);
+ for (unsigned i = 0; i < sizeof(x)/sizeof(x[0]); i++)
+bar(x[i]);
+}
\ No newline at end of file
--
2.43.0
[commited] cobol: Eliminate check-cobol -Os failure in EVALUATE testcase
This represents the first success due to converting tests to DejaGnu.
One of these new tests passed everything except the -Os run.
With the patch, the changes have been demonstrated for proper behavior on
x86_64 and aarch64.
>From a369cc815a53659e5079a32091e02e0fecc84f28 Mon Sep 17 00:00:00 2001
From: Bob Dubner mailto:rdub...@symas.com
Date: Fri, 28 Mar 2025 08:57:24 -0400
Subject: [PATCH] cobol: Eliminate check-cobol -Os failure in EVALUATE
testcase
The coding error was the lack of a necessary cast from unsigned
char to int.
gcc/cobol
* genapi.cc: (create_and_call): cast unsigned char to int
gcc/testsuite
* cobol.dg/group2/Complex_EVALUATE__1_.cob: New EVALUTE testcase.
* cobol.dg/group2/Complex_EVALUATE__2_.cob: Likewise.
* cobol.dg/group2/EVALUATE_WHEN_NEGATIVE.cob: Likewise.
* cobol.dg/group2/EVALUATE_condition__2_.cob: Likewise.
* cobol.dg/group2/EVALUATE_doubled_WHEN.cob: Likewise.
* cobol.dg/group2/EVALUATE_with_WHEN_using_condition-1.cob:
Likewise.
* cobol.dg/group2/Complex_EVALUATE__1_.out: Known-good data for
testcase.
* cobol.dg/group2/Complex_EVALUATE__2_.out: Likewise.
* cobol.dg/group2/EVALUATE_WHEN_NEGATIVE.out: Likewise.
* cobol.dg/group2/EVALUATE_condition__2_.out: Likewise.
* cobol.dg/group2/EVALUATE_doubled_WHEN.out: Likewise.
* cobol.dg/group2/EVALUATE_with_WHEN_using_condition-1.out:
Likewise.
---
gcc/cobol/genapi.cc | 3 +-
.../cobol.dg/group2/Complex_EVALUATE__1_.cob | 46
.../cobol.dg/group2/Complex_EVALUATE__1_.out | 5 ++
.../cobol.dg/group2/Complex_EVALUATE__2_.cob | 52 +++
.../cobol.dg/group2/Complex_EVALUATE__2_.out | 15 ++
.../group2/EVALUATE_WHEN_NEGATIVE.cob | 16 ++
.../group2/EVALUATE_WHEN_NEGATIVE.out | 2 +
.../group2/EVALUATE_condition__2_.cob | 38 ++
.../group2/EVALUATE_condition__2_.out | 5 ++
.../cobol.dg/group2/EVALUATE_doubled_WHEN.cob | 30 +++
.../cobol.dg/group2/EVALUATE_doubled_WHEN.out | 5 ++
.../EVALUATE_with_WHEN_using_condition-1.cob | 18 +++
.../EVALUATE_with_WHEN_using_condition-1.out | 2 +
13 files changed, 236 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/cobol.dg/group2/Complex_EVALUATE__1_.cob
create mode 100644 gcc/testsuite/cobol.dg/group2/Complex_EVALUATE__1_.out
create mode 100644 gcc/testsuite/cobol.dg/group2/Complex_EVALUATE__2_.cob
create mode 100644 gcc/testsuite/cobol.dg/group2/Complex_EVALUATE__2_.out
create mode 100644
gcc/testsuite/cobol.dg/group2/EVALUATE_WHEN_NEGATIVE.cob
create mode 100644
gcc/testsuite/cobol.dg/group2/EVALUATE_WHEN_NEGATIVE.out
create mode 100644
gcc/testsuite/cobol.dg/group2/EVALUATE_condition__2_.cob
create mode 100644
gcc/testsuite/cobol.dg/group2/EVALUATE_condition__2_.out
create mode 100644
gcc/testsuite/cobol.dg/group2/EVALUATE_doubled_WHEN.cob
create mode 100644
gcc/testsuite/cobol.dg/group2/EVALUATE_doubled_WHEN.out
create mode 100644
gcc/testsuite/cobol.dg/group2/EVALUATE_with_WHEN_using_condition-1.cob
create mode 100644
gcc/testsuite/cobol.dg/group2/EVALUATE_with_WHEN_using_condition-1.out
diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
index 032236b15dba..6ecdc159e4a3 100644
--- a/gcc/cobol/genapi.cc
+++ b/gcc/cobol/genapi.cc
@@ -12395,13 +12395,14 @@ create_and_call(size_t narg,
// We got back a 64-bit or 128-bit integer. The called and calling
// programs have to agree on size, but other than that, integer
numeric
// types are converted one to the other.
+
gg_call(VOID,
"__gg__int128_to_qualified_field",
gg_get_address_of(returned.field->var_decl_node),
refer_offset_dest(returned),
refer_size_dest(returned),
gg_cast(INT128, returned_value),
- member(returned.field->var_decl_node, "rdigits"),
+ gg_cast(INT, member(returned.field->var_decl_node,
"rdigits")),
build_int_cst_type(INT, truncation_e),
null_pointer_node,
NULL_TREE );
diff --git a/gcc/testsuite/cobol.dg/group2/Complex_EVALUATE__1_.cob
b/gcc/testsuite/cobol.dg/group2/Complex_EVALUATE__1_.cob
new file mode 100644
index ..a070d16108e9
--- /dev/null
+++ b/gcc/testsuite/cobol.dg/group2/Complex_EVALUATE__1_.cob
@@ -0,0 +1,46 @@
+ *> { dg-do run }
+ *> { dg-output-file "group2/Complex_EVALUATE__1_.out" }
+
+identification division.
+function-id.bumper.
+datadivision.
+working-storage section.
+77 bump pic value zero.
+linkage section.
+77 bumped pic .
+procedure division returning bumped.
+add 1 to bump.
+move bump to bumped.
+goback.
+end functionbumper.
+
+identification
[PATCH] other/119510 - use --enable-languages=default,cobol for release tarballs
The following adds cobol to the set of languages built during release
tarball building so the bison and flex generated sources for cobol
are included in the tarball.
OK?
I think an explicit list is better since you'll get an error if
prerequesites for a language are not present instead of silently
disabling it as it is done with =all. Note this does not fix the
missed texinfo generated files for other languages. I do have a
RC tarball built with =all, I can see to compare contents between
that and a =default - is that interesting?
PR other/119510
* maintainer-scripts/gcc_release: Use --enable-languages=default,cobol
when building generated files.
---
maintainer-scripts/gcc_release | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/maintainer-scripts/gcc_release b/maintainer-scripts/gcc_release
index 42bb7f68f17..471a10cc39e 100755
--- a/maintainer-scripts/gcc_release
+++ b/maintainer-scripts/gcc_release
@@ -267,7 +267,7 @@ EOF
esac
fi
contrib/gcc_build -d ${SOURCE_DIRECTORY} -o ${OBJECT_DIRECTORY} \
- -c "--enable-generated-files-in-srcdir --disable-multilib" \
+ -c "--enable-languages=default,cobol --enable-generated-files-in-srcdir
--disable-multilib" \
-m "-j$num_cpus" build || \
error "Could not rebuild GCC"
fi
--
2.43.0
Patch v2 of Bug 119222 Conversion of inf to integer is not diagnosed , pay attention to Notice !
>From bd5541b903747082c984aa92ebe16faeae7b0c71 Mon Sep 17 00:00:00 2001
From: Gwen Fu
Date: Thu, 27 Mar 2025 15:55:23 +0800
Subject: [PATCH] [Description of 119222 bug] Conversion of inf to integer is
not diagnosed
[How addresses it] In c-warn.cc, function: warnings_for_convert_and_check:
Since the conversion of inf to int occurs when result is FIX_TRUNC_EXPR,
this is the main basis for judgment and processing . Since expr may be a
variable declaration, DECL_INITIAL is required . After that, the program
discusses three situations from the view of floating-point constants,
floating-point expressions,and real-point division expressions to determine
whether it is infinity. The flag bit warn_flag is used to indicate whether
an illegal situation occurs.
[Test cases]
double c = 3.3/4.4-4.4 ;
double b = 1/static_cast(0) ;
int m = b ;
int n = c ;
int f = 1/0 ;
int g = 1/static_cast(0) ;
int h = 1/static_cast(0) / static_cast(0) /
static_cast(0) ;
[Bootstrapping and testing]
host:Ubuntu24 x86_64 (And I think this pathch suitable for any machine
type)
result:
int m = b ; //successful warning
int n = c ; //missing a warning
int f = 1/0;//successful warning
int g =...; int h = ... //successful warning
[Notice]
"int n = c" didn't send a warning ,
"""
REAL_VALUE_TYPE value = TREE_REAL_CST(dst);
bool is_inf = REAL_VALUE_ISINF(value);
"""
And when I execute"call debug_tree(dst)" to clerify the value of c , it
displayed as:
constant -3.6503552713678800500929355621337890625e+0> .It is
not infinity.
But actually the value mast be infinity
---
gcc/c-family/c-warn.cc | 51 +-
1 file changed, 40 insertions(+), 11 deletions(-)
[Changelog]
gcc/c-family/ChangeLog:
* c-warn.cc (conversion_warning):
(warnings_for_convert_and_check):
I use "./contrib/mklog.py *patch " to generate that above . Is this
Changelog?
From bd5541b903747082c984aa92ebe16faeae7b0c71 Mon Sep 17 00:00:00 2001
From: Gwen Fu
Date: Thu, 27 Mar 2025 15:55:23 +0800
Subject: [PATCH] [Description of 119222 bug] Conversion of inf to integer is
not diagnosed
[How addresses it] In c-warn.cc, function: warnings_for_convert_and_check:
Since the conversion of inf to int occurs when result is FIX_TRUNC_EXPR,
this is the main basis for judgment and processing . Since expr may be a
variable declaration, DECL_INITIAL is required . After that, the program
discusses three situations from the view of floating-point constants,
floating-point expressions,and real-point division expressions to determine
whether it is infinity. The flag bit warn_flag is used to indicate whether
an illegal situation occurs.
[Test cases]
double c = 3.3/4.4-4.4 ;
double b = 1/static_cast(0) ;
int m = b ;
int n = c ;
int f = 1/0 ;
int g = 1/static_cast(0) ;
int h = 1/static_cast(0) / static_cast(0) / static_cast(0) ;
[Bootstrapping and testing]
host:Ubuntu24 x86_64 (And I think this pathch suitable for any machine type)
result:
int m = b ; //successful warning
int n = c ; //missing a warning
int f = 1/0;//successful warning
int g =...; int h = ... //successful warning
[Notice]
"int n = c" didn't send a warning ,
"""
REAL_VALUE_TYPE value = TREE_REAL_CST(dst);
bool is_inf = REAL_VALUE_ISINF(value);
"""
And when I execute"call debug_tree(dst)" to clerify the value of c , it displayed as:
constant -3.6503552713678800500929355621337890625e+0> .It is not infinity.
But actually the value mast be infinity
---
gcc/c-family/c-warn.cc | 51 +-
1 file changed, 40 insertions(+), 11 deletions(-)
[Changelog]
gcc/c-family/ChangeLog:
* c-warn.cc (conversion_warning):
(warnings_for_convert_and_check):
I use "./contrib/mklog.py *patch " to generate that above . Is this Changelog?
diff --git a/gcc/c-family/c-warn.cc b/gcc/c-family/c-warn.cc
index 406b591bfa0..16de902dae8 100644
--- a/gcc/c-family/c-warn.cc
+++ b/gcc/c-family/c-warn.cc
@@ -1283,17 +1283,6 @@ conversion_warning (location_t loc, tree type, tree expr, tree result)
case CEIL_DIV_EXPR:
case EXACT_DIV_EXPR:
case RDIV_EXPR:
- /*Issue a warning about infinity conversion to int*/
- if( TREE_CODE(type) == INTEGER_TYPE
-&& TREE_CODE (TREE_OPERAND(expr,1)) == REAL_CST && real_zerop (TREE_OPERAND(expr,1)))
-{
-bool ret = warning_at(loc , OPT_Wfloat_conversion ,
- "conversion from %qT to %qT changes infinity to maximum or minimum integer value",
- expr_type , type) ;
-if(!ret) warning_at(loc , OPT_Wconversion ,
- "conversion from %qT to %qT changes infinity to maximum or minimum integer value",
- expr_type , type) ;
-}
arith_ops = 2;
goto default_;
@@ -1516,6 +1505,46 @@ warnings_for_convert_and_check (location_t loc, tree type, tree expr,
"changes the value of
[PATCH] srcextra fixes
Hi!
Here is a patch which uses sed to fix up the copies of the generated
files by flex/bison in the source directories (i.e. what we ship in
release tarballs).
In that case the generated files are in the same directory as the
files they are generated from, so there should be no absolute or relative
directories, just the filenames.
Furthermore, c.srcextra was duplicating the work of gcc.srcextra, there is
nothing C FE specific on gengtype-lex.l.
Tested on x86_64-linux, ok for trunk?
2025-03-28 Jakub Jelinek
gcc/
* Makefile.in (gcc.srcextra): Use sed to turn .../gcc/gengtype-lex.l
in #line directives into just gengtype-lex.l.
gcc/c/
* Make-lang.in (c.srcextra): Don't depend on anything and don't copy
anything.
gcc/cobol/
* Make-lang.in (cobol.srcextra): Use sed to turn
.../gcc/cobol/*.{y,l,h,cc} and cobol/*.{y,l,h,cc} in #line directives
into just *.{y,l,h,cc}.
--- gcc/Makefile.in.jj 2025-03-27 09:29:36.938576746 +0100
+++ gcc/Makefile.in 2025-03-28 14:45:00.960408922 +0100
@@ -2508,7 +2508,7 @@ s-mlib: $(srcdir)/genmultilib Makefile
srcextra: gcc.srcextra lang.srcextra
gcc.srcextra: gengtype-lex.cc
- -cp -p $^ $(srcdir)
+ -sed -e '/^#line/s,".*/gcc/gengtype-lex\.l","gengtype-lex.l",' $^ >
$(srcdir)/$^
AR_OBJS = file-find.o
AR_LIBS = @COLLECT2_LIBS@
--- gcc/c/Make-lang.in.jj 2025-01-02 11:47:22.032336564 +0100
+++ gcc/c/Make-lang.in 2025-03-28 14:48:43.601409373 +0100
@@ -131,8 +131,7 @@ c.all.cross:
c.start.encap:
c.rest.encap:
c.srcinfo:
-c.srcextra: gengtype-lex.cc
- -cp -p $^ $(srcdir)
+c.srcextra:
c.tags: force
cd $(srcdir)/c; $(ETAGS) -o TAGS.sub *.cc *.h; \
$(ETAGS) --include TAGS.sub --include ../TAGS.sub
--- gcc/cobol/Make-lang.in.jj 2025-03-28 14:30:28.251174728 +0100
+++ gcc/cobol/Make-lang.in 2025-03-28 15:08:29.431543005 +0100
@@ -272,8 +272,9 @@ cobol/scan.o: cobol/scan.cc \
# output, and do not require those tools to be installed.
#
cobol.srcextra: cobol/parse.cc cobol/cdf.cc cobol/scan.cc
- -cp -p $^ cobol/parse.h cobol/cdf.h $(srcdir)/cobol/
-
+ -for i in $^ cobol/parse.h cobol/cdf.h; do \
+ sed -e '/^#line/s,"\(.*gcc/\)\?cobol/\([^/]*\.\([ylh]\|cc\)\)","\2",'
$$i \
+ > $(srcdir)/$$i; done
# And the cobol1 front end
Jakub
Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language
> On Mar 28, 2025, at 9:05 AM, Qing Zhao wrote:
>
>
>
>> On Mar 28, 2025, at 08:51, Yeoul Na wrote:
>>
>>
>>
>>> On Mar 27, 2025, at 9:17 AM, Qing Zhao wrote:
>>>
>>> Yeoul,
>>>
>>> Thanks for the writeup.
>>>
>>> So, basically, This writeup insisted on introducing a new “structure scope”
>>> (similar as the instance scope in C++) into C language ONLY for counted_by
>>> attribute:
>>>
>>> 1. Inside counted_by attribute, the name lookup starts:
>>>
>>> A. Inside the current structure first (the NEW structure scope added to
>>> C);
>>> B. Then outside the structure; (other current C scopes, local scope or
>>> global scope)
>>>
>>> 2. When trying to reference a variable outside of the structure scope that
>>> name_conflicts with
>>> a structure member, a new builtin function “__builtin_global_ref” is
>>> introduced for such
>>> purpose.
>>>
>>> ( I think that __builtin_global_ref might not accurate, because the outer
>>> scope might be either global scope or local scope)
>>
>>
>> Clarification: __builtin_global_ref will see the global scope directly. This
>> is similar to global scope resolution syntax (‘::’) in C++.
>
> Yes, that’s my thought too.
>
> Then, you still need another builtin to refer to the local variable with the
> same name as the structure member, for example,
> In the below example, if the “len” inside the counted_by refers to the “const
> int len = 20”, how do you specify this?
>>
>> constexpr int len = 10;
>>
>> void foo (void)
>> {
>> const int len = 20;
>>
>> struct s {
>>int len;
>>int *__counted_by(__builtin_global_ref(len)) buf; // refers to global
>> ‘len'
>> };
>> }
>>
>> Here are some reasons why we chose to provide a global scope resolution
>> builtin, not a builtin to see an outer scope or just a local scope:
>>
>> 1) The builtin is a substitute for some “scope resolution specifier”. Scope
>> specifiers typically meant to choose a “specific" scope.
>> 2) To the best of my knowledge there is no precedence in any other C family
>> language to provide a scope resolution for local scopes.
>
> However, there is possibility that in the above example, the “len” might
> refer to the local variable len, not the global one. How do you specify that?
>
>> 3) Name conflicts with local variables can be easily renamed.
>
> Then more source code change in different places is needed, I am not sure
> whether this is easy to do in some cases.
The change will be only to the local variable and IMOH, renaming local variable
would likely not a trouble in practice.
In fact, when a local variable shadows a global variable like below, there is
currently no way to choose the global variable ‘var’ in C. The programmer
renames their local variable in the case like this.
int var;
void foo(void) {
int var;
// ...
var = 0; // actually wanted to use a global var
}
That said, I do not object to introducing some builtin to specify local scope
at some point, if there is a compelling use case is found during adoption.
>
>> 4) If we provide a builtin that selects outer scope instead, there is no way
>> to choose a global ‘len' if it’s shadowed by a local variable, so then the
>> member name has to be renamed anyway in order to choose a global `len`.
>
> Yes, that’s true. So maybe two builtins are needed?
>
>> 5) This way, code can be written compatibly both in C and C++.
>>
>>>
>>> 3. Where there is confliction between counted_by and VLA such as:
>>>
>>> constexpr int len = 10;
>>>
>>> struct s {
>>> int len;
>>> int *__counted_by(len) buf; // refers to struct member `len`.
>>> int arr[len]; // refers to global constexpr `len`
>>> };
>>>
>>> Issue compiler warning to user to ask the user to use __builtin_global_ref
>>> to distinguish.
>>
>> Additionally, our proposal suggests __builtin_member_ref to explicitly use a
>> member in a similar situation.
>> The builtin could be replaced by ‘__self' or some other syntax once the
>> standard committee decides in the future, but earlier in the thread JeanHeyd
>> pointed out that:
>>
>> "I would like to gently push back about __self__, or __self, or self,
>> because all of these identifiers are fairly common identifiers in code. When
>> I writing the paper for __self_func (
>> https://thephd.dev/_vendor/future_cxx/papers/C%20-%20__self_func.html ), I
>> searched GitHub and other source code indexing and repository services:
>> __self, __self__, and self has a substantial amount of uses. If there's an
>> alternative spelling to consider, I think that would be helpful."
>>
>> Thus, I think instead of trying to stick to a certain syntax right now,
>> using some builtin will allow us to easily migrate to a new syntax by
>> guarding the current usage under a macro.
>>
>> Writing the builtin could be cumbersome but this shall be written only when
>> there is an ambiguity. Btw, I’m open to any other name suggestions for the
>> builtins!
>
> I think that it’s bette
Re: [PATCH RFC] c++: optimize push_to_top_level [PR64500]
On Fri, 28 Mar 2025, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, initially with extra checking to make sure that
> indeed nothing got saved from a namespace level.
>
> This isn't a regression, but a 20% speedup for a simple change is pretty
> attractive; what do people think about this change for GCC 15?
>
> -- 8< --
>
> Profiling showed that the loop to save away IDENTIFIER_BINDINGs from open
> binding levels was taking 5% of total compilation time in the PR116285
> testcase. This turned out to be because we were unnecessarily trying to do
> this for namespaces, whose bindings are found through
> DECL_NAMESPACE_BINDINGS, not IDENTIFIER_BINDING.
>
> As a result we would frequently loop through everything in std::, checking
> whether it needs to be stored, and never storing anything.
>
> This change actually appears to speed up compilation for the PR116285
> testcase by ~20%.
Nice, this also speeds up compilation of stdc++.h by ~20%! And std
module compilation by ~10%. +1
>
> The replaced comments referred either to long-replaced handling of classes
> and templates, or to wanting b to point to :: when the loop exits.
>
> PR c++/64500
> PR c++/116285
>
> gcc/cp/ChangeLog:
>
> * name-lookup.cc (push_to_top_level): Don't try to store_bindings
> for namespace levels.
> ---
> gcc/cp/name-lookup.cc | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/cp/name-lookup.cc b/gcc/cp/name-lookup.cc
> index 7f1ee869d52..61b7bfcaf94 100644
> --- a/gcc/cp/name-lookup.cc
> +++ b/gcc/cp/name-lookup.cc
> @@ -8675,6 +8675,9 @@ store_class_bindings (vec
> *names,
>
> static GTY((deletable)) struct saved_scope *free_saved_scope;
>
> +/* Temporarily make the current scope the global namespace, saving away
> + the current scope for pop_from_top_level. */
> +
> void
> push_to_top_level (void)
> {
> @@ -8716,18 +8719,19 @@ push_to_top_level (void)
> store_class_bindings (previous_class_level->class_shadowed,
> &s->old_bindings);
>
> - /* Have to include the global scope, because class-scope decls
> - aren't listed anywhere useful. */
> + /* Save and clear any IDENTIFIER_BINDING from local scopes. */
>for (; b; b = b->level_chain)
> {
>tree t;
>
> - /* Template IDs are inserted into the global level. If they were
> - inserted into namespace level, finish_file wouldn't find them
> - when doing pending instantiations. Therefore, don't stop at
> - namespace level, but continue until :: . */
> - if (global_scope_p (b))
> - break;
> + /* We don't need to consider namespace scopes, they don't affect
> + IDENTIFIER_BINDING. */
> + if (b->kind == sk_namespace)
> + {
> + /* Jump straight to '::'. */
> + b = NAMESPACE_LEVEL (global_namespace);
> + break;
> + }
>
>store_bindings (b->names, &s->old_bindings);
>/* We also need to check class_shadowed to save class-level type
>
> base-commit: d9b56c65a2697e0d7a6c0f15f1977803dc94579b
> --
> 2.49.0
>
>
Re: [PATCH 08/10] testsuite: aarch64: arm: Fix -mcpu=unset support in some effective targets
On 20/03/2025 16:15, Christophe Lyon wrote:
> Many tests became unsupported on aarch64 when -mcpu=unset was added to
> arm_v8_2a_fp16_neon_ok and arm_v8_2a_bf16_neon_ok effective targets,
> because this flag is only supported on arm.
>
> Since these effective targets are used on arm and aarch64, the patch
> adds -mcpu=unset on arm only, and restores "" on aarch64.
>
> This re-enables bf16 tests on aarch64, and I noticed
> #PASS: 6838 -> 8290
> #UNSUPPORTED: 1491 -> 1030 in gcc.target/aarch64/advsimd-intrinsics
>
> gcc/testsuite/
> * lib/target-supports.exp
> (check_effective_target_arm_v8_2a_fp16_neon_ok_nocache): Use
> -mcpu=unset on arm only.
> (check_effective_target_arm_v8_2a_bf16_neon_ok_nocache): Likewise.
OK.
R.
> ---
> gcc/testsuite/lib/target-supports.exp | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index 09b16a14024..c2df22d2255 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -6660,11 +6660,16 @@ proc check_effective_target_arm_v8_2a_fp16_scalar_ok
> { } {
> proc check_effective_target_arm_v8_2a_fp16_neon_ok_nocache { } {
> global et_arm_v8_2a_fp16_neon_flags
> set et_arm_v8_2a_fp16_neon_flags ""
> +set cpu_unset ""
>
> if { ![istarget arm*-*-*] && ![istarget aarch64*-*-*] } {
> return 0;
> }
>
> +if { [istarget arm*-*-*] } {
> + set cpu_unset "-mcpu=unset"
> +}
> +
> # Iterate through sets of options to find the compiler flags that
> # need to be added to the -march option.
> foreach flags {"" "-mfpu=neon-fp-armv8" "-mfloat-abi=softfp" \
> @@ -6674,8 +6679,8 @@ proc
> check_effective_target_arm_v8_2a_fp16_neon_ok_nocache { } {
> #if !defined (__ARM_FEATURE_FP16_VECTOR_ARITHMETIC)
> #error "__ARM_FEATURE_FP16_VECTOR_ARITHMETIC not defined"
> #endif
> - } "$flags -mcpu=unset -march=armv8.2-a+fp16"] } {
> - set et_arm_v8_2a_fp16_neon_flags "$flags -mcpu=unset
> -march=armv8.2-a+fp16"
> + } "$flags $cpu_unset -march=armv8.2-a+fp16"] } {
> + set et_arm_v8_2a_fp16_neon_flags "$flags $cpu_unset
> -march=armv8.2-a+fp16"
> return 1
> }
> }
> @@ -6871,6 +6876,7 @@ proc add_options_for_arm_fp16fml_neon { flags } {
> proc check_effective_target_arm_v8_2a_bf16_neon_ok_nocache { } {
> global et_arm_v8_2a_bf16_neon_flags
> set et_arm_v8_2a_bf16_neon_flags ""
> +set cpu_unset ""
> set fpu_auto ""
>
> if { ![istarget arm*-*-*] && ![istarget aarch64*-*-*] } {
> @@ -6878,6 +6884,7 @@ proc
> check_effective_target_arm_v8_2a_bf16_neon_ok_nocache { } {
> }
>
> if { [istarget arm*-*-*] } {
> + set cpu_unset "-mcpu=unset"
> set fpu_auto "-mfpu=auto"
> }
>
> @@ -6889,8 +6896,8 @@ proc
> check_effective_target_arm_v8_2a_bf16_neon_ok_nocache { } {
> #if !defined (__ARM_FEATURE_BF16_VECTOR_ARITHMETIC)
> #error "__ARM_FEATURE_BF16_VECTOR_ARITHMETIC not defined"
> #endif
> - } "$flags -mcpu=unset -march=armv8.2-a+bf16"] } {
> - set et_arm_v8_2a_bf16_neon_flags "$flags -mcpu=unset
> -march=armv8.2-a+bf16"
> + } "$flags $cpu_unset -march=armv8.2-a+bf16"] } {
> + set et_arm_v8_2a_bf16_neon_flags "$flags $cpu_unset
> -march=armv8.2-a+bf16"
> return 1
> }
> }
[COMMITTED 002/146] gccrs: Insert trait names during toplevel resolution 2.0
From: Owen Avery gcc/rust/ChangeLog: * resolve/rust-toplevel-name-resolver-2.0.cc (TopLevel::visit): Insert trait names into the type namespace. Signed-off-by: Owen Avery --- gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc b/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc index a0d8492b7eb..fff3769cd70 100644 --- a/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc +++ b/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc @@ -120,6 +120,9 @@ TopLevel::visit (AST::Trait &trait) trait.insert_implict_self ( std::unique_ptr (implicit_self)); + insert_or_error_out (trait.get_identifier ().as_string (), trait, + Namespace::Types); + DefaultResolver::visit (trait); } -- 2.45.2
Re: [PATCH v5] libcpp: Fix incorrect line numbers in large files [PR108900]
On 3/28/25 3:54 AM, yash.shi...@windriver.com wrote:
From: Jeremy Bettis
This patch addresses an issue in the C preprocessor where incorrect
line number information is generated when processing files with a
large number of lines. The problem arises from improper handling
of location intervals in the line map, particularly when locations
exceed LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES.
By ensuring that the highest location is not decremented if it
would move to a different ordinary map, this fix resolves
the line number discrepancies observed in certain test cases.
This change improves the accuracy of line number reporting, benefiting
users relying on precise code coverage and debugging information.
Pushed, thanks.
libcpp/ChangeLog:
PR preprocessor/108900
* files.cc (_cpp_stack_file): Do not decrement highest_location
across distinct maps.
Signed-off-by: Jeremy Bettis
Signed-off-by: Yash Shinde
---
libcpp/files.cc | 9 +
1 file changed, 9 insertions(+)
diff --git a/libcpp/files.cc b/libcpp/files.cc
index 1ed19ca..c1abde6639f 100644
--- a/libcpp/files.cc
+++ b/libcpp/files.cc
@@ -1046,6 +1046,15 @@ _cpp_stack_file (cpp_reader *pfile, _cpp_file *file,
include_type type,
&& type < IT_DIRECTIVE_HWM
&& (pfile->line_table->highest_location
!= LINE_MAP_MAX_LOCATION - 1));
+
+ if (decrement && LINEMAPS_ORDINARY_USED (pfile->line_table))
+{
+ const line_map_ordinary *map
+ = LINEMAPS_LAST_ORDINARY_MAP (pfile->line_table);
+ if (map && map->start_location == pfile->line_table->highest_location)
+ decrement = false;
+}
+
if (decrement)
pfile->line_table->highest_location--;
[PATCH RFC] c++: optimize push_to_top_level [PR64500]
Tested x86_64-pc-linux-gnu, initially with extra checking to make sure that
indeed nothing got saved from a namespace level.
This isn't a regression, but a 20% speedup for a simple change is pretty
attractive; what do people think about this change for GCC 15?
-- 8< --
Profiling showed that the loop to save away IDENTIFIER_BINDINGs from open
binding levels was taking 5% of total compilation time in the PR116285
testcase. This turned out to be because we were unnecessarily trying to do
this for namespaces, whose bindings are found through
DECL_NAMESPACE_BINDINGS, not IDENTIFIER_BINDING.
As a result we would frequently loop through everything in std::, checking
whether it needs to be stored, and never storing anything.
This change actually appears to speed up compilation for the PR116285
testcase by ~20%.
The replaced comments referred either to long-replaced handling of classes
and templates, or to wanting b to point to :: when the loop exits.
PR c++/64500
PR c++/116285
gcc/cp/ChangeLog:
* name-lookup.cc (push_to_top_level): Don't try to store_bindings
for namespace levels.
---
gcc/cp/name-lookup.cc | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/gcc/cp/name-lookup.cc b/gcc/cp/name-lookup.cc
index 7f1ee869d52..61b7bfcaf94 100644
--- a/gcc/cp/name-lookup.cc
+++ b/gcc/cp/name-lookup.cc
@@ -8675,6 +8675,9 @@ store_class_bindings (vec *names,
static GTY((deletable)) struct saved_scope *free_saved_scope;
+/* Temporarily make the current scope the global namespace, saving away
+ the current scope for pop_from_top_level. */
+
void
push_to_top_level (void)
{
@@ -8716,18 +8719,19 @@ push_to_top_level (void)
store_class_bindings (previous_class_level->class_shadowed,
&s->old_bindings);
- /* Have to include the global scope, because class-scope decls
- aren't listed anywhere useful. */
+ /* Save and clear any IDENTIFIER_BINDING from local scopes. */
for (; b; b = b->level_chain)
{
tree t;
- /* Template IDs are inserted into the global level. If they were
-inserted into namespace level, finish_file wouldn't find them
-when doing pending instantiations. Therefore, don't stop at
-namespace level, but continue until :: . */
- if (global_scope_p (b))
- break;
+ /* We don't need to consider namespace scopes, they don't affect
+IDENTIFIER_BINDING. */
+ if (b->kind == sk_namespace)
+ {
+ /* Jump straight to '::'. */
+ b = NAMESPACE_LEVEL (global_namespace);
+ break;
+ }
store_bindings (b->names, &s->old_bindings);
/* We also need to check class_shadowed to save class-level type
base-commit: d9b56c65a2697e0d7a6c0f15f1977803dc94579b
--
2.49.0
Re:[pushed] [PATCH 1/2] LoongArch: Set default alignment for functions jumps loops and labels.
Pushed to r15-9022.
在 2025/3/27 下午3:01, Lulu Cheng 写道:
Based on r15-7624, a set of align combinations with better performance
was tested through spec2006.
LA464: -falign-loops=8 -falign-functions=32 -falign-jumps=32 -falign-labels=8
LA664: -falign-loops=16 -falign-functions=16 -falign-jumps=32 -falign-labels=8
gcc/ChangeLog:
* config/loongarch/loongarch-def.cc
(la464_align): Add settings for labels.
(la664_align): Likewise.
* config/loongarch/loongarch-opts.cc
(loongarch_target_option_override): Likewise.
* config/loongarch/loongarch-tune.h
(struct loongarch_align): Implement the function `label_`.
---
gcc/config/loongarch/loongarch-def.cc | 4 ++--
gcc/config/loongarch/loongarch-opts.cc | 3 +++
gcc/config/loongarch/loongarch-tune.h | 9 -
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/gcc/config/loongarch/loongarch-def.cc
b/gcc/config/loongarch/loongarch-def.cc
index 5f235a04ef2..04b277eb742 100644
--- a/gcc/config/loongarch/loongarch-def.cc
+++ b/gcc/config/loongarch/loongarch-def.cc
@@ -107,12 +107,12 @@ array_tune loongarch_cpu_cache =
static inline loongarch_align la464_align ()
{
- return loongarch_align ().function_ ("32").loop_ ("16").jump_ ("16");
+ return loongarch_align ().function_ ("32").loop_ ("8").jump_ ("32").label_
("8");
}
static inline loongarch_align la664_align ()
{
- return loongarch_align ().function_ ("8").loop_ ("8").jump_ ("32");
+ return loongarch_align ().function_ ("16").loop_ ("16").jump_ ("32").label_
("8");
}
array_tune loongarch_cpu_align =
diff --git a/gcc/config/loongarch/loongarch-opts.cc
b/gcc/config/loongarch/loongarch-opts.cc
index c2a63f75fc2..6e72084b9be 100644
--- a/gcc/config/loongarch/loongarch-opts.cc
+++ b/gcc/config/loongarch/loongarch-opts.cc
@@ -965,6 +965,9 @@ loongarch_target_option_override (struct loongarch_target
*target,
if (opts->x_flag_align_jumps && !opts->x_str_align_jumps)
opts->x_str_align_jumps = loongarch_cpu_align[target->cpu_tune].jump;
+
+ if (opts->x_flag_align_labels && !opts->x_str_align_labels)
+ opts->x_str_align_labels = loongarch_cpu_align[target->cpu_tune].label;
}
/* Set up parameters to be used in prefetching algorithm. */
diff --git a/gcc/config/loongarch/loongarch-tune.h
b/gcc/config/loongarch/loongarch-tune.h
index f7819fe7678..0ae74e77f99 100644
--- a/gcc/config/loongarch/loongarch-tune.h
+++ b/gcc/config/loongarch/loongarch-tune.h
@@ -177,8 +177,9 @@ struct loongarch_align {
const char *function; /* default value for -falign-functions */
const char *loop; /* default value for -falign-loops */
const char *jump; /* default value for -falign-jumps */
+ const char *label; /* default value for -falign-labels */
- loongarch_align () : function (nullptr), loop (nullptr), jump (nullptr) {}
+ loongarch_align () : function (nullptr), loop (nullptr), jump (nullptr),
label (nullptr) {}
loongarch_align function_ (const char *_function)
{
@@ -197,6 +198,12 @@ struct loongarch_align {
jump = _jump;
return *this;
}
+
+ loongarch_align label_ (const char *_label)
+ {
+label = _label;
+return *this;
+ }
};
#endif /* LOONGARCH_TUNE_H */
[COMMITTED 031/146] gccrs: Improve handling of static items in toplevel 2.0
From: Owen Avery
gcc/rust/ChangeLog:
* resolve/rust-toplevel-name-resolver-2.0.cc
(TopLevel::visit): Use DefaultResolver::visit and avoid a call
to Identifier::as_string while handling instances of StaticItem.
Signed-off-by: Owen Avery
---
gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc
b/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc
index ef7a727dae9..a2f695e54f6 100644
--- a/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc
+++ b/gcc/rust/resolve/rust-toplevel-name-resolver-2.0.cc
@@ -241,13 +241,10 @@ TopLevel::visit (AST::BlockExpr &expr)
void
TopLevel::visit (AST::StaticItem &static_item)
{
- auto sub_vis
-= [this, &static_item] () { static_item.get_expr ().accept_vis (*this); };
-
- ctx.scoped (Rib::Kind::Item, static_item.get_node_id (), sub_vis);
-
- insert_or_error_out (static_item.get_identifier ().as_string (), static_item,
+ insert_or_error_out (static_item.get_identifier (), static_item,
Namespace::Values);
+
+ DefaultResolver::visit (static_item);
}
void
--
2.45.2
[PATCH] combine: Use reg_used_between_p rather than modified_between_p in two spots [PR119291]
Hi!
The following testcase is miscompiled on x86_64-linux at -O2 by the combiner.
We have from earlier combinations
(insn 22 21 23 4 (set (reg:SI 104 [ _7 ])
(const_int 0 [0])) "pr119291.c":25:15 96 {*movsi_internal}
(nil))
(insn 23 22 24 4 (set (reg/v:SI 117 [ e ])
(reg/v:SI 116 [ e ])) 96 {*movsi_internal}
(expr_list:REG_DEAD (reg/v:SI 116 [ e ])
(nil)))
(note 24 23 25 4 NOTE_INSN_DELETED)
(insn 25 24 26 4 (parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (neg:SI (reg:SI 104 [ _7 ]))
(const_int 0 [0])))
(set (reg/v:SI 116 [ e ])
(neg:SI (reg:SI 104 [ _7 ])))
]) "pr119291.c":26:13 977 {*negsi_2}
(expr_list:REG_DEAD (reg:SI 104 [ _7 ])
(nil)))
(note 26 25 27 4 NOTE_INSN_DELETED)
(insn 27 26 28 4 (set (reg:DI 128 [ _9 ])
(ne:DI (reg:CCZ 17 flags)
(const_int 0 [0]))) "pr119291.c":26:13 1447 {*setcc_di_1}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
and try_combine is called on i3 25 and i2 22 (second time)
and reach the hunk being patched with simplified i3
(insn 25 24 26 4 (parallel [
(set (pc)
(pc))
(set (reg/v:SI 116 [ e ])
(const_int 0 [0]))
]) "pr119291.c":28:13 977 {*negsi_2}
(expr_list:REG_DEAD (reg:SI 104 [ _7 ])
(nil)))
and
(insn 22 21 23 4 (set (reg:SI 104 [ _7 ])
(const_int 0 [0])) "pr119291.c":27:15 96 {*movsi_internal}
(nil))
Now, the try_combine code there attempts to split two independent
sets in newpat by moving one of them to i2.
And among other tests it checks
!modified_between_p (SET_DEST (set1), i2, i3)
which is certainly needed, if there would be say
(set (reg/v:SI 116 [ e ]) (const_int 42 [0x2a]))
in between i2 and i3, we couldn't do that, as that set would overwrite
the value set by set1 we want to move to the i2 position.
But in this case pseudo 116 isn't set in between i2 and i3, but used
(and additionally there is a REG_DEAD note for it).
This is equally bad for the move, because while the i3 insn
and later will see the pseudo value that we set, the insn in between
which uses the value will see a different value from the one that
it should see.
As we don't check for that, in the end try_combine succeeds and
changes the IL to:
(insn 22 21 23 4 (set (reg/v:SI 116 [ e ])
(const_int 0 [0])) "pr119291.c":27:15 96 {*movsi_internal}
(nil))
(insn 23 22 24 4 (set (reg/v:SI 117 [ e ])
(reg/v:SI 116 [ e ])) 96 {*movsi_internal}
(expr_list:REG_DEAD (reg/v:SI 116 [ e ])
(nil)))
(note 24 23 25 4 NOTE_INSN_DELETED)
(insn 25 24 26 4 (set (pc)
(pc)) "pr119291.c":28:13 2147483647 {NOOP_MOVE}
(nil))
(note 26 25 27 4 NOTE_INSN_DELETED)
(insn 27 26 28 4 (set (reg:DI 128 [ _9 ])
(const_int 0 [0])) "pr119291.c":28:13 95 {*movdi_internal}
(nil))
(note, the i3 got turned into a nop and try_combine also modified insn 27).
The following patch replaces the modified_between_p
tests with reg_used_between_p, my understanding is that
modified_between_p is a subset of reg_used_between_p, so one
doesn't need both.
Bootstrapped/regtested on x86_64-linux, i686-linux, aarch64-linux,
powerpc64le-linux and s390x-linux, ok for trunk?
Looking at this some more today, I think we should special case
set_noop_p because that can be put into i2 (except for the JUMP_P
violations), currently both modified_between_p (pc_rtx, i2, i3)
and reg_used_between_p (pc_rtx, i2, i3) returns false.
I'll post a patch incrementally for that (but that feels like
new optimization, so probably not something that should be backported).
2025-03-28 Jakub Jelinek
PR rtl-optimization/119291
* combine.cc (try_combine): For splitting of PARALLEL with
2 independent SETs into i2 and i3 sets check reg_used_between_p
of the SET_DESTs rather than just modified_between_p.
* gcc.c-torture/execute/pr119291.c: New test.
--- gcc/combine.cc.jj 2025-03-25 09:34:33.469102343 +0100
+++ gcc/combine.cc 2025-03-27 09:50:15.768567383 +0100
@@ -4012,18 +4012,18 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
rtx set1 = XVECEXP (newpat, 0, 1);
/* Normally, it doesn't matter which of the two is done first, but
-one which uses any regs/memory set in between i2 and i3 can't
-be first. The PARALLEL might also have been pre-existing in i3,
-so we need to make sure that we won't wrongly hoist a SET to i2
-that would conflict with a death note present in there, or would
-have its dest modified between i2 and i3. */
+one which uses any regs/memory set or used in between i2 and i3
+can't be first. The PARALLEL might also have been pre-existing
+in i3, so we need to make sure that we won't wrongly hoist a SET
+to i2 that would conflict with a death note present in there, or
+would have its dest modified or used between i2
[wwwdocs] gcc-15/changes.html + projects/gomp/: OpenMP update for interop
This patch updates both https://gcc.gnu.org/gcc-15/changes.html#openmp and https://gcc.gnu.org/projects/gomp/ for the current OpenMP implementation status. It also fixes a typo and intents to actually commit the change that mentions the support for aarch64 to nvptx offloading, cf. https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671799.html Comments before [or after :-)] I commit(ted) it? Tobias PS: For dispatch, the OpenMP 6 support is almost but not fully complete, lacking a small addition to adjust_args. If that still lands for GCC 15, the wording could be simplified. gcc-15/changes.html + projects/gomp/: OpenMP update for interop It additionally mentiones the improved aarch64 with nvptx offload support (PR96265); the change was discussed on Dev 17, 2024 but not committed. htdocs/gcc-15/changes.html | 23 --- htdocs/projects/gomp/index.html | 10 +- 2 files changed, 25 insertions(+), 8 deletions(-) diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html index 14bd3f77..d1dbe358 100644 --- a/htdocs/gcc-15/changes.html +++ b/htdocs/gcc-15/changes.html @@ -66,6 +66,11 @@ a work-in-progress. href="https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto-incremental"; >-flto-incremental=. + +For offloading, issues preventing some host-device architecture +combinations have been resolved. In particular, offloading from aarch64 +hosts to nvptx devices is now supported. + @@ -118,10 +123,22 @@ a work-in-progress. selectors in both metadirective and declare variant (the latter with some restrictions). + +The interop construct and the OpenMP interoperability API +routines for C, C++ and Fortran are now implemented, including the +OpenMP 6.0 additions. This includes foreign-runtime support for https://gcc.gnu.org/onlinedocs/libgomp/Foreign-runtime-support-for-Nvidia-GPUs.html"; +>Cuda, Cuda Driver, and HIP on Nvida GPUs and for https://gcc.gnu.org/onlinedocs/libgomp/Foreign-runtime-support-for-AMD-GPUs.html"; +>HIP and HSA on AMD GPUs. + The OpenMP 5.1 dispatch construct has been implemented -with support for the adjust_args clause to the -declare variant directive. +with support for the adjust_args and append_args +clauses to the declare variant directive, including the +following OpenMP 6.0 additions: the interop clause to +dispatch and the syntax extensions to append_args +are supported. OpenMP 6.0: The PowerPC Darwin - Fortran's IEEE modules are now suppored on Darwin PowerPC. + Fortran's IEEE modules are now supported on Darwin PowerPC. diff --git a/htdocs/projects/gomp/index.html b/htdocs/projects/gomp/index.html index 97d14308..ab45cc5e 100644 --- a/htdocs/projects/gomp/index.html +++ b/htdocs/projects/gomp/index.html @@ -708,9 +708,8 @@ than listed, depending on resolved corner cases and optimizations. declare variant: new clauses adjust_args and append_args -GCC 15 -For append_args, all interop objects - must be specified in the interop clause of dispatch +GCC 15 + dispatch construct @@ -734,8 +733,9 @@ than listed, depending on resolved corner cases and optimizations. interop directive -No - +GCC 15 +Cf. https://gcc.gnu.org/onlinedocs/libgomp/Offload-Target-Specifics.html";> + Offload-Target Specifics omp_interop_t object support in runtime routines
[PATCH] combine: Special case set_noop_p in two spots
Hi!
Here is the incremental patch I was talking about.
For noop sets, we don't need to test much, they can go to i2
unless that would violate i3 JUMP condition.
With this the try_combine on the pr119291.c testcase doesn't fail,
but succeeds and we get
(insn 22 21 23 4 (set (pc)
(pc)) "pr119291.c":27:15 2147483647 {NOOP_MOVE}
(nil))
(insn 23 22 24 4 (set (reg/v:SI 117 [ e ])
(reg/v:SI 116 [ e ])) 96 {*movsi_internal}
(expr_list:REG_DEAD (reg/v:SI 116 [ e ])
(nil)))
(note 24 23 25 4 NOTE_INSN_DELETED)
(insn 25 24 26 4 (set (reg/v:SI 116 [ e ])
(const_int 0 [0])) "pr119291.c":28:13 96 {*movsi_internal}
(nil))
(note 26 25 27 4 NOTE_INSN_DELETED)
(insn 27 26 28 4 (set (reg:DI 128 [ _9 ])
(const_int 0 [0])) "pr119291.c":28:13 95 {*movdi_internal}
(nil))
after it.
Ok for trunk if this passes bootstrap/regtest?
2025-03-28 Jakub Jelinek
* combine.cc (try_combine): Sets which satisfy set_noop_p can go
to i2 unless i3 is a jump and the other set is not.
--- gcc/combine.cc.jj 2025-03-28 11:44:15.491458700 +0100
+++ gcc/combine.cc 2025-03-28 12:11:49.505835983 +0100
@@ -4017,13 +4017,14 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
in i3, so we need to make sure that we won't wrongly hoist a SET
to i2 that would conflict with a death note present in there, or
would have its dest modified or used between i2 and i3. */
- if (!modified_between_p (SET_SRC (set1), i2, i3)
- && !(REG_P (SET_DEST (set1))
- && find_reg_note (i2, REG_DEAD, SET_DEST (set1)))
- && !(GET_CODE (SET_DEST (set1)) == SUBREG
- && find_reg_note (i2, REG_DEAD,
-SUBREG_REG (SET_DEST (set1
- && !reg_used_between_p (SET_DEST (set1), i2, i3)
+ if ((set_noop_p (set1)
+ || (!modified_between_p (SET_SRC (set1), i2, i3)
+ && !(REG_P (SET_DEST (set1))
+ && find_reg_note (i2, REG_DEAD, SET_DEST (set1)))
+ && !(GET_CODE (SET_DEST (set1)) == SUBREG
+ && find_reg_note (i2, REG_DEAD,
+ SUBREG_REG (SET_DEST (set1
+ && !reg_used_between_p (SET_DEST (set1), i2, i3)))
/* If I3 is a jump, ensure that set0 is a jump so that
we do not create invalid RTL. */
&& (!JUMP_P (i3) || SET_DEST (set0) == pc_rtx)
@@ -4032,13 +4033,14 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
newi2pat = set1;
newpat = set0;
}
- else if (!modified_between_p (SET_SRC (set0), i2, i3)
- && !(REG_P (SET_DEST (set0))
- && find_reg_note (i2, REG_DEAD, SET_DEST (set0)))
- && !(GET_CODE (SET_DEST (set0)) == SUBREG
- && find_reg_note (i2, REG_DEAD,
- SUBREG_REG (SET_DEST (set0
- && !reg_used_between_p (SET_DEST (set0), i2, i3)
+ else if ((set_noop_p (set0)
+ || (!modified_between_p (SET_SRC (set0), i2, i3)
+ && !(REG_P (SET_DEST (set0))
+&& find_reg_note (i2, REG_DEAD, SET_DEST (set0)))
+ && !(GET_CODE (SET_DEST (set0)) == SUBREG
+&& find_reg_note (i2, REG_DEAD,
+ SUBREG_REG (SET_DEST (set0
+ && !reg_used_between_p (SET_DEST (set0), i2, i3)))
/* If I3 is a jump, ensure that set1 is a jump so that
we do not create invalid RTL. */
&& (!JUMP_P (i3) || SET_DEST (set1) == pc_rtx)
Jakub
Re: [PATCH] tailc: Handle musttail noreturn calls [PR119483]
On Thu, 27 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> The following (first) testcase is accepted by clang (if clang::musttail)
> and rejected by gcc, because we discover the call is noreturn and then bail
> out because we don't want noreturn tailcalls.
> The general reason not to support noreturn tail calls is for cases like
> abort where we want nicer backtrace, but if user asks explicitly to
> musttail a call which either is explicitly noreturn or is implicitly
> determined to be noreturn, I don't see a reason why we couldn't do that.
> Both for tail calls and tail recursions.
>
> An alternative would be to keep rejecting musttail to explicit noreturn,
> but not actually implicitly mark anything as noreturn if it has any musttail
> calls. But it is unclear how we could do that, such marking is I think done
> typically before IPA and e.g. for LTO we won't know whether some other TU
> could have musttail calls to it. And keeping around both explicit and
> implicit noreturn bits would be ugly. Well, I guess we could differentiate
> between presence of noreturn/_Noreturn attributes and just ECF_NORETURN
> without those, but then tailc would still need to support it, just error out
> if it was explicit.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
> 2025-03-27 Jakub Jelinek
>
> PR tree-optimization/119483
> * tree-tailcall.cc (find_tail_calls): Handle noreturn musttail
> calls.
> (eliminate_tail_call): Likewise.
> (tree_optimize_tail_calls_1): If cfun->has_musttail and
> diag_musttail, handle also basic blocks with no successors
> with noreturn musttail calls.
> * calls.cc (can_implement_as_sibling_call_p): Allow ECF_NORETURN
> calls if they are musttail calls.
>
> * c-c++-common/pr119483-1.c: New test.
> * c-c++-common/pr119483-2.c: New test.
>
> --- gcc/tree-tailcall.cc.jj 2025-03-25 09:36:31.502487137 +0100
> +++ gcc/tree-tailcall.cc 2025-03-27 16:18:30.017898249 +0100
> @@ -484,7 +484,8 @@ find_tail_calls (basic_block bb, struct
>size_t idx;
>tree var;
>
> - if (!single_succ_p (bb))
> + if (!single_succ_p (bb)
> + && (EDGE_COUNT (bb->succs) || !cfun->has_musttail || !diag_musttail))
> {
>/* If there is an abnormal edge assume it's the only extra one.
>Tolerate that case so that we can give better error messages
> @@ -605,7 +606,7 @@ find_tail_calls (basic_block bb, struct
>/* If the call might throw an exception that wouldn't propagate out of
> cfun, we can't transform to a tail or sibling call (82081). */
>if ((stmt_could_throw_p (cfun, stmt)
> - && !stmt_can_throw_external (cfun, stmt)) || !single_succ_p (bb))
> + && !stmt_can_throw_external (cfun, stmt)) || EDGE_COUNT (bb->succs) >
> 1)
>{
> if (stmt == last_stmt)
>maybe_error_musttail (call,
> @@ -760,10 +761,12 @@ find_tail_calls (basic_block bb, struct
>a = NULL_TREE;
>auto_bitmap to_move_defs;
>auto_vec to_move_stmts;
> + bool is_noreturn
> += EDGE_COUNT (bb->succs) == 0 && gimple_call_noreturn_p (call);
>
>abb = bb;
>agsi = gsi;
> - while (1)
> + while (!is_noreturn)
> {
>tree tmp_a = NULL_TREE;
>tree tmp_m = NULL_TREE;
> @@ -844,7 +847,22 @@ find_tail_calls (basic_block bb, struct
> }
>
>/* See if this is a tail call we can handle. */
> - ret_var = gimple_return_retval (as_a (stmt));
> + if (is_noreturn)
> +{
> + tree rettype = TREE_TYPE (TREE_TYPE (current_function_decl));
> + tree calltype = TREE_TYPE (gimple_call_fntype (call));
> + if (!VOID_TYPE_P (rettype)
> + && !useless_type_conversion_p (rettype, calltype))
> + {
> + maybe_error_musttail (call,
> + _("call and return value are different"),
> + diag_musttail);
> + return;
> + }
> + ret_var = NULL_TREE;
> +}
> + else
> +ret_var = gimple_return_retval (as_a (stmt));
>
>/* We may proceed if there either is no return value, or the return value
> is identical to the call's return or if the return decl is an empty type
> @@ -1153,24 +1171,32 @@ eliminate_tail_call (struct tailcall *t,
> gsi_prev (&gsi2);
> }
>
> - /* Number of executions of function has reduced by the tailcall. */
> - e = single_succ_edge (gsi_bb (t->call_gsi));
> + if (gimple_call_noreturn_p (as_a (stmt)))
> +{
> + e = make_edge (gsi_bb (t->call_gsi), first, EDGE_FALLTHRU);
> + e->probability = profile_probability::always ();
> +}
> + else
> +{
> + /* Number of executions of function has reduced by the tailcall. */
> + e = single_succ_edge (gsi_bb (t->call_gsi));
>
> - profile_count count = e->count ();
> + profile_count count = e->count ();
>
> - /* When profile is inconsistent and the recursion edge is more frequent
> - than number of executions of functions, scale it down
Re: [PATCH] PR tree-optimization/119471 - If the LHS does not contain zero, neither do multiply operands.
On Fri, Mar 28, 2025 at 12:28 AM Andrew MacLeod wrote: > > This patch fixes both 119471 and the remainder of 110992. > > At issue is we do not recognize that if > >"a * b != 0" , then neither "a" nor "b" can be zero. > > This is fairly trivial with range-ops. op1_range and op2_range for > operator_mult are taught that if the LHS does not contain zero, than > neither does either operand. > > Included are patches for trunk (gcc15), gcc14, and gcc13. All are > basically the same few lines. > > I presume we want to wait for stage 1 to check this into trunk . > > Bootstraps with no regressions on x86_64-pc-linux-gnu on all 3 > branches. OK for gcc13 and gcc14 branches? This is OK for branches only after it was on trunk. Since one of the PRs is a regression it's technically OK for trunk now. Richard. > > Andrew >
Re: [PATCH][gcc13] PR tree-optimization/117287 - Backport new assume implementation
On Thu, Mar 27, 2025 at 8:14 PM Andrew MacLeod wrote: > > This patch backports the ASSUME support that was rewritten in GCC 15. > > Its slightly more complicated than the port to GCC 14 was in that a few > classes have been rewritten. I've isolated them all to tree-assume.cc > which contains the pass. > > It has to also bring in the ssa_cache and lazy_ssa_cache from gcc14, > along with some tweaks to those classes to deal with changes in the way > range_allocators worked started in GCC14. Those changes are are all the > top of the tree-assume.cc file. The rest of the file is a carbon copy of > the GCC14 version. (well, what should be... there is an outstanding > debug output support that was never submitted I discovered) > > I'm not sure if its worth putting this in GCC13 or not, but I will > submit it and leave it to the release managers :-) It should be low > risk, especially since assume was experimental support? I have no strong opinion here besides questioning whether it's necessary (as you say, assume is experimental) and the fact that by splicing out the VRP changes to a special place further maintenance is made more difficult. IMO, up to you (expecting you'll fix issues if they come up), but would like to hear a 2nd opinion from Jakub. Richard. > Bootstraps on x86_64-pc-linux-gnu with no regressions. > > > Andrew
Re: [PATCH] Further use of mod_scope in modified_type_die
On Fri, Mar 28, 2025 at 8:32 AM Eric Botcazou wrote: > > > Let's involve Eric here, I have no idea what was intended here. > > We discussed it with Tom internally and he makes the final decisions here. Well the, Tom, go ahead. Richard. > -- > Eric Botcazou > >
Re: [PATCH][gcc13] PR tree-optimization/117287 - Backport new assume implementation
On Fri, Mar 28, 2025 at 08:12:35AM +0100, Richard Biener wrote: > On Thu, Mar 27, 2025 at 8:14 PM Andrew MacLeod wrote: > > > > This patch backports the ASSUME support that was rewritten in GCC 15. > > > > Its slightly more complicated than the port to GCC 14 was in that a few > > classes have been rewritten. I've isolated them all to tree-assume.cc > > which contains the pass. > > > > It has to also bring in the ssa_cache and lazy_ssa_cache from gcc14, > > along with some tweaks to those classes to deal with changes in the way > > range_allocators worked started in GCC14. Those changes are are all the > > top of the tree-assume.cc file. The rest of the file is a carbon copy of > > the GCC14 version. (well, what should be... there is an outstanding > > debug output support that was never submitted I discovered) > > > > I'm not sure if its worth putting this in GCC13 or not, but I will > > submit it and leave it to the release managers :-) It should be low > > risk, especially since assume was experimental support? > > I have no strong opinion here besides questioning whether it's > necessary (as you say, assume is experimental) and the fact that > by splicing out the VRP changes to a special place further maintenance > is made more difficult. > > IMO, up to you (expecting you'll fix issues if they come up), but would > like to hear a 2nd opinion from Jakub. I'd probably apply it, it was a wrong-code issue and I'm not sure users understand assume as experimental. While the [[assume (...)]]; form is a C++23 feature which is experimental, we accept that attribute even since C++11 and in C23 and in the __attribute__((assume (...))); form everywhere and as a documented extension. If the ranger changes are done only when users actually use assume rather than all the time (and only when using non-trivial assumptions, trivial ones with no side-effects are turned into if (!x) __builtin_unreachable ()), I think this decreases the risks. Jakub
[PATCH] [COBOL] use native_encode_real
The following avoids the round-trip through a newly built tree and
instead directly uses the now exported native_encode_real.
Tested on x86_64-unknown-linux-gnu.
OK?
gcc/cobol/
* genapi.cc (initial_from_float128): Use native_encode_real.
---
gcc/cobol/genapi.cc | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
index 032236b15db..bc915338158 100644
--- a/gcc/cobol/genapi.cc
+++ b/gcc/cobol/genapi.cc
@@ -15680,24 +15680,23 @@ initial_from_float128(cbl_field_t *field)
case FldFloat:
{
- tree tem;
retval = (char *)xmalloc(field->data.capacity);
switch( field->data.capacity )
{
case 4:
value = real_value_truncate (TYPE_MODE (FLOAT), value);
- tem = build_real (FLOAT, value);
- native_encode_expr (tem, (unsigned char *)retval, 4, 0);
+ native_encode_real (SCALAR_FLOAT_TYPE_MODE (FLOAT), &value,
+ (unsigned char *)retval, 4, 0);
break;
case 8:
value = real_value_truncate (TYPE_MODE (DOUBLE), value);
- tem = build_real (DOUBLE, value);
- native_encode_expr (tem, (unsigned char *)retval, 8, 0);
+ native_encode_real (SCALAR_FLOAT_TYPE_MODE (DOUBLE), &value,
+ (unsigned char *)retval, 8, 0);
break;
case 16:
value = real_value_truncate (TYPE_MODE (FLOAT128), value);
- tem = build_real (FLOAT128, value);
- native_encode_expr (tem, (unsigned char *)retval, 16, 0);
+ native_encode_real (SCALAR_FLOAT_TYPE_MODE (FLOAT128), &value,
+ (unsigned char *)retval, 16, 0);
break;
}
break;
--
2.43.0
Re: [PATCH] [COBOL] use native_encode_real
On Fri, Mar 28, 2025 at 08:54:53AM +0100, Richard Biener wrote:
> The following avoids the round-trip through a newly built tree and
> instead directly uses the now exported native_encode_real.
>
> Tested on x86_64-unknown-linux-gnu.
>
> OK?
>
> gcc/cobol/
> * genapi.cc (initial_from_float128): Use native_encode_real.
LGTM.
Note, we still have at least
/* ??? Use native_encode_* below. */
retval = (char *)xmalloc(field->data.capacity);
switch(field->data.capacity)
{
case 1:
*(signed char *)retval = (signed char)i.slow ();
break;
case 2:
*(signed short *)retval = (signed short)i.slow ();
break;
case 4:
*(signed int *)retval = (signed int)i.slow ();
break;
case 8:
*(signed long *)retval = (signed long)i.slow ();
break;
case 16:
*(unsigned long *)retval = (unsigned long)i.ulow ();
*((signed long *)retval + 1) = (signed long)i.shigh ();
break;
that needs some endian handling (and is also wrong for
hosts which don't have 1 byte chars, 2 byte shorts, 4 byte ints
and 8 byte longs), dunno if we want a round-trip through wide_int_to_tree
and native_encode_expr in that case or if we do similar hack with exporting
native_encode_int's helper or native_encode_int itself which will accept
wide_int + type rather than tree.
And I'm sure trying to do a cross from powerpc-linux to x86_64-linux
will show up tons of other problems.
Jakub
Re: [PATCH] other/119510 - use --enable-languages=default,cobol for release tarballs
On Fri, Mar 28, 2025 at 03:26:04PM +0100, Richard Biener wrote: > The following adds cobol to the set of languages built during release > tarball building so the bison and flex generated sources for cobol > are included in the tarball. > > OK? > > I think an explicit list is better since you'll get an error if > prerequesites for a language are not present instead of silently > disabling it as it is done with =all. Note this does not fix the > missed texinfo generated files for other languages. I do have a > RC tarball built with =all, I can see to compare contents between > that and a =default - is that interesting? > > PR other/119510 > * maintainer-scripts/gcc_release: Use --enable-languages=default,cobol > when building generated files. Ok. Jakub
