[patch,avr,applied] Clarify some optimization options.
Applied the patch below.
Johann
--
AVR: Clarify some optimization options.
gcc/
* doc/invoke.texi (AVR Optimization Options)
<-maccumulate-args>: Refer to -fdefer-pop.
<-muse-nonzero-bits>: Re-formulate what the option does.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 81bfacfc35d..36b252be387 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -24555,6 +24555,8 @@ Accumulate outgoing function arguments and
acquire/release the needed
stack space for outgoing function arguments once in function
prologue/epilogue. Without this option, outgoing arguments are pushed
before calling a function and popped afterwards.
+See also the @option{-fdefer-pop}
+@ref{Optimize Options,,optimization option}.
Popping the arguments after the function call can be expensive on
AVR so that accumulating the stack space might lead to smaller
@@ -24632,7 +24634,8 @@ This optimization is turned on per default for
@option{-O2} and higher.
@opindex muse-nonzero-bits
@item -muse-nonzero-bits
-Enable some patterns for bit optimizations that depend on specific values.
+Enable optimizations that are only possible when some bits in a
+register are always zero.
This optimization is turned on per default for @option{-O2} and higher.
@end table
[COMMITTED 120/146] gccrs: Remove dead code related to external functions
From: Owen Avery
gcc/rust/ChangeLog:
* ast/rust-ast-collector.cc
(TokenCollector::visit): Remove visitor for NamedFunctionParam.
* ast/rust-ast-collector.h
(TokenCollector::visit): Likewise.
* ast/rust-ast-full-decls.h
(class NamedFunctionParam): Remove forward declaration.
* ast/rust-ast-visitor.cc
(DefaultASTVisitor::visit): Remove visitor for
NamedFunctionParam.
* ast/rust-ast-visitor.h
(DefaultASTVisitor::visit): Likewise.
* ast/rust-ast.cc
(NamedFunctionParam::as_string): Remove.
* ast/rust-item.h
(class NamedFunctionParam): Remove.
(class ExternalFunctionItem): Remove.
* parse/rust-parse-impl.h
(Parser::parse_named_function_param): Remove.
(Parser::parse_named_function_params): Remove.
* parse/rust-parse.h
(Parser::parse_named_function_param): Remove.
(Parser::parse_named_function_params): Remove.
Signed-off-by: Owen Avery
---
gcc/rust/ast/rust-ast-collector.cc | 23 ---
gcc/rust/ast/rust-ast-collector.h | 1 -
gcc/rust/ast/rust-ast-full-decls.h | 1 -
gcc/rust/ast/rust-ast-visitor.cc | 8 -
gcc/rust/ast/rust-ast-visitor.h| 1 -
gcc/rust/ast/rust-ast.cc | 16 --
gcc/rust/ast/rust-item.h | 297 -
gcc/rust/parse/rust-parse-impl.h | 100 --
gcc/rust/parse/rust-parse.h| 4 -
9 files changed, 451 deletions(-)
diff --git a/gcc/rust/ast/rust-ast-collector.cc
b/gcc/rust/ast/rust-ast-collector.cc
index bc76deb9a6d..320611614e9 100644
--- a/gcc/rust/ast/rust-ast-collector.cc
+++ b/gcc/rust/ast/rust-ast-collector.cc
@@ -250,29 +250,6 @@ TokenCollector::visit (Visibility &vis)
}
}
-void
-TokenCollector::visit (NamedFunctionParam ¶m)
-{
- auto name = param.get_name ();
- if (!param.is_variadic ())
-{
- push (
- Rust::Token::make_identifier (param.get_locus (), std::move (name)));
- push (Rust::Token::make (COLON, UNDEF_LOCATION));
- visit (param.get_type ());
-}
- else
-{
- if (name != "")
- {
- push (Rust::Token::make_identifier (param.get_locus (),
- std::move (name)));
- push (Rust::Token::make (COLON, UNDEF_LOCATION));
- }
- push (Rust::Token::make (ELLIPSIS, UNDEF_LOCATION));
-}
-}
-
void
TokenCollector::visit (std::vector> ¶ms)
{
diff --git a/gcc/rust/ast/rust-ast-collector.h
b/gcc/rust/ast/rust-ast-collector.h
index 32a5bd33da7..30aff985105 100644
--- a/gcc/rust/ast/rust-ast-collector.h
+++ b/gcc/rust/ast/rust-ast-collector.h
@@ -210,7 +210,6 @@ public:
void visit (TupleField &field);
void visit (StructField &field);
void visit (SimplePathSegment &segment);
- void visit (NamedFunctionParam ¶m);
void visit (MacroRule &rule);
void visit (WhereClause &rule);
void visit (std::vector &for_lifetimes);
diff --git a/gcc/rust/ast/rust-ast-full-decls.h
b/gcc/rust/ast/rust-ast-full-decls.h
index 80d217e0c52..9359248aabd 100644
--- a/gcc/rust/ast/rust-ast-full-decls.h
+++ b/gcc/rust/ast/rust-ast-full-decls.h
@@ -202,7 +202,6 @@ class TraitImpl;
class ExternalItem;
class ExternalTypeItem;
class ExternalStaticItem;
-class NamedFunctionParam;
class ExternBlock;
// rust-macro.h
diff --git a/gcc/rust/ast/rust-ast-visitor.cc b/gcc/rust/ast/rust-ast-visitor.cc
index d10ca6ca07b..6959c49d66a 100644
--- a/gcc/rust/ast/rust-ast-visitor.cc
+++ b/gcc/rust/ast/rust-ast-visitor.cc
@@ -1060,14 +1060,6 @@ DefaultASTVisitor::visit (AST::ExternalStaticItem &item)
visit (item.get_type ());
}
-void
-DefaultASTVisitor::visit (AST::NamedFunctionParam ¶m)
-{
- visit_outer_attrs (param);
- if (!param.is_variadic ())
-visit (param.get_type ());
-}
-
void
DefaultASTVisitor::visit (AST::ExternBlock &block)
{
diff --git a/gcc/rust/ast/rust-ast-visitor.h b/gcc/rust/ast/rust-ast-visitor.h
index 7e3423cd493..a7c1cc9c62b 100644
--- a/gcc/rust/ast/rust-ast-visitor.h
+++ b/gcc/rust/ast/rust-ast-visitor.h
@@ -428,7 +428,6 @@ public:
virtual void visit (AST::WhereClause &where);
virtual void visit (AST::StructField &field);
virtual void visit (AST::TupleField &field);
- virtual void visit (AST::NamedFunctionParam ¶m);
virtual void visit (AST::MacroRule &rule);
virtual void visit (AST::MacroInvocData &data);
virtual void visit (AST::MacroTranscriber &transcriber);
diff --git a/gcc/rust/ast/rust-ast.cc b/gcc/rust/ast/rust-ast.cc
index 06a7a097cfb..25e522bf948 100644
--- a/gcc/rust/ast/rust-ast.cc
+++ b/gcc/rust/ast/rust-ast.cc
@@ -2997,22 +2997,6 @@ ExternalStaticItem::as_string () const
return str;
}
-std::string
-NamedFunctionParam::as_string () const
-{
- std::string str = append_attributes (outer_attrs, OUTER);
-
- if (has_name ())
-str += "\n" + name;
-
- if (is_variadic ())
-str += "...";
- else
-str += "\n Type: " + param_type->as_string ();
-
- return str;
-}
-
std::st
[COMMITTED] testsuite: i386: Require dfp support in gcc.target/i386/pr117946.c etc.
Two tests FAIL on 64-bit Solaris/x86:
FAIL: gcc.target/i386/pr117946.c (test for excess errors)
FAIL: gcc.target/i386/pr118017.c (test for excess errors)
The failure mode is the same in both cases:
Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr117946.c:4:47:
error: decimal floating-point not supported for this target
Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr118017.c:6:47:
error: decimal floating-point not supported for this target
Fixed by requiring dfp support.
Tested on i386-pc-solaris2.11 and x86_64-pc-linux-gnu, committed to
trunk.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
2025-03-25 Rainer Orth
gcc/testsuite:
* gcc.target/i386/pr117946.c: Require dfp support.
* gcc.target/i386/pr118017.c: Likewise. Use
dg-require-effective-target for both this and int128.
# HG changeset patch
# Parent 1e15e22457284abe861410881c9df9ef68f8a47d
testsuite: i386: Require dfp support in gcc.target/i386/pr117946.c etc.
diff --git a/gcc/testsuite/gcc.target/i386/pr117946.c b/gcc/testsuite/gcc.target/i386/pr117946.c
--- a/gcc/testsuite/gcc.target/i386/pr117946.c
+++ b/gcc/testsuite/gcc.target/i386/pr117946.c
@@ -1,4 +1,5 @@
/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-require-effective-target dfp } */
/* { dg-options "-O -favoid-store-forwarding -mavx10.1 -mprefer-avx128 --param=store-forwarding-max-distance=128 -Wno-psabi" } */
/* { dg-warning "'-mavx10.1' is aliased to 512 bit since GCC14.3 and GCC15.1 while '-mavx10.1-256' and '-mavx10.1-512' will be deprecated in GCC 16 due to all machines 512 bit vector size supported" "" { target *-*-* } 0 } */
typedef __attribute__((__vector_size__ (64))) _Decimal32 V;
diff --git a/gcc/testsuite/gcc.target/i386/pr118017.c b/gcc/testsuite/gcc.target/i386/pr118017.c
--- a/gcc/testsuite/gcc.target/i386/pr118017.c
+++ b/gcc/testsuite/gcc.target/i386/pr118017.c
@@ -1,5 +1,7 @@
/* PR target/118017 */
-/* { dg-do compile { target int128 } } */
+/* { dg-do compile } */
+/* { dg-require-effective-target int128 } */
+/* { dg-require-effective-target dfp } */
/* { dg-options "-Og -frounding-math -mno-80387 -mno-mmx -Wno-psabi" } */
typedef __attribute__((__vector_size__ (64))) _Float128 F;
Re: [PATCH v2 1/2] PR118442: Don't instrument exit edges after musttail
> > > > Hmm. I do wonder whether your earlier patch was more "correct" in the > > sense that a tail call does not return to the calling function but its > > caller. > > That means it should not have a fallthru edge, so our representation > > with feeding a return value to a function-local return stmt isn't a good > > one. > > > > That said, the CFG hook you are patching is supposed to add edges when > > a function call can possibly not reach the return stmt and I think that's > > the case for tail-calls. So IMO the patch is wrong. Iff instead the > > instrumentation confuses later tail-call verification then this > > instrumentation > > should be either not emitted or handled there. > > For the edge profling algorithm to be able to fill in missing counters > correctly, every valid execution must correspond to a path from entry > block to exit block. So we need an edge here, but we can mark it as Just to be correct, For the profiling code, executions starting in entry and circulating forever in a loop are also OK, that makes it bit different from DCE which expects every execution path to be finite. What is not OK is execution starting in entry and stopping somewhere in the middle (by exitting or, for example, by hidden infinite loop inside an asm statement) since resulting profile is not a circulation. Still I think it would be good idea to factor out the logic and share it for dce and other similar algorithms. I will try to find time to look into that. (But we don't need hookize it, since we have nothing doing this that works both on RTL and gimple). Honza
Re: [PATCH v2] c: Fix tagname confusion for typedef redefinitions [PR118765]
On Wed, 26 Mar 2025, Martin Uecker wrote: > I looked at this again and do not need a workaround anymore. > > I did not implement any restrictions preventing typedef > redeclarations from having different alignment, because > merge_decls does not include any such restrictions at this > time. I could write another patch for this, but I think > this would be an unrelated change. > > Bootstrapped and regression tested on x86_64. > > > > c: Fix tagname confusion for typedef redefinitions [PR118765] > > When we redefine a typedef for a tagged type that has just been > redefined, merge_decls may produce invalid TYPE_DECLS that are not > consistent with what set_underlying_type produces. This is fixed > by updating DECL_ORIGINAL_TYPE. OK. -- Joseph S. Myers josmy...@redhat.com
[PATCH] libstdc++: Use const_cast to workaround tm_zone being non-const
Iain reported that he's seeing this on Darwin:
include/bits/chrono_io.h:914: warning: ISO C++ forbids converting a string
constant to 'char*' [-Wwrite-strings]
This is because the BSD definition ot tm::tm_zone is a char* (and has
been since 1987) rather than const char* as in Glibc and POSIX.1-2024.
This uses const_cast when setting the tm_zone member. This should
be safe because libc doesn't actually write anything to tm_zone, it's
only non-const because the BSD definition predates the addition of the
const keyword to C.
For targets where it's a const char* the cast won't matter because it
will be converted back to const char* on assignment anyway.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (__formatter_chrono::_M_c): Use
const_cast when setting tm.tm_zone.
---
Testing x86_64-linux.
libstdc++-v3/include/bits/chrono_io.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libstdc++-v3/include/bits/chrono_io.h
b/libstdc++-v3/include/bits/chrono_io.h
index 08969166d2f..c55b651d049 100644
--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -907,21 +907,22 @@ namespace __format
#ifdef _GLIBCXX_HAVE_STRUCT_TM_TM_ZONE
// POSIX.1-2024 adds tm.tm_zone which will be used for %Z.
+ // BSD has had tm_zone since 1987 but as char* so cast away const.
if constexpr (__is_time_point_v<_Tp>)
{
// One of sys_time, utc_time, or local_time.
if constexpr (!is_same_v)
- __tm.tm_zone = "UTC";
+ __tm.tm_zone = const_cast("UTC");
}
else if constexpr (__is_specialization_of<_Tp, __local_time_fmt>)
{
// local-time-format-t is used to provide time zone info for
// one of zoned_time, tai_time, gps_time, or local_time.
if (__t._M_abbrev)
- __tm.tm_zone = __t._M_abbrev->c_str();
+ __tm.tm_zone = const_cast(__t._M_abbrev->c_str());
}
else
- __tm.tm_zone = "UTC";
+ __tm.tm_zone = const_cast("UTC");
#endif
auto __d = _S_days(__t); // Either sys_days or local_days.
--
2.49.0
RE: [PATCH] cobol: Get rid of __int128 uses in the COBOL FE [PR119242]
The use of 128-bit arithmetic in the library is completely integral to the
implementation.
Because a 128-bit integer can hold a 38-digit signed decimal number, I
decided to create a limit of 37 digits for user-defined variables, because
that gave me an additional digit to the right for rounding.
The ISO specification says 31 digits for fixed-point literals. Even that
requires 111 bits for signed values.
So, not only do I use __int128 for handling any values with more than 19
digits, I have to allow for the possibility that that somebody might want
to multiply a
PIC 9(36)V1 by a 9V9(36). They are both 37-digit numbers; one has 1
decimal place, and the other has 36 decimal places.
The product has 74 digits with 37 decimal places. That's an intermediate
value; the target location, if not big enough to hold the result after the
rightmost decimal places are trimmed away, results in a run-time error
condition that the programmer can choose how to handle. But if the target
is big enough, then the result is exact, after rounding rules are applied.
This meant I had to implement 128-by-128 bit multiplication, resulting in
a 256-bit product.
And it works fine. Could this be done with GMP? Sure. That was a can I
consciously and deliberately kicked down the road, partly because my boss,
who pays my salary, is of the opinion that 32-bit implementations don't
matter for COBOL as we enter the second quarter of the 21st century.
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, March 26, 2025 08:30
> To: Robert Dubner
> Cc: James K. Lowden ; Richard Biener
> ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] cobol: Get rid of __int128 uses in the COBOL FE
> [PR119242]
>
> On Tue, Mar 25, 2025 at 11:41:09PM -0500, Robert Dubner wrote:
> > I'll take a look at this tomorrow. Conditional compilation is one
> > possibility. Another is to bust that .h file into two; one that goes
> into
> > libgcobol and is accessed by gcc/cobol and libgcobol, and a second
that
> is
> > accessed solely by libgcobol. I'll want to look at the magnitude of
the
> > problem before deciding which.
>
> That would work fine too.
>
> Another question for later is if any of those APIs with __int128 are
> actually ever called from compiled COBOL code, or if after this change
> and your header split __int128 will be just a type internal to the
> library,
> with compiled COBOL code only storing stuff into memory as 16-byte
values.
>
> In that case, we could easily get rid of the __int128 dependency and
> enable
> COBOL support e.g. on many 32-bit architectures, by doing
> #ifdef __SIZEOF_INT128__
> typedef __int128 int128;
> #else
> class int128 {
> ...
> };
> #endif
> where the class would have overloaded operators such that it would work
> fully or mostly the same as native __int128 type. The library is
written
> in C++ so let's take some advantage of it. Guess it depends on
> what exactly is __int128 used for in the library and e.g. what C library
> functions are used with it if any.
>
> Jakub
Re: [PATCH] c++: Fix FAIL: g++.dg/tree-ssa/initlist-opt1.C
On 3/26/25 6:14 AM, Jonathan Wakely wrote:
My r15-8904-ge200f53a555651 changed the std::vector initializer-list
constructor so that it calls a new _M_range_initialize_n function
instead of _M_range_initialize. Change the scan-tree-dump pattern in
this g++.dg test to match the new gimple output.
gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/initlist-opt1.C: Match _M_range_initialize_n
instead of _M_range_initialize.
---
Would anybody prefer a different pattern?
e.g. just {_M_range_initialize_n' would work, and would be correct
for the gcc-14 backport where the new function only has one template
parameter.
That sounds most convenient to me. I don't think the specific signature
is important, as long as it checks that we use range-initialization from
const char *.
Or is it better to be more explicit about the full signature here, and
then use {_M_range_initialize_n} for gcc-14?
gcc/testsuite/g++.dg/tree-ssa/initlist-opt1.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/g++.dg/tree-ssa/initlist-opt1.C
b/gcc/testsuite/g++.dg/tree-ssa/initlist-opt1.C
index 89abdd90a82..2b9089acd82 100644
--- a/gcc/testsuite/g++.dg/tree-ssa/initlist-opt1.C
+++ b/gcc/testsuite/g++.dg/tree-ssa/initlist-opt1.C
@@ -4,7 +4,7 @@
// { dg-skip-if "requires hosted libstdc++ for string" { ! hostedlib } }
// Test that we do range-initialization from const char *.
-// { dg-final { scan-tree-dump {_M_range_initialize}
"gimple" } }
+// { dg-final { scan-tree-dump {_M_range_initialize_n} "gimple" } }
// { dg-final { scan-tree-dump {static const char.*72} "gimple" } }
#include
[PATCH v2] c++: Fix FAIL: g++.dg/tree-ssa/initlist-opt1.C
On Wed, 26 Mar 2025 at 17:42, Jason Merrill wrote:
>
> On 3/26/25 6:14 AM, Jonathan Wakely wrote:
> > My r15-8904-ge200f53a555651 changed the std::vector initializer-list
> > constructor so that it calls a new _M_range_initialize_n function
> > instead of _M_range_initialize. Change the scan-tree-dump pattern in
> > this g++.dg test to match the new gimple output.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/tree-ssa/initlist-opt1.C: Match _M_range_initialize_n
> > instead of _M_range_initialize.
> > ---
> >
> > Would anybody prefer a different pattern?
> >
> > e.g. just {_M_range_initialize_n > the second template argument and '>' would work, and would be correct
> > for the gcc-14 backport where the new function only has one template
> > parameter.
>
> That sounds most convenient to me. I don't think the specific signature
> is important, as long as it checks that we use range-initialization from
> const char *.
Agreed - so I've pushed the attached patch to trunk now, thanks.
commit 101f302363e8773958887e00750098b760a5b6bd
Author: Jonathan Wakely
AuthorDate: Wed Mar 26 10:10:19 2025
Commit: Jonathan Wakely
CommitDate: Wed Mar 26 17:53:34 2025
c++: Fix FAIL: g++.dg/tree-ssa/initlist-opt1.C
My r15-8904-ge200f53a555651 changed the std::vector initializer-list
constructor so that it calls a new _M_range_initialize_n function
instead of _M_range_initialize. Change the scan-tree-dump pattern in
this g++.dg test to match the new gimple output.
gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/initlist-opt1.C: Match _M_range_initialize_n
instead of _M_range_initialize.
diff --git a/gcc/testsuite/g++.dg/tree-ssa/initlist-opt1.C
b/gcc/testsuite/g++.dg/tree-ssa/initlist-opt1.C
index 89abdd90a82..976c3f30b16 100644
--- a/gcc/testsuite/g++.dg/tree-ssa/initlist-opt1.C
+++ b/gcc/testsuite/g++.dg/tree-ssa/initlist-opt1.C
@@ -4,7 +4,7 @@
// { dg-skip-if "requires hosted libstdc++ for string" { ! hostedlib } }
// Test that we do range-initialization from const char *.
-// { dg-final { scan-tree-dump {_M_range_initialize}
"gimple" } }
+// { dg-final { scan-tree-dump {_M_range_initialize_n
[PATCH] arm: don't vectorize fmaxf() unless unsafe math opts are enabled
This test has presumably been failing since vectorization was enabled
at -O2. I suspect part of the reason this wasn't picked up sooner is
that the test is a hybrid execution/scan-assembler test and the
execution part requires appropriate hardware.
The problem is that we are vectorizing an expansion of fmaxf() when
the vector version of the instruction does not preserve denormal
values. This means we should only apply this optimization when
-funsafe-math-optimizations is enabled.
This fix does a few things:
- Moves the expand pattern to vec-common.md. Although I haven't changed
its behaviour (beyond fixing the bug), this should really be enabled for
MVE as well (but that will need to wait for gcc-16 since the MVE code
needs some additional changes first).
- Adds support for HF mode vectors.
- splits the test that was exposing the bug into two parts: an executable
test and a scan-assembler test. The scan-assembler version is more
widely enabled, since it does not require a suitable executable environment.
gcc/ChangeLog:
* config/arm/neon.md (3): Move pattern from here...
* config/arm/vec-common.md (3): ... to here. Convert
to define_expand and disable the pattern when denormal values might
get truncated to zero. Iterate on VF to add V4HF and V8HF variants.
gcc/testsuite/ChangeLog:
* gcc.target/arm/fmaxmin.c: Move scan-assembler checks to ...
* gcc.target/arm/fmaxmin-2.c: ... here. New test.
---
gcc/config/arm/neon.md | 11 ---
gcc/config/arm/vec-common.md | 11 +++
gcc/testsuite/gcc.target/arm/fmaxmin-2.c | 12
gcc/testsuite/gcc.target/arm/fmaxmin.c | 9 +
4 files changed, 24 insertions(+), 19 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/arm/fmaxmin-2.c
I'll wait until tomorrow before pushing this, so that I can see some
broarder testing.
R.
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index ef3310605ca..8446dd7f964 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -2738,17 +2738,6 @@ (define_insn "neon_"
[(set_attr "type" "neon_fp_minmax_s")]
)
-;; Vector forms for the IEEE-754 fmax()/fmin() functions
-(define_insn "3"
- [(set (match_operand:VCVTF 0 "s_register_operand" "=w")
- (unspec:VCVTF [(match_operand:VCVTF 1 "s_register_operand" "w")
- (match_operand:VCVTF 2 "s_register_operand" "w")]
- VMAXMINFNM))]
- "TARGET_NEON && TARGET_VFP5"
- ".\t%0, %1, %2"
- [(set_attr "type" "neon_fp_minmax_s")]
-)
-
(define_expand "neon_vpadd"
[(match_operand:VD 0 "s_register_operand")
(match_operand:VD 1 "s_register_operand")
diff --git a/gcc/config/arm/vec-common.md b/gcc/config/arm/vec-common.md
index 204205cb0b7..a485d057f0f 100644
--- a/gcc/config/arm/vec-common.md
+++ b/gcc/config/arm/vec-common.md
@@ -137,6 +137,17 @@ (define_expand "umax3"
"ARM_HAVE__ARITH"
)
+;; Vector forms for the IEEE-754 fmax()/fmin() functions
+;; Fixme: Should be enabled for MVE as well, but currently that uses an
+;; incompatible expasion.
+(define_expand "3"
+ [(set (match_operand:VF 0 "s_register_operand" "")
+ (unspec:VF [(match_operand:VF 1 "s_register_operand")
+ (match_operand:VF 2 "s_register_operand")]
+ VMAXMINFNM))]
+ "TARGET_NEON && TARGET_VFP5 && ARM_HAVE__ARITH"
+)
+
(define_expand "vec_perm"
[(match_operand:VE 0 "s_register_operand")
(match_operand:VE 1 "s_register_operand")
diff --git a/gcc/testsuite/gcc.target/arm/fmaxmin-2.c
b/gcc/testsuite/gcc.target/arm/fmaxmin-2.c
new file mode 100644
index 000..a9990e19243
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/fmaxmin-2.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_arch_v8a_hard_ok } */
+/* { dg-options "-O2 -fno-inline" } */
+/* { dg-add-options arm_arch_v8a_hard } */
+
+#include "fmaxmin.x"
+
+/* { dg-final { scan-assembler-times "vmaxnm.f32\ts\[0-9\]+, s\[0-9\]+,
s\[0-9\]+" 1 } } */
+/* { dg-final { scan-assembler-times "vminnm.f32\ts\[0-9\]+, s\[0-9\]+,
s\[0-9\]+" 1 } } */
+
+/* { dg-final { scan-assembler-times "vmaxnm.f64\td\[0-9\]+, d\[0-9\]+,
d\[0-9\]+" 1 } } */
+/* { dg-final { scan-assembler-times "vminnm.f64\td\[0-9\]+, d\[0-9\]+,
d\[0-9\]+" 1 } } */
diff --git a/gcc/testsuite/gcc.target/arm/fmaxmin.c
b/gcc/testsuite/gcc.target/arm/fmaxmin.c
index 5a6fb804e3d..7f30c1237ab 100644
--- a/gcc/testsuite/gcc.target/arm/fmaxmin.c
+++ b/gcc/testsuite/gcc.target/arm/fmaxmin.c
@@ -1,13 +1,6 @@
/* { dg-do run } */
/* { dg-require-effective-target arm_v8_neon_hw } */
-/* { dg-options "-O2 -fno-inline -march=armv8-a -save-temps" } */
+/* { dg-options "-O2 -fno-inline" } */
/* { dg-add-options arm_v8_neon } */
#include "fmaxmin.x"
-
-/* { dg-final { scan-assembler-times "vmaxnm.f32\ts\[0-9\]+, s\[0-9\]+,
s\[0-9\]+" 1 } } */
-/* { dg-final { scan-assembler-times "vminnm.f32\ts\[0-9\]+, s\[0-9\]+,
s\[0-9\]+" 1 } } */
-
-/
Re: [PATCH] cobol: Get rid of __int128 uses in the COBOL FE [PR119242]
> On 26 Mar 2025, at 04:41, Robert Dubner wrote:
>
>
>
>> -Original Message-
>> From: Jakub Jelinek
>> Sent: Tuesday, March 25, 2025 19:49
>> To: Robert Dubner ; James K. Lowden
>> ; Richard Biener
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: [PATCH] cobol: Get rid of __int128 uses in the COBOL FE
>> [PR119242]
>>
>> Hi!
>>
>> The following patch changes some remaining __int128 uses in the FE
>> into FIXED_WIDE_INT(128), i.e. emulated 128-bit integral type.
>> The use of wide_int_to_tree directly from that rather than going through
>> build_int_cst_type means we don't throw away the upper 64 bits of the
>> values, so the emitting of constants needing full 128 bits can be
> greatly
>> simplied.
>> Plus all the #pragma GCC diagnostic ignored "-Wpedantic" spots aren't
>> needed, we don't use the _Float128/__int128 types directly in the FE
>> anymore.
>>
>> Tested on x86_64-linux with make check-cobol, could you please test this
>> on UAT/NIST?
>>
>> Note, PR119241/PR119242 bugs are still not fully fixed, I think the
>> remaining problem is that several FE sources include
>> ../../libgcobol/libgcobol.h and that header declares various APIs with
>> __int128 and _Float128 types, so trying to build a cross-compiler on a
>> host
>> without __int128 and _Float128 will still fail miserably.
>> I believe none of those APIs are actually used by the FE, so the
> question
>> is
>> what the FE needs from libgcobol.h and whether the rest could be wrapped
>> with #ifndef IN_GCC or #ifndef IN_GCC_FRONTEND or something similar
>> (those 2 macros are predefined when compiling the FE files).
>
> I'll take a look at this tomorrow. Conditional compilation is one
> possibility. Another is to bust that .h file into two; one that goes into
> libgcobol and is accessed by gcc/cobol and libgcobol, and a second that is
> accessed solely by libgcobol. I'll want to look at the magnitude of the
> problem before deciding which.
(one data point, in case it helps)
I just rebased my library-side changes onto Jakub’s patch here.
It seems that, with this patch, none of the APIs in libgcobol.h are now used in
the FE; however the FE does continue to use the #defines and typedefs.
With said library changes the wrapping of the APIs in #if !defined (IN_GCC)
allows a build to complete without any heavy lifting (a few small changes to the
library patch but those can be done before posting it)
Of course splitting the header would work too.
Iain
>> 2025-03-26 Jakub Jelinek
>>
>> PR cobol/119242
>> * cobol/genutil.h (get_power_of_ten): Remove #pragma GCC
> diagnostic
>> around declaration.
>> * cobol/genapi.cc (psa_FldLiteralN): Change type of value from
>> __int128 to FIXED_WIDE_INT(128). Remove #pragma GCC diagnostic
>> around the declaration. Use wi::min_precision to determine
>> minimum unsigned precision of the value. Use wi::neg_p instead
>> of value < 0 tests and wi::set_bit_in_zero
>> to build sign bit. Handle field->data.capacity == 16 like
>> 1, 2, 4 and 8, use wide_int_to_tree instead of build_int_cst.
>> (mh_source_is_literalN): Remove #pragma GCC diagnostic around
>> the definition.
>> (binary_initial_from_float128): Likewise.
>> * cobol/genutil.cc (get_power_of_ten): Remove #pragma GCC
> diagnostic
>> before the definition.
>>
>> --- gcc/cobol/genutil.h.jj 2025-03-25 21:14:48.448384925 +0100
>> +++ gcc/cobol/genutil.h 2025-03-25 21:19:24.358620134 +0100
>> @@ -104,10 +104,7 @@ void get_binary_value( tree value,
>> tree get_data_address( cbl_field_t *field,
>> tree offset);
>>
>> -#pragma GCC diagnostic push
>> -#pragma GCC diagnostic ignored "-Wpedantic"
>> FIXED_WIDE_INT(128) get_power_of_ten(int n);
>> -#pragma GCC diagnostic pop
>> void scale_by_power_of_ten_N(tree value,
>> int N,
>> bool check_for_fractional = false);
>> --- gcc/cobol/genapi.cc.jj 2025-03-25 21:11:06.767409766 +0100
>> +++ gcc/cobol/genapi.cc 2025-03-25 21:22:28.038113833 +0100
>> @@ -3798,16 +3798,13 @@ psa_FldLiteralN(struct cbl_field_t *fiel
>> // We are constructing a completely static constant structure, based
> on
>> the
>> // text string in .initial
>>
>> -#pragma GCC diagnostic push
>> -#pragma GCC diagnostic ignored "-Wpedantic"
>> - __int128 value = 0;
>> -#pragma GCC diagnostic pop
>> + FIXED_WIDE_INT(128) value = 0;
>>
>> do
>> {
>> // This is a false do{}while, to isolate the variables:
>>
>> -// We need to convert data.initial to an __int128 value
>> +// We need to convert data.initial to an FIXED_WIDE_INT(128) value
>> char *p = const_cast(field->data.initial);
>> int sign = 1;
>> if( *p == '-' )
>> @@ -3903,24 +3900,24 @@ psa_FldLiteralN(struct cbl_field_t *fiel
>>
>> // We now need to calculate the capacity.
>>
>> -unsigned char *pvalue = (unsigned char *)&value;
>>
[PATCH] libstdc++: Fix std::ranges::iter_move for function references [PR119469]
The result of std::move (or a cast to an rvalue reference) on a function
reference is always an lvalue. Because std::ranges::iter_move was using
the type std::remove_reference_t&& as the result of std::move, it was
giving the wrong type for function references. Use a decltype-specifier
with declval>() instead of just using the
remove_reference_t&& type directly. This gives the right result,
while still avoiding the cost of doing overload resolution for
std::move.
libstdc++-v3/ChangeLog:
PR libstdc++/119469
* include/bits/iterator_concepts.h (_IterMove::__result): Use
decltype-specifier instead of an explicit type.
* testsuite/24_iterators/customization_points/iter_move.cc:
Check results for function references.
---
This one is weird, but I think the fix is right.
Testing x86_64-linux.
libstdc++-v3/include/bits/iterator_concepts.h | 11 +--
.../24_iterators/customization_points/iter_move.cc| 11 +++
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/include/bits/iterator_concepts.h
b/libstdc++-v3/include/bits/iterator_concepts.h
index a201e24d2e2..e36556dc512 100644
--- a/libstdc++-v3/include/bits/iterator_concepts.h
+++ b/libstdc++-v3/include/bits/iterator_concepts.h
@@ -133,12 +133,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct __result<_Tp>
{ using type = decltype(iter_move(std::declval<_Tp>())); };
- // Otherwise, if *E if an lvalue, use std::move(*E).
+ // Otherwise, if *E is an lvalue, use std::move(*E).
template
requires (!__adl_imove<_Tp>)
&& is_lvalue_reference_v<__iter_ref_t<_Tp>>
struct __result<_Tp>
- { using type = remove_reference_t<__iter_ref_t<_Tp>>&&; };
+ {
+ // Instead of decltype(std::move(*E)) we define the type as the
+ // return type of std::move, i.e. remove_reference_t&&.
+ // N.B. the use of decltype(declval()) instead of just X&& is
+ // needed for function reference types, see PR libstdc++/119469.
+ using type
+ = decltype(std::declval>>());
+ };
template
static constexpr bool
diff --git
a/libstdc++-v3/testsuite/24_iterators/customization_points/iter_move.cc
b/libstdc++-v3/testsuite/24_iterators/customization_points/iter_move.cc
index 341bd5b98d7..87375746dfd 100644
--- a/libstdc++-v3/testsuite/24_iterators/customization_points/iter_move.cc
+++ b/libstdc++-v3/testsuite/24_iterators/customization_points/iter_move.cc
@@ -157,9 +157,20 @@ test_pr106612()
static_assert( std::same_as );
}
+void
+test_pr119469()
+{
+ // rvalue references to function types are weird.
+ using F = int();
+ static_assert( std::same_as, F&> );
+ static_assert( std::same_as, F&> );
+ static_assert( std::same_as, F&> );
+}
+
int
main()
{
test01();
test_adl();
+ test_pr119469();
}
--
2.49.0
[PATCH] testsuite: i386: Fix c-c++-common/gomp/metadirective-device.c etc. with i?86 compiler
Two new tests FAIL on both Solaris/x86 and Linux/i686 with a
32-bit-default compiler:
FAIL: c-c++-common/gomp/metadirective-device.c -std=c++17 scan-tree-dump-not
optimized "__builtin_GOMP_error"
FAIL: c-c++-common/gomp/metadirective-device.c -std=c++26 scan-tree-dump-not
optimized "__builtin_GOMP_error"
FAIL: c-c++-common/gomp/metadirective-device.c -std=c++98 scan-tree-dump-not
optimized "__builtin_GOMP_error"
FAIL: c-c++-common/gomp/metadirective-target-device-1.c -std=c++17
scan-tree-dump-times optimized "GOMP_error" 0
FAIL: c-c++-common/gomp/metadirective-target-device-1.c -std=c++26
scan-tree-dump-times optimized "GOMP_error" 0
FAIL: c-c++-common/gomp/metadirective-target-device-1.c -std=c++98
scan-tree-dump-times optimized "GOMP_error" 0
FAIL: c-c++-common/gomp/metadirective-device.c scan-tree-dump-not optimized
"__builtin_GOMP_error"
FAIL: c-c++-common/gomp/metadirective-target-device-1.c scan-tree-dump-times
optimized "GOMP_error" 0
They also FAIL on Linux/x86_64 with -mx32.
The problem is two-fold: restricting to a test to target x86_64-*-* is
always wrong: an i?86-*-* compiler can produce 64-bit code with -m64
just as well, so it should always be both.
In addition, the -mx32 failure shows that the test seems to be 64-bit
only.
To fix both issues, this patch uses the new x86 effective-target keyword
and restricts the tests to lp64 instead of ! ia32.
Tested on i386-pc-solaris2.11 and x86_64-pc-linux-gnu.
Ok for trunk?
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
2025-03-25 Rainer Orth
gcc/testsuite:
* c-c++-common/gomp/metadirective-device.c
(dg-additional-options): Use on all x86 targets. Restrict to lp64.
* c-c++-common/gomp/metadirective-target-device-1.c: Likewise.
# HG changeset patch
# Parent 34d01fe0d6bcb2fe20c5d2a54ccf80f653eb7edd
testsuite: i386: Fix c-c++-common/gomp/metadirective-device.c etc. with i?86 compiler
diff --git a/gcc/testsuite/c-c++-common/gomp/metadirective-device.c b/gcc/testsuite/c-c++-common/gomp/metadirective-device.c
--- a/gcc/testsuite/c-c++-common/gomp/metadirective-device.c
+++ b/gcc/testsuite/c-c++-common/gomp/metadirective-device.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-additional-options "-foffload=disable -fdump-tree-optimized" } */
-/* { dg-additional-options "-DDEVICE_ARCH=x86_64 -DDEVICE_ISA=sse -msse" { target { x86_64-*-* && { ! ia32 } } } } */
+/* { dg-additional-options "-DDEVICE_ARCH=x86_64 -DDEVICE_ISA=sse -msse" { target { x86 && lp64 } } } */
#include
diff --git a/gcc/testsuite/c-c++-common/gomp/metadirective-target-device-1.c b/gcc/testsuite/c-c++-common/gomp/metadirective-target-device-1.c
--- a/gcc/testsuite/c-c++-common/gomp/metadirective-target-device-1.c
+++ b/gcc/testsuite/c-c++-common/gomp/metadirective-target-device-1.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-additional-options "-fdump-tree-optimized" } */
-/* { dg-additional-options "-DDEVICE_ARCH=x86_64 -DDEVICE_ISA=mmx -mmmx" { target { x86_64-*-* && { ! ia32 } } } } */
+/* { dg-additional-options "-DDEVICE_ARCH=x86_64 -DDEVICE_ISA=mmx -mmmx" { target { x86 && lp64 } } } */
#include
[PUSHED] driver: Forward '-lstdc++' to offloading compilation [PR101544]
From: Thomas Schwinge
..., so that users don't manually need to specify '-foffload-options=-lstdc++'
in addition to '-lstdc++' (specified manually, or implicitly by the driver).
Do like commit 4bcb46b3ade1796c5a57b294f5cca25f00671cac
"driver: Forward '-lgfortran', '-lm' to offloading compilation".
PR driver/101544
gcc/
* gcc.cc (driver_handle_option): Forward host '-lstdc++' to
offloading compilation.
* config/gcn/mkoffload.cc (main): Adjust.
* config/nvptx/mkoffload.cc (main): Likewise.
libgomp/
* testsuite/libgomp.c++/pr101544-1-O0.C: Remove
'-foffload-options=-lstdc++'.
* testsuite/libgomp.c++/pr101544-1.C: Likewise.
* testsuite/libgomp.oacc-c++/pr101544-1.C: Likewise.
---
gcc/config/gcn/mkoffload.cc | 3 ++-
gcc/config/nvptx/mkoffload.cc | 3 ++-
gcc/gcc.cc | 3 ++-
libgomp/testsuite/libgomp.c++/pr101544-1-O0.C | 1 -
libgomp/testsuite/libgomp.c++/pr101544-1.C | 1 -
libgomp/testsuite/libgomp.oacc-c++/pr101544-1.C | 1 -
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/gcc/config/gcn/mkoffload.cc b/gcc/config/gcn/mkoffload.cc
index fbd68a6cd8c9..f5b89c9fee7a 100644
--- a/gcc/config/gcn/mkoffload.cc
+++ b/gcc/config/gcn/mkoffload.cc
@@ -1070,7 +1070,8 @@ main (int argc, char **argv)
#undef STR
/* Translate host into offloading libraries. */
else if (strcmp (argv[i], "-l_GCC_gfortran") == 0
- || strcmp (argv[i], "-l_GCC_m") == 0)
+ || strcmp (argv[i], "-l_GCC_m") == 0
+ || strcmp (argv[i], "-l_GCC_stdc++") == 0)
{
/* Elide '_GCC_'. */
size_t i_dst = strlen ("-l");
diff --git a/gcc/config/nvptx/mkoffload.cc b/gcc/config/nvptx/mkoffload.cc
index 958e16f3918e..bdfe7f58b166 100644
--- a/gcc/config/nvptx/mkoffload.cc
+++ b/gcc/config/nvptx/mkoffload.cc
@@ -741,7 +741,8 @@ main (int argc, char **argv)
dumppfx = argv[++i];
/* Translate host into offloading libraries. */
else if (strcmp (argv[i], "-l_GCC_gfortran") == 0
- || strcmp (argv[i], "-l_GCC_m") == 0)
+ || strcmp (argv[i], "-l_GCC_m") == 0
+ || strcmp (argv[i], "-l_GCC_stdc++") == 0)
{
/* Elide '_GCC_'. */
size_t i_dst = strlen ("-l");
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index c7b2aa6df166..3edd21fb09e1 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -4154,7 +4154,8 @@ forward_offload_option (size_t opt_index, const char
*arg, bool validated)
are injected by default in offloading compilation, and therefore not
forwarded here. */
/* GCC libraries. */
- if (/* '-lgfortran' */ strcmp (arg, "gfortran") == 0 )
+ if (/* '-lgfortran' */ strcmp (arg, "gfortran") == 0
+ || /* '-lstdc++' */ strcmp (arg, "stdc++") == 0)
save_switch (concat ("-foffload-options=-l_GCC_", arg, NULL),
0, NULL, validated, true);
/* Other libraries. */
diff --git a/libgomp/testsuite/libgomp.c++/pr101544-1-O0.C
b/libgomp/testsuite/libgomp.c++/pr101544-1-O0.C
index 19a8cad23286..c8a73dcfa19f 100644
--- a/libgomp/testsuite/libgomp.c++/pr101544-1-O0.C
+++ b/libgomp/testsuite/libgomp.c++/pr101544-1-O0.C
@@ -1,4 +1,3 @@
-// { dg-additional-options -foffload-options=-lstdc++ }
// { dg-additional-options -O0 }
#include "pr101544-1.C"
diff --git a/libgomp/testsuite/libgomp.c++/pr101544-1.C
b/libgomp/testsuite/libgomp.c++/pr101544-1.C
index 8ea70a242bc5..fcd3e970bd89 100644
--- a/libgomp/testsuite/libgomp.c++/pr101544-1.C
+++ b/libgomp/testsuite/libgomp.c++/pr101544-1.C
@@ -1,4 +1,3 @@
-// { dg-additional-options -foffload-options=-lstdc++ }
// See also '../libgomp.oacc-c++/pr101544-1.C'.
#ifndef ALWAYS_INLINE
# define ALWAYS_INLINE
diff --git a/libgomp/testsuite/libgomp.oacc-c++/pr101544-1.C
b/libgomp/testsuite/libgomp.oacc-c++/pr101544-1.C
index 004cd49353be..d4d28a611597 100644
--- a/libgomp/testsuite/libgomp.oacc-c++/pr101544-1.C
+++ b/libgomp/testsuite/libgomp.oacc-c++/pr101544-1.C
@@ -1,4 +1,3 @@
-// { dg-additional-options -foffload-options=-lstdc++ }
// { dg-additional-options -fno-inline } for stable results regarding OpenACC
'routine'.
// But actually, as none of the '#pragma acc routine' syntax is accepted,
force inlining:
#define ALWAYS_INLINE __attribute__((always_inline))
--
2.34.1
[PATCH 2/2] c++/modules: Handle conflicting ABI tags [PR118920]
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The ICE in the linked PR is caused because out_ptr_t inherits an ABI tag
in a module that it does not in the importing module. When we try to
build a qualified 'const out_ptr_t' during stream-in, we find the
existing 'const out_ptr_t' variant type that has been built, but discard
it due to having a mismatching attribute list. This causes us to build
a new copy of this variant, and ultimately fail a checking assertion due
to this being an identical type with different TYPE_CANONICAL.
This patch adds checking that ABI tags between an imported and existing
declaration match, and errors if they are incompatible. We make use of
'equal_abi_tags' from mangle.cc to determine if we should error; in the
case in the PR, because the ABI tag was an implicit tag that doesn't
affect name mangling, we don't need to error. To fix the ICE we ensure
that (regardless of whether we errored or not) later processing
considers the ABI tags as equivalent.
PR c++/118920
gcc/cp/ChangeLog:
* cp-tree.h (equal_abi_tags): Declare.
* mangle.cc (equal_abi_tags): Make external, fix comparison.
(tree_string_cmp): Make internal.
* module.cc (trees_in::check_abi_tags): New function.
(trees_in::decl_value): Use it.
(trees_in::is_matching_decl): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/modules/attrib-3_a.H: New test.
* g++.dg/modules/attrib-3_b.C: New test.
* g++.dg/modules/pr118920.h: New test.
* g++.dg/modules/pr118920_a.H: New test.
* g++.dg/modules/pr118920_b.H: New test.
* g++.dg/modules/pr118920_c.C: New test.
Signed-off-by: Nathaniel Shead
---
gcc/cp/cp-tree.h | 1 +
gcc/cp/mangle.cc | 8 ++--
gcc/cp/module.cc | 55 ++-
gcc/testsuite/g++.dg/modules/attrib-3_a.H | 16 +++
gcc/testsuite/g++.dg/modules/attrib-3_b.C | 30 +
gcc/testsuite/g++.dg/modules/pr118920.h | 3 ++
gcc/testsuite/g++.dg/modules/pr118920_a.H | 4 ++
gcc/testsuite/g++.dg/modules/pr118920_b.H | 12 +
gcc/testsuite/g++.dg/modules/pr118920_c.C | 5 +++
9 files changed, 129 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/modules/attrib-3_a.H
create mode 100644 gcc/testsuite/g++.dg/modules/attrib-3_b.C
create mode 100644 gcc/testsuite/g++.dg/modules/pr118920.h
create mode 100644 gcc/testsuite/g++.dg/modules/pr118920_a.H
create mode 100644 gcc/testsuite/g++.dg/modules/pr118920_b.H
create mode 100644 gcc/testsuite/g++.dg/modules/pr118920_c.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 07500fa2b21..6f0f5cc14a2 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -8623,6 +8623,7 @@ extern void mangle_module_substitution(int);
extern int mangle_module_component (tree id, bool partition);
extern tree mangle_module_global_init (int);
extern unsigned HOST_WIDE_INT range_expr_nelts (tree);
+extern bool equal_abi_tags (tree, tree);
/* in dump.cc */
extern bool cp_dump_tree (void *, tree);
diff --git a/gcc/cp/mangle.cc b/gcc/cp/mangle.cc
index 9ca5cf6eecd..02129c6b89a 100644
--- a/gcc/cp/mangle.cc
+++ b/gcc/cp/mangle.cc
@@ -238,7 +238,6 @@ static void write_local_name (tree, const tree, const tree);
static void dump_substitution_candidates (void);
static tree mangle_decl_string (const tree);
static void maybe_check_abi_tags (tree, tree = NULL_TREE, int = 10);
-static bool equal_abi_tags (tree, tree);
/* Control functions. */
@@ -1673,7 +1672,7 @@ write_source_name (tree identifier)
/* Compare two TREE_STRINGs like strcmp. */
-int
+static int
tree_string_cmp (const void *p1, const void *p2)
{
if (p1 == p2)
@@ -1728,7 +1727,7 @@ write_abi_tags (tree tags)
/* True iff the TREE_LISTS T1 and T2 of ABI tags are equivalent. */
-static bool
+bool
equal_abi_tags (tree t1, tree t2)
{
releasing_vec v1 = sorted_abi_tags (t1);
@@ -1738,7 +1737,8 @@ equal_abi_tags (tree t1, tree t2)
if (len1 != v2->length())
return false;
for (unsigned i = 0; i < len1; ++i)
-if (tree_string_cmp (v1[i], v2[i]) != 0)
+if (strcmp (TREE_STRING_POINTER (v1[i]),
+ TREE_STRING_POINTER (v2[i])) != 0)
return false;
return true;
}
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 2cded878c64..9eabceec33f 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -3012,6 +3012,7 @@ public:
bool read_definition (tree decl);
private:
+ void check_abi_tags (tree existing, tree decl, tree &eattr, tree &dattr);
bool is_matching_decl (tree existing, tree decl, bool is_typedef);
static bool install_implicit_member (tree decl);
bool read_function_def (tree decl, tree maybe_template);
@@ -8832,8 +8833,11 @@ trees_in::decl_value ()
tree etype = TREE_TYPE (existing);
/* Handle separate declar
[PATCH 1/2] c++/modules: Fix tsubst of global module friend classes [PR118920]
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
When doing tsubst_friend_class, we need to first check if any imported
module has already created a (hidden) declaration for the class so that
we don't end up with conflicting declarations. Currently we do this
using DECL_MODULE_IMPORT_P, but this is not set in cases where the class
is in the global module and matches an existing GM declaration we've
seen (via an include, for example).
This patch fixes this by checking DECL_MODULE_ENTITY_P instead, which is
set on all entities that have been seen from a module import. We also
use the 'for_mangle' version of get_originating_module so that we don't
treat imported GM entities as attached to the module we imported them
from.
PR c++/118920
gcc/cp/ChangeLog:
* name-lookup.cc (lookup_imported_hidden_friend): Check for
module entity rather than just module import.
gcc/testsuite/ChangeLog:
* g++.dg/modules/tpl-friend-17.h: New test.
* g++.dg/modules/tpl-friend-17_a.C: New test.
* g++.dg/modules/tpl-friend-17_b.C: New test.
Signed-off-by: Nathaniel Shead
---
gcc/cp/name-lookup.cc | 10 +-
gcc/testsuite/g++.dg/modules/tpl-friend-17.h | 8
gcc/testsuite/g++.dg/modules/tpl-friend-17_a.C | 9 +
gcc/testsuite/g++.dg/modules/tpl-friend-17_b.C | 11 +++
4 files changed, 33 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-17.h
create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-17_a.C
create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-17_b.C
diff --git a/gcc/cp/name-lookup.cc b/gcc/cp/name-lookup.cc
index 742e5d289dc..10fa1fcff36 100644
--- a/gcc/cp/name-lookup.cc
+++ b/gcc/cp/name-lookup.cc
@@ -4568,7 +4568,7 @@ lookup_imported_hidden_friend (tree friend_tmpl)
tree inner = DECL_TEMPLATE_RESULT (friend_tmpl);
if (!DECL_LANG_SPECIFIC (inner)
- || !DECL_MODULE_IMPORT_P (inner))
+ || !DECL_MODULE_ENTITY_P (inner))
return NULL_TREE;
lazy_load_pendings (friend_tmpl);
@@ -4578,16 +4578,16 @@ lookup_imported_hidden_friend (tree friend_tmpl)
if (!bind)
return NULL_TREE;
- /* We're only interested in declarations coming from the same module
- of the friend class we're attempting to instantiate. */
- int m = get_originating_module (friend_tmpl);
+ /* We're only interested in declarations attached to the same module
+ as the friend class we're attempting to instantiate. */
+ int m = get_originating_module (friend_tmpl, true);
gcc_assert (m != 0);
/* There should be at most one class template from the module we're
looking for, return it. */
for (ovl_iterator iter (bind); iter; ++iter)
if (DECL_CLASS_TEMPLATE_P (*iter)
- && get_originating_module (*iter) == m)
+ && get_originating_module (*iter, true) == m)
return *iter;
return NULL_TREE;
diff --git a/gcc/testsuite/g++.dg/modules/tpl-friend-17.h
b/gcc/testsuite/g++.dg/modules/tpl-friend-17.h
new file mode 100644
index 000..429ab3d5977
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/tpl-friend-17.h
@@ -0,0 +1,8 @@
+// PR c++/118920
+
+template struct unique_ptr {
+ template friend class out_ptr_t;
+};
+template struct shared_ptr {
+ template friend class out_ptr_t;
+};
diff --git a/gcc/testsuite/g++.dg/modules/tpl-friend-17_a.C
b/gcc/testsuite/g++.dg/modules/tpl-friend-17_a.C
new file mode 100644
index 000..7c5a3ac7ed1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/tpl-friend-17_a.C
@@ -0,0 +1,9 @@
+// PR c++/118920
+// { dg-additional-options "-fmodules" }
+// { dg-module-cmi M }
+
+module;
+#include "tpl-friend-17.h"
+export module M;
+unique_ptr s;
+export template void foo() { shared_ptr u; }
diff --git a/gcc/testsuite/g++.dg/modules/tpl-friend-17_b.C
b/gcc/testsuite/g++.dg/modules/tpl-friend-17_b.C
new file mode 100644
index 000..33586e662ef
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/tpl-friend-17_b.C
@@ -0,0 +1,11 @@
+// PR c++/118920
+// { dg-additional-options "-fmodules" }
+
+#include "tpl-friend-17.h"
+import M;
+
+int main() {
+ // instantiating shared_ptr should find previously generated
+ // out_ptr_t template from the unique_ptr instantiation
+ foo();
+}
--
2.47.0
Re: [PATCH v2 1/2] PR118442: Don't instrument exit edges after musttail
> The only question I have is flow_call_edges_add only called while
> profiling or is it called some other time? So looking into who calls
> flow_call_edges_add, it is only branch_prob (profile.cc) which is only
> called from tree-profile.cc. So a cleanup (for GCC 16 is remove the
> cfghook flow_call_edges_add and call gimple_flow_call_edges_add
> directly from branch_prob).
This is remainder of times we were able to instrument both at RTL and
Gimple level. Before cfgexpand we had no way to maintain gimple profile
down to RTL land.
So indeed we can drop the hook.
Adding fake edges should be useful tool for passes with dataflow
formulated in a way that it expects path form every statement to exit to
exit. We do have some bugs in this direction and some other code
ensuring this (like one in tree-ssa-dce).
Honza
> Plus blocks argument is always NULL so we could even remove support
> for that too.
> So this LGTM; though I can't approve it.
>
> Thanks,
> Andrew Pinski
>
> > {
> > edge e;
> >
> > --
> > 2.47.1
> >
Re: [PATCH] libstdc++: Support maps deduction from_range of tuples.
On 19/03/25 12:08 +0100, Tomasz Kamiński wrote:
This implements part of LWG2713 that enables deduction for maps types
LWG 4223 not 2713
(map, unordered_map, flat_map and non-unique equivalent) from
(from_range, rg, ...) arguments, where rg is range of tuple
and other pair-like.
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__detail::__range_key_type):
Replace RV::first_type with tuple_element_t<0, RV>.
(__detail::__range_mapped_type) Replace RV::second_type
with tuple_element_t<1, RV>.
* testsuite/23_containers/flat_map/1.cc: New tests.
* testsuite/23_containers/flat_multimap/1.cc: New tests.
* testsuite/23_containers/map/cons/from_range.cc: New tests.
* testsuite/23_containers/multimap/cons/from_range.cc: New tests.
* testsuite/23_containers/unordered_map/cons/from_range.cc: New tests.
* testsuite/23_containers/unordered_multimap/cons/from_range.cc:
New tests.
---
This implements non-controvesial part of LWG2713, which provides
parity between iterator pair and from_range cosntructors.
Testing on x86_64-linux (*map* tests passed).
OK for trunk when test finishes?
libstdc++-v3/include/bits/ranges_base.h | 8 ++-
.../testsuite/23_containers/flat_map/1.cc | 61 +
.../23_containers/flat_multimap/1.cc | 65 +++
.../23_containers/map/cons/from_range.cc | 8 ++-
.../23_containers/multimap/cons/from_range.cc | 8 ++-
.../unordered_map/cons/from_range.cc | 8 ++-
.../unordered_multimap/cons/from_range.cc | 12 +++-
7 files changed, 156 insertions(+), 14 deletions(-)
diff --git a/libstdc++-v3/include/bits/ranges_base.h
b/libstdc++-v3/include/bits/ranges_base.h
index c9687c256e9..7d5aee9c430 100644
--- a/libstdc++-v3/include/bits/ranges_base.h
+++ b/libstdc++-v3/include/bits/ranges_base.h
@@ -41,6 +41,10 @@
#include
#include
+#if __glibcxx_ranges_to_container // C++ >= 23
+# include // for tuple_element_t
+#endif
+
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wpedantic" // __int128
@@ -1095,11 +1099,11 @@ namespace __detail
I think we should have a _GLIBCXX_RESOLVE_LIB_DEFECTS comment here, as
this changes something that was in the published C++23 standard. (We
only need one comment, since __range_mapped_type is right next to it.)
OK with that comment added, and the issue number in the commit message
fixed.
template
using __range_key_type
- = remove_const_t::first_type>;
+ = remove_const_t>>;
template
using __range_mapped_type
- = typename ranges::range_value_t<_Range>::second_type;
+ = tuple_element_t<1, ranges::range_value_t<_Range>>;
// The allocator's value_type for map-like containers.
template
diff --git a/libstdc++-v3/testsuite/23_containers/flat_map/1.cc
b/libstdc++-v3/testsuite/23_containers/flat_map/1.cc
index 00254dc2ee6..4e5ac9b62b7 100644
--- a/libstdc++-v3/testsuite/23_containers/flat_map/1.cc
+++ b/libstdc++-v3/testsuite/23_containers/flat_map/1.cc
@@ -11,6 +11,67 @@
#include
#include
#include
+#include
+#include
+
+struct Gt {
+ template
+ bool operator()(T const& l, U const & r) const
+ { return l > r; }
+};
+
+void
+test_deduction_guide()
+{
+ __gnu_test::test_input_range> r(0, 0);
+ std::flat_map it1(std::from_range, r);
+ static_assert(std::is_same_v>);
+ std::flat_map fr1(std::from_range, r);
+ static_assert(std::is_same_v>);
+
+ Gt cmp;
+ std::flat_map it2(r.begin(), r.begin(), cmp);
+ static_assert(std::is_same_v>);
+ std::flat_map fr2(std::from_range, r, cmp);
+ static_assert(std::is_same_v>);
+
+ using Alloc = __gnu_test::SimpleAllocator>;
+ Alloc alloc;
+ // No matching deduction guide
+ // std::flat_map it3(r.begin(), r.begin(), alloc);
+ std::flat_map fr3(std::from_range, r, alloc);
+ static_assert(std::is_same_v<
+ decltype(fr3),
+ std::flat_map,
+ std::vector>,
+ std::vector>>>);
+
+ // No matching deduction guide
+ // std::flat_map it4(r.begin(), r.begin(), cmp, alloc);
+ std::flat_map fr4(std::from_range, r, cmp, alloc);
+ static_assert(std::is_same_v<
+ decltype(fr4),
+ std::flat_map>,
+ std::vector>>>);
+
+ // LWG4223: deduces flat_map, which in turn instantiates
+ // std::vector that is ill-formed.
+ // __gnu_test::test_input_range> r2(0, 0);
+ // std::flat_map it5(r2.begin(), r2.begin());
+ // std::flat_map fr5(std::from_range, r2);
+
+ // LWG4223: deduces flat_map
+ //__gnu_test::test_input_range> r3(0, 0);
+ // std::flat_map it6(r3.begin(), r3.begin());
+ // std::flat_map fr6(std::from_range, r3);
+
+ __gnu_test::test_input_range> r4(0, 0);
+ std::flat_map it7(r4.begin(), r4.begin());
+ static_assert(std::is_same_v>);
+ std::flat_map fr7(std::from_range, r4);
+ static_assert(std::is_same_v>);
+}
template class KeyContainer, template class
MappedContainer>
void
diff --git a/libstdc++-v3/testsuite/23_containers/flat_multimap/1.cc
b/libst
[PATCH] libstdc++: do not advertise full P2562R1 support (was: Re: [PATCH 2/2] libstdc++: add constexpr stable_partition)
Hello,
On 17/03/2025 11:22, Giuseppe D'Angelo wrote:
PS: I've noticed that I have already accidentally bumped the FTM for
constexpr stable sort; that's a bug as these two last algorithms were
not inculded. I can decrement it for the time being, then rebump it again?
I didn't get an answer to this... I'm attaching a patch to fix the
status quo, so that at least we don't advertise the wrong FTM value.
This can be reverted once the other two patches for the algorithms go in.
Thank you,
--
Giuseppe D'Angelo
From 6c6323d3e95f3af51e68c48c877115efbec51db5 Mon Sep 17 00:00:00 2001
From: Giuseppe D'Angelo
Date: Wed, 26 Mar 2025 15:30:47 +0100
Subject: [PATCH] libstdc++: do not advertise full P2562R1 support
P2562R1 ("constexpr Stable Sorting") adds constexpr to stable_sort,
stable_partition and inplace_merge. However only the first is already
implemented in libstdc++, so we shouldn't bump the feature-testing
macro to the bumped C++26 value. This commit sets it to one less
than the final value.
Amends r15-7708-gff43f9853d3b10.
libstdc++-v3/ChangeLog:
* include/bits/version.def (constexpr_algorithms): Change
the value of the feature-testing macro.
* include/bits/version.h: Regenerate.
* testsuite/25_algorithms/cpp_lib_constexpr.cc: Amend the
check of the feature-testing macro.
Signed-off-by: Giuseppe D'Angelo
---
libstdc++-v3/include/bits/version.def | 2 +-
libstdc++-v3/include/bits/version.h | 4 ++--
libstdc++-v3/testsuite/25_algorithms/cpp_lib_constexpr.cc | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libstdc++-v3/include/bits/version.def b/libstdc++-v3/include/bits/version.def
index 1468c0491b7..7ef60af39de 100644
--- a/libstdc++-v3/include/bits/version.def
+++ b/libstdc++-v3/include/bits/version.def
@@ -1117,7 +1117,7 @@ ftms = {
ftms = {
name = constexpr_algorithms;
values = {
-v = 202306;
+v = 202305;
cxxmin = 26;
};
values = {
diff --git a/libstdc++-v3/include/bits/version.h b/libstdc++-v3/include/bits/version.h
index f7c9849893d..a96ff49efa4 100644
--- a/libstdc++-v3/include/bits/version.h
+++ b/libstdc++-v3/include/bits/version.h
@@ -1257,9 +1257,9 @@
#if !defined(__cpp_lib_constexpr_algorithms)
# if (__cplusplus > 202302L)
-# define __glibcxx_constexpr_algorithms 202306L
+# define __glibcxx_constexpr_algorithms 202305L
# if defined(__glibcxx_want_all) || defined(__glibcxx_want_constexpr_algorithms)
-# define __cpp_lib_constexpr_algorithms 202306L
+# define __cpp_lib_constexpr_algorithms 202305L
# endif
# elif (__cplusplus >= 202002L)
# define __glibcxx_constexpr_algorithms 201806L
diff --git a/libstdc++-v3/testsuite/25_algorithms/cpp_lib_constexpr.cc b/libstdc++-v3/testsuite/25_algorithms/cpp_lib_constexpr.cc
index 3f60e996115..3e5e55252fc 100644
--- a/libstdc++-v3/testsuite/25_algorithms/cpp_lib_constexpr.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/cpp_lib_constexpr.cc
@@ -23,7 +23,7 @@
#ifndef __cpp_lib_constexpr_algorithms
# error "Feature-test macro for constexpr algorithms missing"
#elif __cplusplus > 202302L
-# if __cpp_lib_constexpr_algorithms < 202306L
+# if __cpp_lib_constexpr_algorithms < 202305L
# error "Feature-test macro for constexpr algorithms has wrong value"
# endif
#elif __cpp_lib_constexpr_algorithms < 201806L
--
2.34.1
smime.p7s
Description: S/MIME Cryptographic Signature
RE: [PATCH] change cbl_field_data_t::etc_t::value from _Float128 to tree
[I am going to try to maintain a grip on my professionalism. A
professional does not give in to the urge to say, "I told you so".]
This program, compiled with the most recent level of patching, is
generating the result
IDENTIFICATION DIVISION.
PROGRAM-ID. float-sub1.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 S1 PIC 999V99 DISPLAYVALUE 111.11 .
01 D1 PIC 999V99 DISPLAYVALUE 666.66 .
PROCEDURE DIVISION.
DISPLAY "S1 should be 111.11"
DISPLAY "S1is " S1.
DISPLAY "D1 should be 666.66"
DISPLAY "D1is " D1.
END PROGRAM float-sub1.
S1 should be 111.11
S1is 111.10
D1 should be 666.66
D1is 666.66
Those values are NumericDisplay. They are each stored as five ASCII
characters. They are not floating point numbers. They never are floating
point numbers. They are operated on as the smallest binary integers I can
make them be. I do that partly for speed, although the actual operations
are swamped by the conversions from string to binary. Mainly I operate on
them as fixed-point values for the sake of accuracy. In fixed-point, 0.1
is 0.1
But, many months back, I allowed my concerns about having them
*initialized* from the _Float128 "value" member of the cbl_field_t to be
overridden.
I worked out ways of making that work, but I have never been happy about
it, and now those chickens have come home to roost.
So. Anyway. Jim and I may end up discussing this again, and I may well
end up refactoring the code so as to *not* use the floating-point "value"
member for
initialization of fixed-point variables. But I can't try to do that while
you are trying to fix the front-end arithmetic.
In any event, this is the next obvious cause of reasons for test failures.
I look forward to seeing what marvels you perform while I am sleeping.
Oh, wait. It's the weekend. Maybe the marvels will be postponed until
Monday.
All this said, I am more than a little astonished at the progress that's
being made here.
Bob D.
> -Original Message-
> From: Richard Biener
> Sent: Friday, March 21, 2025 15:25
> To: Jakub Jelinek
> Cc: Robert Dubner ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] change cbl_field_data_t::etc_t::value from
_Float128
> to tree
>
> On Fri, 21 Mar 2025, Jakub Jelinek wrote:
>
> > On Fri, Mar 21, 2025 at 01:47:05PM -0500, Robert Dubner wrote:
> > > > -Original Message-
> > > > From: Robert Dubner
> > > > Sent: Friday, March 21, 2025 14:23
> > > > To: Richard Biener
> > > > Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek
> > > > Subject: RE: [PATCH] change cbl_field_data_t::etc_t::value from
> > > _Float128
> > > > to tree
> > > >
> > > > Crossed in the mail.
> > > >
> > > > I applied your fixes below.
> > > >
> > > > The output of the one-liner program is now 1.2345678E+07, as
> expected.
> > > >
> > > > The .00 instead of .01 problem still exists; source code coming
> soon.
> > >
> > > This program
> > >
> > > IDENTIFICATION DIVISION.
> > > PROGRAM-ID. numeds.
> > > DATA DIVISION.
> > > WORKING-STORAGE SECTION.
> > > 01 VARP9 PIC P9 VALUE 0.01.
> > > PROCEDURE DIVISION.
> > > DISPLAY "VARP9 should be .01"
> > > DISPLAY "VARP9is " VARP9.
> > > END PROGRAM numeds.
> > >
> > > generates
> > >
> > > VARP9 should be .01
> > > VARP9is .00
> > >
> > > As usual, it's COBOL, so it comes with a lecture:
> > >
> > > The variable
> > >
> > > 01 VARP9 PIC P9 VALUE 0.01.
> > >
> > > means that it is a NUMERIC DISPLAY variable, which is represented in
> > > memory as ASCII digits. There is but one '9' in the PICTURE, so it
is
> a
> > > one-digit number. The prefix 'P', in the "P9", means that the
actual
> > > value of the variable is scaled by 0.01 So, the value 0.01 is
> represented
> > > in memory by a single "1".
> > >
> > > If it were "PIC 9PPP", then 1,000 would be represented in memory as
a
> > > single "1".
> >
> > The following incremental patch should fix that (but otherwise
> untested).
> >
> > --- gcc/cobol/parse.y.jj2025-03-21 17:49:43.571440176 +0100
> > +++ gcc/cobol/parse.y 2025-03-21 20:15:24.852414777 +0100
> > @@ -4331,7 +4331,8 @@ value_clause: VALUE all LITERAL[lit] {
> >cbl_field_t *field = current_field();
> >auto orig_str = original_number();
> > REAL_VALUE_TYPE orig_val;
> > - real_from_string (&orig_val, orig_str);
> > + real_from_string3 (&orig_val, orig_str,
> > +TYPE_MODE (float128_type_node));
> >char *initial = NULL;
> >
> >if( real_identical (&orig_val, &$value) ) {
> > @@ -6922,7 +6923,8 @@ cce_expr: cce_factor
> > cce_factor: NUMSTR {
> >/* ??? real_from_string does not allow arbitra
[COMMITTED 023/146] gccrs: fix typechecking of Fn trait calls using ADT types
From: Philip Herron
Fixes RustGcc#2953
gcc/rust/ChangeLog:
* typecheck/rust-hir-type-check-item.cc (TypeCheckItem::visit): fix the
ty_id
gcc/testsuite/ChangeLog:
* rust/compile/nr2/exclude: nr2 cant handle these
* rust/compile/issue-2953-1.rs: New test.
* rust/compile/issue-2953-2.rs: New test.
Signed-off-by: Philip Herron
---
.../typecheck/rust-hir-type-check-item.cc | 10 +++--
gcc/testsuite/rust/compile/issue-2953-1.rs| 27 ++
gcc/testsuite/rust/compile/issue-2953-2.rs| 37 +++
gcc/testsuite/rust/compile/nr2/exclude| 2 +
4 files changed, 72 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/rust/compile/issue-2953-1.rs
create mode 100644 gcc/testsuite/rust/compile/issue-2953-2.rs
diff --git a/gcc/rust/typecheck/rust-hir-type-check-item.cc
b/gcc/rust/typecheck/rust-hir-type-check-item.cc
index 81e2f25f73d..28368d4730a 100644
--- a/gcc/rust/typecheck/rust-hir-type-check-item.cc
+++ b/gcc/rust/typecheck/rust-hir-type-check-item.cc
@@ -231,7 +231,8 @@ TypeCheckItem::visit (HIR::TupleStruct &struct_decl)
= parse_repr_options (attrs, struct_decl.get_locus ());
auto *type = new TyTy::ADTType (
-struct_decl.get_mappings ().get_hirid (), mappings.get_next_hir_id (),
+struct_decl.get_mappings ().get_hirid (),
+struct_decl.get_mappings ().get_hirid (),
struct_decl.get_identifier ().as_string (), ident,
TyTy::ADTType::ADTKind::TUPLE_STRUCT, std::move (variants),
std::move (substitutions), repr,
@@ -312,7 +313,8 @@ TypeCheckItem::visit (HIR::StructStruct &struct_decl)
= parse_repr_options (attrs, struct_decl.get_locus ());
auto *type = new TyTy::ADTType (
-struct_decl.get_mappings ().get_hirid (), mappings.get_next_hir_id (),
+struct_decl.get_mappings ().get_hirid (),
+struct_decl.get_mappings ().get_hirid (),
struct_decl.get_identifier ().as_string (), ident,
TyTy::ADTType::ADTKind::STRUCT_STRUCT, std::move (variants),
std::move (substitutions), repr,
@@ -369,7 +371,7 @@ TypeCheckItem::visit (HIR::Enum &enum_decl)
// multi variant ADT
auto *type
= new TyTy::ADTType (enum_decl.get_mappings ().get_hirid (),
-mappings.get_next_hir_id (),
+enum_decl.get_mappings ().get_hirid (),
enum_decl.get_identifier ().as_string (), ident,
TyTy::ADTType::ADTKind::ENUM, std::move (variants),
std::move (substitutions));
@@ -440,7 +442,7 @@ TypeCheckItem::visit (HIR::Union &union_decl)
auto *type
= new TyTy::ADTType (union_decl.get_mappings ().get_hirid (),
-mappings.get_next_hir_id (),
+union_decl.get_mappings ().get_hirid (),
union_decl.get_identifier ().as_string (), ident,
TyTy::ADTType::ADTKind::UNION, std::move (variants),
std::move (substitutions));
diff --git a/gcc/testsuite/rust/compile/issue-2953-1.rs
b/gcc/testsuite/rust/compile/issue-2953-1.rs
new file mode 100644
index 000..d07059e440e
--- /dev/null
+++ b/gcc/testsuite/rust/compile/issue-2953-1.rs
@@ -0,0 +1,27 @@
+#[lang = "sized"]
+pub trait Sized {
+// Empty.
+}
+
+#[lang = "fn_once"]
+pub trait FnOnce {
+/// The returned type after the call operator is used.
+#[lang = "fn_once_output"]
+type Output;
+
+/// Performs the call operation.
+extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
+}
+
+pub enum Ordering {
+/// An ordering where a compared value is less than another.
+Less = -1,
+/// An ordering where a compared value is equal to another.
+Equal = 0,
+/// An ordering where a compared value is greater than another.
+Greater = 1,
+}
+
+pub fn f Ordering>(g: F) -> Ordering {
+g(1)
+}
diff --git a/gcc/testsuite/rust/compile/issue-2953-2.rs
b/gcc/testsuite/rust/compile/issue-2953-2.rs
new file mode 100644
index 000..59276246a1c
--- /dev/null
+++ b/gcc/testsuite/rust/compile/issue-2953-2.rs
@@ -0,0 +1,37 @@
+#[lang = "sized"]
+pub trait Sized {
+// Empty.
+}
+
+#[lang = "fn_once"]
+pub trait FnOnce {
+/// The returned type after the call operator is used.
+#[lang = "fn_once_output"]
+type Output;
+
+/// Performs the call operation.
+extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
+}
+
+pub enum Ordering {
+/// An ordering where a compared value is less than another.
+Less = -1,
+/// An ordering where a compared value is equal to another.
+Equal = 0,
+/// An ordering where a compared value is greater than another.
+Greater = 1,
+}
+
+pub fn max_by Ordering>(v1: T, v2: T, compare: F) -> T
{
+match compare(&v1, &v2) {
+Ordering::Less | Ordering::Equal => v2,
+Ordering::Greater => v1,
+}
+}
+
+pub fn min_by Ordering>(v1: T, v2: T, compare: F) -> T
{
+ma
Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language
Sorry for the delay. I’m planning on sending out our design rationale of the current approach without the new syntax today. - Yeoul > On Mar 14, 2025, at 9:22 PM, John McCall wrote: > > On 14 Mar 2025, at 15:18, Martin Uecker wrote: > > Am Freitag, dem 14.03.2025 um 14:42 -0400 schrieb John McCall: > > On 14 Mar 2025, at 14:13, Martin Uecker wrote: > > Am Freitag, dem 14.03.2025 um 10:11 -0700 schrieb David Tarditi: > > Hi Martin, > > The C design of VLAs misunderstood dependent typing. > > They probably did not care about theory, but the design is > not inconsistent with theory. > > This is almost true, but for bad reasons. The theory of dependent types is > heavily concerned with deciding whether two types are the same, and C simply > sidesteps this question because type identity is largely meaningless in C. > Every value of variably-modified type is (or decays to) a pointer, and all > pointers in C freely convert to one another (within the object/function > categories). _Generic is based on type compatibility, not equality. So in > that sense, the standard doesn’t say anything inconsistent with theory > because it doesn’t even try to say anything. > > The reason it is not quite true is that C does have rules for compatible and > composite types, and alas, those rules for variably-modified types are not > consistent with theory. Two VLA types of compatible element type are always > statically considered compatible, and it’s simply UB if the sizes aren’t the > same. The composite type of a VLA and a fixed-size array type is always the > fixed-size array type. The standard is literally incomplete about the > composite type of two VLAs; if you use a ternary operator where both operands > are casts to VLA types, the standard just says it’s straight-up just > undefined behavior (because one of the types has a bound that’s unevaluated) > and doesn’t even bother telling us what the static type is supposed to be. > > Yes, I guess this is all true. > > But let's rephrase my point a bit more precisely: One could take > a strict subset of C that includes variably modified types but > obviously has to forbid a lot other things (e.g. arbitrary pointer > conversions or unsafe down-casts and much more) and make this a > memory-safe language with dependent types. This would also > require adding run-time checks at certain places where there > is now UB, in particular where two VLA types need to be compatible. > > Mmm. You can certainly subset C to the point that it’s memory-safe, but > it wouldn’t really be anything like C anymore. As long as C has a heap, > I don’t see any path to achieving temporal safety without significant > extensions to the language. But if we’re just talking about spatial safety, > then sure, that could be a lot closer to C today. > > Is that your vision, then, that you’d like to see the same sort of checks > that -fbounds-safety does, but you want them based firmly in the language > as a dynamic check triggered by pointer type conversion, with bounds > specified using variably-modified types? It’s a pretty elegant vision, and > I can see the attraction. It has some real merits, which I’ll get to below. > I do see at least two significant challenges, though. > > The first and biggest problem is that, in general, array bounds can only be > expressed on a pointer value if it’s got pointer to array type. Most C array > code today works primarily with pointers to elements; programmers just use > array types to create concrete arrays, and they very rarely use pointers to > array type at all. There are a bunch of reasons for that: > > Pointers to arrays have to be dereferenced twice: (*ptr)[idx] instead > of ptr[idx]. > > That makes them more error-prone, because it is easy to do pointer > arithmetic at the wrong level, e.g. by writing ptr[idx], which will > stride by multiples of the entire array size. That may even pass the > compiler without complaint because of C’s laxness about conversions. > > Keeping the bound around in the pointer type is more work and doesn’t do > anything useful right now. > > A lot of C programmers dislike nested declarator syntax and can’t remember > how it works. Those of us who can write it off the top of our heads are > quite atypical. > > Now, there is an exception: you can write a parameter using an array type, > and it actually declares a pointer parameter. You could imagine using this > as a syntax for an enforceable array bound for arguments, although the > committee did already decide that these bounds were meaningless without > static. Unfortunately, you can’t do this in any other position and still > end up with just a pointer, so it’s not helpful as a general syntax for > associating bounds with pointers. > > The upshot is that this isn’t really something people can just adopt by > adding annotations. It’s not just a significant rewrite, it’s a rewrite that > programmers will have very legitimate objections to. I t
Re: [PATCH] tailc: Only diagnose musttail failures during tailc or musttail passes [PR119376]
Jakub Jelinek writes:
> --- gcc/testsuite/g++.dg/opt/musttail2.C.jj 2025-03-24 13:27:44.329204196
> +0100
> +++ gcc/testsuite/g++.dg/opt/musttail2.C 2025-03-24 13:28:08.975867389
> +0100
> @@ -0,0 +1,14 @@
> +// PR ipa/119376
> +// { dg-do compile { target musttail } }
I think this needs to be target external_tailcall, otherwise you will
fail on targets that don't support that.
> +// { dg-options "-O2 -fno-early-inlining -fdump-tree-optimized" }
> +// { dg-final { scan-tree-dump-times " \[^\n\r]* = foo \\\(\[^\n\r]*\\\);
> \\\[tail call\\\] \\\[must tail call\\\]" 1 "optimized" } }
> +
> +struct S { S () {} };
> +char *foo (S);
Or alternatively make this not extern.
> +
> +char *
> +bar (S)
> +{
> + S t;
> + [[clang::musttail]] return foo (t);
> +}
>
> Jakub
[PATCH v2] c: Fix tagname confusion for typedef redefinitions [PR118765]
I looked at this again and do not need a workaround anymore.
I did not implement any restrictions preventing typedef
redeclarations from having different alignment, because
merge_decls does not include any such restrictions at this
time. I could write another patch for this, but I think
this would be an unrelated change.
Bootstrapped and regression tested on x86_64.
c: Fix tagname confusion for typedef redefinitions [PR118765]
When we redefine a typedef for a tagged type that has just been
redefined, merge_decls may produce invalid TYPE_DECLS that are not
consistent with what set_underlying_type produces. This is fixed
by updating DECL_ORIGINAL_TYPE.
PR c/118765
gcc/c/ChangeLog:
* c-decl.cc (merge_decls): For TYPE_DECLS copy
DECL_ORIGINAL_TYPE from the old declaration.
* c-typeck.cc (tagged_types_tu_compatible_p): Add
checking assertions.
gcc/testsuite/ChangeLog:
* gcc.dg/pr118765-2.c: New test.
* gcc.dg/pr118765-3.c: New test.
* gcc.dg/typedef-redecl3.c: New test.
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 1ae520828c3..c778c7febfa 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -2788,6 +2788,9 @@ merge_decls (tree newdecl, tree olddecl, tree newtype,
tree oldtype)
break;
}
}
+
+ /* Make sure we refer to the same type as the olddecl. */
+ DECL_ORIGINAL_TYPE (newdecl) = DECL_ORIGINAL_TYPE (olddecl);
}
/* Merge the data types specified in the two decls. */
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 71782bc42d2..aaf8e54416a 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -1812,6 +1812,10 @@ tagged_types_tu_compatible_p (const_tree t1, const_tree
t2,
to go look at the original type. */
t1 = c_type_original (t1);
t2 = c_type_original (t2);
+ gcc_checking_assert (!TYPE_NAME (t1)
+ || TREE_CODE (TYPE_NAME (t1)) == IDENTIFIER_NODE);
+ gcc_checking_assert (!TYPE_NAME (t2)
+ || TREE_CODE (TYPE_NAME (t2)) == IDENTIFIER_NODE);
if (TYPE_NAME (t1) != TYPE_NAME (t2))
return false;
diff --git a/gcc/testsuite/gcc.dg/pr118765-2.c
b/gcc/testsuite/gcc.dg/pr118765-2.c
new file mode 100644
index 000..0c3e4988118
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr118765-2.c
@@ -0,0 +1,33 @@
+/* { dg-do "compile" } */
+/* { dg-options "-std=gnu23" } */
+
+typedef struct q { int x; } q_t;
+typedef struct q { int x; } q_t;
+typedef struct q { int x; } q_t;
+typedef struct q { int x; } q_t;
+typedef struct q { int x; } q_t;
+
+typedef struct r r_t;
+typedef struct r r_t;
+typedef struct r r_t;
+typedef struct r r_t;
+typedef struct r r_t;
+
+extern struct s { int x; } s;
+extern struct s { int x; } s;
+extern struct s { int x; } s;
+extern struct s { int x; } s;
+extern struct s { int x; } s;
+
+struct t { int x; };
+struct t { int x; };
+struct t { int x; };
+struct t { int x; };
+struct t { int x; };
+
+typedef enum e { E = 1 } e_t;
+typedef enum e { E = 1 } e_t;
+typedef enum e { E = 1 } e_t;
+typedef enum e { E = 1 } e_t;
+typedef enum e { E = 1 } e_t;
+
diff --git a/gcc/testsuite/gcc.dg/pr118765-3.c
b/gcc/testsuite/gcc.dg/pr118765-3.c
new file mode 100644
index 000..e86d1100482
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr118765-3.c
@@ -0,0 +1,33 @@
+/* { dg-do "compile" } */
+/* { dg-options "-std=gnu23" } */
+
+typedef struct q { int x; } q_t;
+typedef struct q q_t;
+typedef struct q { int x; } q_t;
+typedef struct q q_t;
+typedef struct q { int x; } q_t;
+
+typedef struct r r_t;
+typedef struct r r_t;
+typedef struct r r_t;
+typedef struct r r_t;
+typedef struct r r_t;
+
+extern struct s { int x; } s;
+extern struct s s;
+extern struct s { int x; } s;
+extern struct s s;
+extern struct s { int x; } s;
+
+struct t { int x; };
+struct t;
+struct t { int x; };
+struct t;
+struct t { int x; };
+
+typedef enum e { E = 1 } e_t;
+typedef enum e_t; /* { dg-warning "useless storage class
specifier in empty declaration" } */
+typedef enum e { E = 1 } e_t;
+typedef enum e_t; /* { dg-warning "empty declaration with storage
class specifier does not redeclare tag"
} */
+typedef enum e { E = 1 } e_t;
+
diff --git a/gcc/testsuite/gcc.dg/typedef-redecl3.c
b/gcc/testsuite/gcc.dg/typedef-redecl3.c
new file mode 100644
index 000..a2424d6b7ab
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/typedef-redecl3.c
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+#define N 64
+
+struct f { int x; };
+typedef struct f T;
+typedef struct f T __attribute__((aligned (N)));
+typedef struct f T __attribute__((aligned (N * 2)));
+typedef struct f T __attribute__((aligned (N)));
+typedef struct f T;
+
+_Static_assert (_Alignof (T) == N * 2, "N * 2");
+
+enum g { A = 1 };
+typedef enum g S;
+typedef enum g S __attribute__((aligned (N)));
+typedef enum g S __attribute__((aligned (N *
RE: [PATCH] cobol, v2: Get rid of __int128 uses in the COBOL FE [PR119242]
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, March 26, 2025 08:24
> To: Robert Dubner
> Cc: James K. Lowden ; Richard Biener
> ; gcc-patches@gcc.gnu.org
> Subject: [PATCH] cobol, v2: Get rid of __int128 uses in the COBOL FE
> [PR119242]
>
> On Tue, Mar 25, 2025 at 11:36:10PM -0500, Robert Dubner wrote:
> > I took a minute to apply the patch and run the tests. Ten of the UAT
> > tests fail; they are the ones that test the ROUNDED clause.
> >
> > It's 00:30 local time here, so I am not going to look into it now.
But
> > here is a simple case so that you have something to chew on while I am
> > getting my beauty sleep:
> >
> >IDENTIFICATION DIVISION.
> >PROGRAM-ID. prog.
> >DATA DIVISION.
> >WORKING-STORAGE SECTION.
> >01 NPIC S9.
> >PROCEDURE DIVISION.
> >COMPUTE N ROUNDED MODE AWAY-FROM-ZERO = -2.51
> >DISPLAY "N should be -3"
> >DISPLAY "Nis " N
> >GOBACK.
> >END PROGRAM prog.
> >
> > N should be -3
> > Nis +1
>
> Sorry, got the conversion wrong in 2 spots.
>
> For signable the old code did
> if( value < 0 && (((pvalue[capacity-1] & 0x80) == 0 )))
> {
> capacity *= 2;
> }
> else if( value >= 0 && (((pvalue[capacity-1] & 0x80) == 0x80 )))
> {
> capacity *= 2;
> }
> value < 0 has been correctly replaced with wi::neg_p (value)
> and (pvalue[capacity-1] & 0x80) with
> (value & wi::set_bit_in_zero(capacity * 8 - 1))
> (both are testing the same bit), but I got the two comparisons exactly
> the other way, for negative values it was testing if that bit is set
> (while previously it was testing if it was clear) and vice versa.
>
> Here is a fixed patch, passes make check-cobol, but that is
unfortunately
> still not enough.
With this second fixed patch, all of our tests pass.
Implicit criticism about tests accepted. I have 679 UAT tests, and now
I've got the bit in my teeth, and I am creating a process that will
convert as many as I can to DejaGnu. However: the autom4te and DejaGnu
principles, practices, and philosophies are almost, but not quite,
completely unlike each other.
With Jim back to help pay attention to the e-mails, I'll be able to focus
on the conversion. I hope to have a first tranche later today.
>
> 2025-03-26 Jakub Jelinek
>
> PR cobol/119242
> * cobol/genutil.h (get_power_of_ten): Remove #pragma GCC
diagnostic
> around declaration.
> * cobol/genapi.cc (psa_FldLiteralN): Change type of value from
> __int128 to FIXED_WIDE_INT(128). Remove #pragma GCC diagnostic
> around the declaration. Use wi::min_precision to determine
> minimum unsigned precision of the value. Use wi::neg_p instead
> of value < 0 tests and wi::set_bit_in_zero
> to build sign bit. Handle field->data.capacity == 16 like
> 1, 2, 4 and 8, use wide_int_to_tree instead of build_int_cst.
> (mh_source_is_literalN): Remove #pragma GCC diagnostic around
> the definition.
> (binary_initial_from_float128): Likewise.
> * cobol/genutil.cc (get_power_of_ten): Remove #pragma GCC
diagnostic
> before the definition.
>
> --- gcc/cobol/genutil.h.jj2025-03-25 21:14:48.448384925 +0100
> +++ gcc/cobol/genutil.h 2025-03-25 21:19:24.358620134 +0100
> @@ -104,10 +104,7 @@ void get_binary_value( tree value,
> tree get_data_address( cbl_field_t *field,
> tree offset);
>
> -#pragma GCC diagnostic push
> -#pragma GCC diagnostic ignored "-Wpedantic"
> FIXED_WIDE_INT(128) get_power_of_ten(int n);
> -#pragma GCC diagnostic pop
> void scale_by_power_of_ten_N(tree value,
> int N,
> bool check_for_fractional = false);
> --- gcc/cobol/genapi.cc.jj2025-03-25 21:11:06.767409766 +0100
> +++ gcc/cobol/genapi.cc 2025-03-26 13:16:23.932827326 +0100
> @@ -3798,16 +3798,13 @@ psa_FldLiteralN(struct cbl_field_t *fiel
>// We are constructing a completely static constant structure, based
on
> the
>// text string in .initial
>
> -#pragma GCC diagnostic push
> -#pragma GCC diagnostic ignored "-Wpedantic"
> - __int128 value = 0;
> -#pragma GCC diagnostic pop
> + FIXED_WIDE_INT(128) value = 0;
>
>do
> {
> // This is a false do{}while, to isolate the variables:
>
> -// We need to convert data.initial to an __int128 value
> +// We need to convert data.initial to an FIXED_WIDE_INT(128) value
> char *p = const_cast(field->data.initial);
> int sign = 1;
> if( *p == '-' )
> @@ -3903,24 +3900,24 @@ psa_FldLiteralN(struct cbl_field_t *fiel
>
> // We now need to calculate the capacity.
>
> -unsigned char *pvalue = (unsigned char *)&value;
> +unsigned int min_prec = wi::min_precision(value, UNSIGNED);
> int capacity;
> -if( *(uint64
Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language
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. Best regards, Yeoul > On Mar 26, 2025, at 9:11 AM, Yeoul Na wrote: > > Sorry for the delay. > > I’m planning on sending out our design rationale of the current approach > without the new syntax today. > > - Yeoul > >> On Mar 14, 2025, at 9:22 PM, John McCall wrote: >> >> On 14 Mar 2025, at 15:18, Martin Uecker wrote: >> >> Am Freitag, dem 14.03.2025 um 14:42 -0400 schrieb John McCall: >> >> On 14 Mar 2025, at 14:13, Martin Uecker wrote: >> >> Am Freitag, dem 14.03.2025 um 10:11 -0700 schrieb David Tarditi: >> >> Hi Martin, >> >> The C design of VLAs misunderstood dependent typing. >> >> They probably did not care about theory, but the design is >> not inconsistent with theory. >> >> This is almost true, but for bad reasons. The theory of dependent types is >> heavily concerned with deciding whether two types are the same, and C simply >> sidesteps this question because type identity is largely meaningless in C. >> Every value of variably-modified type is (or decays to) a pointer, and all >> pointers in C freely convert to one another (within the object/function >> categories). _Generic is based on type compatibility, not equality. So in >> that sense, the standard doesn’t say anything inconsistent with theory >> because it doesn’t even try to say anything. >> >> The reason it is not quite true is that C does have rules for compatible and >> composite types, and alas, those rules for variably-modified types are not >> consistent with theory. Two VLA types of compatible element type are always >> statically considered compatible, and it’s simply UB if the sizes aren’t the >> same. The composite type of a VLA and a fixed-size array type is always the >> fixed-size array type. The standard is literally incomplete about the >> composite type of two VLAs; if you use a ternary operator where both >> operands are casts to VLA types, the standard just says it’s straight-up >> just undefined behavior (because one of the types has a bound that’s >> unevaluated) and doesn’t even bother telling us what the static type is >> supposed to be. >> >> Yes, I guess this is all true. >> >> But let's rephrase my point a bit more precisely: One could take >> a strict subset of C that includes variably modified types but >> obviously has to forbid a lot other things (e.g. arbitrary pointer >> conversions or unsafe down-casts and much more) and make this a >> memory-safe language with dependent types. This would also >> require adding run-time checks at certain places where there >> is now UB, in particular where two VLA types need to be compatible. >> >> Mmm. You can certainly subset C to the point that it’s memory-safe, but >> it wouldn’t really be anything like C anymore. As long as C has a heap, >> I don’t see any path to achieving temporal safety without significant >> extensions to the language. But if we’re just talking about spatial safety, >> then sure, that could be a lot closer to C today. >> >> Is that your vision, then, that you’d like to see the same sort of checks >> that -fbounds-safety does, but you want them based firmly in the language >> as a dynamic check triggered by pointer type conversion, with bounds >> specified using variably-modified types? It’s a pretty elegant vision, and >> I can see the attraction. It has some real merits, which I’ll get to below. >> I do see at least two significant challenges, though. >> >> The first and biggest problem is that, in general, array bounds can only be >> expressed on a pointer value if it’s got pointer to array type. Most C array >> code today works primarily with pointers to elements; programmers just use >> array types to create concrete arrays, and they very rarely use pointers to >> array type at all. There are a bunch of reasons for that: >> >> Pointers to arrays have to be dereferenced twice: (*ptr)[idx] instead >> of ptr[idx]. >> >> That makes them more error-prone, because it is easy to do pointer >> arithmetic at the wrong level, e.g. by writing ptr[idx], which will >> stride by multiples of the entire array size. That may even pass the >> compiler without complaint because of C’s laxness about conversions. >> >> Keeping the bound around in the pointer type is more work and doesn’t do >> anything useful right now. >> >> A lot of C programmers dislike nested declarator syntax and can’t remember >> how it works. Those of us who can write it off the top of our heads are >> quite atypical. >> >> Now, there is an exception: you can write a parameter using an array type, >> and it actua
[PATCH] testsuite: Fix up musttail2.C test
On Wed, Mar 26, 2025 at 10:10:07AM -0700, Andi Kleen wrote:
> Jakub Jelinek writes:
>
> > --- gcc/testsuite/g++.dg/opt/musttail2.C.jj 2025-03-24 13:27:44.329204196
> > +0100
> > +++ gcc/testsuite/g++.dg/opt/musttail2.C2025-03-24 13:28:08.975867389
> > +0100
> > @@ -0,0 +1,14 @@
> > +// PR ipa/119376
> > +// { dg-do compile { target musttail } }
>
> I think this needs to be target external_tailcall, otherwise you will
> fail on targets that don't support that.
>
> > +// { dg-options "-O2 -fno-early-inlining -fdump-tree-optimized" }
> > +// { dg-final { scan-tree-dump-times " \[^\n\r]* = foo \\\(\[^\n\r]*\\\);
> > \\\[tail call\\\] \\\[must tail call\\\]" 1 "optimized" } }
> > +
> > +struct S { S () {} };
> > +char *foo (S);
>
> Or alternatively make this not extern.
You're right (although I don't remember which targets are
non-external_musttail).
Here is a patch to define the function, tested on x86_64-linux, ok for trunk?
2025-03-26 Jakub Jelinek
* g++.dg/opt/musttail2.C (foo): Define the function instead of
just declaring it, add [[gnu::noipa]] attribute to it.
--- gcc/testsuite/g++.dg/opt/musttail2.C.jj 2025-03-25 09:36:31.502487137
+0100
+++ gcc/testsuite/g++.dg/opt/musttail2.C2025-03-26 18:17:59.827281263
+0100
@@ -4,7 +4,12 @@
// { dg-final { scan-tree-dump-times " \[^\n\r]* = foo \\\(\[^\n\r]*\\\);
\\\[tail call\\\] \\\[must tail call\\\]" 1 "optimized" } }
struct S { S () {} };
-char *foo (S);
+
+[[gnu::noipa]] char *
+foo (S)
+{
+ return 0;
+}
char *
bar (S)
Jakub
Re: [PATCH] libstdc++: do not advertise full P2562R1 support (was: Re: [PATCH 2/2] libstdc++: add constexpr stable_partition)
On Wed, 26 Mar 2025 at 14:41, Giuseppe D'Angelo wrote: > > Hello, > > On 17/03/2025 11:22, Giuseppe D'Angelo wrote: > > > > PS: I've noticed that I have already accidentally bumped the FTM for > > constexpr stable sort; that's a bug as these two last algorithms were > > not inculded. I can decrement it for the time being, then rebump it again? > > I didn't get an answer to this... I'm attaching a patch to fix the > status quo, so that at least we don't advertise the wrong FTM value. > This can be reverted once the other two patches for the algorithms go in. Thanks - OK for trunk.
Re: [PATCH] cobol, v2: Get rid of __int128 uses in the COBOL FE [PR119242]
On Wed, Mar 26, 2025 at 10:21:31AM -0500, Robert Dubner wrote: > > Here is a fixed patch, passes make check-cobol, but that is unfortunately > > still not enough. > > With this second fixed patch, all of our tests pass. Great. Is the patch ok for trunk then, or do you plan to review it or will James do that? > Implicit criticism about tests accepted. I have 679 UAT tests, and now > I've got the bit in my teeth, and I am creating a process that will > convert as many as I can to DejaGnu. However: the autom4te and DejaGnu > principles, practices, and philosophies are almost, but not quite, > completely unlike each other. Didn't mean to criticize in any way, just mention that because we have just 23 tests so far, the UAT/NIST testing you are doing is a precondition for any non-trivial FE changes and that testing wasn't done on my side. Jakub
testsuite: Fix up append-args-interop.f90 test
On Tue, Mar 25, 2025 at 10:03:17AM -0600, Sandra Loosemore wrote: > * gfortran.dg/gomp/append-args-interop.f90: New. The test fails for me with UNRESOLVED: gfortran.dg/gomp/append-args-interop.f90 -O scan-tree-dump gimple "__builtin_GOMP_interop (99, 0, 0B, 0B, 0B, 0, 0B, 3, interopobjs.[0-9]+," UNRESOLVED: gfortran.dg/gomp/append-args-interop.f90 -O scan-tree-dump gimple "__builtin_GOMP_interop (99, 3, interopobjs.[0-9]+, tgt_tgtsync.[0-9]+, pref_type.[0-9]+, " UNRESOLVED: gfortran.dg/gomp/append-args-interop.f90 -O scan-tree-dump gimple "g (&interop.[0-9]+, interop.[0-9]+, &interop.[0-9]+)" FAIL: gfortran.dg/gomp/append-args-interop.f90 -O (test for excess errors) on both x86_64-linux and i686-linux. The gcc/testsuite/*/gomp/ tests aren't compiled with include or module paths pointing to libgomp, so shouldn't be using omp.h nor use omp_lib etc. The following patch adjusts the test to define it locally, like e.g. recently in interop-5.f90 test or many other tests which have their own definitions of types or enumerators they need. Tested on x86_64-linux, committed to trunk. 2025-03-26 Jakub Jelinek * gfortran.dg/gomp/append-args-interop.f90: Don't use omp_lib, instead use iso_c_binding and define omp_interop_kind parameter locally. --- gcc/testsuite/gfortran.dg/gomp/append-args-interop.f90.jj 2025-03-25 21:11:06.863408456 +0100 +++ gcc/testsuite/gfortran.dg/gomp/append-args-interop.f90 2025-03-26 14:39:53.435511151 +0100 @@ -6,7 +6,8 @@ ! append_args clause. module m - use omp_lib, only: omp_interop_kind + use iso_c_binding, only: c_intptr_t + integer, parameter :: omp_interop_kind = c_intptr_t contains subroutine g(x,y,z) integer(omp_interop_kind) :: x, y, z Jakub
[PATCH 02/12] testsuite: fix broken dg directives
Found by dg-lint.
gcc/testsuite/ChangeLog:
* gcc.dg/ipa/pr110377.c: Fix missing trailing " }" in dg-do
directive.
* gcc.dg/plugin/infoleak-1.c: Fix dg-bogus directive.
* gcc.dg/pr101364-1.c: Fix missing trailing " }" in dg-options
directive.
* gcc.dg/pr113207.c: Fix dg-do.
* gcc.dg/sarif-output/include-chain-2.c: Fix ordering of dg-do
and dg-require-effective-target.
* gcc.dg/strub-pr118007.c: Likewise.
* gcc.dg/tanhbysinh.c: Fix missing whitespace after opening
brace and before closing brace in 6 dg-final directives.
* gcc.dg/uninit-pred-3_c.c: Fix missing whitespace after opening
brace in 6 dg-final directive.
* gcc.dg/uninit-pred-3_d.c: Likewise.
* gcc.dg/variable-sized-type-flex-array.c: Fix missing space
between dg-bogus and message in 2 places.
---
gcc/testsuite/gcc.dg/ipa/pr110377.c | 2 +-
gcc/testsuite/gcc.dg/plugin/infoleak-1.c | 2 +-
gcc/testsuite/gcc.dg/pr101364-1.c| 2 +-
gcc/testsuite/gcc.dg/pr113207.c | 2 +-
gcc/testsuite/gcc.dg/sarif-output/include-chain-2.c | 2 +-
gcc/testsuite/gcc.dg/strub-pr118007.c| 2 +-
gcc/testsuite/gcc.dg/tanhbysinh.c| 12 ++--
gcc/testsuite/gcc.dg/uninit-pred-3_c.c | 2 +-
gcc/testsuite/gcc.dg/uninit-pred-3_d.c | 2 +-
.../gcc.dg/variable-sized-type-flex-array.c | 4 ++--
10 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/ipa/pr110377.c
b/gcc/testsuite/gcc.dg/ipa/pr110377.c
index 63120a97bd0c..76faef5e74ec 100644
--- a/gcc/testsuite/gcc.dg/ipa/pr110377.c
+++ b/gcc/testsuite/gcc.dg/ipa/pr110377.c
@@ -1,4 +1,4 @@
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-options "-O2 -fdump-ipa-cp" } */
int test3(int);
__attribute__ ((noinline))
diff --git a/gcc/testsuite/gcc.dg/plugin/infoleak-1.c
b/gcc/testsuite/gcc.dg/plugin/infoleak-1.c
index 4c5a86aeb0aa..07e3101a8367 100644
--- a/gcc/testsuite/gcc.dg/plugin/infoleak-1.c
+++ b/gcc/testsuite/gcc.dg/plugin/infoleak-1.c
@@ -69,7 +69,7 @@ void test_2d (void __user *dst, u32 a)
{
struct s2 s = {0};
s.i = a;
- copy_to_user(dst, &s, sizeof (struct s2)); /* { dg-bogus" } */
+ copy_to_user(dst, &s, sizeof (struct s2)); /* { dg-bogus "" } */
}
struct empty {};
diff --git a/gcc/testsuite/gcc.dg/pr101364-1.c
b/gcc/testsuite/gcc.dg/pr101364-1.c
index e7c94a05553c..c2e321141798 100644
--- a/gcc/testsuite/gcc.dg/pr101364-1.c
+++ b/gcc/testsuite/gcc.dg/pr101364-1.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-std=c90 "} */
+/* { dg-options "-std=c90" } */
void fruit(); /* { dg-message "previous declaration" } */
void fruit( /* { dg-error "conflicting types for" } */
diff --git a/gcc/testsuite/gcc.dg/pr113207.c b/gcc/testsuite/gcc.dg/pr113207.c
index 81f53d8fcc2f..a8bc80d964d4 100644
--- a/gcc/testsuite/gcc.dg/pr113207.c
+++ b/gcc/testsuite/gcc.dg/pr113207.c
@@ -1,4 +1,4 @@
-/* { dg-compile } */
+/* { dg-do compile } */
/* { dg-require-effective-target lto } */
/* { dg-options "-flto -fchecking" } */
diff --git a/gcc/testsuite/gcc.dg/sarif-output/include-chain-2.c
b/gcc/testsuite/gcc.dg/sarif-output/include-chain-2.c
index d5e3b0cbf472..643a709f4e8d 100644
--- a/gcc/testsuite/gcc.dg/sarif-output/include-chain-2.c
+++ b/gcc/testsuite/gcc.dg/sarif-output/include-chain-2.c
@@ -1,6 +1,6 @@
+/* { dg-do compile } */
/* { dg-require-effective-target analyzer } */
/* { dg-options "-fanalyzer -fdiagnostics-format=sarif-file" } */
-/* { dg-do compile } */
/* Verify that SARIF output can capture chains of include files in
diagnostic paths within result locations.
diff --git a/gcc/testsuite/gcc.dg/strub-pr118007.c
b/gcc/testsuite/gcc.dg/strub-pr118007.c
index 51f48245b3f2..92cd31ebd1f3 100644
--- a/gcc/testsuite/gcc.dg/strub-pr118007.c
+++ b/gcc/testsuite/gcc.dg/strub-pr118007.c
@@ -1,5 +1,5 @@
-/* { dg-require-effective-target strub } */
/* { dg-do compile } */
+/* { dg-require-effective-target strub } */
/* { dg-options "-fstrub=all -O2" } */
void rb_ec_error_print(struct rb_execution_context_struct *volatile) {}
/* { dg-warning "declared inside parameter list" } */
diff --git a/gcc/testsuite/gcc.dg/tanhbysinh.c
b/gcc/testsuite/gcc.dg/tanhbysinh.c
index 9dbe133ec749..74fdd52b2086 100644
--- a/gcc/testsuite/gcc.dg/tanhbysinh.c
+++ b/gcc/testsuite/gcc.dg/tanhbysinh.c
@@ -30,12 +30,12 @@ tanhbysinhl_ (long double x)
/* There must be no calls to sinh or atanh */
/* There must be calls to cosh */
-/* {dg-final { scan-tree-dump-not "sinh " "optimized" } } */
-/* {dg-final { scan-tree-dump-not "tanh " "optimized" }} */
-/* {dg-final { scan-tree-dump-not "sinhf " "optimized" } } */
-/* {dg-final { scan-tree-dump-not "tanhf " "optimized" }} */
-/* {dg-final { scan-tree-dump-not "sinhl " "optimized" } } */
-/* {dg-final { scan-tree-dump-not "tanhl " "optimi
[PATCH 08/12] testsuite, i386: fix broken dg directives
Found by dg-lint.
gcc/testsuite/ChangeLog:
* gcc.target/i386/addr-space-1.c: Add missing trailing }
to dg-do directive.
* gcc.target/i386/strub-pr118006.c: Fix ordering of dg-do and
dg-require- directive so that dg-do is first.
---
gcc/testsuite/gcc.target/i386/addr-space-1.c | 2 +-
gcc/testsuite/gcc.target/i386/strub-pr118006.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/i386/addr-space-1.c
b/gcc/testsuite/gcc.target/i386/addr-space-1.c
index 1e1314760e20..9a5ce9c5b0ed 100644
--- a/gcc/testsuite/gcc.target/i386/addr-space-1.c
+++ b/gcc/testsuite/gcc.target/i386/addr-space-1.c
@@ -1,4 +1,4 @@
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-final { scan-assembler "movl\[ \t\]%gs:\\((%eax|%rax)\\), %eax" } } */
diff --git a/gcc/testsuite/gcc.target/i386/strub-pr118006.c
b/gcc/testsuite/gcc.target/i386/strub-pr118006.c
index f1167906629c..88f66c153193 100644
--- a/gcc/testsuite/gcc.target/i386/strub-pr118006.c
+++ b/gcc/testsuite/gcc.target/i386/strub-pr118006.c
@@ -1,5 +1,5 @@
-/* { dg-require-effective-target strub } */
/* { dg-do compile } */
+/* { dg-require-effective-target strub } */
/* { dg-options "-fstrub=all -O2 -mno-accumulate-outgoing-args" } */
__attribute__((noipa))
--
2.26.3
[PATCH 03/12] testsuite, gomp: fix broken dg directives
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/metadirective-target-device-2.c: Fix missing
trailing " }" on dg-do directive.
* gcc.dg/gomp/attrs-21.c: Likewise for dg-options.
* gcc.dg/gomp/parallel-2.c: Drop ":" from dg-message.
---
gcc/testsuite/c-c++-common/gomp/metadirective-target-device-2.c | 2 +-
gcc/testsuite/gcc.dg/gomp/attrs-21.c| 2 +-
gcc/testsuite/gcc.dg/gomp/parallel-2.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/c-c++-common/gomp/metadirective-target-device-2.c
b/gcc/testsuite/c-c++-common/gomp/metadirective-target-device-2.c
index 24584f294387..4de192177f8d 100644
--- a/gcc/testsuite/c-c++-common/gomp/metadirective-target-device-2.c
+++ b/gcc/testsuite/c-c++-common/gomp/metadirective-target-device-2.c
@@ -1,4 +1,4 @@
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-additional-options "-fdump-tree-optimized" } */
/* In configurations without offloading configured, we can resolve many
diff --git a/gcc/testsuite/gcc.dg/gomp/attrs-21.c
b/gcc/testsuite/gcc.dg/gomp/attrs-21.c
index 551fe6c78503..e572f21a6e72 100644
--- a/gcc/testsuite/gcc.dg/gomp/attrs-21.c
+++ b/gcc/testsuite/gcc.dg/gomp/attrs-21.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-fopenmp -std=c23" */
+/* { dg-options "-fopenmp -std=c23" } */
void
foo ()
diff --git a/gcc/testsuite/gcc.dg/gomp/parallel-2.c
b/gcc/testsuite/gcc.dg/gomp/parallel-2.c
index b2d653db9e2a..38875ad94ed6 100644
--- a/gcc/testsuite/gcc.dg/gomp/parallel-2.c
+++ b/gcc/testsuite/gcc.dg/gomp/parallel-2.c
@@ -8,7 +8,7 @@ void foo()
{
#pragma omp parallel
{
- #pragma omp parallel default(none) // { dg-message: "note:
enclosing 'parallel'" }
+ #pragma omp parallel default(none) // { dg-message "note:
enclosing 'parallel'" }
{
i++; // { dg-error "not specified" }
}
--
2.26.3
[PATCH 00/12] Implement a new dg-lint tool and use on our testsuite
This patch kit: * adds minimal Python bindings for libgdiagnostics.so (below contrib) * implements a new dg-lint tool (below contrib) to detect for common mistakes in our testsuite, using Python 3 (and the above bindings) * fixes a bunch of issues reported by the tool I've only tested the testsuite fixes on x86_64-pc-linux-gnu; there were some new PASSes and no regressions, but I haven't tested the tests on non-x86 archs. Thoughts? David Malcolm (12): contrib: add dg-lint and libgdiagnostics.py [PR116163] testsuite: fix broken dg directives testsuite, gomp: fix broken dg directives testsuite, aarch64: fix broken dg directives testsuite, arc: fix broken dg directives testsuite, arm: fix broken dg directives testsuite, bfin: fix broken dg directive testsuite, i386: fix broken dg directives testsuite, ia64: fix broken dg directives testsuite, powerpc: fix broken dg directives testsuite, riscv: fix broken dg directives testsuite, s390: fix broken dg directives contrib/dg-lint/dg-lint | 210 +++ contrib/dg-lint/libgdiagnostics.py| 248 ++ contrib/dg-lint/test-1.c | 28 ++ contrib/dg-lint/test-2.c | 8 + .../gomp/metadirective-target-device-2.c | 2 +- gcc/testsuite/gcc.dg/gomp/attrs-21.c | 2 +- gcc/testsuite/gcc.dg/gomp/parallel-2.c| 2 +- gcc/testsuite/gcc.dg/ipa/pr110377.c | 2 +- gcc/testsuite/gcc.dg/plugin/infoleak-1.c | 2 +- gcc/testsuite/gcc.dg/pr101364-1.c | 2 +- gcc/testsuite/gcc.dg/pr113207.c | 2 +- .../gcc.dg/sarif-output/include-chain-2.c | 2 +- gcc/testsuite/gcc.dg/strub-pr118007.c | 2 +- gcc/testsuite/gcc.dg/tanhbysinh.c | 12 +- gcc/testsuite/gcc.dg/uninit-pred-3_c.c| 2 +- gcc/testsuite/gcc.dg/uninit-pred-3_d.c| 2 +- .../gcc.dg/variable-sized-type-flex-array.c | 4 +- .../gcc.target/aarch64/atomic-inst-ldlogic.c | 4 +- .../aarch64/saturating_arithmetic_1.c | 4 +- .../aarch64/saturating_arithmetic_2.c | 4 +- gcc/testsuite/gcc.target/arc/taux-1.c | 2 +- gcc/testsuite/gcc.target/arc/taux-2.c | 2 +- gcc/testsuite/gcc.target/arm/cmse/cmse-17.c | 2 +- gcc/testsuite/gcc.target/arm/short-vfp-1.c| 10 +- gcc/testsuite/gcc.target/bfin/l2.c| 2 +- gcc/testsuite/gcc.target/i386/addr-space-1.c | 2 +- .../gcc.target/i386/strub-pr118006.c | 2 +- .../gcc.target/ia64/mfused-madd-vect.c| 2 +- gcc/testsuite/gcc.target/ia64/mfused-madd.c | 2 +- .../gcc.target/ia64/mno-fused-madd.c | 2 +- gcc/testsuite/gcc.target/powerpc/pr70243.c| 2 +- gcc/testsuite/gcc.target/powerpc/pr91903.c| 2 +- gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c | 2 +- gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c | 2 +- .../gcc.target/riscv/prefetch-zicbop.c| 2 +- .../gcc.target/riscv/prefetch-zihintntl.c | 2 +- .../riscv/rvv/autovec/vls-vlmax/merge-4.c | 2 +- .../riscv/rvv/autovec/vls/merge-4.c | 2 +- .../s390/target-attribute/tattr-1.c | 2 +- .../s390/target-attribute/tattr-2.c | 2 +- 40 files changed, 543 insertions(+), 49 deletions(-) create mode 100755 contrib/dg-lint/dg-lint create mode 100644 contrib/dg-lint/libgdiagnostics.py create mode 100644 contrib/dg-lint/test-1.c create mode 100644 contrib/dg-lint/test-2.c -- 2.26.3
[PATCH 05/12] testsuite, arc: fix broken dg directives
Found by dg-lint.
gcc/testsuite/ChangeLog:
* gcc.target/arc/taux-1.c: Fix missing trailing '" }' from
dg-options.
* gcc.target/arc/taux-2.c: Likewise.
---
gcc/testsuite/gcc.target/arc/taux-1.c | 2 +-
gcc/testsuite/gcc.target/arc/taux-2.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arc/taux-1.c
b/gcc/testsuite/gcc.target/arc/taux-1.c
index a2b77782192c..41b0fc40ed5a 100644
--- a/gcc/testsuite/gcc.target/arc/taux-1.c
+++ b/gcc/testsuite/gcc.target/arc/taux-1.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O1 */
+/* { dg-options "-O1" } */
#define __aux() __attribute__((aux))
diff --git a/gcc/testsuite/gcc.target/arc/taux-2.c
b/gcc/testsuite/gcc.target/arc/taux-2.c
index 5644bcd65c19..3e57ac87ea06 100644
--- a/gcc/testsuite/gcc.target/arc/taux-2.c
+++ b/gcc/testsuite/gcc.target/arc/taux-2.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O1 */
+/* { dg-options "-O1" } */
#define __aux(r) __attribute__((aux(r)))
static volatile __aux(0x1000) int var;
--
2.26.3
[PATCH 09/12] testsuite, ia64: fix broken dg directives
Found by dg-lint.
gcc/testsuite/ChangeLog:
* gcc.target/ia64/mfused-madd-vect.c: Fix missing trailing " }" in
dg-do directive.
* gcc.target/ia64/mfused-madd.c: Likewise.
* gcc.target/ia64/mno-fused-madd.c: Likewise.
---
gcc/testsuite/gcc.target/ia64/mfused-madd-vect.c | 2 +-
gcc/testsuite/gcc.target/ia64/mfused-madd.c | 2 +-
gcc/testsuite/gcc.target/ia64/mno-fused-madd.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.target/ia64/mfused-madd-vect.c
b/gcc/testsuite/gcc.target/ia64/mfused-madd-vect.c
index 5bf6976caa0b..d1dc3c1cabbc 100644
--- a/gcc/testsuite/gcc.target/ia64/mfused-madd-vect.c
+++ b/gcc/testsuite/gcc.target/ia64/mfused-madd-vect.c
@@ -1,4 +1,4 @@
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-options "-O2 -ftree-vectorize" } */
/* { dg-final { scan-assembler-not "fpmpy" } } */
diff --git a/gcc/testsuite/gcc.target/ia64/mfused-madd.c
b/gcc/testsuite/gcc.target/ia64/mfused-madd.c
index 8ecb31f0dd3a..04fd95a6f092 100644
--- a/gcc/testsuite/gcc.target/ia64/mfused-madd.c
+++ b/gcc/testsuite/gcc.target/ia64/mfused-madd.c
@@ -1,4 +1,4 @@
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-final { scan-assembler-not "fmpy" } } */
/* { dg-final { scan-assembler-not "fadd" } } */
diff --git a/gcc/testsuite/gcc.target/ia64/mno-fused-madd.c
b/gcc/testsuite/gcc.target/ia64/mno-fused-madd.c
index 487519addf56..1f2922588763 100644
--- a/gcc/testsuite/gcc.target/ia64/mno-fused-madd.c
+++ b/gcc/testsuite/gcc.target/ia64/mno-fused-madd.c
@@ -1,4 +1,4 @@
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-options "-O2 -ffp-contract=off" } */
/* { dg-final { scan-assembler-not "fma" } } */
/* { dg-final { scan-assembler-not "fms" } } */
--
2.26.3
[PATCH 07/12] testsuite, bfin: fix broken dg directive
Found by dg-lint.
gcc/testsuite/ChangeLog:
* gcc.target/bfin/l2.c: Fix missing space before trailing "}"
in dg-bfin-processors directive.
---
gcc/testsuite/gcc.target/bfin/l2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/bfin/l2.c
b/gcc/testsuite/gcc.target/bfin/l2.c
index 56f64cc82b48..2d39c46f8f12 100644
--- a/gcc/testsuite/gcc.target/bfin/l2.c
+++ b/gcc/testsuite/gcc.target/bfin/l2.c
@@ -1,5 +1,5 @@
/* { dg-do run { target bfin-*-linux-uclibc } } */
-/* { dg-bfin-processors bf544 bf547 bf548 bf549 bf561} */
+/* { dg-bfin-processors bf544 bf547 bf548 bf549 bf561 } */
#if defined(__ADSPBF544__)
#define L2_START 0xFEB0
--
2.26.3
[PATCH 10/12] testsuite, powerpc: fix broken dg directives
Found by dg-lint.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr70243.c: Fix missing trailing " }" in
dg-do directive.
* gcc.target/powerpc/pr91903.c: Likewise.
---
gcc/testsuite/gcc.target/powerpc/pr70243.c | 2 +-
gcc/testsuite/gcc.target/powerpc/pr91903.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/pr70243.c
b/gcc/testsuite/gcc.target/powerpc/pr70243.c
index 11525186ef05..512c199e88b1 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr70243.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr70243.c
@@ -1,4 +1,4 @@
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-options "-O2 -mvsx" } */
/* { dg-require-effective-target powerpc_vsx } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr91903.c
b/gcc/testsuite/gcc.target/powerpc/pr91903.c
index d70a0c664693..b147d0e4dfe0 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr91903.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr91903.c
@@ -1,4 +1,4 @@
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-options "-mdejagnu-cpu=power8 -mvsx" } */
/* { dg-require-effective-target powerpc_vsx } */
--
2.26.3
[PATCH 12/12] testsuite, s390: fix broken dg directives
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.
---
gcc/testsuite/gcc.target/s390/target-attribute/tattr-1.c | 2 +-
gcc/testsuite/gcc.target/s390/target-attribute/tattr-2.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/s390/target-attribute/tattr-1.c
b/gcc/testsuite/gcc.target/s390/target-attribute/tattr-1.c
index ff573443d041..7344af3b7003 100644
--- a/gcc/testsuite/gcc.target/s390/target-attribute/tattr-1.c
+++ b/gcc/testsuite/gcc.target/s390/target-attribute/tattr-1.c
@@ -1,6 +1,6 @@
/* Functional tests for the "target" attribute and pragma. */
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-require-effective-target target_attribute } */
/* { dg-options "-O3 -march=zEC12 -mzarch" } */
diff --git a/gcc/testsuite/gcc.target/s390/target-attribute/tattr-2.c
b/gcc/testsuite/gcc.target/s390/target-attribute/tattr-2.c
index 739c2eabc837..3a6e4bbb6ae5 100644
--- a/gcc/testsuite/gcc.target/s390/target-attribute/tattr-2.c
+++ b/gcc/testsuite/gcc.target/s390/target-attribute/tattr-2.c
@@ -1,6 +1,6 @@
/* Functional tests for the "target" attribute and pragma. */
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-require-effective-target target_attribute } */
/* { dg-options "-O3 -march=zEC12 -mno-htm -fno-ipa-icf" } */
--
2.26.3
Re: [PATCH 2/2] Add prime path coverage to gcc/gcov
On 3/26/25 20:49, Jørgen Kvalsvik wrote: On 3/26/25 14:54, Jan Hubicka wrote: Hello, I apologize for late reply here. I went thru the paper in gereater detail. While I originally though the usual path-profiling can be reasonably merged with the prime math profiling, so it is useful both for optimizaiton and coverage testing, I think it is better to not do that - the requirements of prime path profiling are rather specific and expensive to get right. gcc/ChangeLog: * Makefile.in (OBJS): Add prime-paths.o, path-coverage.o. (GTFILES): Add prime-paths.cc, path-coverage.cc (GCOV_OBJS): Add graphds.o, prime-paths.o, bitmap.o * builtins.cc (expand_builtin_fork_or_exec): Check path_coverage_flag. * collect2.cc (main): Add -fno-path-coverage to OBSTACK. * common.opt: Add new options -fpath-coverage, -fpath-coverage-limit, -Wcoverage-too-many-paths * doc/gcov.texi: Add --prime-paths, --prime-paths-lines, --prime-paths-source documentation. * doc/invoke.texi: Add -fpath-coverage, -fpath-coverage-limit, -Wcoverage-too-many-paths documentation. * gcc.cc: Link gcov on -fpath-coverage. * gcov-counter.def (GCOV_COUNTER_PATHS): New. * gcov-io.h (GCOV_TAG_PATHS): New. (GCOV_TAG_PATHS_LENGTH): New. (GCOV_TAG_PATHS_NUM): New. * gcov.cc (class path_info): New. (struct coverage_info): Add paths, paths_covered. (find_prime_paths): New. (add_path_counts): New. (find_arc): New. (print_usage): Add -e, --prime-paths, --prime-paths-lines, --prime-paths-source. (process_args): Likewise. (json_set_prime_path_coverage): New. (output_json_intermediate_file): Call json_set_prime_path_coverage. (process_all_functions): Call find_prime_paths. (generate_results): Call add_path_counts. (read_graph_file): Read path counters. (read_count_file): Likewise. (function_summary): Print path counts. (file_summary): Likewise. (print_source_line): New. (print_prime_path_lines): New. (print_inlined_separator): New. (print_prime_path_source): New. (output_path_coverage): New. (output_lines): Print path coverage. * ipa-inline.cc (can_early_inline_edge_p): Check path_coverage_flag. * passes.cc (finish_optimization_passes): Likewise. * profile.cc (branch_prob): Likewise. * selftest-run-tests.cc (selftest::run_tests): Run path coverage tests. * selftest.h (path_coverage_cc_tests): New declaration. * tree-profile.cc (tree_profiling): Check path_coverage_flag. (pass_ipa_tree_profile::gate): Likewise. * path-coverage.cc: New file. * prime-paths.cc: New file. gcc/testsuite/ChangeLog: * lib/gcov.exp: Add prime paths test function. * g++.dg/gcov/gcov-22.C: New test. * g++.dg/gcov/gcov-23-1.h: New test. * g++.dg/gcov/gcov-23-2.h: New test. * g++.dg/gcov/gcov-23.C: New test. * gcc.misc-tests/gcov-29.c: New test. * gcc.misc-tests/gcov-30.c: New test. * gcc.misc-tests/gcov-31.c: New test. * gcc.misc-tests/gcov-32.c: New test. * gcc.misc-tests/gcov-33.c: New test. * gcc.misc-tests/gcov-34.c: New test. --- gcc/Makefile.in | 6 +- gcc/builtins.cc | 2 +- gcc/collect2.cc | 6 +- gcc/common.opt | 16 + gcc/doc/gcov.texi | 187 +++ gcc/doc/invoke.texi | 36 + gcc/gcc.cc | 4 +- gcc/gcov-counter.def | 3 + gcc/gcov-io.h | 3 + gcc/gcov.cc | 487 +- gcc/ipa-inline.cc | 2 +- gcc/passes.cc | 4 +- gcc/path-coverage.cc | 776 + gcc/prime-paths.cc | 2052 gcc/profile.cc | 6 +- gcc/selftest-run-tests.cc | 1 + gcc/selftest.h | 1 + gcc/testsuite/g++.dg/gcov/gcov-22.C | 170 ++ gcc/testsuite/g++.dg/gcov/gcov-23-1.h | 9 + gcc/testsuite/g++.dg/gcov/gcov-23-2.h | 9 + gcc/testsuite/g++.dg/gcov/gcov-23.C | 30 + gcc/testsuite/gcc.misc-tests/gcov-29.c | 869 ++ gcc/testsuite/gcc.misc-tests/gcov-30.c | 869 ++ gcc/testsuite/gcc.misc-tests/gcov-31.c | 35 + gcc/testsuite/gcc.misc-tests/gcov-32.c | 24 + gcc/testsuite/gcc.misc-tests/gcov-33.c | 27 + gcc/testsuite/gcc.misc-tests/gcov-34.c | 29 + gcc/testsuite/lib/gcov.exp | 118 +- gcc/tree-profile.cc | 11 +- 29 files changed, 5775 insertions(+), 17 deletions(-) create mode 100644 gcc/path-coverage.cc create mode 100644 gcc/prime-paths.cc create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-22.C create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-23-1.h create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-23-2.h create mode 10064
[PATCH 04/12] testsuite, aarch64: fix broken dg directives
Found by dg-lint.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/atomic-inst-ldlogic.c: Add missing trailing
" }" for 2 dg-final directives.
* gcc.target/aarch64/saturating_arithmetic_1.c: Fix dg-do compile.
* gcc.target/aarch64/saturating_arithmetic_2.c: Likewise.
---
gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c | 4 ++--
gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_1.c | 4 ++--
gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_2.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c
b/gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c
index 4879d52b9b4f..ef79396151c6 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c
@@ -128,7 +128,7 @@ TEST (xor_load_notreturn, XOR_LOAD_NORETURN)
/* { dg-final { scan-assembler-times "ldclrlh\t" 8} } */
/* { dg-final { scan-assembler-times "ldclralh\t" 16} } */
-/* { dg-final { scan-assembler-times "ldclr\t" 16} */
+/* { dg-final { scan-assembler-times "ldclr\t" 16} } */
/* { dg-final { scan-assembler-times "ldclra\t" 32} } */
/* { dg-final { scan-assembler-times "ldclrl\t" 16} } */
/* { dg-final { scan-assembler-times "ldclral\t" 32} } */
@@ -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} } */
diff --git a/gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_1.c
b/gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_1.c
index 2ac0c376d126..acd2e11f41d3 100644
--- a/gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_1.c
@@ -1,4 +1,4 @@
-/* { dg-do-compile } */
+/* { dg-do compile } */
/* { dg-options "-O2 --save-temps -fno-schedule-insns2" } */
/* { dg-final { check-function-bodies "**" "" "" } } */
@@ -33,4 +33,4 @@
#define UMAX UCHAR_MAX
#define UMIN 0
-#include "saturating_arithmetic.inc"
\ No newline at end of file
+#include "saturating_arithmetic.inc"
diff --git a/gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_2.c
b/gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_2.c
index 2a55aa9f2218..86c88f8447c3 100644
--- a/gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_2.c
+++ b/gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_2.c
@@ -1,4 +1,4 @@
-/* { dg-do-compile } */
+/* { dg-do compile } */
/* { dg-options "-O2 --save-temps -fno-schedule-insns2" } */
/* { dg-final { check-function-bodies "**" "" "" } } */
@@ -33,4 +33,4 @@
#define UMAX USHRT_MAX
#define UMIN 0
-#include "saturating_arithmetic.inc"
\ No newline at end of file
+#include "saturating_arithmetic.inc"
--
2.26.3
[PATCH 5/6] testsuite: fix more dg-* whitespace issues
A handful of cosmetic ones in here but most meant the directive wasn't
doing anything.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/udlit-namespace-ambiguous.C: Fix whitespace.
* g++.dg/cpp2a/constexpr-init21.C: Ditto.
* g++.dg/diagnostic/wrong-tag-1.C: Ditto.
* g++.dg/init/self1.C: Ditto.
* g++.dg/opt/pr98743.C: Add missing '}' to terminate dg directive.
* g++.dg/parse/error8.C: Fix whitespace.
* g++.dg/template/explicit-args6.C: Add missing '{' to begin dg
directive.
* g++.dg/template/unify9.C: Fix whitespace.
* g++.dg/tree-ssa/pr105820.C: Ditto.
* g++.dg/warn/Wmismatched-tags-8.C: Add missing braces.
* gcc.dg/cpp/cmdlne-dM-M.c: Ditto.
* gcc.dg/tree-ssa/reassoc-32.c: Ditto.
* gcc.dg/tree-ssa/reassoc-33.c: Ditto.
* gcc.dg/tree-ssa/reassoc-34.c: Ditto.
* gcc.dg/tree-ssa/reassoc-35.c: Ditto.
* gcc.dg/tree-ssa/reassoc-36.c: Ditto.
* gcc.dg/tree-ssa/reassoc-39.c: Ditto.
* gcc.dg/tree-ssa/reassoc-41.c: Ditto.
---
gcc/testsuite/g++.dg/cpp0x/udlit-namespace-ambiguous.C | 4 ++--
gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C | 2 +-
gcc/testsuite/g++.dg/diagnostic/wrong-tag-1.C | 2 +-
gcc/testsuite/g++.dg/init/self1.C | 2 +-
gcc/testsuite/g++.dg/opt/pr98743.C | 2 +-
gcc/testsuite/g++.dg/parse/error8.C| 2 +-
gcc/testsuite/g++.dg/template/explicit-args6.C | 2 +-
gcc/testsuite/g++.dg/template/unify9.C | 2 +-
gcc/testsuite/g++.dg/tree-ssa/pr105820.C | 2 +-
gcc/testsuite/g++.dg/warn/Wmismatched-tags-8.C | 6 +++---
gcc/testsuite/gcc.dg/cpp/cmdlne-dM-M.c | 2 +-
gcc/testsuite/gcc.dg/tree-ssa/reassoc-32.c | 2 +-
gcc/testsuite/gcc.dg/tree-ssa/reassoc-33.c | 2 +-
gcc/testsuite/gcc.dg/tree-ssa/reassoc-34.c | 2 +-
gcc/testsuite/gcc.dg/tree-ssa/reassoc-35.c | 2 +-
gcc/testsuite/gcc.dg/tree-ssa/reassoc-36.c | 2 +-
gcc/testsuite/gcc.dg/tree-ssa/reassoc-39.c | 2 +-
gcc/testsuite/gcc.dg/tree-ssa/reassoc-41.c | 2 +-
18 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/gcc/testsuite/g++.dg/cpp0x/udlit-namespace-ambiguous.C
b/gcc/testsuite/g++.dg/cpp0x/udlit-namespace-ambiguous.C
index c67be390f8b8..1ba4c8d74c79 100644
--- a/gcc/testsuite/g++.dg/cpp0x/udlit-namespace-ambiguous.C
+++ b/gcc/testsuite/g++.dg/cpp0x/udlit-namespace-ambiguous.C
@@ -1,9 +1,9 @@
// { dg-do compile { target c++11 } }
-int operator""_t (long long unsigned); // { dg-message "note: candidate"}
+int operator""_t (long long unsigned); // { dg-message "note: candidate" }
namespace foo {
- int operator""_t (long long unsigned); // { dg-message "note: candidate"}
+ int operator""_t (long long unsigned); // { dg-message "note: candidate" }
}
using namespace foo;
diff --git a/gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C
b/gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C
index f5e1b3e76da4..1014292c1f87 100644
--- a/gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C
+++ b/gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C
@@ -20,7 +20,7 @@ constexpr A a4(4); // { dg-error "not a constant
expression|incompletely in
struct s { int n; };
constexpr A b;
-constexpr A b0(0); // { dg-error "not a constant expression|incompletely
initialized" }
+constexpr A b0(0); // { dg-error "not a constant expression|incompletely
initialized" }
struct empty {};
constexpr A c;
diff --git a/gcc/testsuite/g++.dg/diagnostic/wrong-tag-1.C
b/gcc/testsuite/g++.dg/diagnostic/wrong-tag-1.C
index 2cf75f8bd7a4..05ad326a4547 100644
--- a/gcc/testsuite/g++.dg/diagnostic/wrong-tag-1.C
+++ b/gcc/testsuite/g++.dg/diagnostic/wrong-tag-1.C
@@ -1,4 +1,4 @@
// Origin PR c++/51427
-typedef struct _GMutex GMutex; // { dg-message "previously declared here"}
+typedef struct _GMutex GMutex; // { dg-message "previously declared here" }
typedef union _GMutex GMutex; // { dg-error "tag used in naming" }
diff --git a/gcc/testsuite/g++.dg/init/self1.C
b/gcc/testsuite/g++.dg/init/self1.C
index 2fc5aa65ec8e..f9e995144517 100644
--- a/gcc/testsuite/g++.dg/init/self1.C
+++ b/gcc/testsuite/g++.dg/init/self1.C
@@ -9,7 +9,7 @@ void f(__SIZE_TYPE__) {
int main()
{
- int* const savepos = sizeof(*savepos) ? 0 : 0; /* { dg-error "invalid
conversion" "convert" { target c++11 } } */
+ int* const savepos = sizeof(*savepos) ? 0 : 0; /* { dg-error "invalid
conversion" "convert" { target c++11 } } */
f (sizeof (*savepos));
diff --git a/gcc/testsuite/g++.dg/opt/pr98743.C
b/gcc/testsuite/g++.dg/opt/pr98743.C
index 41f476fbe8e9..9380ff26fc82 100644
--- a/gcc/testsuite/g++.dg/opt/pr98743.C
+++ b/gcc/testsuite/g++.dg/opt/pr98743.C
@@ -1,6 +1,6 @@
// Test for value-initialization via {}
// { dg-do run { target c++11 } }
-/* { dg-options "-Og -fno-early-inlining -finline-small-functions
-fpack-struct" */
+/* {
ping: [PATCH] c-family: Improve location for -Wunknown-pragmas in a _Pragma [PR118838]
Hello-
May I please ping this patch? Thanks!
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675645.html
-Lewis
On Wed, Feb 12, 2025 at 8:27 PM Lewis Hyatt wrote:
>
> Hello-
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118838
>
> This patch addresses the issue mentioned in the PR (another instance of
> _Pragma string location issues). bootstrap + regtest all languages on
> aarch64 looks good. Is it OK please for now or for stage 1? Note, it is not
> a regression, since this never worked in C or C++ frontends; but on the
> other hand, r15-4505 for GCC 15 fixed some related issues, so it could be
> nice if this one gets in along with it. Thanks!
>
> -Lewis
>
> -- >8 --
>
> The warning for -Wunknown-pragmas is issued at the location provided by
> libcpp to the def_pragma() callback. This location is
> cpp_reader::directive_line, which is a location for the start of the line
> only; it is also not a valid location in case the unknown pragma was lexed
> from a _Pragma string. These factors make it impossible to suppress
> -Wunknown-pragmas via _Pragma("GCC diagnostic...") directives on the same
> source line, as in the PR and the test case. Address that by issuing the
> warning at a better location returned by cpp_get_diagnostic_override_loc().
> libcpp already maintains this location to handle _Pragma-related diagnostics
> internally; it was needed also to make a publicly accessible version of it.
>
> gcc/c-family/ChangeLog:
>
> PR c/118838
> * c-lex.cc (cb_def_pragma): Call cpp_get_diagnostic_override_loc()
> to get a valid location at which to issue -Wunknown-pragmas, in case
> it was triggered from a _Pragma.
>
> libcpp/ChangeLog:
>
> PR c/118838
> * errors.cc (cpp_get_diagnostic_override_loc): New function.
> * include/cpplib.h (cpp_get_diagnostic_override_loc): Declare.
>
> gcc/testsuite/ChangeLog:
>
> PR c/118838
> * c-c++-common/cpp/pragma-diagnostic-loc-2.c: New test.
> * g++.dg/gomp/macro-4.C: Adjust expected output.
> * gcc.dg/gomp/macro-4.c: Likewise.
> * gcc.dg/cpp/Wunknown-pragmas-1.c: Likewise.
> ---
> libcpp/errors.cc | 10 +
> libcpp/include/cpplib.h | 5 +
> gcc/c-family/c-lex.cc | 7 +-
> .../cpp/pragma-diagnostic-loc-2.c | 15 +
> gcc/testsuite/g++.dg/gomp/macro-4.C | 8 +++
> gcc/testsuite/gcc.dg/cpp/Wunknown-pragmas-1.c | 22 +++
> gcc/testsuite/gcc.dg/gomp/macro-4.c | 8 +++
> 7 files changed, 57 insertions(+), 18 deletions(-)
> create mode 100644 gcc/testsuite/c-c++-common/cpp/pragma-diagnostic-loc-2.c
>
> diff --git a/libcpp/errors.cc b/libcpp/errors.cc
> index 9621c4b66ea..d9efb6acd30 100644
> --- a/libcpp/errors.cc
> +++ b/libcpp/errors.cc
> @@ -52,6 +52,16 @@ cpp_diagnostic_get_current_location (cpp_reader *pfile)
> }
> }
>
> +/* Sometimes a diagnostic needs to be generated before libcpp has been able
> + to generate a valid location for the current token; in that case, the
> + non-zero location returned by this function is the preferred one to use.
> */
> +
> +location_t
> +cpp_get_diagnostic_override_loc (const cpp_reader *pfile)
> +{
> + return pfile->diagnostic_override_loc;
> +}
> +
> /* Print a diagnostic at the given location. */
>
> ATTRIBUTE_CPP_PPDIAG (5, 0)
> diff --git a/libcpp/include/cpplib.h b/libcpp/include/cpplib.h
> index 90aa3160ebf..04d4621da3c 100644
> --- a/libcpp/include/cpplib.h
> +++ b/libcpp/include/cpplib.h
> @@ -1168,6 +1168,11 @@ extern const char *cpp_probe_header_unit (cpp_reader
> *, const char *file,
> extern const char *cpp_get_narrow_charset_name (cpp_reader *) ATTRIBUTE_PURE;
> extern const char *cpp_get_wide_charset_name (cpp_reader *) ATTRIBUTE_PURE;
>
> +/* Sometimes a diagnostic needs to be generated before libcpp has been able
> + to generate a valid location for the current token; in that case, the
> + non-zero location returned by this function is the preferred one to use.
> */
> +extern location_t cpp_get_diagnostic_override_loc (const cpp_reader *);
> +
> /* This function reads the file, but does not start preprocessing. It
> returns the name of the original file; this is the same as the
> input file, except for preprocessed input. This will generate at
> diff --git a/gcc/c-family/c-lex.cc b/gcc/c-family/c-lex.cc
> index e450c9a57f0..df84020de62 100644
> --- a/gcc/c-family/c-lex.cc
> +++ b/gcc/c-family/c-lex.cc
> @@ -248,7 +248,12 @@ cb_def_pragma (cpp_reader *pfile, location_t loc)
> {
>const unsigned char *space, *name;
>const cpp_token *s;
> - location_t fe_loc = loc;
> +
> + /* If we are processing a _Pragma, LOC is not a valid location, but
> libcpp
> +will provide a good location via this function instead. */
> + location_t fe_loc = cpp_get_diagnostic_override_loc (pfile);
> +
Re: [PATCH, V3] PR target/118541 - Do not generate unordered fp cmoves for IEEE compares on PowerPC
On Mon, Mar 24, 2025 at 09:15:26PM +0100, Florian Weimer wrote:
> * Michael Meissner:
>
> > +enum reverse_cond_t {
> > + REVERSE_COND_ORDERED_OK,
> > + REVERSE_COND_NO_ORDERED
> > +};
>
> This should probably be something
> like
>
> enum reverse_cond_t {
> ordered_ok,
> no_ordered,
> };
>
> to inhibit implicit conversion to integer types and bool.
Thanks. At heart I am still a C programmer, so I missed this. I wrote version
4 of the patch that hopefully codes this correctly.
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679428.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Re: [PATCH 01/12] contrib: add dg-lint and libgdiagnostics.py [PR116163]
Sam James writes: > David Malcolm writes: > >> This patch adds a new dg-lint subdirectory below contrib, containing >> a "dg-lint" script for detecting common mistakes made in our DejaGnu >> tests. >> I should say: I don't think any of my comments are blockers at all, they're really just further enhancements we could and should do, and I'm happy to help refine it as I notice things too once it is in. Plus, once we have a linter, things can't regress so easily and I can focus on looking for more interesting errors (which we can then lint).
Re: [PATCH] Fortran: fix bogus recursion with DT default initialization [PR118796]
Hi Andre, Am 26.03.25 um 22:49 schrieb Andre Vehreschild: Hi Harald, looks good to me. Thanks for the patch. pushed as r15-8945-gb70bd691cfd77b. Thanks for the swift review! Harald - Andre Andre Vehreschild * ve...@gmx.de Am 26. März 2025 22:18:41 schrieb Harald Anlauf : Dear all, it seems that my patch for default-initialization of function results of derived type could trigger a weird issue if a type-bound function of a type that is use-associated from a different module had the same name, even if the declared function had a different type, but only if the result clause is present. While I had hoped that resolution should not lead to this situation, checking whether the function was use-associated solved the issue. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald
[PATCH] cobol, v2: Get rid of __int128 uses in the COBOL FE [PR119242]
On Tue, Mar 25, 2025 at 11:36:10PM -0500, Robert Dubner wrote:
> I took a minute to apply the patch and run the tests. Ten of the UAT
> tests fail; they are the ones that test the ROUNDED clause.
>
> It's 00:30 local time here, so I am not going to look into it now. But
> here is a simple case so that you have something to chew on while I am
> getting my beauty sleep:
>
>IDENTIFICATION DIVISION.
>PROGRAM-ID. prog.
>DATA DIVISION.
>WORKING-STORAGE SECTION.
>01 NPIC S9.
>PROCEDURE DIVISION.
>COMPUTE N ROUNDED MODE AWAY-FROM-ZERO = -2.51
>DISPLAY "N should be -3"
>DISPLAY "Nis " N
>GOBACK.
>END PROGRAM prog.
>
> N should be -3
> Nis +1
Sorry, got the conversion wrong in 2 spots.
For signable the old code did
if( value < 0 && (((pvalue[capacity-1] & 0x80) == 0 )))
{
capacity *= 2;
}
else if( value >= 0 && (((pvalue[capacity-1] & 0x80) == 0x80 )))
{
capacity *= 2;
}
value < 0 has been correctly replaced with wi::neg_p (value)
and (pvalue[capacity-1] & 0x80) with
(value & wi::set_bit_in_zero(capacity * 8 - 1))
(both are testing the same bit), but I got the two comparisons exactly
the other way, for negative values it was testing if that bit is set
(while previously it was testing if it was clear) and vice versa.
Here is a fixed patch, passes make check-cobol, but that is unfortunately
still not enough.
2025-03-26 Jakub Jelinek
PR cobol/119242
* cobol/genutil.h (get_power_of_ten): Remove #pragma GCC diagnostic
around declaration.
* cobol/genapi.cc (psa_FldLiteralN): Change type of value from
__int128 to FIXED_WIDE_INT(128). Remove #pragma GCC diagnostic
around the declaration. Use wi::min_precision to determine
minimum unsigned precision of the value. Use wi::neg_p instead
of value < 0 tests and wi::set_bit_in_zero
to build sign bit. Handle field->data.capacity == 16 like
1, 2, 4 and 8, use wide_int_to_tree instead of build_int_cst.
(mh_source_is_literalN): Remove #pragma GCC diagnostic around
the definition.
(binary_initial_from_float128): Likewise.
* cobol/genutil.cc (get_power_of_ten): Remove #pragma GCC diagnostic
before the definition.
--- gcc/cobol/genutil.h.jj 2025-03-25 21:14:48.448384925 +0100
+++ gcc/cobol/genutil.h 2025-03-25 21:19:24.358620134 +0100
@@ -104,10 +104,7 @@ void get_binary_value( tree value,
tree get_data_address( cbl_field_t *field,
tree offset);
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wpedantic"
FIXED_WIDE_INT(128) get_power_of_ten(int n);
-#pragma GCC diagnostic pop
void scale_by_power_of_ten_N(tree value,
int N,
bool check_for_fractional = false);
--- gcc/cobol/genapi.cc.jj 2025-03-25 21:11:06.767409766 +0100
+++ gcc/cobol/genapi.cc 2025-03-26 13:16:23.932827326 +0100
@@ -3798,16 +3798,13 @@ psa_FldLiteralN(struct cbl_field_t *fiel
// We are constructing a completely static constant structure, based on the
// text string in .initial
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wpedantic"
- __int128 value = 0;
-#pragma GCC diagnostic pop
+ FIXED_WIDE_INT(128) value = 0;
do
{
// This is a false do{}while, to isolate the variables:
-// We need to convert data.initial to an __int128 value
+// We need to convert data.initial to an FIXED_WIDE_INT(128) value
char *p = const_cast(field->data.initial);
int sign = 1;
if( *p == '-' )
@@ -3903,24 +3900,24 @@ psa_FldLiteralN(struct cbl_field_t *fiel
// We now need to calculate the capacity.
-unsigned char *pvalue = (unsigned char *)&value;
+unsigned int min_prec = wi::min_precision(value, UNSIGNED);
int capacity;
-if( *(uint64_t*)(pvalue + 8) )
+if( min_prec > 64 )
{
// Bytes 15 through 8 are non-zero
capacity = 16;
}
-else if( *(uint32_t*)(pvalue + 4) )
+else if( min_prec > 32 )
{
// Bytes 7 through 4 are non-zero
capacity = 8;
}
-else if( *(uint16_t*)(pvalue + 2) )
+else if( min_prec > 16 )
{
// Bytes 3 and 2
capacity = 4;
}
-else if( pvalue[1] )
+else if( min_prec > 8 )
{
// Byte 1 is non-zero
capacity = 2;
@@ -3940,11 +3937,13 @@ psa_FldLiteralN(struct cbl_field_t *fiel
if( capacity < 16 && (field->attr & signable_e) )
{
- if( value < 0 && (((pvalue[capacity-1] & 0x80) == 0 )))
+ FIXED_WIDE_INT(128) mask
+= wi::set_bit_in_zero(capacity * 8 - 1);
+ if( wi::neg_p (value) && (value & mask) == 0 )
{
capacity *= 2;
}
- else if( value >= 0 && (((pvalue[capacity-
[PATCH, V4] PR target/118541 - Do not generate unordered fp cmoves for IEEE compares on PowerPC
This is version 4 of the patch for PR target/118541.
In version 4, I made the following changes:
1: I changed the use of enums to match current C++. Thanks to Florian
Weimer.
In version 3, I made the following changes:
1: The new argument to rs6000_reverse_condition that says whether we should
allow ordered floating point compares to be reversed is now an
enumeration instead of a boolean.
2: I tried to make the code in rs6000_reverse_condition clearer.
3: I added checks in invert_fpmask_comparison_operator to prevent ordered
floating point compares from being reversed unless -ffast-math.
4: I split the test cases into 4 separate tests (ordered vs. unordered
compare and -O2 vs. -Ofast).
In bug PR target/118541 on power9, power10, and power11 systems, for the
function:
extern double __ieee754_acos (double);
double
__acospi (double x)
{
double ret = __ieee754_acos (x) / 3.14;
return __builtin_isgreater (ret, 1.0) ? 1.0 : ret;
}
GCC currently generates the following code:
Power9 Power10 and Power11
== ===
bl __ieee754_acos bl __ieee754_acos@notoc
nop plfd 0,.LC0@pcrel
addis 9,2,.LC2@toc@ha xxspltidp 12,1065353216
addi 1,1,32 addi 1,1,32
lfd 0,.LC2@toc@l(9) ld 0,16(1)
addis 9,2,.LC0@toc@ha fdiv 0,1,0
ld 0,16(1) mtlr 0
lfd 12,.LC0@toc@l(9)xscmpgtdp 1,0,12
fdiv 0,1,0 xxsel 1,0,12,1
mtlr 0 blr
xscmpgtdp 1,0,12
xxsel 1,0,12,1
blr
This is because ifcvt.c optimizes the conditional floating point move to use the
XSCMPGTDP instruction.
However, the XSCMPGTDP instruction will generate an interrupt if one of the
arguments is a signalling NaN and signalling NaNs can generate an interrupt.
The IEEE comparison functions (isgreater, etc.) require that the comparison not
raise an interrupt.
The following patch changes the PowerPC back end so that ifcvt.c will not change
the if/then test and move into a conditional move if the comparison is one of
the comparisons that do not raise an error with signalling NaNs and -Ofast is
not used. If a normal comparison is used or -Ofast is used, GCC will continue
to generate XSCMPGTDP and XXSEL.
For the following code:
double
ordered_compare (double a, double b, double c, double d)
{
return __builtin_isgreater (a, b) ? c : d;
}
/* Verify normal > does generate xscmpgtdp. */
double
normal_compare (double a, double b, double c, double d)
{
return a > b ? c : d;
}
with the following patch, GCC generates the following for power9, power10, and
power11:
ordered_compare:
fcmpu 0,1,2
fmr 1,4
bnglr 0
fmr 1,3
blr
normal_compare:
xscmpgtdp 1,1,2
xxsel 1,4,3,1
blr
I have built bootstrap compilers on big endian power9 systems and little endian
power9/power10 systems and there were no regressions. Can I check this patch
into the GCC trunk, and after a waiting period, can I check this into the active
older branches?
2025-03-26 Michael Meissner
gcc/
PR target/118541
* config/rs6000/predicates.md (invert_fpmask_comparison_operator): Do
not allow UNLT and UNLE unless -ffast-math.
* config/rs6000/rs6000-protos.h (enum rev_cond_ordered): New
enumeration.
(rs6000_reverse_condition): Add argument.
* config/rs6000/rs6000.cc (rs6000_reverse_condition): Do not allow
ordered comparisons to be reversed for floating point conditional moves,
but allow ordered comparisons to be reversed on jumps.
(rs6000_emit_sCOND): Adjust rs6000_reverse_condition call.
* config/rs6000/rs6000.h (REVERSE_CONDITION): Likewise.
* config/rs6000/rs6000.md (reverse_branch_comparison): Name insn.
Adjust rs6000_reverse_condition calls.
gcc/testsuite/
PR target/118541
* gcc.target/powerpc/pr118541-1.c: New test.
* gcc.target/powerpc/pr118541-2.c: Likewise.
* gcc.target/powerpc/pr118541-3.c: Likewise.
* gcc.target/powerpc/pr118541-4.c: Likewise.
---
gcc/config/rs6000/predicates.md | 10 +++-
gcc/config/rs6000/rs6000-protos.h | 17 ++-
gcc/config/rs6000/rs6000.cc | 46 ++-
gcc/config/rs6000/rs6000.h| 10 +++-
gcc/config/rs6000/rs6000.md | 25 ++
gcc/testsuite/gcc.target/powerpc/pr118541-1.c | 28 +++
gcc/testsuite/gcc.target/powerpc/pr118541-2.c | 26 +++
[COMMITTED, OBVIOUS] OpenMP: Fix declaration in append-args-interop.c test case
I ran into this while backporting my declare variant/dispatch/interop
patch f016ee89955ab4da5fe7ef89368e9437bb5ffb13 to the og14 development
branch. In C dialects prior to C23 (the default on mainline),
functions declared "float f()" and "float g(void)" aren't considered
equivalent for the purpose of the C front end code that checks whether
a type of a variant matches the base function after accounting for the
added interop arguments. Using "(void)" instead of "()" works in all
C dialects as well as C++, so do that.
gcc/testsuite/ChangeLog
* c-c++-common/gomp/append-args-interop.c: Fix declaration of base
function to be correct for pre-C23 dialects.
---
gcc/testsuite/c-c++-common/gomp/append-args-interop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/c-c++-common/gomp/append-args-interop.c
b/gcc/testsuite/c-c++-common/gomp/append-args-interop.c
index 9494625cbbb..1211450ce63 100644
--- a/gcc/testsuite/c-c++-common/gomp/append-args-interop.c
+++ b/gcc/testsuite/c-c++-common/gomp/append-args-interop.c
@@ -23,7 +23,7 @@ typedef enum omp_interop_t __GOMP_UINTPTR_T_ENUM
float repl1(omp_interop_t, omp_interop_t, omp_interop_t);
#pragma omp declare variant(repl1) match(construct={dispatch})
append_args(interop(target), interop(targetsync), interop (target))
-float base1();
+float base1(void);
float
test (int *a, int *b)
--
2.34.1
[committed] cobol: Bring trunk into line with Dubner's test system.
Jim discovered a couple of tests that succeed on my system didn't succeed
on his. That led to the discovery that some stuff in my test environment
hadn't actually found its way in to trunk.
This fixes that.
>From 0747d51de55ae29430cb3ae6371210076d7b7c0d Mon Sep 17 00:00:00 2001
From: Robert Dubner mailto:rdub...@symas.com
Date: Wed, 26 Mar 2025 16:07:44 -0400
Subject: [PATCH] cobol: Bring trunk into line with Dubner's test system.
gcc/cobol
* genapi.cc: (parser_display_internal): Adjust for E vs e exponent
notation.
* parse.y: (literal_refmod_valid): Display correct value in error
message.
---
gcc/cobol/genapi.cc | 24 ++--
gcc/cobol/parse.y | 4 ++--
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
index 8a58423264e4..301ae9fffe0f 100644
--- a/gcc/cobol/genapi.cc
+++ b/gcc/cobol/genapi.cc
@@ -4890,14 +4890,34 @@ parser_display_internal(tree file_descriptor,
if( !p )
{
// Probably INF -INF NAN or -NAN, so ach has our result
+ // Except that real_to_decimal prints -0.0 and 0.0 like that with
+ // no e.
+ if( ach[0] == '0' || ( ach[0] == '-' && ach[1] == '0' ))
+__gg__remove_trailing_zeroes(ach);
}
else
{
- p += 1;
- int exp = atoi(p);
+ int exp = atoi(p+1);
if( exp >= 6 || exp <= -5 )
{
// We are going to stick with the E notation, so ach has our
result
+// Except that real_to_decimal prints with e notation rather than
E
+// and doesn't guarantee at least two exponent digits.
+*p = 'E';
+if( exp < 0 && exp >= -9 )
+ {
+p[1] = '-';
+p[2] = '0';
+p[3] = '0' - exp;
+p[4] = '\0';
+ }
+else if( exp >= 0 && exp <= 9 )
+ {
+p[1] = '+';
+p[2] = '0';
+p[3] = '0' + exp;
+p[4] = '\0';
+ }
}
else if (exp == 0)
{
diff --git a/gcc/cobol/parse.y b/gcc/cobol/parse.y
index bad99528e599..538e56fa64d1 100644
--- a/gcc/cobol/parse.y
+++ b/gcc/cobol/parse.y
@@ -12856,14 +12856,14 @@ literal_refmod_valid( YYLTYPE loc, const
cbl_refer_t& r ) {
if( ! is_literal(refmod.len->field) ) return true;
auto edge = refmod.len->field->as_integer();
if( 0 < edge ) {
- if( --edge < r.field->data.capacity ) return true;
+ if( edge-1 < r.field->data.capacity ) return true;
}
// len < 0 or not: 0 < from + len <= capacity
error_msg(loc, "%s(%s:%zu) out of bounds, "
"size is %u",
r.field->name,
refmod.from->name(),
- size_t(refmod.len->field->data.value_of()),
+ size_t(edge),
static_cast(r.field->data.capacity) );
return false;
}
--
2.34.1
Re: [PATCH] libstdc++: Use const_cast to workaround tm_zone being non-const
> On 26 Mar 2025, at 17:50, Jonathan Wakely wrote:
>
> Iain reported that he's seeing this on Darwin:
>
> include/bits/chrono_io.h:914: warning: ISO C++ forbids converting a string
> constant to 'char*' [-Wwrite-strings]
>
> This is because the BSD definition ot tm::tm_zone is a char* (and has
> been since 1987) rather than const char* as in Glibc and POSIX.1-2024.
>
> This uses const_cast when setting the tm_zone member. This should
> be safe because libc doesn't actually write anything to tm_zone, it's
> only non-const because the BSD definition predates the addition of the
> const keyword to C.
>
> For targets where it's a const char* the cast won't matter because it
> will be converted back to const char* on assignment anyway.
This resolves the issue on x86_64-darwin21, (I did not test more widely yet, but
it LGTM), thanks
Iain
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/chrono_io.h (__formatter_chrono::_M_c): Use
> const_cast when setting tm.tm_zone.
> ---
>
> Testing x86_64-linux.
>
> libstdc++-v3/include/bits/chrono_io.h | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libstdc++-v3/include/bits/chrono_io.h
> b/libstdc++-v3/include/bits/chrono_io.h
> index 08969166d2f..c55b651d049 100644
> --- a/libstdc++-v3/include/bits/chrono_io.h
> +++ b/libstdc++-v3/include/bits/chrono_io.h
> @@ -907,21 +907,22 @@ namespace __format
>
> #ifdef _GLIBCXX_HAVE_STRUCT_TM_TM_ZONE
> // POSIX.1-2024 adds tm.tm_zone which will be used for %Z.
> + // BSD has had tm_zone since 1987 but as char* so cast away const.
> if constexpr (__is_time_point_v<_Tp>)
> {
> // One of sys_time, utc_time, or local_time.
> if constexpr (!is_same_v)
> - __tm.tm_zone = "UTC";
> + __tm.tm_zone = const_cast("UTC");
> }
> else if constexpr (__is_specialization_of<_Tp, __local_time_fmt>)
> {
> // local-time-format-t is used to provide time zone info for
> // one of zoned_time, tai_time, gps_time, or local_time.
> if (__t._M_abbrev)
> - __tm.tm_zone = __t._M_abbrev->c_str();
> + __tm.tm_zone = const_cast(__t._M_abbrev->c_str());
> }
> else
> - __tm.tm_zone = "UTC";
> + __tm.tm_zone = const_cast("UTC");
> #endif
>
> auto __d = _S_days(__t); // Either sys_days or local_days.
> --
> 2.49.0
>
[PATCH] tailcall: Improve debug dumps
While trying to reduce musttail failures, I noticed
that it was hard to figure out if `Cannot convert` message
was on a musttail call or just a normal call. This adds
extra messages to the dump debug to signify it was a musttail
call and if we are going to remove the musttail from it too.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-tailcall.cc (maybe_error_musttail): Move the print
to the dump file to begining of the function. Also expand dump
to include more information.
Signed-off-by: Andrew Pinski
---
gcc/tree-tailcall.cc | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/gcc/tree-tailcall.cc b/gcc/tree-tailcall.cc
index 3efbe9042f2..b72ca6d8d8f 100644
--- a/gcc/tree-tailcall.cc
+++ b/gcc/tree-tailcall.cc
@@ -441,6 +441,17 @@ propagate_through_phis (tree var, edge e)
static void
maybe_error_musttail (gcall *call, const char *err, bool diag_musttail)
{
+ if (dump_file)
+{
+ print_gimple_stmt (dump_file, call, 0, TDF_SLIM);
+ fprintf (dump_file, "Cannot convert: %s\n", err);
+ if (gimple_call_must_tail_p (call))
+ {
+ fprintf (dump_file, "was musttail.\n");
+ if (diag_musttail)
+ fprintf (dump_file, "turned off musttail\n");
+ }
+}
if (gimple_call_must_tail_p (call) && diag_musttail)
{
error_at (call->location, "cannot tail-call: %s", err);
@@ -451,11 +462,6 @@ maybe_error_musttail (gcall *call, const char *err, bool
diag_musttail)
gimple_call_set_must_tail (call, false); /* Avoid another error. */
gimple_call_set_tail (call, false);
}
- if (dump_file)
-{
- print_gimple_stmt (dump_file, call, 0, TDF_SLIM);
- fprintf (dump_file, "Cannot convert: %s\n", err);
-}
}
/* Argument for compute_live_vars/live_vars_at_stmt and what compute_live_vars
--
2.43.0
Re: [PATCH 01/12] contrib: add dg-lint and libgdiagnostics.py [PR116163]
Jakub Jelinek writes: > On Wed, Mar 26, 2025 at 09:32:30PM +, Sam James wrote: >> Right, we can extend it for 'dg-do known-actions' as well. > > I think that shouldn't be necessary. > > gcc-dg-test-1 should already complain about unexpected actions. Ah, you're right. Thanks.
[PATCH] doc: say "compatible types" for -fstrict-aliasing
Include the term used in the standard to ease further research for users.
gcc/ChangeLog:
* doc/invoke.texi: Use "compatible types" term.
---
gcc/doc/invoke.texi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b3f7f0479cc4..ad749f2fd258 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -14552,10 +14552,10 @@ Allow the compiler to assume the strictest aliasing
rules applicable to
the language being compiled. For C (and C++), this activates
optimizations based on the type of expressions. In particular, an
object of one type is assumed never to reside at the same address as an
-object of a different type, unless the types are almost the same. For
-example, an @code{unsigned int} can alias an @code{int}, but not a
-@code{void*} or a @code{double}. A character type may alias any other
-type.
+object of a different type, unless the types are almost the same
+(``compatible types''). For example, an @code{unsigned int} can alias an
+@code{int}, but not a @code{void*} or a @code{double}. A character type may
+alias any other type.
@anchor{Type-punning}Pay special attention to code like this:
@smallexample
base-commit: 2e7c1b589bc58be0e155098cf87d8535d41adeab
--
2.49.0
[PATCH 1/6] testsuite: fortran: fix dg syntax errors
No change in test results. The changes other than the first are
arguably not errors, but still clearly wrong and mistakes.
gcc/testsuite/ChangeLog:
* gfortran.dg/associate_70.f90: Replace ')' with '}'.
* gfortran.dg/bessel_3.f90: Drop extraneous ')'.
* gfortran.dg/c_funloc_tests_6.f90: Ditto.
* gfortran.dg/parity_2.f90: Ditto.
---
gcc/testsuite/gfortran.dg/associate_70.f90 | 2 +-
gcc/testsuite/gfortran.dg/bessel_3.f90 | 2 +-
gcc/testsuite/gfortran.dg/c_funloc_tests_6.f90 | 2 +-
gcc/testsuite/gfortran.dg/parity_2.f90 | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/associate_70.f90
b/gcc/testsuite/gfortran.dg/associate_70.f90
index ddb38b84c4b3..6f8f5d6a7cb8 100644
--- a/gcc/testsuite/gfortran.dg/associate_70.f90
+++ b/gcc/testsuite/gfortran.dg/associate_70.f90
@@ -1,5 +1,5 @@
! { dg-do run }
-! ( dg-options "-Wuninitialized" )
+! { dg-options "-Wuninitialized" }
!
! Test fix for PR115700 comment 5, in which ‘.tmp1’ is used uninitialized and
! both normal and scalarized array references did not work correctly.
diff --git a/gcc/testsuite/gfortran.dg/bessel_3.f90
b/gcc/testsuite/gfortran.dg/bessel_3.f90
index 51e11e9160a9..4191d2478cd6 100644
--- a/gcc/testsuite/gfortran.dg/bessel_3.f90
+++ b/gcc/testsuite/gfortran.dg/bessel_3.f90
@@ -6,7 +6,7 @@
!
IMPLICIT NONE
print *, SIN (1.0)
-print *, BESSEL_J0(1.0) ! { dg-error "has no IMPLICIT type" })
+print *, BESSEL_J0(1.0) ! { dg-error "has no IMPLICIT type" }
print *, BESSEL_J1(1.0) ! { dg-error "has no IMPLICIT type" }
print *, BESSEL_JN(1,1.0) ! { dg-error "has no IMPLICIT type|Type mismatch" }
print *, BESSEL_JN(1,2,1.0) ! { dg-error "has no IMPLICIT type|Type
mismatch|More actual than formal" }
diff --git a/gcc/testsuite/gfortran.dg/c_funloc_tests_6.f90
b/gcc/testsuite/gfortran.dg/c_funloc_tests_6.f90
index 45d095566d13..d8c8039e2586 100644
--- a/gcc/testsuite/gfortran.dg/c_funloc_tests_6.f90
+++ b/gcc/testsuite/gfortran.dg/c_funloc_tests_6.f90
@@ -20,7 +20,7 @@ procedure(sub), pointer :: fsub
integer, external :: noCsub
procedure(integer), pointer :: fint
-cp = c_funloc (sub) ! { dg-error "Cannot convert TYPE.c_funptr. to
TYPE.c_ptr." })
+cp = c_funloc (sub) ! { dg-error "Cannot convert TYPE.c_funptr. to
TYPE.c_ptr." }
cfp = c_loc (int) ! { dg-error "Cannot convert TYPE.c_ptr. to
TYPE.c_funptr." }
call c_f_pointer (cfp, int) ! { dg-error "Argument CPTR at .1. to
C_F_POINTER shall have the type TYPE.C_PTR." }
diff --git a/gcc/testsuite/gfortran.dg/parity_2.f90
b/gcc/testsuite/gfortran.dg/parity_2.f90
index 5ff11dab9d91..9a8e0357d67b 100644
--- a/gcc/testsuite/gfortran.dg/parity_2.f90
+++ b/gcc/testsuite/gfortran.dg/parity_2.f90
@@ -6,7 +6,7 @@
! Check implementation of PARITY
!
implicit none
-print *, parity([real ::]) ! { dg-error "must be LOGICAL" })
+print *, parity([real ::]) ! { dg-error "must be LOGICAL" }
print *, parity([integer ::]) ! { dg-error "must be LOGICAL" }
print *, parity([logical ::])
print *, parity(.true.) ! { dg-error "must be an array" }
--
2.49.0
[PATCH 3/6] testsuite: more (mostly cosmetic) dg- whitespace fixes
Some of these are harmless but still inconsistent (and asking for trouble
given it may give people the wrong idea about similar "style").
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/gen-attrs-6.C: Surround 'target' by whitespace.
* gcc.target/aarch64/atomic-inst-ldlogic.c: Fix 'dg-final' whitespace.
* gcc.target/arm/short-vfp-1.c: Ditto.
* gcc.target/bfin/l2.c: Fix 'dg-bfin-processors' whitespace.
* gcc.target/i386/avx512fp16-vmovw-1b.c: Surround 'target' by
whitespace.
* gcc.target/i386/sse2-float16-5.c: Ditto.
* gcc.target/powerpc/fold-vec-perm-longlong.c: Ditto.
---
gcc/testsuite/g++.dg/cpp0x/gen-attrs-6.C | 2 +-
gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c | 4 ++--
gcc/testsuite/gcc.target/arm/short-vfp-1.c | 10 +-
gcc/testsuite/gcc.target/bfin/l2.c | 2 +-
gcc/testsuite/gcc.target/i386/avx512fp16-vmovw-1b.c| 2 +-
gcc/testsuite/gcc.target/i386/sse2-float16-5.c | 2 +-
.../gcc.target/powerpc/fold-vec-perm-longlong.c| 2 +-
7 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-6.C
b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-6.C
index 54071d5ed149..d166add65b99 100644
--- a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-6.C
+++ b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-6.C
@@ -4,7 +4,7 @@
//
// Written by Richard Henderson, 26 May 2002.
-// { dg-do link { target c++11} }
+// { dg-do link { target c++11 } }
extern void foo [[gnu::nothrow]] ();
extern void link_error();
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c
b/gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c
index 4879d52b9b4f..1927ebc10e28 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c
@@ -128,7 +128,7 @@ TEST (xor_load_notreturn, XOR_LOAD_NORETURN)
/* { dg-final { scan-assembler-times "ldclrlh\t" 8} } */
/* { dg-final { scan-assembler-times "ldclralh\t" 16} } */
-/* { dg-final { scan-assembler-times "ldclr\t" 16} */
+/* { dg-final { scan-assembler-times "ldclr\t" 16 } */
/* { dg-final { scan-assembler-times "ldclra\t" 32} } */
/* { dg-final { scan-assembler-times "ldclrl\t" 16} } */
/* { dg-final { scan-assembler-times "ldclral\t" 32} } */
@@ -137,7 +137,7 @@ TEST (xor_load_notreturn, XOR_LOAD_NORETURN)
/* { dg-final { scan-assembler-times "ldeorb\t" 8} } */
/* { dg-final { scan-assembler-times "ldeorab\t" 16} } */
-/* { dg-final { scan-assembler-times "ldeorlb\t" 8} } */
+/* { dg-final { scan-assembler-times "ldeorlb\t" 8 } } */
/* { dg-final { scan-assembler-times "ldeoralb\t" 16} } */
/* { dg-final { scan-assembler-times "ldeorh\t" 8} } */
diff --git a/gcc/testsuite/gcc.target/arm/short-vfp-1.c
b/gcc/testsuite/gcc.target/arm/short-vfp-1.c
index 3ca1ffc00173..ddab09a4b7fb 100644
--- a/gcc/testsuite/gcc.target/arm/short-vfp-1.c
+++ b/gcc/testsuite/gcc.target/arm/short-vfp-1.c
@@ -38,8 +38,8 @@ test_sihi (short x)
return (int)x;
}
-/* {dg-final { scan-assembler-times {vcvt\.s32\.f32\ts[0-9]+,s[0-9]+} 2 }} */
-/* {dg-final { scan-assembler-times {vcvt\.f32\.s32\ts[0-9]+,s[0-9]+} 2 }} */
-/* {dg-final { scan-assembler-times {vmov\tr[0-9]+,s[0-9]+} 2 }} */
-/* {dg-final { scan-assembler-times {vmov\ts[0-9]+,r[0-9]+} 2 }} */
-/* {dg-final { scan-assembler-times {sxth\tr[0-9]+,r[0-9]+} 2 }} */
+/* { dg-final { scan-assembler-times {vcvt\.s32\.f32\ts[0-9]+,s[0-9]+} 2 }} */
+/* { dg-final { scan-assembler-times {vcvt\.f32\.s32\ts[0-9]+,s[0-9]+} 2 }} */
+/* { dg-final { scan-assembler-times {vmov\tr[0-9]+,s[0-9]+} 2 }} */
+/* { dg-final { scan-assembler-times {vmov\ts[0-9]+,r[0-9]+} 2 }} */
+/* { dg-final { scan-assembler-times {sxth\tr[0-9]+,r[0-9]+} 2 }} */
diff --git a/gcc/testsuite/gcc.target/bfin/l2.c
b/gcc/testsuite/gcc.target/bfin/l2.c
index 56f64cc82b48..2d39c46f8f12 100644
--- a/gcc/testsuite/gcc.target/bfin/l2.c
+++ b/gcc/testsuite/gcc.target/bfin/l2.c
@@ -1,5 +1,5 @@
/* { dg-do run { target bfin-*-linux-uclibc } } */
-/* { dg-bfin-processors bf544 bf547 bf548 bf549 bf561} */
+/* { dg-bfin-processors bf544 bf547 bf548 bf549 bf561 } */
#if defined(__ADSPBF544__)
#define L2_START 0xFEB0
diff --git a/gcc/testsuite/gcc.target/i386/avx512fp16-vmovw-1b.c
b/gcc/testsuite/gcc.target/i386/avx512fp16-vmovw-1b.c
index a96007d6fd87..9b08f5a9c488 100644
--- a/gcc/testsuite/gcc.target/i386/avx512fp16-vmovw-1b.c
+++ b/gcc/testsuite/gcc.target/i386/avx512fp16-vmovw-1b.c
@@ -1,4 +1,4 @@
-/* { dg-do run {target avx512fp16} } */
+/* { dg-do run { target avx512fp16 } } */
/* { dg-options "-O2 -mavx512fp16" } */
static void do_test (void);
diff --git a/gcc/testsuite/gcc.target/i386/sse2-float16-5.c
b/gcc/testsuite/gcc.target/i386/sse2-float16-5.c
index c3ed23b8ab3c..82078429cc20 100644
--- a/gcc/testsuite/gcc.target/i386/sse2-float16-5.c
+++ b/gcc/testsuite/gcc.target/i386/sse2-float16-5.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target i
[PATCH 6/6] testsuite: assorted targets: add missing braces to dg-* directives
These get ignored otherwise.
gcc/testsuite/ChangeLog:
* gcc.target/arc/taux-1.c: Add missing brace.
* gcc.target/arc/taux-2.c: Ditto.
* gcc.target/i386/addr-space-1.c: Ditto.
* gcc.target/ia64/mfused-madd-vect.c: Ditto.
* gcc.target/ia64/mfused-madd.c: Ditto.
* gcc.target/ia64/mno-fused-madd-vect.c: Ditto.
* gcc.target/ia64/mno-fused-madd.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls-vlmax/merge-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/merge-4.c: Ditto.
* gcc.target/s390/target-attribute/tattr-1.c: Ditto.
* gcc.target/s390/target-attribute/tattr-2.c: Ditto.
---
gcc/testsuite/gcc.target/arc/taux-1.c | 2 +-
gcc/testsuite/gcc.target/arc/taux-2.c | 2 +-
gcc/testsuite/gcc.target/i386/addr-space-1.c | 2 +-
gcc/testsuite/gcc.target/ia64/mfused-madd-vect.c | 2 +-
gcc/testsuite/gcc.target/ia64/mfused-madd.c| 2 +-
gcc/testsuite/gcc.target/ia64/mno-fused-madd-vect.c| 2 +-
gcc/testsuite/gcc.target/ia64/mno-fused-madd.c | 2 +-
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/merge-4.c | 2 +-
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/merge-4.c | 2 +-
gcc/testsuite/gcc.target/s390/target-attribute/tattr-1.c | 2 +-
gcc/testsuite/gcc.target/s390/target-attribute/tattr-2.c | 2 +-
11 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arc/taux-1.c
b/gcc/testsuite/gcc.target/arc/taux-1.c
index a2b77782192c..41b0fc40ed5a 100644
--- a/gcc/testsuite/gcc.target/arc/taux-1.c
+++ b/gcc/testsuite/gcc.target/arc/taux-1.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O1 */
+/* { dg-options "-O1" } */
#define __aux() __attribute__((aux))
diff --git a/gcc/testsuite/gcc.target/arc/taux-2.c
b/gcc/testsuite/gcc.target/arc/taux-2.c
index 5644bcd65c19..3e57ac87ea06 100644
--- a/gcc/testsuite/gcc.target/arc/taux-2.c
+++ b/gcc/testsuite/gcc.target/arc/taux-2.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O1 */
+/* { dg-options "-O1" } */
#define __aux(r) __attribute__((aux(r)))
static volatile __aux(0x1000) int var;
diff --git a/gcc/testsuite/gcc.target/i386/addr-space-1.c
b/gcc/testsuite/gcc.target/i386/addr-space-1.c
index 1e1314760e20..9a5ce9c5b0ed 100644
--- a/gcc/testsuite/gcc.target/i386/addr-space-1.c
+++ b/gcc/testsuite/gcc.target/i386/addr-space-1.c
@@ -1,4 +1,4 @@
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-final { scan-assembler "movl\[ \t\]%gs:\\((%eax|%rax)\\), %eax" } } */
diff --git a/gcc/testsuite/gcc.target/ia64/mfused-madd-vect.c
b/gcc/testsuite/gcc.target/ia64/mfused-madd-vect.c
index 5bf6976caa0b..d1dc3c1cabbc 100644
--- a/gcc/testsuite/gcc.target/ia64/mfused-madd-vect.c
+++ b/gcc/testsuite/gcc.target/ia64/mfused-madd-vect.c
@@ -1,4 +1,4 @@
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-options "-O2 -ftree-vectorize" } */
/* { dg-final { scan-assembler-not "fpmpy" } } */
diff --git a/gcc/testsuite/gcc.target/ia64/mfused-madd.c
b/gcc/testsuite/gcc.target/ia64/mfused-madd.c
index 8ecb31f0dd3a..04fd95a6f092 100644
--- a/gcc/testsuite/gcc.target/ia64/mfused-madd.c
+++ b/gcc/testsuite/gcc.target/ia64/mfused-madd.c
@@ -1,4 +1,4 @@
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-final { scan-assembler-not "fmpy" } } */
/* { dg-final { scan-assembler-not "fadd" } } */
diff --git a/gcc/testsuite/gcc.target/ia64/mno-fused-madd-vect.c
b/gcc/testsuite/gcc.target/ia64/mno-fused-madd-vect.c
index 10b047bd9b5c..a80ce8b18df3 100644
--- a/gcc/testsuite/gcc.target/ia64/mno-fused-madd-vect.c
+++ b/gcc/testsuite/gcc.target/ia64/mno-fused-madd-vect.c
@@ -1,4 +1,4 @@
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-options "-O2 -ffp-contract=off -ftree-vectorize" } */
/* { dg-final { scan-assembler "fpmpy" } } */
diff --git a/gcc/testsuite/gcc.target/ia64/mno-fused-madd.c
b/gcc/testsuite/gcc.target/ia64/mno-fused-madd.c
index 487519addf56..1f2922588763 100644
--- a/gcc/testsuite/gcc.target/ia64/mno-fused-madd.c
+++ b/gcc/testsuite/gcc.target/ia64/mno-fused-madd.c
@@ -1,4 +1,4 @@
-/* { dg-do compile */
+/* { dg-do compile } */
/* { dg-options "-O2 -ffp-contract=off" } */
/* { dg-final { scan-assembler-not "fma" } } */
/* { dg-final { scan-assembler-not "fms" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/merge-4.c
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/merge-4.c
index 3095a6df1890..a043b3323d77 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/merge-4.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/merge-4.c
@@ -119,4 +119,4 @@ merge10 (vnx16df x, vnx16df y, vnx16df *out)
*(vnx16df*)out = v;
}
-/* dg-final scan-assembler-times {\tvmerge.vvm} 11 */
+/* { dg-final { scan-assembler-times {\tvmerge.vvm} 11 } } */
diff --git a/gcc
[PATCH 0/6] testsuite: more misc. syntax fixes
Pushed as obvious. Sam James (6): testsuite: fortran: fix dg syntax errors testsuite: fix dg-bogus typo testsuite: more (mostly cosmetic) dg- whitespace fixes testsuite: fix dg-message typos testsuite: fix more dg-* whitespace issues testsuite: assorted targets: add missing braces to dg-* directives gcc/testsuite/g++.dg/cpp0x/gen-attrs-6.C | 2 +- gcc/testsuite/g++.dg/cpp0x/udlit-namespace-ambiguous.C | 4 ++-- gcc/testsuite/g++.dg/cpp2a/constexpr-init21.C | 2 +- gcc/testsuite/g++.dg/diagnostic/unclosed-extern-c.C| 2 +- gcc/testsuite/g++.dg/diagnostic/wrong-tag-1.C | 2 +- gcc/testsuite/g++.dg/init/self1.C | 2 +- gcc/testsuite/g++.dg/opt/pr98743.C | 2 +- gcc/testsuite/g++.dg/parse/error8.C| 2 +- gcc/testsuite/g++.dg/template/explicit-args6.C | 2 +- gcc/testsuite/g++.dg/template/unify9.C | 2 +- gcc/testsuite/g++.dg/tree-ssa/pr105820.C | 2 +- gcc/testsuite/g++.dg/warn/Wmismatched-tags-8.C | 6 +++--- gcc/testsuite/g++.dg/warn/Wno-attributes-1.C | 6 +++--- gcc/testsuite/g++.dg/warn/Wstringop-overflow-5.C | 2 +- gcc/testsuite/gcc.dg/cpp/cmdlne-dM-M.c | 2 +- gcc/testsuite/gcc.dg/tree-ssa/reassoc-32.c | 2 +- gcc/testsuite/gcc.dg/tree-ssa/reassoc-33.c | 2 +- gcc/testsuite/gcc.dg/tree-ssa/reassoc-34.c | 2 +- gcc/testsuite/gcc.dg/tree-ssa/reassoc-35.c | 2 +- gcc/testsuite/gcc.dg/tree-ssa/reassoc-36.c | 2 +- gcc/testsuite/gcc.dg/tree-ssa/reassoc-39.c | 2 +- gcc/testsuite/gcc.dg/tree-ssa/reassoc-41.c | 2 +- gcc/testsuite/gcc.target/aarch64/atomic-inst-ldlogic.c | 4 ++-- gcc/testsuite/gcc.target/arc/taux-1.c | 2 +- gcc/testsuite/gcc.target/arc/taux-2.c | 2 +- gcc/testsuite/gcc.target/arm/short-vfp-1.c | 10 +- gcc/testsuite/gcc.target/bfin/l2.c | 2 +- gcc/testsuite/gcc.target/i386/addr-space-1.c | 2 +- gcc/testsuite/gcc.target/i386/avx512fp16-vmovw-1b.c| 2 +- gcc/testsuite/gcc.target/i386/sse2-float16-5.c | 2 +- gcc/testsuite/gcc.target/ia64/mfused-madd-vect.c | 2 +- gcc/testsuite/gcc.target/ia64/mfused-madd.c| 2 +- gcc/testsuite/gcc.target/ia64/mno-fused-madd-vect.c| 2 +- gcc/testsuite/gcc.target/ia64/mno-fused-madd.c | 2 +- .../gcc.target/powerpc/fold-vec-perm-longlong.c| 2 +- .../gcc.target/riscv/rvv/autovec/vls-vlmax/merge-4.c | 2 +- .../gcc.target/riscv/rvv/autovec/vls/merge-4.c | 2 +- .../gcc.target/s390/target-attribute/tattr-1.c | 2 +- .../gcc.target/s390/target-attribute/tattr-2.c | 2 +- gcc/testsuite/gfortran.dg/associate_70.f90 | 2 +- gcc/testsuite/gfortran.dg/bessel_3.f90 | 2 +- gcc/testsuite/gfortran.dg/c_funloc_tests_6.f90 | 2 +- gcc/testsuite/gfortran.dg/parity_2.f90 | 2 +- 43 files changed, 53 insertions(+), 53 deletions(-) base-commit: dcbc80af6fc3fb5c2b23a1773682ec8f91b4eeaf -- 2.49.0
[PATCH 2/4] testsuite: tree-ssa: fix PR98265 filename
.C is for C++ testcases and gcc.dg's dg.exp ignores .c. The test
was not being run.
gcc/testsuite/ChangeLog:
PR ipa/98265
* gcc.dg/tree-ssa/pr98265.C: Move to...
* g++.dg/tree-ssa/pr98265.C: ...here.
---
gcc/testsuite/{gcc.dg => g++.dg}/tree-ssa/pr98265.C | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename gcc/testsuite/{gcc.dg => g++.dg}/tree-ssa/pr98265.C (100%)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr98265.C
b/gcc/testsuite/g++.dg/tree-ssa/pr98265.C
similarity index 100%
rename from gcc/testsuite/gcc.dg/tree-ssa/pr98265.C
rename to gcc/testsuite/g++.dg/tree-ssa/pr98265.C
--
2.49.0
[PATCH] libcpp: Add missing configure check for setlocale.
The libcpp code uses `#ifdef HAVE_SETLOCALE` but its configure doesn't have the corresponding check. Ok for trunk and 14 branch? (Sorry for the attachment, my MUA is difficult.) Thanks, Roland libcpp/ 2025-03-27 Roland McGrath * configure.ac: Check for setlocale. * configure, config.in: Regenerated. diff --git a/libcpp/config.in b/libcpp/config.in index b2e2f4e842c..c81ee08c253 100644 --- a/libcpp/config.in +++ b/libcpp/config.in @@ -210,6 +210,9 @@ /* Define to 1 if you have the `putc_unlocked' function. */ #undef HAVE_PUTC_UNLOCKED +/* Define to 1 if you have the `setlocale' function. */ +#undef HAVE_SETLOCALE + /* Define to 1 if you can assemble SSSE3 insns. */ #undef HAVE_SSSE3 diff --git a/libcpp/configure b/libcpp/configure index 1391081ba09..2d517397c02 100755 --- a/libcpp/configure +++ b/libcpp/configure @@ -4654,7 +4654,7 @@ else We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) +#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -4700,7 +4700,7 @@ else We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) +#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -4724,7 +4724,7 @@ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) +#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -4769,7 +4769,7 @@ else We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) +#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -4793,7 +4793,7 @@ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) +#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -6034,7 +6034,7 @@ _ACEOF -for ac_func in clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked +for ac_func in clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked setlocale do : as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh` ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var" diff --git a/libcpp/configure.ac b/libcpp/configure.ac index 981f97c4abd..845dd644948 100644 --- a/libcpp/configure.ac +++ b/libcpp/configure.ac @@ -81,7 +81,7 @@ define(libcpp_UNLOCKED_FUNCS, clearerr_unlocked feof_unlocked dnl fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked dnl fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked dnl putchar_unlocked putc_unlocked) -AC_CHECK_FUNCS(libcpp_UNLOCKED_FUNCS) +AC_CHECK_FUNCS(libcpp_UNLOCKED_FUNCS setlocale) AC_CHECK_DECLS([abort, asprintf, basename(char *), errno, getopt, vasprintf]) AC_CHECK_DECLS(m4_split(m4_normalize(libcpp_UNLOCKED_FUNCS))) @@ -172,7 +172,7 @@ do esac done IFS="$ac_save_IFS" - + if test x$ac_checking != x ; then AC_DEFINE(CHECKING_P, 1, [Define to 1 if you want more run-time sanity checks.])
Re: [PATCH 2/2] Add prime path coverage to gcc/gcov
On 3/26/25 14:54, Jan Hubicka wrote: Hello, I apologize for late reply here. I went thru the paper in gereater detail. While I originally though the usual path-profiling can be reasonably merged with the prime math profiling, so it is useful both for optimizaiton and coverage testing, I think it is better to not do that - the requirements of prime path profiling are rather specific and expensive to get right. gcc/ChangeLog: * Makefile.in (OBJS): Add prime-paths.o, path-coverage.o. (GTFILES): Add prime-paths.cc, path-coverage.cc (GCOV_OBJS): Add graphds.o, prime-paths.o, bitmap.o * builtins.cc (expand_builtin_fork_or_exec): Check path_coverage_flag. * collect2.cc (main): Add -fno-path-coverage to OBSTACK. * common.opt: Add new options -fpath-coverage, -fpath-coverage-limit, -Wcoverage-too-many-paths * doc/gcov.texi: Add --prime-paths, --prime-paths-lines, --prime-paths-source documentation. * doc/invoke.texi: Add -fpath-coverage, -fpath-coverage-limit, -Wcoverage-too-many-paths documentation. * gcc.cc: Link gcov on -fpath-coverage. * gcov-counter.def (GCOV_COUNTER_PATHS): New. * gcov-io.h (GCOV_TAG_PATHS): New. (GCOV_TAG_PATHS_LENGTH): New. (GCOV_TAG_PATHS_NUM): New. * gcov.cc (class path_info): New. (struct coverage_info): Add paths, paths_covered. (find_prime_paths): New. (add_path_counts): New. (find_arc): New. (print_usage): Add -e, --prime-paths, --prime-paths-lines, --prime-paths-source. (process_args): Likewise. (json_set_prime_path_coverage): New. (output_json_intermediate_file): Call json_set_prime_path_coverage. (process_all_functions): Call find_prime_paths. (generate_results): Call add_path_counts. (read_graph_file): Read path counters. (read_count_file): Likewise. (function_summary): Print path counts. (file_summary): Likewise. (print_source_line): New. (print_prime_path_lines): New. (print_inlined_separator): New. (print_prime_path_source): New. (output_path_coverage): New. (output_lines): Print path coverage. * ipa-inline.cc (can_early_inline_edge_p): Check path_coverage_flag. * passes.cc (finish_optimization_passes): Likewise. * profile.cc (branch_prob): Likewise. * selftest-run-tests.cc (selftest::run_tests): Run path coverage tests. * selftest.h (path_coverage_cc_tests): New declaration. * tree-profile.cc (tree_profiling): Check path_coverage_flag. (pass_ipa_tree_profile::gate): Likewise. * path-coverage.cc: New file. * prime-paths.cc: New file. gcc/testsuite/ChangeLog: * lib/gcov.exp: Add prime paths test function. * g++.dg/gcov/gcov-22.C: New test. * g++.dg/gcov/gcov-23-1.h: New test. * g++.dg/gcov/gcov-23-2.h: New test. * g++.dg/gcov/gcov-23.C: New test. * gcc.misc-tests/gcov-29.c: New test. * gcc.misc-tests/gcov-30.c: New test. * gcc.misc-tests/gcov-31.c: New test. * gcc.misc-tests/gcov-32.c: New test. * gcc.misc-tests/gcov-33.c: New test. * gcc.misc-tests/gcov-34.c: New test. --- gcc/Makefile.in|6 +- gcc/builtins.cc|2 +- gcc/collect2.cc|6 +- gcc/common.opt | 16 + gcc/doc/gcov.texi | 187 +++ gcc/doc/invoke.texi| 36 + gcc/gcc.cc |4 +- gcc/gcov-counter.def |3 + gcc/gcov-io.h |3 + gcc/gcov.cc| 487 +- gcc/ipa-inline.cc |2 +- gcc/passes.cc |4 +- gcc/path-coverage.cc | 776 + gcc/prime-paths.cc | 2052 gcc/profile.cc |6 +- gcc/selftest-run-tests.cc |1 + gcc/selftest.h |1 + gcc/testsuite/g++.dg/gcov/gcov-22.C| 170 ++ gcc/testsuite/g++.dg/gcov/gcov-23-1.h |9 + gcc/testsuite/g++.dg/gcov/gcov-23-2.h |9 + gcc/testsuite/g++.dg/gcov/gcov-23.C| 30 + gcc/testsuite/gcc.misc-tests/gcov-29.c | 869 ++ gcc/testsuite/gcc.misc-tests/gcov-30.c | 869 ++ gcc/testsuite/gcc.misc-tests/gcov-31.c | 35 + gcc/testsuite/gcc.misc-tests/gcov-32.c | 24 + gcc/testsuite/gcc.misc-tests/gcov-33.c | 27 + gcc/testsuite/gcc.misc-tests/gcov-34.c | 29 + gcc/testsuite/lib/gcov.exp | 118 +- gcc/tree-profile.cc| 11 +- 29 files changed, 5775 insertions(+), 17 deletions(-) create mode 100644 gcc/path-coverage.cc create mode 100644 gcc/pri
Re: [PATCH 03/12] testsuite, gomp: fix broken dg directives
On Wed, Mar 26, 2025 at 02:34:45PM -0400, David Malcolm wrote: > gcc/testsuite/ChangeLog: > * c-c++-common/gomp/metadirective-target-device-2.c: Fix missing > trailing " }" on dg-do directive. > * gcc.dg/gomp/attrs-21.c: Likewise for dg-options. > * gcc.dg/gomp/parallel-2.c: Drop ":" from dg-message. LGTM. Jakub
Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language
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
[PATCH 6/7] Doc: Move Integer Overflow Builtins section [PR42270]
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Numeric Builtins): Move Integer Overflow Builtins
section here, as a subsection.
---
gcc/doc/extend.texi | 303 ++--
1 file changed, 153 insertions(+), 150 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index de9c2b36ba3..f2710959ece 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -14244,8 +14244,6 @@ a function call results in a compile-time error.
* Stack Scrubbing:: Stack scrubbing internal interfaces.
* Vector Extensions:: Using vector instructions through built-in functions.
* Atomic Memory Access:: __atomic and __sync builtins.
-* Integer Overflow Builtins:: Built-in functions to perform arithmetics and
-arithmetic overflow checking.
* Object Size Checking:: Built-in functions for limited buffer overflow
checking.
* New/Delete Builtins:: Built-in functions for C++ allocations and
deallocations.
@@ -14831,6 +14829,8 @@ floating-point or integer operand.
* Bit Operation Builtins:: Counting bits and similar functions.
* Byte-Swapping Builtins:: Reversing byte order.
* CRC Builtins:: Compute cyclic redundancy checks.
+* Integer Overflow Builtins:: Built-in functions to perform arithmetics
+ and arithmetic overflow checking.
@end menu
@node Floating-Point Format Builtins
@@ -15445,6 +15445,157 @@ Similar to @code{__builtin_crc64_data64}, except the
@var{data} argument type
is 32-bit.
@enddefbuiltin
+@node Integer Overflow Builtins
+@subsection Built-in Functions to Perform Arithmetic with Overflow Checking
+@cindex overflow checking builtins
+@cindex integer arithmetic overflow checking builtins
+@cindex builtins for arithmetic overflow checking
+
+The following built-in functions allow performing simple arithmetic operations
+together with checking whether the operations overflowed.
+
+@defbuiltin{bool __builtin_add_overflow (@var{type1} @var{a}, @var{type2}
@var{b}, @var{type3} *@var{res})}
+@defbuiltinx{bool __builtin_sadd_overflow (int @var{a}, int @var{b}, int
*@var{res})}
+@defbuiltinx{bool __builtin_saddl_overflow (long int @var{a}, long int
@var{b}, long int *@var{res})}
+@defbuiltinx{bool __builtin_saddll_overflow (long long int @var{a}, long long
int @var{b}, long long int *@var{res})}
+@defbuiltinx{bool __builtin_uadd_overflow (unsigned int @var{a}, unsigned int
@var{b}, unsigned int *@var{res})}
+@defbuiltinx{bool __builtin_uaddl_overflow (unsigned long int @var{a},
unsigned long int @var{b}, unsigned long int *@var{res})}
+@defbuiltinx{bool __builtin_uaddll_overflow (unsigned long long int @var{a},
unsigned long long int @var{b}, unsigned long long int *@var{res})}
+
+These built-in functions promote the first two operands into infinite
precision signed
+type and perform addition on those promoted operands. The result is then
+cast to the type the third pointer argument points to and stored there.
+If the stored result is equal to the infinite precision result, the built-in
+functions return @code{false}, otherwise they return @code{true}. As the
addition is
+performed in infinite signed precision, these built-in functions have fully
defined
+behavior for all argument values.
+
+The first built-in function allows arbitrary integral types for operands and
+the result type must be pointer to some integral type other than enumerated or
+boolean type, the rest of the built-in functions have explicit integer types.
+
+The compiler will attempt to use hardware instructions to implement
+these built-in functions where possible, like conditional jump on overflow
+after addition, conditional jump on carry etc.
+
+@enddefbuiltin
+
+@defbuiltin{bool __builtin_sub_overflow (@var{type1} @var{a}, @var{type2}
@var{b}, @var{type3} *@var{res})}
+@defbuiltinx{bool __builtin_ssub_overflow (int @var{a}, int @var{b}, int
*@var{res})}
+@defbuiltinx{bool __builtin_ssubl_overflow (long int @var{a}, long int
@var{b}, long int *@var{res})}
+@defbuiltinx{bool __builtin_ssubll_overflow (long long int @var{a}, long long
int @var{b}, long long int *@var{res})}
+@defbuiltinx{bool __builtin_usub_overflow (unsigned int @var{a}, unsigned int
@var{b}, unsigned int *@var{res})}
+@defbuiltinx{bool __builtin_usubl_overflow (unsigned long int @var{a},
unsigned long int @var{b}, unsigned long int *@var{res})}
+@defbuiltinx{bool __builtin_usubll_overflow (unsigned long long int @var{a},
unsigned long long int @var{b}, unsigned long long int *@var{res})}
+
+These built-in functions are similar to the add overflow checking built-in
+functions above, except they perform subtraction, subtract the second argument
+from the first one, instead of addition.
+
+@enddefbuiltin
+
+@defbuiltin{bool __b
[PATCH 1/7] Doc: Remove separate "Target Format Checks" section [PR42270]
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
Following the last round of patches, there's a leftover section
"Target Format Checks" that didn't fit into any category. It seems best
to merge this material into the main discussion of the "format" attribute,
in particular because that discussion already contains similar discussion
for mingw/Windows targets.
gcc/ChangeLog
PR other/42270
* extend.texi (Function Attributes): Merge text from "Target
Format Checks" into the main discussion of the format and
format_arg attributes.
(Target Format Checks): Delete section.
---
gcc/doc/extend.texi | 95 +++--
1 file changed, 39 insertions(+), 56 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index ed766e53dcc..e68b810c043 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -58,7 +58,6 @@ extensions, accepted by GCC in C90 mode and in C++.
* New/Delete Builtins:: Built-in functions for C++ allocations and
deallocations.
* Other Builtins:: Other built-in functions.
* Target Builtins:: Built-in functions specific to particular targets.
-* Target Format Checks:: Format checks specific to particular targets.
@end menu
@node Additional Numeric Types
@@ -2219,18 +2218,43 @@ for consistency with the @code{printf} style format
string argument
@code{my_format}.
The parameter @var{archetype} determines how the format string is
-interpreted, and should be @code{printf}, @code{scanf}, @code{strftime},
+interpreted.
+Valid archetypes include @code{printf}, @code{scanf}, @code{strftime},
@code{gnu_printf}, @code{gnu_scanf}, @code{gnu_strftime} or
@code{strfmon}. (You can also use @code{__printf__},
-@code{__scanf__}, @code{__strftime__} or @code{__strfmon__}.) On
-MinGW targets, @code{ms_printf}, @code{ms_scanf}, and
-@code{ms_strftime} are also present.
+@code{__scanf__}, @code{__strftime__} or @code{__strfmon__}.)
@var{archetype} values such as @code{printf} refer to the formats accepted
by the system's C runtime library,
while values prefixed with @samp{gnu_} always refer
-to the formats accepted by the GNU C Library. On Microsoft Windows
-targets, values prefixed with @samp{ms_} refer to the formats accepted by the
+to the formats accepted by the GNU C Library.
+
+@anchor{Target Format Checks}
+On MinGW and Microsoft Windows targets, @code{ms_printf},
+@code{ms_scanf}, and @code{ms_strftime} are also present. Values
+prefixed with @samp{ms_} refer to the formats accepted by the
@file{msvcrt.dll} library.
+
+@anchor{Solaris Format Checks}
+Solaris targets also support the @code{cmn_err} (or @code{__cmn_err__})
+archetype.
+@code{cmn_err} accepts a subset of the standard @code{printf}
+conversions, and the two-argument @code{%b} conversion for displaying
+bit-fields. See the Solaris man page for @code{cmn_err} for more information.
+
+@anchor{Darwin Format Checks}
+Darwin targets also support the @code{CFString} (or
+@code{__CFString__}) archetype in the @code{format} attribute.
+Declarations with this archetype are parsed for correct syntax
+and argument types. However, parsing of the format string itself and
+validating arguments against it in calls to such functions is currently
+not performed.
+
+For Objective-C dialects, @code{NSString} (or @code{__NSString__}) is
+recognized in the same context. Declarations including these format attributes
+are parsed for correct syntax, however the result of checking of such format
+strings is not yet defined, and is not carried out by this version of the
+compiler.
+
The parameter @var{string-index}
specifies which argument is the format string argument (starting
from 1), while @var{first-to-check} is the number of the first
@@ -2265,15 +2289,7 @@ standard modes, the X/Open function @code{strfmon} is
also checked as
are @code{printf_unlocked} and @code{fprintf_unlocked}.
@xref{C Dialect Options,,Options Controlling C Dialect}.
-For Objective-C dialects, @code{NSString} (or @code{__NSString__}) is
-recognized in the same context. Declarations including these format attributes
-are parsed for correct syntax, however the result of checking of such format
-strings is not yet defined, and is not carried out by this version of the
-compiler.
-The target may also provide additional types of format checks.
-@xref{Target Format Checks,,Format Checks Specific to Particular
-Target Machines}.
@cindex @code{format_arg} function attribute
@opindex Wformat-nonliteral
@@ -2328,13 +2344,17 @@ requested by @option{-ansi} or an appropriate
@option{-std} option, or
is used. @xref{C Dialect Options,,Options
Controlling C Dialect}.
-For Objective-C dialects, the @code{format-arg} attribute may refer to an
+For Objective-C dialects, the @code{format_arg} attribute may refer to an
@code{NSString} reference for compatibility with the @code{format} attri
[PATCH 3/7] Doc: Move builtin documentation to a new chapter [PR42270]
This is part of an incremental effort to make the documentation for
GCC extensions better organized by grouping/rearranging sections by
topic.
I was originally intending to consolidate all the sections documenting
builtins as subsections of a new container section within the C
extensions chapter, but I ran into a technical limitation of Texinfo:
it only supports sectioning depth up to @subsubsection, and we already
had quite a few of those in the target-specific builtins sections. So
instead I have pulled all the existing sections out into a new
chapter. This actually makes sense since some of the builtins are
specific to C++ anyway and are not C language extensions at all.
Subsequent patches in this series will move things around within the
new chapter; this one just adds the new container node and adjusts
the menus.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (C Extensions): Move menu items for
builtin-related sections to...
(Built-in Functions): New chapter.
* doc/gcc.texi (Introduction): Add menu entry for new chapter.
---
gcc/doc/extend.texi | 51 -
gcc/doc/gcc.texi| 1 +
2 files changed, 37 insertions(+), 15 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 371e82a6852..386b6b0f5b1 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -36,21 +36,6 @@ extensions, accepted by GCC in C90 mode and in C++.
* Using Assembly Language with C:: Instructions and extensions for interfacing
C with assembler.
* Syntax Extensions:: Other extensions to C syntax.
* Semantic Extensions:: GNU C defines behavior for some non-standard
constructs.
-* Nonlocal Gotos:: Built-ins for nonlocal gotos.
-* Constructing Calls:: Built-ins for dispatching a call to another function.
-* Return Address:: Getting the return or frame address of a function.
-* Stack Scrubbing:: Stack scrubbing internal interfaces.
-* Vector Extensions:: Using vector instructions through built-in functions.
-* __sync Builtins:: Legacy built-in functions for atomic memory access.
-* __atomic Builtins:: Atomic built-in functions with memory model.
-* Integer Overflow Builtins:: Built-in functions to perform arithmetics and
-arithmetic overflow checking.
-* x86 specific memory model extensions for transactional memory:: x86 memory
models.
-* Object Size Checking:: Built-in functions for limited buffer overflow
-checking.
-* New/Delete Builtins:: Built-in functions for C++ allocations and
deallocations.
-* Other Builtins:: Other built-in functions.
-* Target Builtins:: Built-in functions specific to particular targets.
@end menu
@node Additional Numeric Types
@@ -14217,6 +14202,42 @@ extension explicit. Additionally, using @code{const}
and
@code{volatile} in this way is specific to GNU C and does not work in
GNU C++.
+@node Built-in Functions
+@chapter Built-in Functions Provided by GCC
+@cindex Built-in Functions
+
+GCC provides a very large number of implicitly-declared built-in
+functions that are typically inlined by the compiler. Some of these
+builtins directly correspond to standard library routines, while
+others provide the underlying functionality needed to implement
+features provided by library functions or similar ``glue'' between GCC
+and other programming languages or libraries. Others are
+target-specific, providing direct access to instructions that have no
+direct C equivalents without the need to write assembly language. There
+are also builtins to support various kinds of runtime error checking.
+
+Most builtins have names prefixed with @samp{__builtin_}. Except as
+otherwise documented, all built-in functions are available from any
+of the C family languages supported by GCC.
+
+@menu
+* Nonlocal Gotos:: Built-ins for nonlocal gotos.
+* Constructing Calls:: Built-ins for dispatching a call to another function.
+* Return Address:: Getting the return or frame address of a function.
+* Stack Scrubbing:: Stack scrubbing internal interfaces.
+* Vector Extensions:: Using vector instructions through built-in functions.
+* __sync Builtins:: Legacy built-in functions for atomic memory access.
+* __atomic Builtins:: Atomic built-in functions with memory model.
+* Integer Overflow Builtins:: Built-in functions to perform arithmetics and
+arithmetic overflow checking.
+* x86 specific memory model extensions for transactional memory:: x86 memory
models.
+* Object Size Checking:: Built-in functions for limited buffer overflow
+checking.
+* New/Delete Builtins:: Built-in functions for C++ allocations and
deallocations.
+* Other Builtins:: Other built-in functions.
+* Target Builtins:: Built-in functions specific to particular targets.
+@end menu
+
@node Nonlocal Gotos
@section Nonlocal Gotos
@cindex nonlocal gotos
diff --git a/gcc/doc/gcc
[PATCH, RFC 0/7] Doc: Further cleanups to extend.texi [PR42270]
Here's another batch of patches to address PR42270, a complaint about the poor organization of the documentation for GNU extensions. My last set of patches for this was focused on grouping everything but the attributes and builtins documentation into categories. This set does those two groupings, plus a couple of other leftover cleanups. For the attributes documentation, I moved the multiple existing sections to be subsections of a new container section. I didn't attempt to rewrite any of the material to reduce duplication (PR88472) or to focus on using standard attribute syntax instead of the traditional GNU syntax (PR102397). With the builtins documentation, adding a new level to the section hierarchy wasn't practical because of the limitation that Texinfo only goes as far down as @subsubsection, and we already had many of those in the target-specific builtins sections. Instead, I created a new parallel chapter for builtins. Here I did do some additional reorganization of the material, combining some sections, deleting others, and adding some new container sections, but I didn't do much review or correction of the actual text. As with the previous batch of these patches, I'll hold off on committing these for a few days in case anybody has any complaints or suggestions. (E.g., should the attributes documentation be split into a separate chapter as well, instead of being pushed down?) -Sandra Sandra Loosemore (7): Doc: Remove separate "Target Format Checks" section [PR42270] Doc: Add a container section to consolidate attribute documentation [PR42270] Doc: Move builtin documentation to a new chapter [PR42270] Doc: Break up and rearrange the "other builtins" section [PR42270] Doc: Organize atomic memory builtins documentation [PR42270] Doc: Move Integer Overflow Builtins section [PR42270] Doc: Clean up New/Delete Builtins manual section gcc/doc/extend.texi | 3569 ++- gcc/doc/gcc.texi|1 + gcc/doc/invoke.texi |4 +- 3 files changed, 1848 insertions(+), 1726 deletions(-) -- 2.34.1
[PATCH 2/7] Doc: Add a container section to consolidate attribute documentation [PR42270]
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
Note that this patch does not address the restructuring/rewrite
suggested by PR88472 or PR102397, beyond adding a very short
introduction to the new container section that is more explicit about
both syntaxes being accepted as a GNU extension.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Attributes): New section.
(Function Attributes): Make it a subsection of the new section.
(Variable Attributes): Likewise.
(Type Attributes): Likewise.
(Label Attributes): Likewise.
(Enumerator Attributes): Likewise.
(Attribute Syntax): Likewise.
---
gcc/doc/extend.texi | 174 +---
1 file changed, 101 insertions(+), 73 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index e68b810c043..371e82a6852 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -26,14 +26,7 @@ extensions, accepted by GCC in C90 mode and in C++.
* Additional Numeric Types:: Additional sizes and formats, plus complex
numbers.
* Aggregate Types::Extensions to arrays, structs, and unions.
* Named Address Spaces::Named address spaces.
-* Function Attributes:: Declaring that functions have no side effects,
-or that they can never return.
-* Variable Attributes:: Specifying attributes of variables.
-* Type Attributes:: Specifying attributes of types.
-* Label Attributes::Specifying attributes on labels.
-* Enumerator Attributes:: Specifying attributes on enumerators.
-* Statement Attributes:: Specifying attributes on statements.
-* Attribute Syntax::Formal syntax for attributes.
+* Attributes:: GCC supports both standard and legacy attribute syntax.
* Pragmas:: Pragmas accepted by GCC.
* Thread-Local::Per-thread variables.
* OpenMP:: Multiprocessing extensions.
@@ -1595,8 +1588,43 @@ The preprocessor symbols @code{__SEG_FS} and
@code{__SEG_GS} are
defined when these address spaces are supported.
@end table
+@node Attributes
+@section Attributes Specific to GCC
+@cindex attributes
+@cindex declaring attributes
+@cindex GNU attributes
+
+Attributes provide a mechanism to declare additional properties of
+functions, variables, types, and statements. For example, attributes
+can be used to control placement of objects in particular memory
+sections, or to specify properties that can allow the compiler to
+generate better code or diagnostics, such as declaring that a function
+never returns. GCC supports a large number of such attributes, which
+are documented in this section.
+
+GCC provides two different ways to specify attributes: the traditional
+GNU syntax using @samp{__attribute__ ((...))} annotations, and the
+newer standard C and C++ syntax using @samp{[[...]]} with the
+@samp{gnu::} namespace prefix on attribute names.
+The traditional syntax, described in detail in @ref{Attribute Syntax},
+is supported in all non-strict C and C++ language dialects.
+The standard syntax is supported in C with @option{-std=c23} or later,
+in C++ with @option{-std=c++11} or later, and as an extension in older
+GNU C and C++ dialects.
+
+@menu
+* Function Attributes:: Declaring that functions have no side effects,
+or that they can never return.
+* Variable Attributes:: Specifying attributes of variables.
+* Type Attributes:: Specifying attributes of types.
+* Label Attributes::Specifying attributes on labels.
+* Enumerator Attributes:: Specifying attributes on enumerators.
+* Statement Attributes:: Specifying attributes on statements.
+* Attribute Syntax::Formal syntax for attributes.
+@end menu
+
@node Function Attributes
-@section Declaring Attributes of Functions
+@subsection Declaring Attributes of Functions
@cindex function attributes
@cindex declaring attributes of functions
@@ -1698,7 +1726,7 @@ GCC plugins may provide their own attributes.
@end menu
@node Common Function Attributes
-@subsection Common Function Attributes
+@subsubsection Common Function Attributes
The following attributes are supported on most targets.
@@ -3760,7 +3788,7 @@ The default for the attribute is controlled by
@option{-fzero-call-used-regs}.
@c This is the end of the target-independent attribute table
@node AArch64 Function Attributes
-@subsection AArch64 Function Attributes
+@subsubsection AArch64 Function Attributes
The following target-specific function attributes are available for the
AArch64 target. For the most part, these options mirror the behavior of
@@ -3907,7 +3935,7 @@ foo (int a)
is valid and compiles function @code{foo} for ARMv8-A with @code{crc}
and @code{crypto} extensions and tunes it for @code{cortex-a53}.
-@subsubsection Inlining rules
+@subsubheading Inlining rules
Specifying target attributes on individual functions
Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language
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`.
Thanks,
Yeoul
[PATCH 7/7] Doc: Clean up New/Delete Builtins manual section
I noticed that the "New/Delete Builtins" section failed to explicitly
name or describe the arguments of the builtin functions it purported
to document, outside of using them in an example. I've fixed that
and cleaned up the whole section.
gcc/ChangeLog
* doc/extend.texi (New/Delete Builtins): Cleanup up the text and
explicitly list the builtins being documented.
---
gcc/doc/extend.texi | 41 +
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index f2710959ece..cde8ac24f59 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -16985,18 +16985,20 @@ is called and the @var{flag} argument passed to it.
@node New/Delete Builtins
@section Built-in functions for C++ allocations and deallocations
-@findex __builtin_operator_new
-@findex __builtin_operator_delete
-Calling these C++ built-in functions is similar to calling
-@code{::operator new} or @code{::operator delete} with the same arguments,
-except that it is an error if the selected @code{::operator new} or
-@code{::operator delete} overload is not a replaceable global operator
-and for optimization purposes calls to pairs of these functions can be
-omitted if access to the allocation is optimized out, or could be replaced
-with implementation provided buffer on the stack, or multiple allocation
-calls can be merged into a single allocation. In C++ such optimizations
-are normally allowed just for calls to such replaceable global operators
-from @code{new} and @code{delete} expressions.
+@cindex builtins for C++ @code{new} and @code{delete} operators
+@cindex @code{new} and @code{delete} builtins
+
+GNU C++ provides builtins that are equivalent to calling
+@code{::operator new} or @code{::operator delete} with the same arguments.
+It is an error if the selected @code{::operator new} or
+@code{::operator delete} overload is not a replaceable global operator.
+For optimization purposes, calls to pairs of these
+builtins can be omitted if access to the allocation is optimized out,
+or could be replaced with an implementation-provided buffer on the stack,
+or multiple allocation calls can be merged into a single allocation.
+In C++ such optimizations are normally allowed just for calls to such
+replaceable global operators from @code{new} and @code{delete}
+expressions.
@smallexample
void foo () @{
@@ -17010,6 +17012,21 @@ void foo () @{
@}
@end smallexample
+These built-ins are only available in C++.
+
+@defbuiltin{{void *} __builtin_operator_new (std::size_t @var{size}, ...)}
+This is the built-in form of @code{operator new}. It accepts the same
+argument forms as a ``usual allocation function'', as described in the
+C++ standard.
+@enddefbuiltin
+
+@defbuiltin{void __builtin_operator_delete (void * @var{ptr}, ...)}
+This is the built-in form of @code{operator delete}. It accepts the same
+argument forms as a ``usual deallocation function'', as described in the
+C++ standard.
+@enddefbuiltin
+
+
@node Other Builtins
@section Other Built-in Functions Provided by GCC
--
2.34.1
[PING][PATCH] Makefile.tpl: Implement per-stage GDCFLAGS [PR116975]
Ping. Excerpts from Iain Buclaw's message of März 3, 2025 11:14 pm: > Hi, > > This patch implements STAGE1_GDCFLAGS and others to the configure > machinery, allowing the GDCFLAGS for each bootstrap stage of building > gdc to be overriden, as is the case with CXXFLAGS for other front-ends. > > This is limited to just the generation of recipes for the > configure-stage-gcc and all-stage-gcc, as a D compiler is not optionally > needed by any other module. > > OK for mainline? > > Regards, > Iain. > > --- > PR d/116975 > > ChangeLog: > > * Makefile.in: Regenerate. > * Makefile.tpl (STAGE[+id+]_GDCFLAGS): New. > (STAGE2_GDCFLAGS): Add -fno-checking. > (STAGE3_GDCFLAGS): Add -fchecking=1. > (BASE_FLAGS_TO_PASS): Pass STAGE[+id+]_GDCFLAGS down. > (configure-stage[+id+]-[+prefix+][+module+]): Set GDCFLAGS for all gcc > module stages. > (all-stage[+id+]-[+prefix+][+module+]): Likewise. > --- > Makefile.in | 51 +++ > Makefile.tpl | 15 +-- > 2 files changed, 64 insertions(+), 2 deletions(-) > > diff --git a/Makefile.in b/Makefile.in > index 966d6045496..b80855ffc78 100644 > --- a/Makefile.in > +++ b/Makefile.in > @@ -619,6 +619,26 @@ STAGE1_CONFIGURE_FLAGS = $(STAGE1_CHECKING) \ > --disable-build-format-warnings > > @if target-libphobos-bootstrap > +# Defaults for each stage if we're bootstrapping D. > + > +STAGE1_GDCFLAGS = $(GDCFLAGS) > + > +STAGE2_GDCFLAGS = $(GDCFLAGS) > + > +STAGE3_GDCFLAGS = $(GDCFLAGS) > + > +STAGE4_GDCFLAGS = $(GDCFLAGS) > + > +STAGEprofile_GDCFLAGS = $(GDCFLAGS) > + > +STAGEtrain_GDCFLAGS = $(GDCFLAGS) > + > +STAGEfeedback_GDCFLAGS = $(GDCFLAGS) > + > +STAGEautoprofile_GDCFLAGS = $(GDCFLAGS) > + > +STAGEautofeedback_GDCFLAGS = $(GDCFLAGS) > + > STAGE1_CONFIGURE_FLAGS += --with-libphobos-druntime-only > STAGE2_CONFIGURE_FLAGS += --with-libphobos-druntime-only > @endif target-libphobos-bootstrap > @@ -632,6 +652,10 @@ STAGE2_CFLAGS += -fno-checking > STAGE2_TFLAGS += -fno-checking > STAGE3_CFLAGS += -fchecking=1 > STAGE3_TFLAGS += -fchecking=1 > +@if target-libphobos-bootstrap > +STAGE2_GDCFLAGS += -fno-checking > +STAGE3_GDCFLAGS += -fchecking=1 > +@endif target-libphobos-bootstrap > > STAGEprofile_CFLAGS = $(STAGE2_CFLAGS) -fprofile-generate > STAGEprofile_TFLAGS = $(STAGE2_TFLAGS) > @@ -921,38 +945,47 @@ BASE_FLAGS_TO_PASS = \ > "LEAN=$(LEAN)" \ > "STAGE1_CFLAGS=$(STAGE1_CFLAGS)" \ > "STAGE1_CXXFLAGS=$(STAGE1_CXXFLAGS)" \ > + "STAGE1_GDCFLAGS=$(STAGE1_GDCFLAGS)" \ > "STAGE1_GENERATOR_CFLAGS=$(STAGE1_GENERATOR_CFLAGS)" \ > "STAGE1_TFLAGS=$(STAGE1_TFLAGS)" \ > "STAGE2_CFLAGS=$(STAGE2_CFLAGS)" \ > "STAGE2_CXXFLAGS=$(STAGE2_CXXFLAGS)" \ > + "STAGE2_GDCFLAGS=$(STAGE2_GDCFLAGS)" \ > "STAGE2_GENERATOR_CFLAGS=$(STAGE2_GENERATOR_CFLAGS)" \ > "STAGE2_TFLAGS=$(STAGE2_TFLAGS)" \ > "STAGE3_CFLAGS=$(STAGE3_CFLAGS)" \ > "STAGE3_CXXFLAGS=$(STAGE3_CXXFLAGS)" \ > + "STAGE3_GDCFLAGS=$(STAGE3_GDCFLAGS)" \ > "STAGE3_GENERATOR_CFLAGS=$(STAGE3_GENERATOR_CFLAGS)" \ > "STAGE3_TFLAGS=$(STAGE3_TFLAGS)" \ > "STAGE4_CFLAGS=$(STAGE4_CFLAGS)" \ > "STAGE4_CXXFLAGS=$(STAGE4_CXXFLAGS)" \ > + "STAGE4_GDCFLAGS=$(STAGE4_GDCFLAGS)" \ > "STAGE4_GENERATOR_CFLAGS=$(STAGE4_GENERATOR_CFLAGS)" \ > "STAGE4_TFLAGS=$(STAGE4_TFLAGS)" \ > "STAGEprofile_CFLAGS=$(STAGEprofile_CFLAGS)" \ > "STAGEprofile_CXXFLAGS=$(STAGEprofile_CXXFLAGS)" \ > + "STAGEprofile_GDCFLAGS=$(STAGEprofile_GDCFLAGS)" \ > "STAGEprofile_GENERATOR_CFLAGS=$(STAGEprofile_GENERATOR_CFLAGS)" \ > "STAGEprofile_TFLAGS=$(STAGEprofile_TFLAGS)" \ > "STAGEtrain_CFLAGS=$(STAGEtrain_CFLAGS)" \ > "STAGEtrain_CXXFLAGS=$(STAGEtrain_CXXFLAGS)" \ > + "STAGEtrain_GDCFLAGS=$(STAGEtrain_GDCFLAGS)" \ > "STAGEtrain_GENERATOR_CFLAGS=$(STAGEtrain_GENERATOR_CFLAGS)" \ > "STAGEtrain_TFLAGS=$(STAGEtrain_TFLAGS)" \ > "STAGEfeedback_CFLAGS=$(STAGEfeedback_CFLAGS)" \ > "STAGEfeedback_CXXFLAGS=$(STAGEfeedback_CXXFLAGS)" \ > + "STAGEfeedback_GDCFLAGS=$(STAGEfeedback_GDCFLAGS)" \ > "STAGEfeedback_GENERATOR_CFLAGS=$(STAGEfeedback_GENERATOR_CFLAGS)" \ > "STAGEfeedback_TFLAGS=$(STAGEfeedback_TFLAGS)" \ > "STAGEautoprofile_CFLAGS=$(STAGEautoprofile_CFLAGS)" \ > "STAGEautoprofile_CXXFLAGS=$(STAGEautoprofile_CXXFLAGS)" \ > + "STAGEautoprofile_GDCFLAGS=$(STAGEautoprofile_GDCFLAGS)" \ > > "STAGEautoprofile_GENERATOR_CFLAGS=$(STAGEautoprofile_GENERATOR_CFLAGS)" \ > "STAGEautoprofile_TFLAGS=$(STAGEautoprofile_TFLAGS)" \ > "STAGEautofeedback_CFLAGS=$(STAGEautofeedback_CFLAGS)" \ > "STAGEautofeedback_CXXFLAGS=$(STAGEautofeedback_CXXFLAGS)" \ > + "STAGEautofeedback_GDCFLAGS=$(STAGEautofeedback_GDCFLAGS)" \ > > "STAGEautofeedback_GENERATOR_CFLAGS=$(STAGEautofeedback_GENERATOR_CFLAGS)" \ > "STAGEautofeedback_TFLAGS=$
[PATCH 0/4] testsuite: filename/location fixes
These weren't being run before because of the wrong filename or location.
Pushed the lot as obvious.
Sam James (4):
testsuite: g++.dg: fix PR112938 filename
testsuite: tree-ssa: fix PR98265 filename
testsuite: g++.dg: vect: fix PR37143 filename
testsuite: tree-ssa: fix PR98265 test to use C++14
.../{strub-internal-pr112938.cc => strub-internal-pr112938.C} | 0
gcc/testsuite/{gcc.dg => g++.dg}/tree-ssa/pr98265.C | 4 ++--
gcc/testsuite/g++.dg/vect/{pr37143.C => pr37143.cc} | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename gcc/testsuite/g++.dg/{strub-internal-pr112938.cc =>
strub-internal-pr112938.C} (100%)
rename gcc/testsuite/{gcc.dg => g++.dg}/tree-ssa/pr98265.C (99%)
rename gcc/testsuite/g++.dg/vect/{pr37143.C => pr37143.cc} (100%)
base-commit: dc9ca4b2701f91b1efb82ea605f0ec7254e80974
--
2.49.0
[PATCH 4/4] testsuite: tree-ssa: fix PR98265 test to use C++14
This test was previously not being run at all so this wasn't noticed
until my fix just now.
The test needs C++14 and it also should use scan-tree-dump, not
scan-tree-dump-times, as it wasn't passing a count parameter.
gcc/testsuite/ChangeLog:
PR ipa/98265
* g++.dg/tree-ssa/pr98265.C: Use -std=c++14.
Use scan-tree-dump instead of scan-tree-dump-times.
---
gcc/testsuite/g++.dg/tree-ssa/pr98265.C | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr98265.C
b/gcc/testsuite/g++.dg/tree-ssa/pr98265.C
index 9c798e6c59de..d4872d6af206 100644
--- a/gcc/testsuite/g++.dg/tree-ssa/pr98265.C
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr98265.C
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-options "-O2 -std=c++14 -fdump-tree-optimized" } */
extern void __assert_fail(const char*, const char*, int, const char*);
namespace Eigen {
enum { AutoAlign };
@@ -345,4 +345,4 @@ Eigen::Matrix should_inline(float x, float y,
float z,
// We should inline everything to should_inline
-/* { dg-final { scan-tree-dump-times "Function" "optimized" } } */
+/* { dg-final { scan-tree-dump "Function" "optimized" } } */
--
2.49.0
[PATCH 1/4] testsuite: g++.dg: fix PR112938 filename
The test was being ignored because dg.exp looks for .C in g++.dg/.
gcc/testsuite/ChangeLog:
PR middle-end/112938
* g++.dg/strub-internal-pr112938.cc: Move to...
* g++.dg/strub-internal-pr112938.C: ...here.
---
.../{strub-internal-pr112938.cc => strub-internal-pr112938.C} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename gcc/testsuite/g++.dg/{strub-internal-pr112938.cc =>
strub-internal-pr112938.C} (100%)
diff --git a/gcc/testsuite/g++.dg/strub-internal-pr112938.cc
b/gcc/testsuite/g++.dg/strub-internal-pr112938.C
similarity index 100%
rename from gcc/testsuite/g++.dg/strub-internal-pr112938.cc
rename to gcc/testsuite/g++.dg/strub-internal-pr112938.C
--
2.49.0
Re: [PATCH] testsuite: Fix up musttail2.C test
> You're right (although I don't remember which targets are > non-external_musttail). Several flavors of ARM and Power at least.
Re: [PATCH 10/12] testsuite, powerpc: fix broken dg directives
On 3/26/25 1:34 PM, David Malcolm wrote:
> Found by dg-lint.
>
> gcc/testsuite/ChangeLog:
> * gcc.target/powerpc/pr70243.c: Fix missing trailing " }" in
> dg-do directive.
> * gcc.target/powerpc/pr91903.c: Likewise.
> ---
> gcc/testsuite/gcc.target/powerpc/pr70243.c | 2 +-
> gcc/testsuite/gcc.target/powerpc/pr91903.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr70243.c
> b/gcc/testsuite/gcc.target/powerpc/pr70243.c
> index 11525186ef05..512c199e88b1 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr70243.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr70243.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile */
> +/* { dg-do compile } */
> /* { dg-options "-O2 -mvsx" } */
> /* { dg-require-effective-target powerpc_vsx } */
>
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr91903.c
> b/gcc/testsuite/gcc.target/powerpc/pr91903.c
> index d70a0c664693..b147d0e4dfe0 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr91903.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr91903.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile */
> +/* { dg-do compile } */
> /* { dg-options "-mdejagnu-cpu=power8 -mvsx" } */
> /* { dg-require-effective-target powerpc_vsx } */
>
I consider these obvious, so you should just push them.
Peter
Re: [PATCH 01/12] contrib: add dg-lint and libgdiagnostics.py [PR116163]
On Wed, 2025-03-26 at 19:59 +0100, Jakub Jelinek wrote:
> On Wed, Mar 26, 2025 at 02:34:43PM -0400, David Malcolm wrote:
>
> Thanks for working on this.
> My python is very limited, so just adding some comments rather
> than doing patch review.
>
> > +COMMON_MISSPELLINGS = {('dg_final', 'dg-final')}
>
> Does that catch just dg_final and not say dg_do or dg_error
> or dg-output_file ?
Unfortunately only the ones I spelled out.
> I'd think a common misspelling would be any replacement of - with
> _ (maybe also omitting the - altogether).
Maybe a generalization of the regexp to dg[-_][-_a-z]+ or similar, and
then report things that match the "with underscores" regexp but not the
"without underscores" regexp.
> And I think Sam fixed
> some dg-compile or dg-run misspellings of dg-do compile or dg-do run.
>
> Does it have a list of valid dg-* directives and diagnose if it
> sees dg-invalid-directive?
It doesn't; that's a good idea.
Dave
RE: [PATCH][RFC] [cobol] change cbl_field_data_t::etc_t::value from _Float128 to tree
> -Original Message- > From: Richard Biener > Sent: Friday, March 21, 2025 03:48 > To: Robert Dubner > Cc: Jakub Jelinek ; gcc-patches@gcc.gnu.org > Subject: RE: [PATCH][RFC] [cobol] change cbl_field_data_t::etc_t::value > from _Float128 to tree > > On Thu, 20 Mar 2025, Robert Dubner wrote: > > > Okay, I managed to figure out a way of getting the debug information > back > > into the libgcobol. > > > > The addition is done by the routine __gg__add_fixed_phase1() > > > > The run-tiome inputs to that routine should be 1 and 555. > > > > What's coming through in the patched code are 1 and 554 > > > > I haven't looked at the compile-time code yet. But I have a nickel that > > says somebody is converting "555." to floating-point, and > getting > > an internal value of 555.5554999, and that's getting > truncated > > to the internal value of 554 > > > > I haven't checked for sure, but I suppose I've been counting on the > > strfromf128 routines to round sensibly. I guess if mpfr can handle that > > kind of thing, then we should switch to mpfr. I am not that familiar > with > > mpfr. > > Note I have not consistently used real_value_truncate to the target > float128 format - I was debating on whether ->value should be > aribitrary precision or not. Some real_* functions can take VOIDmode > (no format, whatever that does exactly), but to build a 'tree' we > have to use a type (and I've not consistently performed rounding > or truncation to the format there). > > Now a question on COBOL: > > 77 var8 PIC 999V9(8) COMP-5 > > what precision/digits does this specify? When then doing > > add 0.0001 TO var555 giving var8 rounded > > what's the precision/digit specification for the literal floating > point values and how does that or that of var555 or var8 > "promote" or "demote" to a common specification for the arithmetic > operation? > > Does the COBOL standard expect a literal floating point value to > be represented exactly? Maybe rounding then only applies at the > "giving var8 rounded" point, forcing the exact value to the > specification of var8? > I neglected to address this in Part 1 of my response. Yes, the ROUNDED phrase of the ADD statement specifies that the result of the operation gets ROUNDED to whatever VAR555 precision VAR555 has. The meaning of ROUNDED is as described below from my earlier message. That's handled by assignment logic, found elsewhere, and has nothing to do with the issues of the front end creating literals and establishing initial values of variables, which is what all these messages are dealing with. > Richard. > > > > -Original Message- > > > From: Robert Dubner > > > Sent: Thursday, March 20, 2025 17:50 > > > To: Jakub Jelinek > > > Cc: Richard Biener ; gcc-patches@gcc.gnu.org > > > Subject: RE: [PATCH][RFC] [cobol] change > cbl_field_data_t::etc_t::value > > > from _Float128 to tree > > > > > > It's time to slow down a bit and give me a chance to catch up. > > > > > > First, all those tests are not arbitrary. I was getting the correct > > > answers before, and it was not an insignificant effort to get them > > correct > > > in the first place. > > > > > > If we don't get the same answers, then something isn't the same as it > > was > > > before. > > > > > > I need to know what. > > > > > > First-prime: > > > > > > Also, keep in mind that this is COBOL, where words don't mean what you > > > think they mean. Under Rounding, we have > > > > > > The following forms of rounding are provided (examples presume an > > integer > > > destination): > > > > > > -AWAY-FROM-ZERO: Rounding is to the nearest value farther from zero. > > > > > > -NEAREST-AWAY-FROM-ZERO: Rounding is to the nearest value. If two > values > > > are equally near, the value farther from zero is selected. This mode > has > > > historically been associated with the ROUNDED clause in earlier > versions > > > of standard COBOL. > > > > > > -NEAREST-EVEN: Rounding is to the nearest value. If two values are > > equally > > > near, the value whose rightmost digit is even is selected. This mode > is > > > sometimes called "Banker's rounding". > > > > > > -NEAREST-TOWARD-ZERO: Rounding is to the nearest value. If two values > > are > > > equally near, the value nearer to zero is selected. > > > > > > -PROHIBITED: No rounding is performed. If the value cannot be > > represented > > > exactly in the desired format, the EC-SIZE-TRUNCATION condition is set > > to > > > exist and the results of the operation are undefined. > > > > > > -TOWARD-GREATER: Rounding is toward the nearest value whose algebraic > > > value is larger. > > > > > > -TOWARD-LESSER: Rounding is toward the nearest value whose algebraic > > value > > > is smaller. > > > > > > -TRUNCATION: Rounding is to the nearest value that is nearer to zero > > than > > > the algebraic value. This mode has historically been associated with > the > > > absence of the ROUNDED clause
[PATCH] testsuite: fixup tree scan syntax for strub-internal-pr112938.C
This wasn't being run before my r15-8949-g6b21f7969241cf so went unnoticed.
Match [0-9+] instead of [0-9][0-9] and escape the parentheses around 'D'.
gcc/testsuite/ChangeLog:
PR testsuite/119489
* g++.dg/strub-internal-pr112938.C: Adjust pattern.
---
Pushed as obvious.
gcc/testsuite/g++.dg/strub-internal-pr112938.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/g++.dg/strub-internal-pr112938.C
b/gcc/testsuite/g++.dg/strub-internal-pr112938.C
index 5a74becc2697..933a4fbdecf7 100644
--- a/gcc/testsuite/g++.dg/strub-internal-pr112938.C
+++ b/gcc/testsuite/g++.dg/strub-internal-pr112938.C
@@ -9,4 +9,4 @@ f(bool i, volatile bool j)
}
/* Check for two dereferences of the indirected volatile j parm. */
-/* { dg-final { scan-tree-dump-times {={v} \*j_[0-9][0-9]*(D)} 2 "optimized" }
} */
+/* { dg-final { scan-tree-dump-times {={v} \*j_[0-9+]\(D\)} 2 "optimized" } }
*/
--
2.49.0
[PATCH 01/12] contrib: add dg-lint and libgdiagnostics.py [PR116163]
This patch adds a new dg-lint subdirectory below contrib, containing
a "dg-lint" script for detecting common mistakes made in our DejaGnu
tests.
Specifically, DejaGnu's dg.exp's dg-get-options has a regexp for
detecting dg- directives
https://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=blob;f=lib/dg.exp
here's the current:
set tmp [grep $prog "{\[ \t\]\+dg-\[-a-z\]\+\[ \t\]\+.*\[ \t\]\+}" line]
which if I'm reading it right requires a "{", then one or more tab/space
chars, then a "dg-" directive name, then one of more tab/space
characters, then anything (for arguments to the directive), then one of
more tab/space character, then a "}".
There are numerous places in our testsuite which look like attempts to
use a directive, but which don't match this regexp.
The script warns about such places, along with a list of misspelled
directives (currently just "dg_options" for "dg-options"), and a warning
if a dg-do appears after a dg-require-* (as per
https://gcc.gnu.org/onlinedocs/gccint/Directives.html
"This directive must appear after any dg-do directive in the test
and before any dg-additional-sources directive." for
dg-require-effective-target.
dg-lint uses libgdiagnostics to report its results; the patch adds a
new libgdiagnostics.py script below contrib/dg-lint. This uses Python's
ctypes module to expose libgdianostics.so to Python via FFI. Hence
the warnings have colorization, quote the pertinent parts of the tested
file, can have fix-it hints, etc. Here's the output from the tests, run
from the top-level directory:
$ LD_LIBRARY_PATH=../build/gcc/ ./contrib/dg-lint/dg-lint
contrib/dg-lint/test-*.c
contrib/dg-lint/test-1.c:6:6: warning: misspelled directive: 'dg_final'; did
you mean 'dg-final'?
6 | /* { dg_final { scan_assembler_times "vmsumudm" 2 } } */
| ^~~~
| dg-final
contrib/dg-lint/test-1.c:15:4: warning: directive 'dg-output-file' appears not
to match dg.exp's regexp
15 |dg-output-file "m4.out"
|^~
contrib/dg-lint/test-1.c:18:4: warning: directive 'dg-output-file' appears not
to match dg.exp's regexp
18 |dg-output-file "m4.out" }
|^~
contrib/dg-lint/test-1.c:21:6: warning: directive 'dg-output-file' appears not
to match dg.exp's regexp
21 |{ dg-output-file "m4.out"
| ^~
contrib/dg-lint/test-1.c:24:5: warning: directive 'dg-output-file' appears not
to match dg.exp's regexp
24 |{dg-output-file "m4.out"}
| ^~
contrib/dg-lint/test-1.c:27:6: warning: directive 'dg-output-file' appears not
to match dg.exp's regexp
27 |{ dg-output-file, "m4.out" }
| ^~
contrib/dg-lint/test-2.c:4:6: warning: 'dg-do' after
'dg-require-effective-target'
4 | /* { dg-do compile } */
| ^
contrib/dg-lint/test-2.c:3:6: note: 'dg-require-effective-target' was here
3 | /* { dg-require-effective-target c++11 } */
| ^~~
I don't yet have a way to verify these tests (clearly we can't use
DejaGnu for this).
These Python bindings could be used by other projects, but so far I only
implemented what I needed for dg-lint.
Running the test on the GCC source tree finds dozens of issues, which
followup patches address.
Tested with Python 3.8
contrib/ChangeLog:
PR testsuite/116163
* dg-lint/dg-lint: New file.
* dg-lint/libgdiagnostics.py: New file.
* dg-lint/test-1.c: New file.
* dg-lint/test-2.c: New file.
---
contrib/dg-lint/dg-lint| 210
contrib/dg-lint/libgdiagnostics.py | 248 +
contrib/dg-lint/test-1.c | 28
contrib/dg-lint/test-2.c | 8 +
4 files changed, 494 insertions(+)
create mode 100755 contrib/dg-lint/dg-lint
create mode 100644 contrib/dg-lint/libgdiagnostics.py
create mode 100644 contrib/dg-lint/test-1.c
create mode 100644 contrib/dg-lint/test-2.c
diff --git a/contrib/dg-lint/dg-lint b/contrib/dg-lint/dg-lint
new file mode 100755
index ..20157c304137
--- /dev/null
+++ b/contrib/dg-lint/dg-lint
@@ -0,0 +1,210 @@
+#!/usr/bin/env python3
+
+# Script to detect common mistakes in DejaGnu tests.
+
+# Contributed by David Malcolm
+#
+# Copyright (C) 2024-2025 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING. If not, write to
+# the Free Software F
[PATCH 06/12] testsuite, arm: fix broken dg directives
Found by dg-lint.
gcc/testsuite/ChangeLog:
* gcc.target/arm/cmse/cmse-17.c: Fix missing space before trailing
"}" in dg-options.
* gcc.target/arm/short-vfp-1.c: Likewise for dg-final; also after
leading "{", in 5 places.
---
gcc/testsuite/gcc.target/arm/cmse/cmse-17.c | 2 +-
gcc/testsuite/gcc.target/arm/short-vfp-1.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-17.c
b/gcc/testsuite/gcc.target/arm/cmse/cmse-17.c
index a2cce09afae5..c5be8101f56a 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/cmse-17.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-17.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-mcmse"} */
+/* { dg-options "-mcmse" } */
#include
diff --git a/gcc/testsuite/gcc.target/arm/short-vfp-1.c
b/gcc/testsuite/gcc.target/arm/short-vfp-1.c
index 3ca1ffc00173..18d38a580377 100644
--- a/gcc/testsuite/gcc.target/arm/short-vfp-1.c
+++ b/gcc/testsuite/gcc.target/arm/short-vfp-1.c
@@ -38,8 +38,8 @@ test_sihi (short x)
return (int)x;
}
-/* {dg-final { scan-assembler-times {vcvt\.s32\.f32\ts[0-9]+,s[0-9]+} 2 }} */
-/* {dg-final { scan-assembler-times {vcvt\.f32\.s32\ts[0-9]+,s[0-9]+} 2 }} */
-/* {dg-final { scan-assembler-times {vmov\tr[0-9]+,s[0-9]+} 2 }} */
-/* {dg-final { scan-assembler-times {vmov\ts[0-9]+,r[0-9]+} 2 }} */
-/* {dg-final { scan-assembler-times {sxth\tr[0-9]+,r[0-9]+} 2 }} */
+/* { dg-final { scan-assembler-times {vcvt\.s32\.f32\ts[0-9]+,s[0-9]+} 2 } } */
+/* { dg-final { scan-assembler-times {vcvt\.f32\.s32\ts[0-9]+,s[0-9]+} 2 } } */
+/* { dg-final { scan-assembler-times {vmov\tr[0-9]+,s[0-9]+} 2 } } */
+/* { dg-final { scan-assembler-times {vmov\ts[0-9]+,r[0-9]+} 2 } } */
+/* { dg-final { scan-assembler-times {sxth\tr[0-9]+,r[0-9]+} 2 } } */
--
2.26.3
[PATCH 11/12] testsuite, riscv: fix broken dg directives
Found by dg-lint.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/cmo-zicbop-1.c: Fix missing space before
trailing } in dg-do directive.
* gcc.target/riscv/cmo-zicbop-2.c: Likewise.
* gcc.target/riscv/prefetch-zicbop.c: Likewise.
* gcc.target/riscv/prefetch-zihintntl.c: Likewise.
* gcc.target/riscv/rvv/autovec/vls-vlmax/merge-4.c: Fix missing
braces around dg-final directive.
* gcc.target/riscv/rvv/autovec/vls/merge-4.c: Likewise.
---
gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c | 2 +-
gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c | 2 +-
gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c | 2 +-
gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c| 2 +-
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/merge-4.c | 2 +-
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/merge-4.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c
b/gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c
index 97181154d85b..e40874fc3df9 100644
--- a/gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c
+++ b/gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c
@@ -1,4 +1,4 @@
-/* { dg-do compile target { { rv64-*-*}}} */
+/* { dg-do compile target { { rv64-*-*}} } */
/* { dg-options "-march=rv64gc_zicbop -mabi=lp64" } */
void foo (char *p)
diff --git a/gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c
b/gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c
index 4871a97b21aa..dd6e1eafd44a 100644
--- a/gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c
+++ b/gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c
@@ -1,4 +1,4 @@
-/* { dg-do compile target { { rv32-*-*}}} */
+/* { dg-do compile target { { rv32-*-*}} } */
/* { dg-options "-march=rv32gc_zicbop -mabi=ilp32" } */
void foo (char *p)
diff --git a/gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c
b/gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c
index 0faa120f1f79..250f9ec6b0a8 100644
--- a/gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c
+++ b/gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c
@@ -1,4 +1,4 @@
-/* { dg-do compile target { { rv64-*-*}}} */
+/* { dg-do compile target { { rv64-*-*}} } */
/* { dg-options "-march=rv64gc_zicbop -mabi=lp64" } */
void foo (char *p)
diff --git a/gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c
b/gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c
index 78a3afe68333..54e809f43535 100644
--- a/gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c
+++ b/gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c
@@ -1,4 +1,4 @@
-/* { dg-do compile target { { rv64-*-*}}} */
+/* { dg-do compile target { { rv64-*-*}} } */
/* { dg-options "-march=rv64gc_zicbop_zihintntl -mabi=lp64" } */
void foo (char *p)
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/merge-4.c
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/merge-4.c
index 3095a6df1890..02543fc81a7b 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/merge-4.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/merge-4.c
@@ -119,4 +119,4 @@ merge10 (vnx16df x, vnx16df y, vnx16df *out)
*(vnx16df*)out = v;
}
-/* dg-final scan-assembler-times {\tvmerge.vvm} 11 */
+/* { dg-final scan-assembler-times {\tvmerge.vvm} 11 } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/merge-4.c
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/merge-4.c
index 1dfd8287b7f2..4ae341a091e8 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/merge-4.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/merge-4.c
@@ -3,6 +3,6 @@
#include "../vls-vlmax/merge-4.c"
-/* dg-final scan-assembler-times {\tvmerge.vvm} 11 */
+/* { dg-final { scan-assembler-times {\tvmerge.vvm} 11 } } */
/* { dg-final { scan-assembler-not {\tvms} } } */
/* { dg-final { scan-assembler-times {\tvlm.v} 11 } } */
--
2.26.3
Re: [Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.
Hi Jerry,
thanks for the review and the kind words. Committed as gcc-15-8481-g0f344846a62
Thanks again,
Andre
On Thu, 20 Mar 2025 11:42:35 -0700
Jerry D wrote:
> On 3/20/25 9:20 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > attached patch fixes a 15-regression where an element of an actual
> > temporary array, i.e., elemental([ e1, e2...]) passed to the formal
> > polymorphic dummy leads to a double free of the derived types components.
> > This patch prevents this by preventing the deallocation of the array
> > constructors temporary, when the formal is polymorphic. ...
> >
> > Folks its so hard to explain this in prose. I rewrote above paragraph the
> > third time now. And I still don't understand on re-reading. So here is some
> > pseudo code:
> >
> > struct derived {
> >char *c; // This is the component suffering from double-free
> > };
> >
> > derived[2] atmp = [ derived(""), derived("")]
> >
> > forall a in atmp
> >derived t_a = a; // <- Copy of a, but no deep copy, i.e. t_a.c == a.c
> >class_temp = class_derived(a); // set _vtype left out for brevity
> >call elemental_function(class_temp);
> >if (class_temp._data.c != NULL)
> > free(class_temp._data.c); // and set it to NULL
> >if (t_a.c != NULL)
> > free(t_a.c); // BOOM, this is freeing the same c
> > end
> >
> > Generating the last if-block and the free is what this patch prevents for
> > polymorphic dummys that stem from an array construction. And only for those.
> >
> > Sorry, I am having a hard time explaining things today. So I hope the code
> > above will do.
> >
> > Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
>
> OK and thanks for the fix. Your prose is fine and your comment in the
> code suffices.
>
> Thanks for the patch.
>
> Jerry
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
[committed] d: import __stdin causes compilation to pause while reading from stdin
Hi,
This patch merges the D front-end with upstream dmd 02a64d2e13.
Moves the special handling of reading from stdin out of the language
semantic routines. All references to `__stdin.d` have also been removed
from the front-end implementation.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32, and
committed to mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* dmd/MERGE: Merge upstream dmd 02a64d2e13.
---
gcc/d/dmd/MERGE | 2 +-
gcc/d/dmd/dmodule.d | 8 ---
gcc/d/dmd/file_manager.d | 55 ++-
gcc/d/dmd/globals.d | 1 +
gcc/d/dmd/globals.h | 1 +
.../gdc.test/fail_compilation/fail21045.d | 12
6 files changed, 20 insertions(+), 59 deletions(-)
create mode 100644 gcc/testsuite/gdc.test/fail_compilation/fail21045.d
diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index 116074932ae..08b4e78aba5 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-032e24446b3d8c6cfe3043d62534d5ce6d004c34
+02a64d2e1359119b91d2b932e61ed712f272507a
The first line of this file holds the git revision number of the last
merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/dmodule.d b/gcc/d/dmd/dmodule.d
index 6c7416856a1..1d14c085d3d 100644
--- a/gcc/d/dmd/dmodule.d
+++ b/gcc/d/dmd/dmodule.d
@@ -58,12 +58,10 @@ import dmd.visitor;
version (Windows)
{
-import core.sys.windows.winbase : getpid = GetCurrentProcessId;
enum PathSeparator = '\\';
}
else version (Posix)
{
-import core.sys.posix.unistd : getpid;
enum PathSeparator = '/';
}
else
@@ -577,12 +575,6 @@ extern (C++) final class Module : Package
else
{
const(char)[] argdoc;
-OutBuffer buf;
-if (arg == "__stdin.d")
-{
-buf.printf("__stdin_%d.d", getpid());
-arg = buf[];
-}
if (global.params.preservePaths)
argdoc = arg;
else
diff --git a/gcc/d/dmd/file_manager.d b/gcc/d/dmd/file_manager.d
index fc7824f0390..8a6ec998e69 100644
--- a/gcc/d/dmd/file_manager.d
+++ b/gcc/d/dmd/file_manager.d
@@ -16,7 +16,6 @@ import dmd.root.stringtable : StringTable;
import dmd.root.file : File, Buffer;
import dmd.root.filename : FileName, isDirSeparator;
import dmd.root.string : toDString;
-import dmd.errors;
import dmd.globals;
import dmd.identifier;
import dmd.location;
@@ -184,9 +183,6 @@ nothrow:
scope(exit) FileName.free(sdi.ptr);
const sd = FileName.forceExt(filename, mars_ext);
-// Special file name representing `stdin`, always assume its presence
-if (sd == "__stdin.d")
-return sd;
if (checkLocal && FileName.exists(sd) == 1)
return sd;
scope(exit) FileName.free(sd.ptr);
@@ -312,20 +308,12 @@ nothrow:
if (auto val = files.lookup(name)) // if `name` is cached
return val.value; // return its contents
-OutBuffer buf;
-if (name == "__stdin.d")// special name for reading
from stdin
-{
-if (readFromStdin(buf))
-fatal();
-}
-else
-{
-if (FileName.exists(name) != 1) // if not an ordinary file
-return null;
+if (FileName.exists(name) != 1) // if not an ordinary file
+return null;
-if (File.read(name, buf))
-return null;// failed
-}
+OutBuffer buf;
+if (File.read(name, buf))
+return null;// failed
buf.write32(0); // terminating dchar 0
@@ -351,36 +339,3 @@ nothrow:
return val == null ? null : val.value;
}
}
-
-private bool readFromStdin(ref OutBuffer sink) nothrow
-{
-import core.stdc.stdio;
-import dmd.errors;
-
-enum BufIncrement = 128 * 1024;
-
-for (size_t j; 1; ++j)
-{
-char[] buffer = sink.allocate(BufIncrement);
-
-// Fill up buffer
-size_t filled = 0;
-do
-{
-filled += fread(buffer.ptr + filled, 1, buffer.length - filled,
stdin);
-if (ferror(stdin))
-{
-import core.stdc.errno;
-error(Loc.initial, "cannot read from stdin, errno = %d",
errno);
-return true;
-}
-if (feof(stdin)) // successful completion
-{
-sink.setsize(j * BufIncrement + filled);
-return false;
-}
-} while (filled < BufIncrement);
-}
-
-assert(0);
-}
diff --git a/gcc/d/dmd/globals.d b/gcc/d/dmd/globals.d
index 900c554e5f4..132683e624a 100644
--- a/gcc/d/dmd/globals.d
+++ b/gcc/d/dmd/globals.d
@@ -160,6 +160,7 @@ extern (C++) struct ImportPathInfo {
extern (C++) struct Param
{
bool obj = true;// write object file
+
RE: [PATCH] cobol, v2: Get rid of __int128 uses in the COBOL FE [PR119242]
> -Original Message- > From: Jakub Jelinek > Sent: Wednesday, March 26, 2025 13:28 > To: Robert Dubner > Cc: James K. Lowden ; Richard Biener > ; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] cobol, v2: Get rid of __int128 uses in the COBOL FE > [PR119242] > > On Wed, Mar 26, 2025 at 10:21:31AM -0500, Robert Dubner wrote: > > > Here is a fixed patch, passes make check-cobol, but that is > unfortunately > > > still not enough. > > > > With this second fixed patch, all of our tests pass. > > Great. > > Is the patch ok for trunk then, or do you plan to review it or will > James do that? That's all "my" code, as opposed to "Jim's" code. Go ahead and push it. > > > Implicit criticism about tests accepted. I have 679 UAT tests, and now > > I've got the bit in my teeth, and I am creating a process that will > > convert as many as I can to DejaGnu. However: the autom4te and DejaGnu > > principles, practices, and philosophies are almost, but not quite, > > completely unlike each other. > > Didn't mean to criticize in any way, just mention that because we have > just 23 tests so far, the UAT/NIST testing you are doing is a precondition > for any non-trivial FE changes and that testing wasn't done on my side. > > Jakub Jakub, I just spoke with Jim. I am developing a deeper understanding of why the industry average for coding is what, ten lines a day? I write five lines of Python. During that time, fourteen patches come in; I get a phone call from Jim about changing the design of the front end because of what we're learning, and my boss calls because somehow the company website got trashed and I need to rebuild and upload all of the packages we make available on that site because they are now at one with the snows of yesteryear. I don't feel criticized. I feel harried!
Re: [PATCH 01/12] contrib: add dg-lint and libgdiagnostics.py [PR116163]
On Wed, Mar 26, 2025 at 02:34:43PM -0400, David Malcolm wrote:
Thanks for working on this.
My python is very limited, so just adding some comments rather
than doing patch review.
> +COMMON_MISSPELLINGS = {('dg_final', 'dg-final')}
Does that catch just dg_final and not say dg_do or dg_error
or dg-output_file ?
I'd think a common misspelling would be any replacement of - with
_ (maybe also omitting the - altogether). And I think Sam fixed
some dg-compile or dg-run misspellings of dg-do compile or dg-do run.
Does it have a list of valid dg-* directives and diagnose if it
sees dg-invalid-directive?
Jakub
[PATCH 5/7] Doc: Organize atomic memory builtins documentation [PR42270]
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
This installment adds a container section to hold documentation for
both the _atomic and _sync builtins, reordering them so that the new
_atomic interface is presented before the legacy _sync one. I also
incorporated material from the separate x86 transactional memory
section directly into the __atomic builtins documentation instead of
retaining that as a parallel section.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Atomic Memory Access): New section.
(__sync Builtins): Make it a subsection of the above.
(Atomic Memory Access): Likewise.
(x86 specific memory model extensions for transactional memory):
Delete this section, incorporating the text into the discussion
of __atomic builtins.
---
gcc/doc/extend.texi | 371 +++-
1 file changed, 196 insertions(+), 175 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 68f9398590f..de9c2b36ba3 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -14243,11 +14243,9 @@ a function call results in a compile-time error.
* Return Address:: Getting the return or frame address of a function.
* Stack Scrubbing:: Stack scrubbing internal interfaces.
* Vector Extensions:: Using vector instructions through built-in functions.
-* __sync Builtins:: Legacy built-in functions for atomic memory access.
-* __atomic Builtins:: Atomic built-in functions with memory model.
+* Atomic Memory Access:: __atomic and __sync builtins.
* Integer Overflow Builtins:: Built-in functions to perform arithmetics and
arithmetic overflow checking.
-* x86 specific memory model extensions for transactional memory:: x86 memory
models.
* Object Size Checking:: Built-in functions for limited buffer overflow
checking.
* New/Delete Builtins:: Built-in functions for C++ allocations and
deallocations.
@@ -16175,149 +16173,27 @@ x = foo ((v128) @{_mm_adds_epu8 (x.mm, y.mm)@});
@c but GCC does not accept it for unions of vector types (PR 88955).
@end smallexample
-@node __sync Builtins
-@section Legacy @code{__sync} Built-in Functions for Atomic Memory Access
+@node Atomic Memory Access
+@section Builtins for Atomic Memory Access
+@cindex atomic memory access builtins
+@cindex builtins for atomic memory access
-The following built-in functions
-are intended to be compatible with those described
-in the @cite{Intel Itanium Processor-specific Application Binary Interface},
-section 7.4. As such, they depart from normal GCC practice by not using
-the @samp{__builtin_} prefix and also by being overloaded so that they
-work on multiple types.
+GCC supports two sets of builtins for atomic memory access primitives. The
+@code{__atomic} builtins provide the underlying support for the C++11
+atomic operations library, and are the currently-recommended interface when
+the C++11 library functions cannot be used directly.
+The @code{__sync} builtins implement the specification from the Intel IA64
+pSABI and are supported primarily for use in legacy code.
-The definition given in the Intel documentation allows only for the use of
-the types @code{int}, @code{long}, @code{long long} or their unsigned
-counterparts. GCC allows any scalar type that is 1, 2, 4 or 8 bytes in
-size other than the C type @code{_Bool} or the C++ type @code{bool}.
-Operations on pointer arguments are performed as if the operands were
-of the @code{uintptr_t} type. That is, they are not scaled by the size
-of the type to which the pointer points.
-
-These functions are implemented in terms of the @samp{__atomic}
-builtins (@pxref{__atomic Builtins}). They should not be used for new
-code which should use the @samp{__atomic} builtins instead.
-
-Not all operations are supported by all target processors. If a particular
-operation cannot be implemented on the target processor, a call to an
-external function is generated. The external function carries the same name
-as the built-in version, with an additional suffix
-@samp{_@var{n}} where @var{n} is the size of the data type.
-
-In most cases, these built-in functions are considered a @dfn{full barrier}.
-That is,
-no memory operand is moved across the operation, either forward or
-backward. Further, instructions are issued as necessary to prevent the
-processor from speculating loads across the operation and from queuing stores
-after the operation.
-
-All of the routines are described in the Intel documentation to take
-``an optional list of variables protected by the memory barrier''. It's
-not clear what is meant by that; it could mean that @emph{only} the
-listed variables are protected, or it could mean a list of additional
-variables to be protected. The list is ignored by GCC which treats it as
-empty. GCC interprets an empty list as me
[PATCH] Fortran: fix bogus recursion with DT default initialization [PR118796]
Dear all,
it seems that my patch for default-initialization of function results
of derived type could trigger a weird issue if a type-bound function
of a type that is use-associated from a different module had the
same name, even if the declared function had a different type, but
only if the result clause is present.
While I had hoped that resolution should not lead to this situation,
checking whether the function was use-associated solved the issue.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 0cfeedf5865cd781478b4652477009ca05f4de77 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 26 Mar 2025 22:04:39 +0100
Subject: [PATCH] Fortran: fix bogus recursion with DT default initialization
[PR118796]
PR fortran/118796
gcc/fortran/ChangeLog:
* resolve.cc: Do not apply default initialization to a derived-type
function result if the resolved function is use-associated.
gcc/testsuite/ChangeLog:
* gfortran.dg/derived_result_4.f90: New test.
---
gcc/fortran/resolve.cc| 3 +-
.../gfortran.dg/derived_result_4.f90 | 38 +++
2 files changed, 40 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/derived_result_4.f90
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index cf9318ff763..cb3658917ef 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -17946,7 +17946,8 @@ skip_interfaces:
/* Mark the result symbol to be referenced, when it has allocatable
components. */
sym->result->attr.referenced = 1;
- else if (a->function && !a->pointer && !a->allocatable && sym->result)
+ else if (a->function && !a->pointer && !a->allocatable && !a->use_assoc
+ && sym->result)
/* Default initialization for function results. */
apply_default_init (sym->result);
}
diff --git a/gcc/testsuite/gfortran.dg/derived_result_4.f90 b/gcc/testsuite/gfortran.dg/derived_result_4.f90
new file mode 100644
index 000..12ab1909492
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/derived_result_4.f90
@@ -0,0 +1,38 @@
+! { dg-do compile }
+! { dg-additional-options "-Wall -Wno-return-type -Wno-unused-variable" }
+!
+! PR fortran/118796 - bogus recursion with DT default initialization
+
+module m1
+ implicit none
+
+ type :: t1
+ type(integer) :: f1 = 0
+ end type t1
+
+ TYPE :: c1
+ contains
+ procedure, public :: z
+ END TYPE c1
+
+contains
+ ! type-bound procedure z has a default initialization
+ function z( this )
+type(t1) :: z
+class(c1), intent(in) :: this
+ end function z
+end module m1
+
+module m2
+ use m1, only : c1
+contains
+ function z() result(field)
+ end function z
+end module m2
+
+module m3
+ use m1, only : c1
+contains
+ function z()
+ end function z
+end module m3
--
2.43.0
Re: [PATCH 01/12] contrib: add dg-lint and libgdiagnostics.py [PR116163]
On Wed, Mar 26, 2025 at 09:32:30PM +, Sam James wrote: > Right, we can extend it for 'dg-do known-actions' as well. I think that shouldn't be necessary. gcc-dg-test-1 should already complain about unexpected actions. Jakub
[PATCH 4/7] Doc: Break up and rearrange the "other builtins" section [PR42270]
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
The "Other Builtins" section had become a catch-all for all sorts of
things with very little organization or attempt to differentiate between
important information (e.g., GCC treats a gazillion library functions as
builtins by default) from obscure builtins provided primarily as internal
interfaces. I've split it up into various pieces and attempted to move
the more important or useful-to-users documentation earlier in the chapter.
What's left of the section is still a jumbled mess... but at least it's a
smaller jumbled mess.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Built-in Functions): Incorporate some text
formerly in "Other Builtins" into the introduction. Adjust
menu for new sections.
(Library Builtins): New section, split from "Other Builtins".
(Numeric Builtins): Likewise.
(Stack Allocation): Likewise.
(Constructing Calls): Move __builtin_call_with_static_chain here.
(Object Size Checking): Minor copy-editing.
(Other Builtins): Move text to new sections listed above. Delete
duplicate docs for object-size checking builtins.
* doc/invoke.texi (C dialect options): Update @xref for -fno-builtin.
---
gcc/doc/extend.texi | 2614 ++-
gcc/doc/invoke.texi |4 +-
2 files changed, 1333 insertions(+), 1285 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 386b6b0f5b1..68f9398590f 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -14208,19 +14208,36 @@ GNU C++.
GCC provides a very large number of implicitly-declared built-in
functions that are typically inlined by the compiler. Some of these
-builtins directly correspond to standard library routines, while
-others provide the underlying functionality needed to implement
+builtins directly correspond to standard library routines. Some are
+for internal use in the processing of exceptions or variable-length
+argument lists and are not documented here because they may change
+from time to time; we do not recommend general use of these functions.
+
+The remaining functions are provided either for optimization purposes, or
+to expose low-level functionality needed to implement
features provided by library functions or similar ``glue'' between GCC
and other programming languages or libraries. Others are
target-specific, providing direct access to instructions that have no
direct C equivalents without the need to write assembly language. There
are also builtins to support various kinds of runtime error checking.
-Most builtins have names prefixed with @samp{__builtin_}. Except as
-otherwise documented, all built-in functions are available from any
-of the C family languages supported by GCC.
+Most builtins have names prefixed with @samp{__builtin_}, although not
+all of them use this convention. Except as otherwise documented, all
+built-in functions are available from any of the C family languages
+supported by GCC.
+
+With the exception of built-ins that have library equivalents such as
+the standard C library functions discussed below in @ref{Library Builtins},
+or that expand to
+library calls, GCC built-in functions are always expanded inline and
+thus do not have corresponding entry points and their address cannot
+be obtained. Attempting to use them in an expression other than
+a function call results in a compile-time error.
@menu
+* Library Builtins:: Built-in equivalents for C library functions.
+* Numeric Builtins:: Additional builtins for numeric and bit operations.
+* Stack Allocation:: Built-in alloca variants.
* Nonlocal Gotos:: Built-ins for nonlocal gotos.
* Constructing Calls:: Built-ins for dispatching a call to another function.
* Return Address:: Getting the return or frame address of a function.
@@ -14238,6 +14255,1300 @@ of the C family languages supported by GCC.
* Target Builtins:: Built-in functions specific to particular targets.
@end menu
+@node Library Builtins
+@section Builtins for C Library Functions
+@cindex built-in library functions
+@cindex library function builtins
+@cindex C library function builtins
+
+@findex __builtin_iseqsig
+@findex __builtin_isfinite
+@findex __builtin_isnormal
+@findex __builtin_isgreater
+@findex __builtin_isgreaterequal
+@findex __builtin_isunordered
+@findex __builtin_speculation_safe_value
+@findex _Exit
+@findex _exit
+@findex abort
+@findex abs
+@findex acos
+@findex acosf
+@findex acosh
+@findex acoshf
+@findex acoshl
+@findex acosl
+@findex alloca
+@findex asin
+@findex asinf
+@findex asinh
+@findex asinhf
+@findex asinhl
+@findex asinl
+@findex atan
+@findex atan2
+@findex atan2f
+@findex atan2l
+@findex atanf
+@findex atanh
+@findex atanhf
+@findex atanhl
+@findex atanl
+@findex bcmp
+@findex bzero
+@findex cabs
+@findex cabsf
+@f
Re: [PATCH 01/12] contrib: add dg-lint and libgdiagnostics.py [PR116163]
David Malcolm writes:
> On Wed, 2025-03-26 at 19:59 +0100, Jakub Jelinek wrote:
>> On Wed, Mar 26, 2025 at 02:34:43PM -0400, David Malcolm wrote:
>>
>> Thanks for working on this.
>> My python is very limited, so just adding some comments rather
>> than doing patch review.
>>
>> > +COMMON_MISSPELLINGS = {('dg_final', 'dg-final')}
>>
>> Does that catch just dg_final and not say dg_do or dg_error
>> or dg-output_file ?
>
> Unfortunately only the ones I spelled out.
>
>> I'd think a common misspelling would be any replacement of - with
>> _ (maybe also omitting the - altogether).
>
> Maybe a generalization of the regexp to dg[-_][-_a-z]+ or similar, and
> then report things that match the "with underscores" regexp but not the
> "without underscores" regexp.
I don't think we have any valid "user-facing" dg_ directives (there are
some dg_ matches in .exp files though).
May be worth having two tiers here, I guess: known mismatch and also
just suspicious _ even when we can't figure out intent. But not that
important?
>
>
>> And I think Sam fixed
>> some dg-compile or dg-run misspellings of dg-do compile or dg-do run.
>>
>> Does it have a list of valid dg-* directives and diagnose if it
>> sees dg-invalid-directive?
>
> It doesn't; that's a good idea.
Right, we can extend it for 'dg-do known-actions' as well.
>
> Dave
Re: [PATCH 01/12] contrib: add dg-lint and libgdiagnostics.py [PR116163]
David Malcolm writes:
> This patch adds a new dg-lint subdirectory below contrib, containing
> a "dg-lint" script for detecting common mistakes made in our DejaGnu
> tests.
>
> Specifically, DejaGnu's dg.exp's dg-get-options has a regexp for
> detecting dg- directives
> https://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=blob;f=lib/dg.exp
> here's the current:
>
> set tmp [grep $prog "{\[ \t\]\+dg-\[-a-z\]\+\[ \t\]\+.*\[ \t\]\+}" line]
>
> which if I'm reading it right requires a "{", then one or more tab/space
> chars, then a "dg-" directive name, then one of more tab/space
> characters, then anything (for arguments to the directive), then one of
> more tab/space character, then a "}".
>
> There are numerous places in our testsuite which look like attempts to
> use a directive, but which don't match this regexp.
>
> The script warns about such places, along with a list of misspelled
> directives (currently just "dg_options" for "dg-options"), and a warning
> if a dg-do appears after a dg-require-* (as per
> https://gcc.gnu.org/onlinedocs/gccint/Directives.html
> "This directive must appear after any dg-do directive in the test
> and before any dg-additional-sources directive." for
> dg-require-effective-target.
>
> dg-lint uses libgdiagnostics to report its results; the patch adds a
> new libgdiagnostics.py script below contrib/dg-lint. This uses Python's
> ctypes module to expose libgdianostics.so to Python via FFI. Hence
> the warnings have colorization, quote the pertinent parts of the tested
> file, can have fix-it hints, etc. Here's the output from the tests, run
> from the top-level directory:
>
> $ LD_LIBRARY_PATH=../build/gcc/ ./contrib/dg-lint/dg-lint
> contrib/dg-lint/test-*.c
> contrib/dg-lint/test-1.c:6:6: warning: misspelled directive: 'dg_final'; did
> you mean 'dg-final'?
> 6 | /* { dg_final { scan_assembler_times "vmsumudm" 2 } } */
> | ^~~~
> | dg-final
> contrib/dg-lint/test-1.c:15:4: warning: directive 'dg-output-file' appears
> not to match dg.exp's regexp
>15 |dg-output-file "m4.out"
> |^~
> contrib/dg-lint/test-1.c:18:4: warning: directive 'dg-output-file' appears
> not to match dg.exp's regexp
>18 |dg-output-file "m4.out" }
> |^~
> contrib/dg-lint/test-1.c:21:6: warning: directive 'dg-output-file' appears
> not to match dg.exp's regexp
>21 |{ dg-output-file "m4.out"
> | ^~
> contrib/dg-lint/test-1.c:24:5: warning: directive 'dg-output-file' appears
> not to match dg.exp's regexp
>24 |{dg-output-file "m4.out"}
> | ^~
> contrib/dg-lint/test-1.c:27:6: warning: directive 'dg-output-file' appears
> not to match dg.exp's regexp
>27 |{ dg-output-file, "m4.out" }
> | ^~
> contrib/dg-lint/test-2.c:4:6: warning: 'dg-do' after
> 'dg-require-effective-target'
> 4 | /* { dg-do compile } */
> | ^
> contrib/dg-lint/test-2.c:3:6: note: 'dg-require-effective-target' was here
> 3 | /* { dg-require-effective-target c++11 } */
> | ^~~
>
> I don't yet have a way to verify these tests (clearly we can't use
> DejaGnu for this).
>
> These Python bindings could be used by other projects, but so far I only
> implemented what I needed for dg-lint.
>
> Running the test on the GCC source tree finds dozens of issues, which
> followup patches address.
>
> Tested with Python 3.8
>
> contrib/ChangeLog:
> PR testsuite/116163
> * dg-lint/dg-lint: New file.
> * dg-lint/libgdiagnostics.py: New file.
> * dg-lint/test-1.c: New file.
> * dg-lint/test-2.c: New file.
> ---
> contrib/dg-lint/dg-lint| 210
> contrib/dg-lint/libgdiagnostics.py | 248 +
> contrib/dg-lint/test-1.c | 28
> contrib/dg-lint/test-2.c | 8 +
> 4 files changed, 494 insertions(+)
> create mode 100755 contrib/dg-lint/dg-lint
> create mode 100644 contrib/dg-lint/libgdiagnostics.py
> create mode 100644 contrib/dg-lint/test-1.c
> create mode 100644 contrib/dg-lint/test-2.c
>
> diff --git a/contrib/dg-lint/dg-lint b/contrib/dg-lint/dg-lint
> new file mode 100755
> index ..20157c304137
> --- /dev/null
> +++ b/contrib/dg-lint/dg-lint
> @@ -0,0 +1,210 @@
> +#!/usr/bin/env python3
> +
> +# Script to detect common mistakes in DejaGnu tests.
> +
> +# Contributed by David Malcolm
> +#
> +# Copyright (C) 2024-2025 Free Software Foundation, Inc.
> +#
> +# This file is part of GCC.
> +#
> +# GCC is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3, or (at your option)
> +# any later version.
> +#
> +# GCC is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or F
Re: [PATCH 02/12] testsuite: fix broken dg directives
On Wed, Mar 26, 2025 at 02:34:44PM -0400, David Malcolm wrote: > Found by dg-lint. > > gcc/testsuite/ChangeLog: > * gcc.dg/ipa/pr110377.c: Fix missing trailing " }" in dg-do > directive. > * gcc.dg/plugin/infoleak-1.c: Fix dg-bogus directive. > * gcc.dg/pr101364-1.c: Fix missing trailing " }" in dg-options > directive. > * gcc.dg/pr113207.c: Fix dg-do. > * gcc.dg/sarif-output/include-chain-2.c: Fix ordering of dg-do > and dg-require-effective-target. > * gcc.dg/strub-pr118007.c: Likewise. > * gcc.dg/tanhbysinh.c: Fix missing whitespace after opening > brace and before closing brace in 6 dg-final directives. > * gcc.dg/uninit-pred-3_c.c: Fix missing whitespace after opening > brace in 6 dg-final directive. > * gcc.dg/uninit-pred-3_d.c: Likewise. > * gcc.dg/variable-sized-type-flex-array.c: Fix missing space > between dg-bogus and message in 2 places. LGTM. Jakub
Re: [PATCH] rs6000: Ignore OPTION_MASK_SAVE_TOC_INDIRECT differences in inlining decisions [PR119327]
On 3/26/25 3:01 AM, Jakub Jelinek wrote:
> In any case, this flag feels like a tuning decision rather than hard
> ISA requirement and I see no problems why we couldn't inline
> even explicit -msave-toc-indirect function into -mno-save-toc-indirect
> or vice versa.
> We already ignore OPTION_MASK_P{8,10}_FUSION which are also more
> like tuning flags.
I agree this is more a tuning decision and not an ISA requirement,
so we should treat -m{no-,}save-toc-indirect similarly to the
fusion options.
LGTM, but I cannot approve it.
Peter
Re: [PATCH] libstdc++: Replace use of std::min in ranges::uninitialized_xxx algos [PR101587]
On Wed, 26 Mar 2025 at 11:50, Jonathan Wakely wrote:
>
> Because ranges can have any signed integer-like type as difference_type,
> it's not valid to use std::min(diff1, diff2). Instead of calling
> std::min with an explicit template argument, this adds a new __min
> helper that determines the common type and uses that with std::min.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/101587
> * include/bits/ranges_uninitialized.h (__detail::__min): New
> function object.
> (ranges::uninitialized_copy, ranges::uninitialized_copy_n)
> (ranges::uninitialized_move, ranges::uninitialized_move_n): Use
> __min instead of std::min.
> *
> testsuite/20_util/specialized_algorithms/uninitialized_copy/constrained.cc:
> Check ranges with difference difference types.
> *
> testsuite/20_util/specialized_algorithms/uninitialized_move/constrained.cc:
> Likewise.
> ---
>
> Tested x86_64-linux.
>
> .../include/bits/ranges_uninitialized.h | 32 +++
> .../uninitialized_copy/constrained.cc | 13
> .../uninitialized_move/constrained.cc | 13
> 3 files changed, 52 insertions(+), 6 deletions(-)
>
> diff --git a/libstdc++-v3/include/bits/ranges_uninitialized.h
> b/libstdc++-v3/include/bits/ranges_uninitialized.h
> index 990929efaa9..92a45e8fcff 100644
> --- a/libstdc++-v3/include/bits/ranges_uninitialized.h
> +++ b/libstdc++-v3/include/bits/ranges_uninitialized.h
> @@ -263,6 +263,26 @@ namespace ranges
>inline constexpr __uninitialized_value_construct_n_fn
> uninitialized_value_construct_n;
>
> + namespace __detail
> + {
> +// This is only intended for finding smaller iterator differences below,
> +// not as a general purpose replacement for std::min.
> +struct __min_fn
> +{
> + template
> + common_type_t<_Dp1, _Dp2>
This needs to be constexpr.
> + operator()(_Dp1 __d1, _Dp2 __d2) const noexcept
> + {
> + // Every C++20 iterator I satisfies weakly_incrementable which
> + // requires signed-integer-like>.
> + static_assert(std::__detail::__is_signed_integer_like<_Dp1>);
> + static_assert(std::__detail::__is_signed_integer_like<_Dp2>);
> + return std::min>(__d1, __d2);
> + }
> +};
> +inline constexpr __min_fn __min{};
> + }
> +
>template
> using uninitialized_copy_result = in_out_result<_Iter, _Out>;
>
> @@ -287,8 +307,8 @@ namespace ranges
> {
> auto __d1 = __ilast - __ifirst;
> auto __d2 = __olast - __ofirst;
> - return ranges::copy_n(std::move(__ifirst), std::min(__d1, __d2),
> - __ofirst);
> + return ranges::copy_n(std::move(__ifirst),
> + __detail::__min(__d1, __d2), __ofirst);
> }
> else
> {
> @@ -337,8 +357,8 @@ namespace ranges
> iter_reference_t<_Iter>>)
> {
> auto __d = __olast - __ofirst;
> - return ranges::copy_n(std::move(__ifirst), std::min(__n, __d),
> - __ofirst);
> + return ranges::copy_n(std::move(__ifirst),
> + __detail::__min(__n, __d), __ofirst);
> }
> else
> {
> @@ -381,7 +401,7 @@ namespace ranges
> auto __d2 = __olast - __ofirst;
> auto [__in, __out]
> = ranges::copy_n(std::make_move_iterator(std::move(__ifirst)),
> - std::min(__d1, __d2), __ofirst);
> + __detail::__min(__d1, __d2), __ofirst);
> return {std::move(__in).base(), __out};
> }
> else
> @@ -435,7 +455,7 @@ namespace ranges
> auto __d = __olast - __ofirst;
> auto [__in, __out]
> = ranges::copy_n(std::make_move_iterator(std::move(__ifirst)),
> - std::min(__n, __d), __ofirst);
> + __detail::__min(__n, __d), __ofirst);
> return {std::move(__in).base(), __out};
> }
> else
> diff --git
> a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/constrained.cc
>
> b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/constrained.cc
> index e0589e33f3d..af3b73364ec 100644
> ---
> a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/constrained.cc
> +++
> b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/constrained.cc
> @@ -175,6 +175,17 @@ test03()
> }
> }
>
> +void
> +test_pr101587()
> +{
> + short in[1];
> + __gnu_test::test_contiguous_range r(in); // difference_type is integer-like
> + long out[1];
> + std::span o(out); // difference_type is ptrdiff_t
> + ranges::uninitialized_copy(r, o);
> + ranges::uninitialized_copy_n(ranges::begin(r),
Re: [PATCH] Fortran: fix bogus recursion with DT default initialization [PR118796]
Hi Harald, looks good to me. Thanks for the patch. - Andre Andre Vehreschild * ve...@gmx.de Am 26. März 2025 22:18:41 schrieb Harald Anlauf : Dear all, it seems that my patch for default-initialization of function results of derived type could trigger a weird issue if a type-bound function of a type that is use-associated from a different module had the same name, even if the declared function had a different type, but only if the result clause is present. While I had hoped that resolution should not lead to this situation, checking whether the function was use-associated solved the issue. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald
[pushed] gcov: branch, conds, calls in function summaries
The gcov function summaries only output the covered lines, not the
branches and calls. Since the function summaries is an opt-in it
probably makes sense to also include branch coverage, calls, and
condition coverage.
$ gcc --coverage -fpath-coverage hello.c -o hello
$ ./hello
Before:
$ gcov -f hello
Function 'main'
Lines executed:100.00% of 4
Function 'fn'
Lines executed:100.00% of 7
File 'hello.c'
Lines executed:100.00% of 11
Creating 'hello.c.gcov'
After:
$ gcov -f hello
Function 'main'
Lines executed:100.00% of 3
No branches
Calls executed:100.00% of 1
Function 'fn'
Lines executed:100.00% of 7
Branches executed:100.00% of 4
Taken at least once:50.00% of 4
No calls
File 'hello.c'
Lines executed:100.00% of 10
Creating 'hello.c.gcov'
Lines executed:100.00% of 10
With conditions:
$ gcov -fg hello
Function 'main'
Lines executed:100.00% of 3
No branches
Calls executed:100.00% of 1
No conditions
Function 'fn'
Lines executed:100.00% of 7
Branches executed:100.00% of 4
Taken at least once:50.00% of 4
Condition outcomes covered:100.00% of 8
No calls
File 'hello.c'
Lines executed:100.00% of 10
Creating 'hello.c.gcov'
Lines executed:100.00% of 10
gcc/ChangeLog:
* gcov.cc (generate_results): Count branches, conditions.
(function_summary): Output branch, calls, condition count.
---
gcc/gcov.cc | 48 +++-
1 file changed, 43 insertions(+), 5 deletions(-)
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 96fdc50f0e8..f9ab93b54d9 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -1687,11 +1687,19 @@ generate_results (const char *file_name)
memset (&coverage, 0, sizeof (coverage));
coverage.name = fn->get_name ();
add_line_counts (flag_function_summary ? &coverage : NULL, fn);
- if (flag_function_summary)
- {
- function_summary (&coverage);
- fnotice (stdout, "\n");
- }
+
+ if (!flag_function_summary)
+ continue;
+
+ for (const block_info& block : fn->blocks)
+ for (arc_info *arc = block.succ; arc; arc = arc->succ_next)
+ add_branch_counts (&coverage, arc);
+
+ for (const block_info& block : fn->blocks)
+ add_condition_counts (&coverage, &block);
+
+ function_summary (&coverage);
+ fnotice (stdout, "\n");
}
name_map needle;
@@ -2764,6 +2772,36 @@ function_summary (const coverage_info *coverage)
{
fnotice (stdout, "%s '%s'\n", "Function", coverage->name);
executed_summary (coverage->lines, coverage->lines_executed);
+
+ if (coverage->branches)
+{
+ fnotice (stdout, "Branches executed:%s of %d\n",
+ format_gcov (coverage->branches_executed, coverage->branches, 2),
+ coverage->branches);
+ fnotice (stdout, "Taken at least once:%s of %d\n",
+ format_gcov (coverage->branches_taken, coverage->branches, 2),
+ coverage->branches);
+}
+ else
+fnotice (stdout, "No branches\n");
+
+ if (coverage->calls)
+fnotice (stdout, "Calls executed:%s of %d\n",
+format_gcov (coverage->calls_executed, coverage->calls, 2),
+coverage->calls);
+ else
+fnotice (stdout, "No calls\n");
+
+ if (flag_conditions)
+{
+ if (coverage->conditions)
+ fnotice (stdout, "Condition outcomes covered:%s of %d\n",
+format_gcov (coverage->conditions_covered,
+ coverage->conditions, 2),
+coverage->conditions);
+ else
+ fnotice (stdout, "No conditions\n");
+}
}
/* Output summary info for a file. */
--
2.39.5
[pushed] Add coverage_instrumentation_p
Provide a helper for checking if any coverage (arc, conditions, paths)
is enabled, rather than manually checking all the flags. This should
make the intent clearer, and make it easier to maintain the checks when
more flags are added.
The function is forward declared in two header files as different passes
tend to include different headers (profile.h vs value-prof.h). This
could maybe be merged at some points, but profiling related symbols are
already a bit spread out and should probably be handled in a targeted
effort.
gcc/ChangeLog:
* builtins.cc (expand_builtin_fork_or_exec): Call
coverage_instrumentation_p.
* ipa-inline.cc (can_early_inline_edge_p): Likewise.
* passes.cc (finish_optimization_passes): Likewise.
* profile.cc (coverage_instrumentation_p): New function.
* profile.h (coverage_instrumentation_p): New declaration.
* tree-profile.cc (tree_profiling): Call
coverage_instrumentation_p.
(pass_ipa_tree_profile::gate): Likewise.
* value-prof.h (coverage_instrumentation_p): New declaration.
---
gcc/builtins.cc | 2 +-
gcc/ipa-inline.cc | 2 +-
gcc/passes.cc | 4 ++--
gcc/profile.cc | 7 +++
gcc/profile.h | 4
gcc/tree-profile.cc | 11 ---
gcc/value-prof.h| 4
7 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index ff48546eafd..a5f711a7b6a 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -6362,7 +6362,7 @@ expand_builtin_fork_or_exec (tree fn, tree exp, rtx
target, int ignore)
tree call;
/* If we are not profiling, just call the function. */
- if (!profile_arc_flag && !condition_coverage_flag && !path_coverage_flag)
+ if (!coverage_instrumentation_p ())
return NULL_RTX;
/* Otherwise call the wrapper. This should be equivalent for the rest of
diff --git a/gcc/ipa-inline.cc b/gcc/ipa-inline.cc
index 38b4c989901..d9fc111a9e7 100644
--- a/gcc/ipa-inline.cc
+++ b/gcc/ipa-inline.cc
@@ -701,7 +701,7 @@ can_early_inline_edge_p (struct cgraph_edge *e)
}
gcc_assert (gimple_in_ssa_p (DECL_STRUCT_FUNCTION (e->caller->decl))
&& gimple_in_ssa_p (DECL_STRUCT_FUNCTION (callee->decl)));
- if ((profile_arc_flag || condition_coverage_flag || path_coverage_flag)
+ if (coverage_instrumentation_p ()
&& ((lookup_attribute ("no_profile_instrument_function",
DECL_ATTRIBUTES (caller->decl)) == NULL_TREE)
!= (lookup_attribute ("no_profile_instrument_function",
diff --git a/gcc/passes.cc b/gcc/passes.cc
index a8c75520c8d..3c28db78f09 100644
--- a/gcc/passes.cc
+++ b/gcc/passes.cc
@@ -352,8 +352,8 @@ finish_optimization_passes (void)
gcc::dump_manager *dumps = m_ctxt->get_dumps ();
timevar_push (TV_DUMP);
- if (profile_arc_flag || condition_coverage_flag || path_coverage_flag
- || flag_test_coverage || flag_branch_probabilities)
+ if (coverage_instrumentation_p () || flag_test_coverage
+ || flag_branch_probabilities)
{
dumps->dump_start (pass_profile_1->static_pass_number, NULL);
end_branch_prob ();
diff --git a/gcc/profile.cc b/gcc/profile.cc
index 8bba8b4398f..0b222cf3864 100644
--- a/gcc/profile.cc
+++ b/gcc/profile.cc
@@ -1798,3 +1798,10 @@ end_branch_prob (void)
total_num_conds);
}
}
+
+/* Return true if any cfg coverage/profiling is enabled; -fprofile-arcs
+ -fcondition-coverage -fpath-coverage. */
+bool coverage_instrumentation_p ()
+{
+ return profile_arc_flag || condition_coverage_flag || path_coverage_flag;
+}
diff --git a/gcc/profile.h b/gcc/profile.h
index 78d69f45ff2..a97445b8f6f 100644
--- a/gcc/profile.h
+++ b/gcc/profile.h
@@ -77,4 +77,8 @@ extern void get_working_sets (void);
profile.cc. */
extern struct gcov_summary *profile_info;
+/* Return true if any cfg coverage/profiling is enabled; -fprofile-arcs
+ -fcondition-coverage -fpath-coverage. */
+extern bool coverage_instrumentation_p ();
+
#endif /* PROFILE_H */
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index 8aaed78e60c..fed218eb60b 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -1908,7 +1908,7 @@ tree_profiling (void)
thunk = true;
/* When generate profile, expand thunk to gimple so it can be
instrumented same way as other functions. */
- if (profile_arc_flag || condition_coverage_flag || path_coverage_flag)
+ if (coverage_instrumentation_p ())
expand_thunk (node, false, true);
/* Read cgraph profile but keep function as thunk at profile-use
time. */
@@ -1953,8 +1953,7 @@ tree_profiling (void)
release_profile_file_filtering ();
/* Drop pure/const flags from instrumented functions. */
- if (profile_arc_flag || condition_coverage_flag || path_coverage_flag
- || flag_test_coverage)
+ if (coverage_instrumentation_p () || flag_test_coverage)
FOR_EACH_DEFINED_FUNCTION (node)
[PATCH 3/4] testsuite: g++.dg: vect: fix PR37143 filename
The test was being ignored because vect.exp looks for .cc in g++.dg/vect/.
gcc/testsuite/ChangeLog:
PR tree-optimization/37143
* g++.dg/vect/pr37143.C: Move to...
* g++.dg/vect/pr37143.cc: ...here.
---
gcc/testsuite/g++.dg/vect/{pr37143.C => pr37143.cc} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename gcc/testsuite/g++.dg/vect/{pr37143.C => pr37143.cc} (100%)
diff --git a/gcc/testsuite/g++.dg/vect/pr37143.C
b/gcc/testsuite/g++.dg/vect/pr37143.cc
similarity index 100%
rename from gcc/testsuite/g++.dg/vect/pr37143.C
rename to gcc/testsuite/g++.dg/vect/pr37143.cc
--
2.49.0
Re: [PATCH] cobol: Get rid of __int128 uses in the COBOL FE [PR119242]
On Tue, Mar 25, 2025 at 11:41:09PM -0500, Robert Dubner wrote:
> I'll take a look at this tomorrow. Conditional compilation is one
> possibility. Another is to bust that .h file into two; one that goes into
> libgcobol and is accessed by gcc/cobol and libgcobol, and a second that is
> accessed solely by libgcobol. I'll want to look at the magnitude of the
> problem before deciding which.
That would work fine too.
Another question for later is if any of those APIs with __int128 are
actually ever called from compiled COBOL code, or if after this change
and your header split __int128 will be just a type internal to the library,
with compiled COBOL code only storing stuff into memory as 16-byte values.
In that case, we could easily get rid of the __int128 dependency and enable
COBOL support e.g. on many 32-bit architectures, by doing
#ifdef __SIZEOF_INT128__
typedef __int128 int128;
#else
class int128 {
...
};
#endif
where the class would have overloaded operators such that it would work
fully or mostly the same as native __int128 type. The library is written
in C++ so let's take some advantage of it. Guess it depends on
what exactly is __int128 used for in the library and e.g. what C library
functions are used with it if any.
Jakub
