On Sat, 2024-11-02 at 14:13 +0800, Lulu Cheng wrote:
>
> 在 2024/11/2 上午1:10, Xi Ruoyao 写道:
> > On Thu, 2024-10-31 at 23:58 +0800, Xi Ruoyao wrote:
> >
> > /* snip */
> >
> > > ---
> > >
> > > Now running bootstrap & regtest. Posted early as a context for some
> > > LLVM patch. I'll post the r
在 2024/11/2 上午1:10, Xi Ruoyao 写道:
On Thu, 2024-10-31 at 23:58 +0800, Xi Ruoyao wrote:
/* snip */
---
Now running bootstrap & regtest. Posted early as a context for some
LLVM patch. I'll post the regtest result once it finishes.
Done, no regressions.
The LLVM patch is https://github.com/
Alexander Monakov writes:
> On Fri, 1 Nov 2024, Jan Hubicka wrote:
>
>> > I have a vague memory that one of the tests in SPEC has a loop that
>> > tries to malloc, doubling the size each time, until it fails. Would
>> > the patch change the behavior of such a loop?
>>
>> If the resulting alloca
On Oct 31, 2024, Jeff Law wrote:
> On 10/25/24 5:57 AM, Alexandre Oliva wrote:
>> The upcoming move of fold_truth_andor to ifcombine brings with it
>> the
>> possibility of TRUTH_ANDIF cond exprs. Handle them by splitting the
>> cond so as to best use both BB insertion points, but only if they'r
Alexandre Oliva writes:
> Refactor ifcombine_ifandif, moving the common code from the various
> paths that apply the combined condition to a new function.
BTW, forgive the possibly silly question, but I don't see any testcases
for the series. Would it be possible to add any?
>
>
> for gcc/Chan
On Oct 30, 2024, Richard Biener wrote:
> As you are only doing bitmap_set_bit/bitmap_bit_p consider doing
>bitmap_tree_view (used);
Ah, nice, I didn't know about this alternate representation. Thanks.
> But we don't have any artificial limit on the number of stmts in the
> middle block, r
gcc/ChangeLog:
* doc/invoke.texi: Remove the non-existent option
'-msmall-data-limit' and add a description of '-G'.
---
gcc/doc/invoke.texi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index fd6c0c44709..
TARGET_ASM_ALIGNED_{HI,SI,QI}_OP are defined repeatedly and deleted.
gcc/ChangeLog:
* config/loongarch/loongarch-builtins.cc
(loongarch_builtin_vectorized_function): Delete.
(LARCH_GET_BUILTIN): Delete.
* config/loongarch/loongarch-protos.h
(loongarch_built
Lulu Cheng (2):
LoongArch: Remove redundant code.
LoongArch: Modify the document to remove options that don't exist.
gcc/config/loongarch/loongarch-builtins.cc | 102 -
gcc/config/loongarch/loongarch-protos.h| 1 -
gcc/config/loongarch/loongarch.cc | 8 -
I was looking to clean up an old patch I'm carrying in my tester. My
first thought was that ft32 was likely going to be deprecated because it
wasn't using LRA -- which in turn would mean the patch in question could
just be removed.
But then I checked, ft32 has an LRA option and if turned on
The ft32 has never supported trampolines, but the target supports bits
in the dejagnu framework weren't appropriately updated.
Fixed thusly.
Jeff
commit 6a2e8913df605e62f20833a6e688ea1950147edc
Author: Jeff Law
Date: Fri Nov 1 20:31:11 2024 -0600
[committed] ft32 doesn't support trampol
On Oct 30, 2024, Richard Biener wrote:
> no need for this brace pair?
No need indeed, but this bit becomes the else branch of an if introduced
in #5. I figured the #5 patch would be cleaner if I kept this bit
braced and indented.
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/b
On Oct 27, 2024, Jeff Law wrote:
> On 10/25/24 5:52 AM, Alexandre Oliva wrote:
>> Refactor ifcombine_ifandif, moving the common code from the various
>> paths that apply the combined condition to a new function.
>>
>> for gcc/ChangeLog
>> * tree-ssa-ifcombine.cc (ifcombine_replace_cond): Factor
在 2024/11/2 上午1:36, Xi Ruoyao 写道:
Without optimization, GCC does not emit a jump table for the test case.
I'm not sure if the test case has been wrong in the first place or
something has changed in these months...
It was in the r15-4756 that turned -fjump-tables off at O0 optimization.
I wa
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-4858-g0cb6078ca83f54.
gcc/analyzer/ChangeLog:
* analyzer.cc: Include "make-unique.h". Convert "to_json"
functions to use std::unique_ptr.
* call-string.cc:
On 10/30/24 6:33 AM, Jovan Vukic wrote:
Thanks for the feedback on the first version of the patch. Accordingly:
I have corrected the code formatting as requested. I added new tests to
the existing file phi-opt-11.c, instead of creating a new one.
I performed testing before and after applying
On Wed, Oct 30, 2024 at 5:34 AM Jovan Vukic wrote:
>
> Thanks for the feedback on the first version of the patch. Accordingly:
>
> I have corrected the code formatting as requested. I added new tests to
> the existing file phi-opt-11.c, instead of creating a new one.
The previous practice has bee
On Tue, Oct 29, 2024 at 10:10 AM Andrew Pinski wrote:
>
> On Tue, Oct 29, 2024 at 5:59 AM Richard Biener
> wrote:
> >
> > On Tue, Oct 29, 2024 at 4:29 AM Andrew Pinski
> > wrote:
> > >
> > > r0-126134-g5d2a9da9a7f7c1 added support for circuiting and combing the ifs
> > > into using either AND o
On Sat, Oct 26, 2024 at 7:25 AM H.J. Lu wrote:
>
> On Sun, Oct 20, 2024 at 6:42 AM H.J. Lu wrote:
> >
> > On Sun, Oct 13, 2024, 10:07 AM H.J. Lu wrote:
> >>
> >> Adjust BLKmode argument size for parameter alignment for sibcall check.
> >>
> >> gcc/
> >>
> >> PR middle-end/117098
> >> * calls.cc
For targets, like x86, which define TARGET_PROMOTE_PROTOTYPES to return
true, all integer arguments smaller than int are passed as int:
[hjl@gnu-tgl-3 pr14907]$ cat x.c
extern int baz (char c1);
int
foo (char c1)
{
return baz (c1);
}
[hjl@gnu-tgl-3 pr14907]$ gcc -S -O2 -m32 x.c
[hjl@gnu-tgl-3 p
There is one more problem, that this patch does not address, and that is
that there are warnings like below, but I do not know what's causing them.
.../gcc/testsuite/gcc.target/arm/pr117408-1.c:8:9: warning: 'pure' attribute on
function returning 'void' [-Wattributes]
.../gcc/testsuite/gcc.target
It eas an existing branch. I will get a scrtach branch and do
everything from scratch the beginning of the week.
IM always suspicious there is something laying around when its been
there a while :-) Who knows what I was doing with it 8 months ago :-)
Let me know if these feels more stable..
On 31/10/24 20:09 +, Jonathan Wakely wrote:
Tested x86_64-linux. Is the g++ test change OK?
Also available for review at:
https://forge.sourceware.org/gcc/gcc-TEST/pulls/4
-- >8 --
These headers make no sense for C++ programs, because they either define
different content to the correspondi
no, I mean those are on the branch as is... at least when I extracted
and built stage 1 release gcc14 branch. UNless there was something wrong
with my build which I havent verified.. it was just a first cut.
The converted patch does not contribute any extra failures.
Andrew
On 11/1/24 16:06,
On Fri, Nov 01, 2024 at 05:00:05PM -0400, Andrew MacLeod wrote:
> no, I mean those are on the branch as is... at least when I extracted and
> built stage 1 release gcc14 branch. UNless there was something wrong with my
> build which I havent verified.. it was just a first cut.
Strange. I certain
On 01/11/24 20:56 +, Jonathan Wakely wrote:
On 31/10/24 20:09 +, Jonathan Wakely wrote:
Tested x86_64-linux. Is the g++ test change OK?
Also available for review at:
https://forge.sourceware.org/gcc/gcc-TEST/pulls/4
-- >8 --
These headers make no sense for C++ programs, because they e
This patch adds test cases for the Function Multi-Versioning (FMV)
feature for RISC-V, which reuses the existing test cases from the
aarch64 and ported them to RISC-V.
Signed-off-by: Yangyu Chen
gcc/testsuite/ChangeLog:
* g++.target/riscv/mv-symbols1.C: New test.
* g++.target/ri
This patch implements the TARGET_MANGLE_DECL_ASSEMBLER_NAME for RISC-V.
This is used to add function multiversioning suffixes to the assembler
name.
Signed-off-by: Yangyu Chen
gcc/ChangeLog:
* config/riscv/riscv.cc
(riscv_mangle_decl_assembler_name): New function.
(TARGE
This patch implements TARGET_COMPARE_VERSION_PRIORITY and
TARGET_OPTION_FUNCTION_VERSIONS for RISC-V.
The TARGET_COMPARE_VERSION_PRIORITY is implemented to compare the
priority of two function versions based on the rules defined in the
RISC-V C-API Doc PR #85:
https://github.com/riscv-non-isa/ris
This patch implements the TARGET_GENERATE_VERSION_DISPATCHER_BODY and
TARGET_GET_FUNCTION_VERSIONS_DISPATCHER for RISC-V. This is used to
generate the dispatcher function and get the dispatcher function for
function multiversioning.
This patch copies many codes from commit 0cfde688e213 ("[aarch64]
This patch implements the TARGET_OPTION_VALID_VERSION_ATTRIBUTE_P for
RISC-V. This hook is used to process attribute
((target_version ("..."))).
As it is the first patch which introduces the target_version attribute,
we also set TARGET_HAS_FMV_TARGET_ATTRIBUTE to 0 to use "target_version"
for func
This patch implements the riscv_minimal_hwprobe_feature_bits feature
for the RISC-V target. The feature bits are defined in the
libgcc/config/riscv/feature_bits.c to provide bitmasks of ISA extensions
that defined in RISC-V C-API. Thus, we need a function to generate the
feature bits for IFUNC reso
This patch adds the priority syntax parser to support the Function
Multi-Versioning (FMV) feature in RISC-V. This feature allows users to
specify the priority of the function version in the attribute syntax.
Chnages based on RISC-V C-API PR:
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/85
Some architectures may use ',' in the attribute string, but it is not
used as the separator for different targets. To avoid conflict, we
introduce a new macro TARGET_CLONES_ATTR_SEPARATOR to separate different
clones.
As an example, according to RISC-V C-API Specification [1], RISC-V allows
',' in
This patch series adds support for Function Multi-Versioning (FMV) to
RISC-V. The FMV feature allows users to specify multiple versions of a
function and select the version at runtime based on the target_clones
and target_version attributes, which follow the RISC-V C-API Docs [1]
and the existing p
On Linux/x86_64,
100751c7905d6866540ca243135629994d3fd032 is the first bad commit
commit 100751c7905d6866540ca243135629994d3fd032
Author: Haochen Jiang
Date: Fri Nov 1 15:59:47 2024 +0800
i386: Do not allow pointer conversion for CMPccXADD intrin under -O0
caused
FAIL: gcc.target/i386/cm
Replace some `__cplusplus > 201402L` preprocessor checks with more
expressive checks for the appropriate feature test macros.
libstdc++-v3/ChangeLog:
* include/bits/unordered_map.h: Check __glibcxx_node_extract and
__glibcxx_unordered_map_try_emplace instead of __cplusplus.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h: Improve comments.
---
Tested x86_64-linux. Pushed to trunk.
libstdc++-v3/include/bits/hashtable.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/include/bits/hashtable.h
b/libstdc++-v3/include/bit
On Fri, Nov 01, 2024 at 04:47:35PM +0800, Haochen Jiang wrote:
> gcc/ChangeLog:
>
> * builtins.cc (expand_builtin_prefetch): Use IN_RANGE to
> avoid second usage of INTVAL.
I doubt this has been actually tested.
> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -1297,7 +1297,7 @
On 10/31/24 21:26, Kito Cheng wrote:
On Thu, Oct 31, 2024 at 6:59 PM Yangyu Chen wrote:
On Oct 31, 2024, at 18:14, Kito Cheng wrote:
diff --git a/gcc/config/riscv/riscv-target-attr.cc
b/gcc/config/riscv/riscv-target-attr.cc
index 087fbae77b0..4c85ad60b72 100644
--- a/gcc/config/riscv/ris
Maybe. The bitwise_and op1_range is very complicated.. I think its
heavily used, so I would be surprised if it didn't. bitwise or was
doing nothing at all and showed up immediately when I tried a few
things. I think i just happned to hit it "lucky". It didnt fail any
existing cases, just t
On Fri, Nov 01, 2024 at 04:00:17PM -0400, Andrew MacLeod wrote:
> Maybe. The bitwise_and op1_range is very complicated.. I think its heavily
> used, so I would be surprised if it didn't. bitwise or was doing nothing
> at all and showed up immediately when I tried a few things. I think i just
>
On Fri, Nov 01, 2024 at 03:25:37PM -0400, Andrew MacLeod wrote:
> When experimenting with more complex flow for the assume pass, I found a
> case where we were not as precise as we should be, but it was because
> range-ops hadn't been taught that if the LHS of a bitwise OR was positive,
> that the
On 10/31/24 17:51, Kito Cheng wrote:
Could you add a test case for what you try to handle?
After carefully reviewing the code, I think this can be dropped in the
next revision.
The intuition of this patch is to handle both target and target_versions
specified in the attributes. But afte
On Thu, Oct 31, 2024 at 04:05:30PM -0400, James K. Lowden wrote:
> >From ccb8a64c97461d792fdc39db249980a9ecb63b4bbld.patch 4 Oct 2024 12:01:22
> >-0400
> From: "James K. Lowden"
> Date: Fri 01 Nov 2024 01:50:33 PM EDT
> Subject: [PATCH] Add 'cobol' to 10 files
>
> ChangeLog
> * Makefile.d
On Thu, Oct 31, 2024 at 04:05:25PM -0400, James K. Lowden wrote:
> On Tue, 29 Oct 2024 18:52:01 +0100
> Jakub Jelinek wrote:
>
> > > This 1st patch includes a stub cobol/ChangeLog, if that helps.
> >
> > It needs to go into a separate commit (i.e. register the new ChangeLog
> > locations in on
The PR exposed latent issues with the assume pass. Upon deeper
investigation, the original approach was a bit naive, and I found other
flaws. There are numerous changes.
The original mechanism made a single pass working back from the return
statement. This fails when flow starts to get a bit
When experimenting with more complex flow for the assume pass, I found a
case where we were not as precise as we should be, but it was because
range-ops hadn't been taught that if the LHS of a bitwise OR was
positive, that the 2 RHS operands must also be positive.
The testcase is simple a twea
The next patch requires a fur_edge class. It needs to calculate ranges
on both edges and statements, and this provides a way to do both without
having different routines.
This patch simply moves it out of the source file and into
gimple-range-fold.h where it is generally accessible.
Bootstr
On 2024-11-01 19:40, Richard Earnshaw (lists) wrote:
On 24/10/2024 09:50, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
As these tests are set to execute and require neon hardware to do so,
add the missing dg-require-effective-target arm_neon_hw.
gcc/testsuite/ChangeLog:
On Fri, Nov 01, 2024 at 12:28:52PM -0400, Jason Merrill wrote:
> Can this block be
>
> if (aligned_allocation_fn_p (decl))
> args = TREE_CHAIN (args);
>
> ?
Yes.
> > + && TREE_CODE (t) == RECORD_TYPE
> > + && DECL_NAMESPACE_STD_P (CP_TYPE_CONTEXT (t))
> > +
On 19/10/2024 19:11, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> The expected assembler in the test case assumes -marm, so explicily
> require it.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/acle/data-intrinsics-assembly.c: Use
> effective-target ar
On 24/10/2024 20:12, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> With the changes in r15-1579-g792f97b44ff, the test_vmul_n_16x8 function
> does not contain any vdup.16 q* r* instruction with -mfloat-abi=softfp.
>
> The differnce between r15-1578-g5185274c76c and r15-1579-g792f97b44ff
>
On 24/10/2024 09:50, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> As these tests are set to execute and require neon hardware to do so,
> add the missing dg-require-effective-target arm_neon_hw.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/memset-inline-4.c
On 19/10/2024 18:23, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> Similar to PR113502, but for non-aarch64 test.
> The test started to fail after r14-7243-gafac1bd3365.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/vect-early-break-cbranch.c: Ignore exact
>
On Sat, 26 Oct 2024 13:41:32 -0400
"James K. Lowden" wrote:
Below is a revised patch set incorporating recent feedback. Changes:
* 2 patches: creation of gcc/cobo/ChangeLog
now precedes "patch #1", the metafile patch
* dead code (#if 0) removed
* One new file included: changes to gcc/dwarf2out
On Tue, 29 Oct 2024 18:52:01 +0100
Jakub Jelinek wrote:
> > This 1st patch includes a stub cobol/ChangeLog, if that helps.
>
> It needs to go into a separate commit (i.e. register the new ChangeLog
> locations in one commit, let gccadmins update the ~gccadmin copy of
> it, then commit a patch
> From: Xi Ruoyao
> Sent: Saturday, November 2, 2024 1:16 AM
>
> How can you use "read-shared" as an identifier? It's not allowed by all C
> standard versions.
>
I did a last minute change to fix that but unfortunately did not get into
my patch.
My apology.
Thx,
Haochen
> From: Xi Ruoyao
> Sent: Saturday, November 2, 2024 1:50 AM
\
> > On 11/1/24 11:16 AM, Xi Ruoyao wrote:
> > > How can you use "read-shared" as an identifier? It's not allowed by
> > > all C standard versions.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > * gcc.c-torture/execute/builtin-pref
This breaks build on hppa64-hp-hpux11.11. This target has clock_gettime
but it doesn't have CLOCK_MONOTONIC. It has CLOCK_REALTIME. I modified
timevar.cc as follows to restore build.
Dave
---
diff --git a/gcc/timevar.cc b/gcc/timevar.cc
index e12775e6ff3..412d9b62a8f 100644
--- a/gcc/timevar.c
On Fri, 2024-11-01 at 11:41 -0600, Jeff Law wrote:
>
>
> On 11/1/24 11:16 AM, Xi Ruoyao wrote:
> > How can you use "read-shared" as an identifier? It's not allowed by
> > all
> > C standard versions.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.c-torture/execute/builtin-prefetch-1.c (rws
Thank you for the reviews! I attached a patch that fixes the problems.
>> On 31 Oct 2024, at 11:50, Richard Sandiford
>> wrote:
>>
>> "Yuta Mukai (Fujitsu)" writes:
>>> Hello,
>>>
>>> This patch adds initial support for FUJITSU-MONAKA CPU, which we are
>>> developing.
>>> This is the slides
On 11/1/24 11:16 AM, Xi Ruoyao wrote:
How can you use "read-shared" as an identifier? It's not allowed by all
C standard versions.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/builtin-prefetch-1.c (rws): Use
"read_shared" instead of "read-shared" as the identifier for
Without optimization, GCC does not emit a jump table for the test case.
I'm not sure if the test case has been wrong in the first place or
something has changed in these months...
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/jump-table-annotate.c
(dg-additional-options): Add -
This isn't nested within another #if group so shouldn't be indented like
this.
libstdc++-v3/ChangeLog:
* libsupc++/typeinfo: Remove whitespace in #endif
---
Pushed as obvious.
libstdc++-v3/libsupc++/typeinfo | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v
On Tue, 2024-10-29 at 07:49 -0600, Jeff Law wrote:
>
>
> On 10/29/24 7:10 AM, Xi Ruoyao wrote:
> > On Fri, 2024-10-11 at 02:54 +0800, Xi Ruoyao wrote:
> > > At least two ports (hppa and loongarch) need to set SECTION_RELRO for
> > > .data.rel.ro{,.local} in section_type_flags (PR52999 and PR11688
We currently crash upon the following invalid code (notice the "void
void**" parameter)
=== cut here ===
using size_t = decltype(sizeof(int));
void *operator new(size_t, void void **p) noexcept { return p; }
int x;
void f() {
int y;
new (&y) int(x);
}
=== cut here ===
The problem is that
Patch 5 has been changed to
"," HOST_WIDE_INT_PRINT_UNSIGNED "\n",
Patch 6 has been updated here
Patch 7 will be dropped.
Patch 9 will be dropped.
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667205.html
And the patch series will be extended with one more patch to handle an issue
wi
How can you use "read-shared" as an identifier? It's not allowed by all
C standard versions.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/builtin-prefetch-1.c (rws): Use
"read_shared" instead of "read-shared" as the identifier for
enum value.
* gcc.dg/builtin-
Hi Ajit,
Sorry for not reviewing this sooner. For a while I thought this patch
was with Richard S to look at the rtl-ssa changes, but we've now agreed
that I should take a look at it.
I noticed that this breaks the build on aarch64. I suspect you got an
email from the Linaro CI about this? You
Wednesday, October 30, 2024
Richard Sandiford wrote:
> So for the change in question, I was expecting, say, a 1024-byte-aligned
> float[3] to be defined using:
>
> .lcomm array, 1024
Thank you for noticing this. The patch series has been rebased from the
upstream
before reproducing the
On Thu, 2024-10-31 at 23:58 +0800, Xi Ruoyao wrote:
/* snip */
> ---
>
> Now running bootstrap & regtest. Posted early as a context for some
> LLVM patch. I'll post the regtest result once it finishes.
Done, no regressions.
The LLVM patch is https://github.com/llvm/llvm-project/pull/114514.
On Fri, 2024-11-01 at 07:36 +0100, Tobias Burnus wrote:
> Am 31.10.24 um 21:57 schrieb David Malcolm:
> > On Thu, 2024-10-31 at 11:36 -0700, Andrew Pinski wrote:
> > > This is recorded as
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117361 already.
> > > I think one idea is to set LANG=C befo
On Fri, Nov 1, 2024 at 3:51 PM Jeff Law wrote:
>
> On 11/1/24 8:45 AM, Uros Bizjak wrote:
> > On Fri, Nov 1, 2024 at 2:18 PM Jeff Law wrote:
> >>
> >>
> >>
> >> On 11/1/24 5:34 AM, Uros Bizjak wrote:
> >>> Stack pointer modifications in asm are currently not flagged in
> >>> crtl->sp_is_unchangin
On Fri, 2024-11-01 at 11:22 +0800, Xi Ruoyao wrote:
> On Thu, 2024-10-31 at 23:18 +, Joseph Myers wrote:
> > On Thu, 31 Oct 2024, David Malcolm wrote:
> >
> > > That said, I think setting LANG=C when running selftests is
> > > probably
> > > the best solution. How does the attached (untested)
On 10/31/24 4:10 AM, Jakub Jelinek wrote:
Hi!
cxx_init_decl_processing predeclares 12 out of the 20 replaceable global
new/delete operators and sets DECL_IS_REPLACEABLE_OPERATOR on those.
But it doesn't handle the remaining 8, in particular
void* operator new(std::size_t, const std::nothrow_t&)
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-4841-g36a92c3829ba7a.
gcc/analyzer/ChangeLog:
PR analyzer/117373
* infinite-loop.cc
(infinite_loop_diagnostic::describe_final_event): Fix
-Wunused-parameter warning
Signed-off-by:
libstdc++-v3/ChangeLog:
* testsuite/23_containers/unordered_set/pr115285.cc: Include
missing header for std::vector.
---
Pushed as obvious.
libstdc++-v3/testsuite/23_containers/unordered_set/pr115285.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libstdc
On 10/31/24 4:18 AM, Jakub Jelinek wrote:
Hi!
Now that C++23 has been finally published, the following patch attempts
to mention it in the option descriptions and documentation.
Given that it has been published about 1.5 years after being finalized
and has the 14882:2024 document number pair rat
On 10/31/24 6:09 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
In cases like the linked PR we sometimes get mutually recursive
dependencies that both rely on the other to have been streamed as part
of their merge key information. In the li
On 10/31/24 6:43 AM, Paul Iannetta wrote:
gcc/c-family/ChangeLog:
* c-pragma.cc (struct pragma_pp_data): Use (struct
internal_pragma_handler);
(c_register_pragma_1): Always register name and space for all pragmas.
If we're using the _pp data structure for all pragmas now, I'd
On 10/31/24 4:09 PM, Jonathan Wakely wrote:
Tested x86_64-linux. Is the g++ test change OK?
Yes.
Also available for review at:
https://forge.sourceware.org/gcc/gcc-TEST/pulls/4
-- >8 --
These headers make no sense for C++ programs, because they either define
different content to the corresp
v2: split off movsf/df pattern fixes, remove some guality xfails that now pass
The early scheduler takes up ~33% of the total build time, however it doesn't
provide a meaningful performance gain. This is partly because modern OoO cores
need far less scheduling, partly because the scheduler tends
The IRA combine_and_move pass runs if the scheduler is disabled and aggressively
combines moves. The movsf/df patterns allow all FP immediates since they rely
on a split pattern. However splits do not happen during IRA, so the result is
extra literal loads. To avoid this, use a more accurate ch
On 11/1/24 5:07 AM, Simon Martin wrote:
Since r10-3793-g1a37b6d9a7e57c, we ICE upon the following valid code
with -std=c++17 and above
=== cut here ===
struct Base {
unsigned int *intarray;
};
template struct Sub : public Base {
bool Get(int i) {
return (Base::intarray[++i] == 0);
On 11/1/24 5:29 AM, Simon Martin wrote:
The testcase in PR101887 has been working since the fix for PR104846,
via r12-7599-gac8310dd122172.
This patch simply adds the case to the testsuite.
OK.
Successfully tested on x86_64-pc-linux-gnu.
PR c++/101887
gcc/testsuite/ChangeLog:
On 10/31/24 5:13 AM, Nathaniel Shead wrote:
On Fri, Oct 25, 2024 at 11:25:15AM -0400, Jason Merrill wrote:
On 10/24/24 5:10 PM, Nathaniel Shead wrote:
On Thu, Oct 24, 2024 at 12:05:18PM -0400, Jason Merrill wrote:
On 10/24/24 3:25 AM, Nathaniel Shead wrote:
I wasn't sure whether I should incl
On 8/22/24 8:02 PM, Nathaniel Shead wrote:
On Thu, Aug 22, 2024 at 02:20:14PM -0400, Patrick Palka wrote:
On Mon, 12 Aug 2024, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
I tried to implement a remapping of the slots for TARGET_EXPRs for the
FIXME b
On 10/29/24 11:31 AM, Jakub Jelinek wrote:
On Fri, Oct 25, 2024 at 12:52:41PM -0400, Jason Merrill wrote:
This does seem like a hole in the wording. I think the clear intent is that
the name/partition must neither be macro-expanded nor come from macro
expansion.
I'll defer filing the DR and f
On Fri, Nov 01, 2024 at 10:00:29AM +0100, Thomas Koenig wrote:
>
> during testing, I noticed that parameters of the form
> - mod(u1,u2) were rejected with an unknown type. The fix
> is straightforward, but required an adjustment to another
> test case.
>
> Regression-tested. OK for trunk?
>
Ye
On 11/1/24 8:45 AM, Uros Bizjak wrote:
On Fri, Nov 1, 2024 at 2:18 PM Jeff Law wrote:
On 11/1/24 5:34 AM, Uros Bizjak wrote:
Stack pointer modifications in asm are currently not flagged in
crtl->sp_is_unchanging due to RTX pointer comparison in
notice_stack_pointer_modification_1. Point
On Fri, Nov 1, 2024 at 2:18 PM Jeff Law wrote:
>
>
>
> On 11/1/24 5:34 AM, Uros Bizjak wrote:
> > Stack pointer modifications in asm are currently not flagged in
> > crtl->sp_is_unchanging due to RTX pointer comparison in
> > notice_stack_pointer_modification_1. Pointer comparison does not detect
On 01/11/2024 11:24, Richard Earnshaw (lists) wrote:
> On 01/11/2024 11:22, Jakub Jelinek wrote:
>> On Fri, Nov 01, 2024 at 11:12:29AM +, Richard Earnshaw (lists) wrote:
>>> As Jakub said in the PR, this is really just papering over a general
>>> problem in the compiler. As such, it's OK for
On Fri, Nov 01, 2024 at 01:34:45PM +0100, Jan Hubicka wrote:
> >
> > malloc(SIZE_MAX / 2 + 1) does not succeed.
>
> Is malloc required to return NULL for block of half of address size or
> it is glibc behavior? Some time ago we was discussing possibility to
I don't see C23 saying that explicitly
On Fri, Nov 01, 2024 at 02:07:26PM +0100, Jan Hubicka wrote:
> > On Fri, Nov 01, 2024 at 01:34:45PM +0100, Jan Hubicka wrote:
> > > >
> > > > malloc(SIZE_MAX / 2 + 1) does not succeed.
> > >
> > > Is malloc required to return NULL for block of half of address size or
> > > it is glibc behavior? S
On 11/1/24 5:34 AM, Uros Bizjak wrote:
Stack pointer modifications in asm are currently not flagged in
crtl->sp_is_unchanging due to RTX pointer comparison in
notice_stack_pointer_modification_1. Pointer comparison does not detect
that "(reg/v:DI 7 sp [ current_stack_pointer ])" and "(reg/f:D
> On Fri, Nov 01, 2024 at 01:34:45PM +0100, Jan Hubicka wrote:
> > >
> > > malloc(SIZE_MAX / 2 + 1) does not succeed.
> >
> > Is malloc required to return NULL for block of half of address size or
> > it is glibc behavior? Some time ago we was discussing possibility to
>
> I don't see C23 saying
Hi!
We incorrectly accept some invalid declare variant cases as if declare
variant wasn't there, in particular if a function template has some dependent
arguments and variant name lookup fails, because that is during
fn_type_unification with complain=tf_none, it just sets it to error_mark_node
and
>
> On Fri, 1 Nov 2024, Jan Hubicka wrote:
>
> > > I have a vague memory that one of the tests in SPEC has a loop that
> > > tries to malloc, doubling the size each time, until it fails. Would
> > > the patch change the behavior of such a loop?
> >
> > If the resulting allocation is unused exce
> On Fri, Nov 01, 2024 at 11:39:13AM +0100, Jan Hubicka wrote:
> > The testcase does:
> > /* { dg-additional-options "-O3 -fsanitize=undefined" } */
> >
> > void memory_exhausted();
> > void memcheck(void *ptr) {
> > if (ptr) /* { dg-warning "leak" } */
> > memory_exhausted();
> > }
> >
> >
1 - 100 of 132 matches
Mail list logo
