Hello, Christophe,
On Feb 10, 2024, Christophe Lyon wrote:
> gcc/
> * Makefile.in: Add no-info dependency.
> * configure.ac: Set BUILD_INFO=no-info if makeinfo is not
> available.
> * configure: Regenerate.
Thank you, this is ok.
Now, this doesn't fix a
On Sat, Feb 10, 2024 at 08:01:46PM -0800, Andrew Pinski wrote:
> On Sat, Feb 10, 2024 at 7:55 PM Nathaniel Shead
> wrote:
> >
> > Bootstrapped and regtested (so far just modules.exp and dg.exp) on
> > x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
> >
> > (Also I noticed I forgot to
On Sat, Feb 10, 2024 at 7:55 PM Nathaniel Shead
wrote:
>
> Bootstrapped and regtested (so far just modules.exp and dg.exp) on
> x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
>
> (Also I noticed I forgot to add the PR to the changelog in my last
> patch, I've fixed that locally.)
>
>
Bootstrapped and regtested (so far just modules.exp and dg.exp) on
x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
(Also I noticed I forgot to add the PR to the changelog in my last
patch, I've fixed that locally.)
-- >8 --
After fixing PR111710, I noticed that we currently ICE when
On 2/2/24 23:55, Jonathan Yong wrote:
Attached patch OK? Fixes the following warnings:
coreutils-sum-pr108666.c:17:1: warning: conflicting types for built-in
function ‘memcpy’; expected ‘void *(void *, const void *, long long
unsigned int)’ [-Wbuiltin-declaration-mismatch]
17 |
Hello,
I have implemented a patch that fixes compile time errors for valid PDT
type-bound procedures. I wrote 4 new tests that address the test-cases in
PR 82943, PR 86148, and PR 86268, since the patch fixes all three of them.
All regression tests pass, including the new ones. This was tested
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Or should I re-introduce the tree checking and just add checks for the
new kinds of declarations that could be have keyed decls?
-- >8 --
The fix for PR107398 weakened the restrictions that lambdas must belong
to namespace scope.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Jason, this is the patch you proposed for PR113545. It looks very safe
so I'm posting it here so that it's not forgotten.
PR c++/113545
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_switch_expr): If the
Hi!
On Tue, 6 Feb 2024 at 06:37, Alexandre Oliva wrote:
>
> Hello, Christophe,
>
> Thanks for the patch.
>
> On Feb 5, 2024, Christophe Lyon wrote:
>
> > In order to save build time, our CI overrides BUILD_INFO="", which
> > works when invoking 'make all' but not for 'make install' in case
> "Andrew" == Andrew Burgess writes:
Andrew> Tom Tromey writes:
>> This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f.
>>
>> This patch caused problems for some users when building gdb, because
>> it would cause 'guild' to be invoked with the wrong versin of guile.
>> On the
I managed to try this patch on aarch64-linux-gnu:
This is the test run without your patch:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807637.html
And this is the "result" with your patch:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807645.html
For me, as for
On 2023-08-28 10:09, Kaz Kylheku wrote:
> On 2022-06-13 16:13, Kaz Kylheku wrote:
>> Pinging this item:
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593473.html
>>
>> Thanks.
Again.
Probably stage1 material but it should be safe...
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
On the heels of r14-8903, this patch adds further complain parameters
so that we don't emit "invalid use of incomplete type" from inside
a concept.
PR c++/112436
Hello,
I have added myself to write after approval.
Thanks,
Alexander Westbrooks
>From 564b307970d3be7a02e827420f0fad87bd335d9b Mon Sep 17 00:00:00 2001
From: Alexander Westbrooks
Date: Sat, 10 Feb 2024 12:20:00 -0600
Subject: [PATCH] Add Myself to Write After Approval and DCO List
On Sat, 10 Feb 2024, Jason Merrill wrote:
> On 2/9/24 17:11, Patrick Palka wrote:
> > On Fri, 9 Feb 2024, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > I'll try to reduce and add testcases overnight for these
The new testcase gcc.target/i386/asm-raw-symbol.c fails on darwin. This is
partly because symbols are prefixed with underscore, and also because the order
of operands in the addition is reversed (but I think it’s valid still). The
code generated is this:
_func:
LFB0:
pushq %rbp
On Sat, Feb 10, 2024 at 9:46 AM Jakub Jelinek wrote:
>
> On Sat, Feb 10, 2024 at 05:14:44PM +, Iain Sandoe wrote:
> > PR target/113855
> >
> > gcc/ChangeLog:
> >
> > * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be
> > available to all sub-targets.
> > *
> On 10 Feb 2024, at 17:46, Jakub Jelinek wrote:
>
> On Sat, Feb 10, 2024 at 05:14:44PM +, Iain Sandoe wrote:
>> PR target/113855
>>
>> gcc/ChangeLog:
>>
>> * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be
>> available to all sub-targets.
>> *
Three new tests using -mcmodel=large, which darwin does not support. Skipping
them.
Pushed as obvious.
FX
0001-Darwin-testsuite-skip-some-mcmodel-large-tests.patch
Description: Binary data
On Sat, Feb 10, 2024 at 05:14:44PM +, Iain Sandoe wrote:
> PR target/113855
>
> gcc/ChangeLog:
>
> * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be
> available to all sub-targets.
> * config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): Delete.
> *
GDB makes use of the libiberty function buildargv for splitting the
inferior (program being debugged) argument string in the case where
the inferior is not being started under a shell.
I have recently been working to improve this area of GDB, and have
tracked done some of the unexpected behaviour
GDB makes use of the libiberty function buildargv for splitting the
inferior (program being debugged) argument string in the case where
the inferior is not being started under a shell.
I have recently been working to improve this area of GDB, and noticed
some unexpected behaviour to the libiberty
I realise that these patches are not going to get merged until GCC is
back in stage 1, but thought I'd post my latest set of changes for the
libiberty buildargv function.
Patch #1 is unchanged from V1.
Patch #2 is new in V2.
Thanks,
Andrew
---
Andrew Burgess (2):
libiberty/buildargv: POSIX
I have so far tested this on i686-darwin17 and on x86_64-linux (with 32b
multilib )with the following permutations:
C (dg.exp=*nest*), Ada :
\{-m64,-m32\}\{,-ftrampoline-impl=heap\}\{,-shared-libgcc\}
Fortran \{-m64,-m32\}\{,-ftrampoline-impl=heap\}
The only fails [gnat] are expected (scanning
I have confirmed that this updated pr97969.c file still hangs with
gcc-arm-none-eabi-9-2020-q2-update as mentioned in comment 2 of PR97969.
Ok for trunk?
--
The test case for PR97969 needs updates in order to comply with recent
changes in GCC14. Without these changes, failures like this can be
> On 10 Feb 2024, at 14:54, FX Coudert wrote:
>
> With Xcode 15, gcc.dg/ssp-2.c fails due to a warning: -multiply_defined is
> obsolete
>
> The patches ignores the warning when present.
> OK to push?
yes, thanks.
Iain
… although part of me is curious about whether we still have any
With Xcode 15, gcc.dg/ssp-2.c fails due to a warning: -multiply_defined is
obsolete
The patches ignores the warning when present.
OK to push?
FX
0001-Darwin-testsuite-multiply_defined-is-obsolete.patch
Description: Binary data
Hello-
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html
May I please ping this one? Thanks!
On Sat, Jan 13, 2024 at 5:12 PM Lewis Hyatt wrote:
>
> Hello-
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109704
>
> The below patch fixes the issue noted in the PR that extended
[Public]
Hi all,
PFA, the patch that enables support for the next generation AMD Zen5 CPU via
-march=znver5 with basic znver5 scheduler Model.
We may update the scheduler model going forward.
Good for trunk?
Thanks and Regards
Karthiban
Resending the patch, as unable to inline the
> On 10 Feb 2024, at 12:07, Jason Merrill wrote:
>
> On 2/10/24 05:46, Iain Sandoe wrote:
>>> On 9 Feb 2024, at 23:21, Iain Sandoe wrote:
>>>
>>>
>>>
On 9 Feb 2024, at 10:56, Iain Sandoe wrote:
> On 8 Feb 2024, at 21:44, Jason Merrill wrote:
>
> On 2/8/24 12:55, Paolo
On 2/9/24 17:11, Patrick Palka wrote:
On Fri, 9 Feb 2024, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
I'll try to reduce and add testcases overnight for these separate bugs
before pushing.
-- >8 --
Building modular fmtlib triggered
On 2/9/24 16:50, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk
-- >8 --
It turns out that with modules we can call mangle_decl recursively,
which is a problem because the global mangling state isn't recursion
aware. The recursion happens
On 2/10/24 05:46, Iain Sandoe wrote:
On 9 Feb 2024, at 23:21, Iain Sandoe wrote:
On 9 Feb 2024, at 10:56, Iain Sandoe wrote:
On 8 Feb 2024, at 21:44, Jason Merrill wrote:
On 2/8/24 12:55, Paolo Bonzini wrote:
On 2/8/24 18:16, Jason Merrill wrote:
Hmm. In stage 1, when we build
Hi FX,
> On 10 Feb 2024, at 11:58, FX Coudert wrote:
>
> With Xcode 15, gcc.dg/darwin-ld-2.c fails due to a warning:
> ld: warning: -bind_at_load is deprecated on macOS
>
> The patches ignores the warning when present.
> OK to push?
Yes, thanks.
Iain
I guess for GCC-15 we might need to see
With Xcode 15, gcc.dg/darwin-ld-2.c fails due to a warning:
ld: warning: -bind_at_load is deprecated on macOS
The patches ignores the warning when present.
OK to push?
FX
0001-Darwin-testsuite-bind_at_load-is-deprecated.patch
Description: Binary data
> Am 10.02.2024 um 11:03 schrieb Jakub Jelinek :
>
> Hi!
>
> torture/bitint-37.c test FAILed on i686-linux e.g. on
> signed _BitInt(575) + unsigned _BitInt(575) -> signed _BitInt(575)
> __builtin_add_overflow. With 64-bit limbs, we use 4 .UADDC calls in
> the IL, 2 in a loop (which handles
> Am 10.02.2024 um 10:56 schrieb Jakub Jelinek :
>
> Hi!
>
> The ia32 _BitInt support revealed a bug in floatbitint?d.c.
> As can be even guessed from how the code is written in the loop,
> the intention was to set inexact to non-zero whenever the remainder
> after division wasn't zero, but
> Am 10.02.2024 um 10:50 schrieb Jakub Jelinek :
>
> Hi!
>
> I've tried last night to enable _BitInt support for i?86-linux, and
> a few spots in libgcc emitted -Wshift-count-overflow warnings and clearly
> didn't do what it was supposed to do.
>
> Fixed thusly, bootstrapped/regtested on
On Sat, Feb 10, 2024 at 11:19:16AM +0100, Jakub Jelinek wrote:
> And bitint-24.c case seems to be miscompilation of __floatbitintxf
> when built with -O2 -m32, it works fine when compiled with -O0 -m32.
> Will address that next week.
Ugh, -O2 -m32 -march=i686 works fine, -O2 -m32 -march=i686
From: Pan Li
When build with "-Werror=format-diag", there will be one misspelled
term args as below. This patch would like fix it by taking the term
arguments instead.
../../gcc/config/riscv/riscv-vector-builtins.cc: In function 'tree_node*
riscv_vector::resolve_overloaded_builtin(location_t,
Hi Florian,
that's been quite a bit. Thank you for putting this together so
comprehensively and thoughtfully, with examples and background!
Note many of my points are suggestions or questions, especially if phrased
as questions or using maybe or similar, so for your consideration.
On Fri, 2
> On 9 Feb 2024, at 23:21, Iain Sandoe wrote:
>
>
>
>> On 9 Feb 2024, at 10:56, Iain Sandoe wrote:
>>> On 8 Feb 2024, at 21:44, Jason Merrill wrote:
>>>
>>> On 2/8/24 12:55, Paolo Bonzini wrote:
On 2/8/24 18:16, Jason Merrill wrote:
>>>
>>
>> Hmm. In stage 1, when we
Hi!
Given the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837#c9
comment, the following patch just attempts to implement what I think
is best for ia32.
Compared to https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 ,
like that patch for _BitInt(64) or smaller it uses the smallest containing
Il 09/02/24 15:18, Matteo Italia ha scritto:
The Win32 threading model uses __gthr_win32_abs_to_rel_time to convert
the timespec used in gthreads to specify the absolute time for end of
the condition variables timed wait to a milliseconds value relative to
"now" to pass to the Win32
Hi!
torture/bitint-37.c test FAILed on i686-linux e.g. on
signed _BitInt(575) + unsigned _BitInt(575) -> signed _BitInt(575)
__builtin_add_overflow. With 64-bit limbs, we use 4 .UADDC calls in
the IL, 2 in a loop (which handles the first 8 limbs), then one partial
limb (we use 63 bits from that)
Hi!
The ia32 _BitInt support revealed a bug in floatbitint?d.c.
As can be even guessed from how the code is written in the loop,
the intention was to set inexact to non-zero whenever the remainder
after division wasn't zero, but I've ended up just checking whether
the 2 least significant limbs of
Hi!
I've tried last night to enable _BitInt support for i?86-linux, and
a few spots in libgcc emitted -Wshift-count-overflow warnings and clearly
didn't do what it was supposed to do.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux
(together with patch which enabled the
> Am 10.02.2024 um 10:41 schrieb Jakub Jelinek :
>
> Hi!
>
> In the previous patch I haven't touched the gcc diagnostic routines,
> using HOST_SIZE_T_PRINT* for those is obviously undesirable because we
> want the strings to be translatable. We already have %w[diox] for
> HOST_WIDE_INT
> Am 10.02.2024 um 10:46 schrieb Jakub Jelinek :
>
> Hi!
>
> As the following testcases show, the gimple-low outlining of assume
> magic functions handled volatile automatic vars (including
> parameters/results) like non-volatile ones except it copied volatile
> to the new PARM_DECL, which
> Am 10.02.2024 um 10:39 schrieb Jakub Jelinek :
>
> Hi!
>
> I went through suspicios %l in format strings of *printf family functions
> combined with casts to (long) or (unsigned long) and tried to find out the
> types of the original expressions that were cast.
> Quite a few had size_t
Hi!
As the following testcases show, the gimple-low outlining of assume
magic functions handled volatile automatic vars (including
parameters/results) like non-volatile ones except it copied volatile
to the new PARM_DECL, which has the undesirable effect that a load
from the volatile var is
Hi!
In the previous patch I haven't touched the gcc diagnostic routines,
using HOST_SIZE_T_PRINT* for those is obviously undesirable because we
want the strings to be translatable. We already have %w[diox] for
HOST_WIDE_INT arguments, this patch adds t and z modifiers for those.
Hi!
I went through suspicios %l in format strings of *printf family functions
combined with casts to (long) or (unsigned long) and tried to find out the
types of the original expressions that were cast.
Quite a few had size_t type, so I've used the new HOST_SIZE_T_PRINT_*
macros together with
WTF?
../../gcc/config/riscv/riscv-vector-builtins.cc: In function 'tree_node*
riscv_vector::resolve_overloaded_builtin(location_t, unsigned int, tree,
vec*)':
../../gcc/config/riscv/riscv-vector-builtins.cc:4633:65: error: misspelled term
'args' in format; use 'arguments' instead
54 matches
Mail list logo
