On Thu, 13 Mar 2025, Michal Jires wrote:
> This adds missing documentation for LTO flags.
>
> Ok?
OK.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * doc/invoke.texi: (Optimize Options):
> Add incremental LTO flags.
> ---
> gcc/doc/invoke.texi | 26 +++---
> 1 file ch
The -ansi option has essentially been superseded by the more general
-std= option, and all the additional information about its effects is
already covered elsewhere in the manual. I also cleaned up some
confusing text about alternate keywords that I noticed while
confirming this.
gcc/ChangeLog
Hi David,
Am Donnerstag, dem 13.03.2025 um 19:23 -0700 schrieb David Tarditi:
>
> I skip your initiial part. I think this was all discussed before
(also in WG14) and I still come to different conclusions. Just
two comments:
...
>
> The VLA semantics are also problematic. User can side-effe
On Fri, 14 Mar 2025 13:30:39 +0800, Monk Chiang wrote:
> Hi Jin Ma,
> This situation is the same on x86. When using -O0, the lpad instruction
> is merely a redundant instruction and does not affect the execution result.
> This is the ASM result for x86, and there is also an endbr64 in foo().
>
Hi Jin Ma,
This situation is the same on x86. When using -O0, the lpad instruction
is merely a redundant instruction and does not affect the execution result.
This is the ASM result for x86, and there is also an endbr64 in foo().
https://godbolt.org/z/M1fTendE3
On Wed, Mar 12, 2025 at 5:4
On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> On Linux at least when not cross-compiling, exit(1) (or this
> STOP RUN ERROR 1) will work as well, I believe the reason is for some
> bare metal targets which just don't propagate return
On Thu, 13 Mar 2025, Jonathan Wakely wrote:
> On Thu, 13 Mar 2025 at 21:29, Patrick Palka wrote:
> >
> > On Thu, 13 Mar 2025, Ville Voutilainen wrote:
> >
> > > On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
> > > wrote:
> > > >
> > > > On Thu, 13 Mar 2025 at 23:03, Patrick Palka wrote:
> > >
This series of patches attempts to bring some organization to the
current random order of topics within the "C Extensions" chapter of
the manual. It's broken up into pieces for easier reviewing (should
anybody care to do that), but there's little in the way of actual text
changes to review; the en
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 (Additional Numeric Types): New section.
(__int128): Make it a subsection of the above.
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
* extend.texi (Aggregate Types): New section.
(Variable Length): Make it a subsection of the above.
(
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
* extend.texi (Nonlocal Gotos): Group with other built-ins sections.
(Constructing Calls): Likewise.
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
* extend.texi (Syntax Extensions): New section.
(Statement Exprs): Make it a subsection of the above.
On Fri, 14 Mar 2025 at 00:04, Ville Voutilainen
wrote:
>
> On Fri, 14 Mar 2025 at 00:03, Ville Voutilainen
> wrote:
> >
> > On Thu, 13 Mar 2025 at 23:57, Jonathan Wakely wrote:
> > > > Do we also want to constraint the tuple(const _Elements&...)
> > > > constructor with requires sizeof...(_Eleme
Based on the PR119214 discussion about "-O -ftracer" causing the assembler
to fail, I offer the following patch.
Okay for trunk? (Gives me shivers to say that the first time!)
Author: Robert Dubner
Date: Thu Mar 13 21:03:46 2025 -0400
COBOL: Prevent use of ASM_EXPR for optimized COBOL co
This patch introduces two new inline functions, __sqrt and __sqrtf, in
arm_acle.h for Aarch64 targets. These functions wrap the new builtins
__builtin_aarch64_sqrtdf and __builtin_aarch64_sqrtsf, respectively,
providing direct access to hardware instructions without relying on the
standard math lib
On Thu, Mar 13, 2025 at 01:37:37PM -0400, Jason Merrill wrote:
> On 3/13/25 11:16 AM, Nathaniel Shead wrote:
> > I discovered from some further testing that I broke 'import std' in some
> > cases with my last patch; this fixes that.
> >
> > This still isn't sufficient I've found to fix PR119154 co
On Thu, 13 Mar 2025 at 23:28, Patrick Palka wrote:
> > Oh, never mind. The pack is just deduced as an empty pack.
>
> Yep that's my understanding, though I don't know where in the standard
> this is specified, a quick Ctrl+F is failing me.
I'll go with https://eel.is/c++draft/temp.variadic#9, and
On Tue, 11 Mar 2025 at 17:21, Christophe Lyon
wrote:
>
> r14-7202-gc8ec3e1327cb1e added vld1xN and vst1xN intrinsics and some
> tests on arm, but didn't enable some existing tests.
>
> Since these tests are shared with aarch64, this patch replaces the
> 'dg-skip-if "unimplemented" { arm*-*-* }' di
On Thu, 13 Mar 2025 14:45:23 -0400
Paul Koning wrote:
> > 3. --enable-languages=cobol, and
> > 4. the host and target are "plausible", 64-bit LE.
>
> Why does it need LE? I understand 64 bits. I might try it on my
> PowerPC based Mac. :-)
That's a good point. "Need" I don't know. I'm not
On 3/12/25 10:57 AM, Nathaniel Shead wrote:
On Mon, Mar 10, 2025 at 02:52:07PM -0400, Jason Merrill wrote:
On 3/10/25 9:52 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Or should this wait for GCC16?
-- >8 --
While looking at PR c++/119154 I notic
This plugs a small loophole in the pattern matching done by -fdump-ada-spec.
Tested on x86-64/Linux, applied on mainline, 14 and 13 branches.
2025-03-13 Eric Botcazou
PR ada/119265
* c-ada-spec.cc (dump_ada_node) : Deal with typedefs
of unsigned __int128.
--
Eric Bo
On Thu, 13 Mar 2025 at 21:54, Jonathan Wakely wrote:
>
> On Thu, 13 Mar 2025 at 21:29, Patrick Palka wrote:
> >
> > On Thu, 13 Mar 2025, Ville Voutilainen wrote:
> >
> > > On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
> > > wrote:
> > > >
> > > > On Thu, 13 Mar 2025 at 23:03, Patrick Palka wr
On Thu, Mar 13, 2025 at 06:33:08PM -0400, James K. Lowden wrote:
> I guess the most controversial engineering choice was to rely on
> __int128 and _Float128. Those gave us native processing and binary <->
> string conversion. Having been advised of real.cc, we're taking a
> look. If we can get 1
On Thu, 13 Mar 2025, 22:28 Patrick Palka, wrote:
> On Thu, 13 Mar 2025, Jonathan Wakely wrote:
>
> > On Thu, 13 Mar 2025 at 21:29, Patrick Palka wrote:
> > >
> > > On Thu, 13 Mar 2025, Ville Voutilainen wrote:
> > >
> > > > On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
> > > > wrote:
> > > >
On Fri, 14 Mar 2025 at 00:03, Ville Voutilainen
wrote:
>
> On Thu, 13 Mar 2025 at 23:57, Jonathan Wakely wrote:
> > > Do we also want to constraint the tuple(const _Elements&...)
> > > constructor with requires sizeof...(_Elements) >= 1, which is present
> > > on the C++17 version?
> >
> > Oh we
On Thu, 13 Mar 2025 at 23:57, Jonathan Wakely wrote:
> > Do we also want to constraint the tuple(const _Elements&...)
> > constructor with requires sizeof...(_Elements) >= 1, which is present
> > on the C++17 version?
>
> Oh we don't need that constraint, because we have an explicit
> specializati
On Thu, 13 Mar 2025 at 21:29, Patrick Palka wrote:
>
> On Thu, 13 Mar 2025, Ville Voutilainen wrote:
>
> > On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
> > wrote:
> > >
> > > On Thu, 13 Mar 2025 at 23:03, Patrick Palka wrote:
> > > > + // Defined as a template to work around PR libstdc++
On Thu, 13 Mar 2025, Ville Voutilainen wrote:
> On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
> wrote:
> >
> > On Thu, 13 Mar 2025 at 23:03, Patrick Palka wrote:
> > > + // Defined as a template to work around PR libstdc++/116440.
> > > + template
> > > + constexpr explicit(!__
On Thu, Mar 13, 2025 at 05:23:00PM -0400, Ayan Shafqat wrote:
> This patch introduces two new inline functions, __sqrt and __sqrtf, in
> arm_acle.h for Aarch64 targets. These functions wrap the new builtins
> __builtin_aarch64_sqrtdf and __builtin_aarch64_sqrtsf, respectively,
> providing direct ac
On Thu, Mar 13, 2025 at 05:25:26PM -0400, Ayan Shafqat wrote:
> This patch introduces acle_sqrt.c in the AArch64 testsuite, verifying
> that the new __sqrt and __sqrtf intrinsics emit the expected fsqrt
> instructions for double and float arguments.
>
> Coverage for new intrinsics ensures that __s
On Thu, 13 Mar 2025 at 23:14, Patrick Palka wrote:
> Ah, I just realized the C++17 tuple impl already defines the
> tuple(const _Elements&...) constructor as a template in order to
> constrain it! So this patch arguably makes the C++20 constructor
> set more consistent with the C++17 impl, and so
On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
wrote:
>
> On Thu, 13 Mar 2025 at 23:03, Patrick Palka wrote:
> > + // Defined as a template to work around PR libstdc++/116440.
> > + template
> > + constexpr explicit(!__convertible())
> > + tuple(const _Elements&... __elemen
This patch introduces acle_sqrt.c in the AArch64 testsuite, verifying
that the new __sqrt and __sqrtf intrinsics emit the expected fsqrt
instructions for double and float arguments.
Coverage for new intrinsics ensures that __sqrt and __sqrtf are
correctly expanded to hardware instructions and do n
This patch introduces two new inline functions, __sqrt and __sqrtf, in
arm_acle.h for Aarch64 targets. These functions wrap the new builtins
__builtin_aarch64_sqrtdf and __builtin_aarch64_sqrtsf, respectively,
providing direct access to hardware instructions without relying on the
standard math lib
This patch changes the `sqrt` builtin definition from `BUILTIN_VHSDF_DF`
to `BUILTIN_VHSDF_HSDF` in `aarch64-simd-builtins.def`, ensuring the
builtin covers half, single, and double precision variants. The redundant
`VAR1 (UNOP, sqrt, 2, FP, hf)` lines are removed, as they are no longer
needed now
Am 13.03.2025 um 21:35 schrieb David Malcolm:
On Thu, 2025-03-13 at 12:11 +0100, Simon Sobisch wrote:
Thanks for your work on adding a testsuite. Can you please explain
why
you do this when a complete testsuite exists in autoconf (autotest)
format (which roots back to decade of work in GnuCOBO
On Thu, 13 Mar 2025, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and 14 after
> a while?
>
> -- >8 --
>
> The type tuple> is clearly copy/move constructible, but for
> reasons that are not yet completely understood checking this triggers
> constraint recurs
Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and 14 after
a while?
-- >8 --
The type tuple> is clearly copy/move constructible, but for
reasons that are not yet completely understood checking this triggers
constraint recursion with our C++20 tuple implementation (and not the
C++17
On Thu, Mar 13, 2025 at 03:52:25PM -0400, Jason Merrill wrote:
> > > How about changing cp_parser_std_attribute_spec_seq in cp_parser_statement
> > > to cp_parser_attributes_opt?
> >
> > I'd be afraid that would be quite significant change of behavior everywhere,
> > something that C doesn't allow
This patch introduces inline definitions for the __fma and __fmaf
functions in arm_acle.h for arm targets. These definitions rely on
__builtin_fma and __builtin_fmaf to ensure proper inlining and to meet
the ACLE requirements [1].
The patch has been tested locally using a crosstool-NG sysroot for
This patch introduces inline definitions for the __fma and __fmaf
functions in arm_acle.h for Aarch64 targets. These definitions rely on
__builtin_fma and __builtin_fmaf to ensure proper inlining and to meet
the ACLE requirements [1].
The patch has been tested locally using a crosstool-NG sysroot
On Thu, 2025-03-13 at 12:11 +0100, Simon Sobisch wrote:
> Thanks for your work on adding a testsuite. Can you please explain
> why
> you do this when a complete testsuite exists in autoconf (autotest)
> format (which roots back to decade of work in GnuCOBOL, with all
> copyrights for that alread
Introduce support for a new set of NEON square-root intrinsics for half,
single, and double precision.
modified: gcc/config/arm/arm-builtins.cc
1. Define the df_UP macro to map to E_DFmode.
2. Add CODE_FOR_neon_vsqrtsf and CODE_FOR_neon_vsqrtdf constants that
reference the underlying VFP sqrt
On Thu, 13 Mar 2025, Jason Merrill wrote:
> > I'd be afraid that would be quite significant change of behavior everywhere,
> > something that C doesn't allow (like mixing std and GNU attributes in any
> > orders or [[]] __attribute__(()) [[]][[]] __attribute__(())
> > expression-statement). Or it
Support for dynamic selectors in "declare variant" was developed in
parallel with support for the adjust_args/append_args clauses and the
dispatch construct; they collided in a bad way. This patch fixes the
"sorry" for calls that need both by removing the adjust_args/append_args
code from gimplify
On 3/13/25 3:16 PM, Jakub Jelinek wrote:
On Thu, Mar 13, 2025 at 01:45:43PM -0400, Jason Merrill wrote:
On 3/13/25 11:27 AM, Jakub Jelinek wrote:
Parsing a jump-statement under cp_parser_expression_statement just because
it happens to start with __attribute is pretty strange.
It is true that i
vect_slp_prefer_store_lanes_p allows an SLP tree to be split even
if the tree could use store-lanes, provided that one of the new
groups would operate on full vectors for each scalar iteration.
That heuristic is no longer firing for gcc.target/aarch64/pr99873_2.c.
The test contains:
void __attrib
On Tue, 11 Mar 2025 11:18:22 +0100
Andreas Schwab wrote:
> > +
> > +# It's early days for COBOL, and it is known to compile on only
> > some host and +# target systems. We remove COBOL from other builds
> > with a warning. +
> > +cobol_is_okay_host="no"
> > +cobol_is_okay_target="no"
> > +
> >
On Thu, 13 Mar 2025, JeanHeyd Meneide wrote:
> On Thu, Mar 13, 2025 Qing Zhao wrote:
>
> > ...
> >
> > Is N3188 the following:
> > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3188.htm
> >
> > What’s the status of this proposal?
>
>
> N3188 was discussed during the January 2024 Meeti
Hi James,
> Our intention, tell me if you disagree, is that cobol is enabled if
>
> 1. --enable-languages=all, and
> 2. the host and target are "known good", x86_64 or aarch64
you tend to forget there's a world outside of Linux, actually: as you
can see at least in PRs cobol/119217 and cobol/11
On Thu, Mar 13, 2025 at 01:45:43PM -0400, Jason Merrill wrote:
> On 3/13/25 11:27 AM, Jakub Jelinek wrote:
> Parsing a jump-statement under cp_parser_expression_statement just because
> it happens to start with __attribute is pretty strange.
It is true that it is pretty strange, but that is where
Am Donnerstag, dem 13.03.2025 um 19:48 +0100 schrieb JeanHeyd Meneide:
> On Thu, Mar 13, 2025 Martin Uecker wrote:
>
>
...
> Part of this problem is self-inflicted: VLAs in structures are
> a GNU extension and not an ISO C feature (for reasons like this one).
Note that this has nothing to do
On Thu, Mar 13, 2025 Martin Uecker wrote:
> ...
>
> So it seems to be a possible way forward while avoiding
> language divergence and without introducing anything too novel
> in either language.
>
> (But others still have concerns about .n and prefer __self__.)
I would like to gently push
> On Mar 13, 2025, at 2:33 PM, James K. Lowden wrote:
>
> ...
> 3. --enable-languages=cobol, and
> 4. the host and target are "plausible", 64-bit LE.
Why does it need LE? I understand 64 bits. I might try it on my PowerPC based
Mac. :-)
paul
On Tue, 11 Mar 2025 14:40:19 +0100 (CET)
Richard Biener wrote:
> > Looking at pretty much all of the above, it seems very Fortran
> > specific with its weird diagnostic output (capital Warning:/Error:,
> > the (1) and (2) in the diagnostics with later printing of those
> > lines and the like. Unl
On Thu, 13 Mar 2025 13:37:32 -0400
Paul Koning wrote:
> > 4. cast pointers formatted with %p as (void*)
>
> Could that be (const void *) instead?
Yes. Nothing is committed yet; I'll make that change first.
Could you explain why it matters, please, for my edification?
--jkl
On Thu, 6 Mar 2025 at 16:29, Jonathan Wakely wrote:
>
> On Wed, 29 Jan 2025 at 18:55, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, I suppose this is stage 1 material?
>
> Yes, I think so, since it could impact C++17 programs.
>
> OK for trunk as soon as stage 1 opens though, thanks.
Dear all,
while testing different stuff using code from the initial commit,
I figured that I copy-pasted erroneous code that could lead to
an infinite loop which did not update its control variable,
and an unhandled REF_INQUIRY in a switch statement.
Fixed and committed as simple and obvious, al
On 3/13/25 11:27 AM, Jakub Jelinek wrote:
Hi!
Apparently some programs in the wild use
#if __has_attribute(musttail)
__attribute__((musttail)) return foo ();
#else
return foo ();
#endif
clang supports musttail both as a standard attribute ([[clang::musttail]]
which we also support for comp
On 3/13/25 11:16 AM, Nathaniel Shead wrote:
I discovered from some further testing that I broke 'import std' in some
cases with my last patch; this fixes that.
This still isn't sufficient I've found to fix PR119154 completely, as
there's still more cases where this assert fires due to performing
> On Mar 13, 2025, at 11:27 AM, James K. Lowden
> wrote:
>
> On Mon, 10 Mar 2025 19:10:26 +0100
> Richard Biener wrote:
>
>>> What is the right answer? Designated initializers are part of C99,
>>> but weren't added to C++ until C++20
>>> (https://en.cppreference.com/w/cpp/language/initiali
"Andre Vieira (lists)" writes:
> Apologies for the delay, had been waiting on some other relevant patches
> to go in to make sure we didn't break any valid existing behaviours. It
> should all be working properly now. I think I've also addressed all your
> comments. Most notable change is that
On 13/03/2025 08:22, Christophe Lyon wrote:
> Since we have vcmp and vcmpe instructions (vcmpe raises an "Invalid
> Operation" exception in presence of a NaN operand), we need to tell
> the compiler it is not safe to reverse comparisons of floating-point
> arguments.
>
> On armv8-m.main+dsp+fp (co
Apologies for the delay, had been waiting on some other relevant patches
to go in to make sure we didn't break any valid existing behaviours. It
should all be working properly now. I think I've also addressed all your
comments. Most notable change is that it now uses the 'sorry' mechanism.
Bo
> On Mar 13, 2025, at 12:29, Martin Uecker wrote:
>
> Am Donnerstag, dem 13.03.2025 um 15:41 + schrieb Qing Zhao:
>>
>>> On Mar 12, 2025, at 12:40, Martin Uecker wrote:
>>>
>>> Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao:
> On Mar 10, 2025, at 15:34, Martin Uec
> On Mar 12, 2025, at 12:58, Joseph Myers wrote:
>
> On Wed, 12 Mar 2025, Martin Uecker wrote:
>
>> For a designator
>>
>> struct foo { int n; } a = { .n = 1 };
>>
>> we also refer to a member 'n' of an instance 'a' of a structure type.
>> The instance is simply implied by the context.
>>
>
Since we have vcmp and vcmpe instructions (vcmpe raises an "Invalid
Operation" exception in presence of a NaN operand), we need to tell
the compiler it is not safe to reverse comparisons of floating-point
arguments.
On armv8-m.main+dsp+fp (cortex-m33):
PASS: gcc.dg/torture/builtin-iseqsig-1.c
at -
From: Sam James
Sent: Friday, March 7, 2025 11:39 PM
To: Prathamesh Kulkarni
Cc: Thomas Schwinge; Tobias Burnus; Joseph Myers; Xi Ruoyao; Matthew Malcomson;
gcc-patches@gcc.gnu.org; Tom de Vries
Subject: Re: [RFC] PR81358: Enable automatic linking of l
Am Donnerstag, dem 13.03.2025 um 15:41 + schrieb Qing Zhao:
>
> > On Mar 12, 2025, at 12:40, Martin Uecker wrote:
> >
> > Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao:
> > >
> > > > On Mar 10, 2025, at 15:34, Martin Uecker wrote:
> > > >
> > > > Am Montag, dem 10.03.2025 u
This adds missing documentation for LTO flags.
Ok?
gcc/ChangeLog:
* doc/invoke.texi: (Optimize Options):
Add incremental LTO flags.
---
gcc/doc/invoke.texi | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/d
On Thu, Mar 13, 2025 Qing Zhao wrote:
> ...
>
> Is N3188 the following:
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3188.htm
>
> What’s the status of this proposal?
N3188 was discussed during the January 2024 Meeting in Strasbourg,
France. There was "along the lines" (opinion poll)
> On Mar 12, 2025, at 18:46, Yeoul Na wrote:
>
>
>
>> On Mar 12, 2025, at 3:40 PM, Bill Wendling wrote:
>>
>> On Wed, Mar 12, 2025 at 3:28 PM Yeoul Na wrote:
On Mar 12, 2025, at 2:51 PM, John McCall wrote:
On 12 Mar 2025, at 16:02, Bill Wendling wrote:
> Qing pointed o
On Thu, 13 Mar 2025, Jakub Jelinek wrote:
> On Thu, Mar 13, 2025 at 03:44:21PM +0100, Richard Biener wrote:
> > + case OPT_D:
> > + case OPT_U:
> > + if (strncmp (options[i].arg, "_FORTIFY_SOURCE",
> > +strlen ("_FORTIFY_SOURCE")) == 0)
>
> I'd say you want to verify t
Wilco Dijkstra writes:
> Hi Richard,
>
>> Could you give details? I thought it was always known that trapped
>> system register accesses were slow. In the previous versions, the
>> checks seemed to be presented as an up-front price worth paying for
>> faster atomic operations, on the systems tha
From: Tomasz Kamiński
This is another piece of P1206R7, adding new members to std::stack,
std::queue, and std::priority_queue.
PR libstdc++/111055
libstdc++-v3/ChangeLog:
* include/bits/stl_queue.h (queue(from_range_t, _Rg&&))
(queue(from_range_t, _Rg&&, const _Alloc&),
On Thu, Mar 13, 2025 at 10:00:48AM -0400, Jason Merrill wrote:
> On 3/13/25 3:54 AM, Richard Biener wrote:
> > On Thu, 13 Mar 2025, Jakub Jelinek wrote:
> >
> > > Hi!
> > >
> > > On Wed, Mar 12, 2025 at 02:01:14PM +0100, Richard Biener wrote:
> > > > On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> >
Hi Richard,
> Could you give details? I thought it was always known that trapped
> system register accesses were slow. In the previous versions, the
> checks seemed to be presented as an up-front price worth paying for
> faster atomic operations, on the systems that would use those paths.
> Now
> On Mar 12, 2025, at 12:40, Martin Uecker wrote:
>
> Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao:
>>
>>> On Mar 10, 2025, at 15:34, Martin Uecker wrote:
>>>
>>> Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall:
>>>
>>> ...
>>>
That said, my preferen
Hi!
Apparently some programs in the wild use
#if __has_attribute(musttail)
__attribute__((musttail)) return foo ();
#else
return foo ();
#endif
clang supports musttail both as a standard attribute ([[clang::musttail]]
which we also support for compatibility) and the above worked just
fine with
On Thu, 13 Mar 2025, Jason Merrill wrote:
> On 3/13/25 3:54 AM, Richard Biener wrote:
> > On Thu, 13 Mar 2025, Jakub Jelinek wrote:
> >
> >> Hi!
> >>
> >> On Wed, Mar 12, 2025 at 02:01:14PM +0100, Richard Biener wrote:
> >>> On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> >>>
> On Tue, Mar 11, 2
On Thu, Mar 13, 2025 at 03:51:15PM +0100, Richard Biener wrote:
> On Thu, 13 Mar 2025, Jakub Jelinek wrote:
>
> > On Thu, Mar 13, 2025 at 03:44:21PM +0100, Richard Biener wrote:
> > > + case OPT_D:
> > > + case OPT_U:
> > > + if (strncmp (options[i].arg, "_FORTIFY_SOURCE",
> > > +
I discovered from some further testing that I broke 'import std' in some
cases with my last patch; this fixes that.
This still isn't sufficient I've found to fix PR119154 completely, as
there's still more cases where this assert fires due to performing
import_export_decl on non-DECL_REALLY_EXTERN
On Thu, Mar 13, 2025 at 04:11:51PM +0100, Andreas Schwab wrote:
> On Mär 13 2025, Richard Biener wrote:
>
> > The following makes sure to record -D_FORTIFY_SOURCE=n and
> > -U_FORTIFY_SOURCE in the DW_AT_producer debuginfo attribute when
> > present on the compiler command line.
>
> Should this a
Among other things, this testcase tests an addition of the four
values (n*4+[0:3])*9//2 for each n in [0:99]. The addition is
done in multiple integer and floating-point types and the test
is compiled with -ffast-math.
One of the floating-point types is _Float16, and as Andrew says
in the PR, _Fl
On Mär 13 2025, Richard Biener wrote:
> The following makes sure to record -D_FORTIFY_SOURCE=n and
> -U_FORTIFY_SOURCE in the DW_AT_producer debuginfo attribute when
> present on the compiler command line.
Should this also handle defines passed via -Wp?
--
Andreas Schwab, SUSE Labs, sch...@suse
This is the second part of the P3370R1 proposal just approved by the
committee in Wrocław. This adds C++ equivalents of the functions added
to C23 by WG14 N2683.
These functions are in the global namespace, but to avoid collisions
with the same functions defined by other standard library
implement
This is the first part of the P3370R1 proposal just approved by the
committee in Wrocław. This adds C++ equivalents of the functions added
to C23 by WG14 N3022.
These functions are in the global namespace, but to avoid collisions
with the same functions defined by other standard library
implementa
Hello people!
This patch adds a link to the Algol 68 front-end development list to
lists.html. OK?
Thanks!
---
htdocs/lists.html | 5 +
1 file changed, 5 insertions(+)
diff --git a/htdocs/lists.html b/htdocs/lists.html
index 03e4a2a2..d5f1d3c8 100644
--- a/htdocs/lists.html
+++ b/htdocs/l
* Jonathan Wakely:
> On Thu, 13 Mar 2025 at 09:24, Florian Weimer wrote:
>>
>> * Jonathan Wakely:
>>
>> > On Thu, 13 Mar 2025 at 06:50, Florian Weimer wrote:
>> >>
>> >> * François Dumont:
>> >>
>> >> > + // Get hash code for a node that comes from another _Hashtable.
>> >> > + // Reus
On Thu, Mar 13, 2025 at 03:44:21PM +0100, Richard Biener wrote:
> + case OPT_D:
> + case OPT_U:
> + if (strncmp (options[i].arg, "_FORTIFY_SOURCE",
> + strlen ("_FORTIFY_SOURCE")) == 0)
I'd say you want to verify that after that substring there is either
'\0' or "=".
The following makes sure to record -D_FORTIFY_SOURCE=n and
-U_FORTIFY_SOURCE in the DW_AT_producer debuginfo attribute when
present on the compiler command line.
We seem to want this internally now, not sure whether others also
need this (I'm happily carrying this downstream).
Bootstrapped on x86
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/version.def (ranges_to_input): Define.
* include/bits/version.h: Regenerate.
* include/std/ranges (ranges::to_input_view): Define for C++26.
(views::__detai
When I changed DECL_GIMPLE_REG_P over to DECL_NOT_GIMPLE_REG_P I
failed to update its description.
Pushed to trunk.
* tree.h (DECL_NOT_GIMPLE_REG_P): Update description.
---
gcc/tree.h | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/gcc/tree.h b/gcc/tree.h
On 3/13/25 3:54 AM, Richard Biener wrote:
On Thu, 13 Mar 2025, Jakub Jelinek wrote:
Hi!
On Wed, Mar 12, 2025 at 02:01:14PM +0100, Richard Biener wrote:
On Wed, 12 Mar 2025, Jakub Jelinek wrote:
On Tue, Mar 11, 2025 at 12:13:13PM +0100, Richard Biener wrote:
On Tue, 11 Mar 2025, Jakub Jelin
On Thu, 13 Mar 2025, Simon Sobisch wrote:
>
> Am 13.03.2025 um 12:49 schrieb Richard Biener:
> > On Thu, 13 Mar 2025, Sam James wrote:
> >
> >> Simon Sobisch writes:
> >>
> >>> Thanks for your work on adding a testsuite. Can you please explain why
> >>> you do this when a complete testsuite exi
gcc.target/aarch64/sve/pr96357.c started failing after
r15-518-g99b1daae18c095d6, which tweaked the heuristics
about when to sink code. The testcase has:
double i = d, j = 1.0 - f, k = j ? d : j;
if (k == 1.0)
i = 0.0;
*l = *n = *g = *h = i * 0.5;
where k == 1.0 is false if j is zero (
Am 13.03.2025 um 12:49 schrieb Richard Biener:
On Thu, 13 Mar 2025, Sam James wrote:
Simon Sobisch writes:
Thanks for your work on adding a testsuite. Can you please explain why
you do this when a complete testsuite exists in autoconf (autotest)
format (which roots back to decade of work i
Testcases for match.pd patterns
`((a ^ b) & c) cmp d | a != b -> (0 cmp d | a != b)` and
`(a ^ b) cmp c | a != b -> (0 cmp c | a != b)` were failing on some targets,
like PowerPC.
This patch adds an implemenetation for the optimization in reassoc. Doing so,
we can now handle cases where the relate
Hi, thanks for the feedback!
I have sent a new version, keeping the match.pd patterns, fixing the
formatting issues and changing std::set to hash_set
(https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677526.html).
Konstantinos
On Mon, Mar 10, 2025 at 6:49 PM Andrew Pinski wrote:
>
> On Mon,
Hi,
this patch fixes false incosistent profile error message seen when building
SPEC with
-fprofile-use -fdump-ipa-profile.
The problem is that with dumping tree_esitmate_probability is run in dry run
mode to report success rates of heuristics. It however runs
determine_unlikely_bbs
which ovewri
1 - 100 of 132 matches
Mail list logo
