Hi!
Using unsigned long long int for fmt_size_t and "ll" for GCC_PRISZ
as broke the gengtype on i686-linux before the libiberty fix is certainly
unexpected. size_t is there unsigned int, so expected fmt_size_t is
unsigned int (or some other 32-bit type).
The problem was that I was comparing
On 2/10/24 15:27, Marek Polacek wrote:
Probably stage1 material but it should be safe...
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Yeah, OK, this should go in along with the 98388 patch.
-- >8 --
On the heels of r14-8903, this patch adds further complain parameters
so
On 2/12/24 16:49, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
OK.
-- >8 --
The current implementation of bytes::calc_crc computes the checksum one
byte at a time, and turns out to be quite slow, taking 5% and 15% of
time compiling and
While working on PERM related stuff, I can across that aarch64_evpc_reencode
was manually figuring out if we shrink the perm indices instead of
using vec_perm_indices::new_shrunk_vector; shrunk was added after reencode
was added.
Built and tested for aarch64-linux-gnu with no regressions.
On Fri, 2024-02-09 at 16:53 +, Joseph Myers wrote:
> On Fri, 1 Dec 2023, David Malcolm wrote:
>
> * diagnostic-core.h (emit_diagnostic_valist): New overload
> decl.
>
> This has broken regeneration of gcc.pot (overloads can't have the
> message
> extracted for translation in
> On Feb 12, 2024, at 5:27 AM, Rainer Orth
> wrote:
>
> The following patches have remained unreviewed for a week or more:
>
> testsuite: Fix c-c++-common/pr103798-2.c on Solaris [PR113706]
>https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644842.html
Jason commented.
On 2/10/24 13:37, Patrick Palka wrote:
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
Ping
On 2/6/24 17:07, Jason Merrill wrote:
Briefly tested that break-on-pass completion works. Oddly, it also works
without the patch, but the fix still seems worthwhile. OK for trunk?
-- 8< --
Recent python complains about this pattern with
SyntaxWarning: invalid escape sequence '\s'
On Mon, 12 Feb 2024 at 22:17, Patrick Palka wrote:
> On Mon, 12 Feb 2024, Paul Keir wrote:
>
> > A call to `basic_string::clear()` in the std::string move assignment
> operator leads to a constexpr error from an access of inactive union member
> `_M_local_buf` in the added test (`test_move()`).
On Mon, 12 Feb 2024, Paul Keir wrote:
> A call to `basic_string::clear()` in the std::string move assignment operator
> leads to a constexpr error from an access of inactive union member
> `_M_local_buf` in the added test (`test_move()`). Changing
> `__str._M_local_buf` to
Hi Jerry.
Am 12.02.24 um 22:28 schrieb Jerry D:
The attached patch fixes this PR by properly adjusting some variables
When using stream io. See log below. New test case included.
Regression tested on x86_64.
OK for trunk and backport?
the patch looks good to me.
As it is simple and very
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
The current implementation of bytes::calc_crc computes the checksum one
byte at a time, and turns out to be quite slow, taking 5% and 15% of
time compiling and streaming in the std module respectively. We
The attached patch fixes this PR by properly adjusting some variables
When using stream io. See log below. New test case included.
Regression tested on x86_64.
OK for trunk and backport?
Regards,
Jerry
ChangeLog:
libgfortran: Adjust bytes_left and pos for access="STREAM".
During
On 2/2/24 10:23, Rainer Orth wrote:
c-c++-common/pr103798-2.c FAILs on Solaris when compiled as C++:
FAIL: c-c++-common/pr103798-2.c -std=gnu++14 scan-assembler-not memchr
FAIL: c-c++-common/pr103798-2.c -std=gnu++17 scan-assembler-not memchr
FAIL: c-c++-common/pr103798-2.c -std=gnu++20
Dear all,
the attached patch fixes a mis-handling of optional dummy arguments
passed to optional dummy arguments of procedures with the bind(c)
attribute. When those procedures are expecting CFI descriptors,
there is no special treatment like a presence check necessary
that by default passes a
> Believe it or not, even though I have re-worked the internals of the
> lattices completely, the array itself is older than my involvement with
> GCC (or at least with ipa-cp.c ;-).
>
> So it being an array and not a vector is historical coincidence, as far
> as I am concerned :-). But that may
On 2/10/24 07:30, Iain Sandoe wrote:
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
> Am 12.02.2024 um 18:47 schrieb Jakub Jelinek :
>
> Hi!
>
> handle_cast handles the simple way all narrowing large/huge bitint to
> large/huge bitint conversions and also such widening conversions if we can
> assume that the most significant limb is processed using constant index
> and both
There is currently no support for matching at least x lines of assembly
(only scan-assembler-times). This patch would allow setting upper or lower
bounds.
Use case: using different scheduler descriptions and/or cost models will change
assembler output. Testing common functionality across tunes
On 2/12/24 12:30, Jakub Jelinek wrote:
Hi!
The C and C++ FEs when parsing attributes already canonicalize them
(i.e. if they start with __ and end with __ substrings, we remove those).
lookup_attribute already verifies in gcc_assert that the first character
of name is not an underscore, and
On 2/10/24 17:42, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK, thanks.
-- >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:
On Mon, Feb 12, 2024 at 01:15:55PM -0500, Marek Polacek wrote:
> On Mon, Feb 12, 2024 at 06:30:55PM +0100, Jakub Jelinek wrote:
> > The C and C++ FEs when parsing attributes already canonicalize them
> > (i.e. if they start with __ and end with __ substrings, we remove those).
> > lookup_attribute
On Mon, Feb 12 2024, Jan Hubicka wrote:
>> Hi,
>>
>> In PR 113476 we have discovered that ipcp_param_lattices is no longer
>> a POD and should be destructed. This patch does that, calling
>> destructor on each element of the array containing them when the
>> corresponding summary of a node is
A call to `basic_string::clear()` in the std::string move assignment operator
leads to a constexpr error from an access of inactive union member
`_M_local_buf` in the added test (`test_move()`). Changing `__str._M_local_buf`
to `__str._M_use_local_data()` in `operator=(basic_string&& __str)`
On Mon, Feb 12, 2024 at 06:30:55PM +0100, Jakub Jelinek wrote:
> Hi!
>
> The C and C++ FEs when parsing attributes already canonicalize them
> (i.e. if they start with __ and end with __ substrings, we remove those).
> lookup_attribute already verifies in gcc_assert that the first character
> of
On Sun, Feb 11, 2024 at 11:12 AM Mike Stump wrote:
>
> On Feb 10, 2024, at 10:07 AM, FX Coudert wrote:
> >
> > 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
> Hi,
>
> In PR 113476 we have discovered that ipcp_param_lattices is no longer
> a POD and should be destructed. This patch does that, calling
> destructor on each element of the array containing them when the
> corresponding summary of a node is freed. An alternative would be to
> change the
Hi!
handle_cast handles the simple way all narrowing large/huge bitint to
large/huge bitint conversions and also such widening conversions if we can
assume that the most significant limb is processed using constant index
and both lhs and rhs have same number of limbs.
But, the condition whether
Hi,
In PR 113476 we have discovered that ipcp_param_lattices is no longer
a POD and should be destructed. This patch does that, calling
destructor on each element of the array containing them when the
corresponding summary of a node is freed. An alternative would be to
change the
Hi!
The C and C++ FEs when parsing attributes already canonicalize them
(i.e. if they start with __ and end with __ substrings, we remove those).
lookup_attribute already verifies in gcc_assert that the first character
of name is not an underscore, and even lookup_scoped_attribute_spec doesn't
> Am 12.02.2024 um 18:14 schrieb Jakub Jelinek :
>
> Hi!
>
> This patch depends on the libiberty/vprintf-support.c change.
>
> Ok for trunk if that one is approved?
Ok
> 2024-02-12 Jakub Jelinek
>
>* gengtype.cc (adjust_field_rtx_def): Use HOST_SIZE_T_PRINT_UNSIGNED
>and cast
> Am 12.02.2024 um 18:13 schrieb Jakub Jelinek :
>
> Hi!
>
> As I wrote earlier and we've discussed on IRC, with the ia32 _BitInt
> enablement patch this testcase FAILs on ia32, there is nothing vectorized in
> there, even with -mavx512{vl,bw,dq}, so no dbgcnt messages are emitted.
>
> The
Hi!
This patch depends on the libiberty/vprintf-support.c change.
Ok for trunk if that one is approved?
2024-02-12 Jakub Jelinek
* gengtype.cc (adjust_field_rtx_def): Use HOST_SIZE_T_PRINT_UNSIGNED
and cast to fmt_size_t instead of %lu and cast to unsigned long.
---
Hi!
As I wrote earlier and we've discussed on IRC, with the ia32 _BitInt
enablement patch this testcase FAILs on ia32, there is nothing vectorized in
there, even with -mavx512{vl,bw,dq}, so no dbgcnt messages are emitted.
The following patch instead prunes it.
Bootstrapped/regtested on
This is a backport of the GCC 13 fix for PR111677 to the GCC 12 branch.
The only part of the patch that isn't a straight cherry-pick is due to
the TX iterator lacking TDmode for GCC 12, so this version adjusts
TX_V16QI accordingly.
Bootstrapped/regtested on aarch64-linux-gnu, the only changes in
Hi!
On 2023-10-20T12:51:03+0100, Andrew Stubbs wrote:
> I've committed this patch
... as commit c7ec7bd1c6590cf4eed267feab490288e0b8d691
"amdgcn: add -march=gfx1030 EXPERIMENTAL".
The RDNA2 ISA variant doesn't support certain instructions previous
implemented in GCC/GCN, so a number of
Hi,
This patch bumps the soname version of libphobos.
Each major release is not binary compatible with the previous.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to mainline.
Regards,
Iain.
---
PR d/113667
libphobos/ChangeLog:
* configure:
Hi,
This patch fixes an ICE triggered in the D front-end.
The cause of the ICE was that TYPE_DECLs were only being generated for
structs with members, not opaque structs.
PR d/113125
Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to mainline.
Regards,
Iain.
Hi,
This patch fixes code generation problem with passing objects by
invisible reference - because of a defined cpctor or dtor.
When generating the argument, check the isCalleeDestroyingArgs hook, and
force a TARGET_EXPR to be created if true, so that a reference to the
live object isn't passed
On Sat, 10 Feb 2024, Jakub Jelinek wrote:
> * c-format.cc (gcc_diag_length_specs): Add t and z modifiers.
> (PP_FORMAT_CHAR_TABLE, gcc_gfc_char_table): Add entries for t and
> z modifiers.
Please also add some tests of format checking for these modifiers in
Hi,
This patch merges the D front-end and core runtime library with upstream
dmd 11240a9663.
Included in the merge are the fix for PR113772, and new testsuite
directives to enable fixing PR104739.
D front-end changes:
- Import latest fixes from dmd v2.107.0.
D runtime changes:
On 2/9/24 02:44, Jakub Jelinek wrote:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644701.html
Introduce HOST_SIZE_T_PRINT_UNSIGNED etc. macros to fix LLP64 host build issue
Both have been successfully bootstrapped/regtested on x86_64-linux and
i686-linux, the latter has been
Hi,
> gcc/ChangeLog:
> * common/config/i386/cpuinfo.h (get_amd_cpu): Recognize znver5.
> * common/config/i386/i386-common.cc (processor_names): Add znver5.
> (processor_alias_table): Likewise.
> * common/config/i386/i386-cpuinfo.h (processor_types): Add new zen
>
On Mon, 12 Feb 2024 at 11:27, Jakub Jelinek wrote:
>
> On Mon, Feb 12, 2024 at 11:13:49AM +0100, Christophe Lyon wrote:
> > On Sun, 11 Feb 2024 at 06:56, Alexandre Oliva wrote:
> > >
> > > Hello, Christophe,
> > >
> > > On Feb 10, 2024, Christophe Lyon wrote:
> > >
> > > > gcc/
> > > >
On Mon, 12 Feb 2024 at 09:00, Richard Biener wrote:
>
> On Sat, Feb 10, 2024 at 10:21 PM Toon Moene wrote:
> >
> > 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
>
On Mon, Feb 12, 2024 at 2:35 PM Siddhesh Poyarekar wrote:
>
> On 2024-02-12 08:16, Martin Jambor wrote:
> >> This probably ties in somewhat with an idea David Malcolm had riffed on
> >> with me earlier, of caching files for diagnostics. If we could unify
> >> file accesses somehow, we could make
This patch marks a rev16 test as XFAIL for architectures having only
Thumb1 support. The generated code is functionally correct, but the
optimization is disabled when -mthumb is equivalent to Thumb1. Fixing
the root issue would requires changes that are not suitable for GCC14
stage 4.
More
On Mon, Feb 12, 2024 at 01:30:31PM +, Andrew Stubbs wrote:
> On 05/02/2024 13:04, Rainer Orth wrote:
> > Two libgomp tests XPASS on Solaris (any non-Linux target actually) since
> > their introduction:
> >
> > XPASS: libgomp.c/alloc-pinned-1.c execution test
> > XPASS:
On 2024-02-12 08:16, Martin Jambor wrote:
This probably ties in somewhat with an idea David Malcolm had riffed on
with me earlier, of caching files for diagnostics. If we could unify
file accesses somehow, we could make this happen, i.e. open/read files
as root and then do all execution as
On 2024-02-09 15:06, Joseph Myers wrote:
Ideally dependencies would be properly set up so that everything is built
in the original build, and ideally there would be no need to relink at
install time (I'm not sure of the exact circumstances in which it might be
needed, or on what OSes to e.g.
On 05/02/2024 13:04, Rainer Orth wrote:
Two libgomp tests XPASS on Solaris (any non-Linux target actually) since
their introduction:
XPASS: libgomp.c/alloc-pinned-1.c execution test
XPASS: libgomp.c/alloc-pinned-2.c execution test
The problem is that the test just prints
OS unsupported
and
The following patches have remained unreviewed for a week or more:
testsuite: Fix c-c++-common/pr103798-2.c on Solaris [PR113706]
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644842.html
Probably needs a C++ maintainer, although I've Cc'ed the testcase author
for good
Hi,
On Fri, Feb 09 2024, Siddhesh Poyarekar wrote:
> On 2024-02-09 10:38, Martin Jambor wrote:
>> If anyone is interested in scoping this and then mentoring this as a
>> Google Summer of Code project this year then now is the right time to
>> speak up!
>
> I can help with mentoring and reviews,
On Sun, Feb 11, 2024 at 02:54:18PM +1100, 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
Rainer Orth writes:
> As detailed in PR modula2/113888, the 32-bit libm2pim/target.c doesn't
> assemble in a Linux/sparc64 multilib build. However, the root cause is
> that the HAVE_EXP10* macros are never defined. While I was at it, I
> checked for other cases where the code uses HAVE_*
As detailed in PR modula2/113888, the 32-bit libm2pim/target.c doesn't
assemble in a Linux/sparc64 multilib build. However, the root cause is
that the HAVE_EXP10* macros are never defined. While I was at it, I
checked for other cases where the code uses HAVE_* macros that are
missing from
When we use get_ref_base_and_extent during VN and that ends up using
global ranges to restrict the range of a ref we have to take care
of not using the same expression in the hashtable as for a ref that
could not use that global range. The following attempts to ensure
this by applying similar
Committed, thanks Robin.
Pan
-Original Message-
From: Robin Dapp
Sent: Monday, February 12, 2024 8:09 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: rdapp@gmail.com; juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Robin Dapp
; Jeff Law
Subject: Re: [PATCH v1] RISC-V: Fix misspelled
OK.
Regards
Robin
Bootstrapped and regtested on aarch64 and ppc64le with languages=all (no
additional test failures seen). Bootstrapped language=m2 on Debian,
SUSE, Redhat and also built with clang. Does the patch seem reasonable
- in particular lang.opt?
-- >8 --
PR modula2/113836 gm2 does not dump gimple or
CC Robin and Jeff.
Pan
-Original Message-
From: Li, Pan2
Sent: Saturday, February 10, 2024 7:04 PM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Li, Pan2 ; Wang, Yanzhang
; kito.ch...@gmail.com
Subject: [PATCH v1] RISC-V: Fix misspelled term args in error_at message
From: Pan
This code will link against parts of the startup code
from AVR-LibC when it is needed to init bit-field FLMAP.
Johann
--
AVR: target/112944 - Addendum: Link code to initialize NVMCTRL_CTRLB.FLMAP
For devices that see a part for the flash memory in the RAM address space,
bit-field
On Mon, Feb 12, 2024 at 11:13:49AM +0100, Christophe Lyon wrote:
> On Sun, 11 Feb 2024 at 06:56, Alexandre Oliva wrote:
> >
> > Hello, Christophe,
> >
> > On Feb 10, 2024, Christophe Lyon wrote:
> >
> > > gcc/
> > > * Makefile.in: Add no-info dependency.
> > > * configure.ac:
This makes sure to elide degenerate virtual PHIs when moving stores
across early exits.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard.
PR tree-optimization/113863
* tree-vect-data-refs.cc (vect_analyze_early_break_dependences):
Record crossed
On Sun, 11 Feb 2024 at 06:56, Alexandre Oliva wrote:
>
> 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.
> > *
Hi Kwok,
Kwok Cheung Yeung wrote:
Oops. I thought exactly the same thing yesterday, but forgot to add
the changes to my commit! Here is the updated version.
I regard(ed) this change as obvious - hence, I missed to reply.
But for completeness: LGTM.
I think it would be useful to commit this
On Sat, Feb 10, 2024 at 10:21 PM Toon Moene wrote:
>
> 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:
>
>
67 matches
Mail list logo
