On Wed, Mar 1, 2023 at 12:07 AM Andrew Pinski via Gcc-patches
wrote:
>
> On Tue, Feb 28, 2023 at 3:02 PM Kwok Cheung Yeung
> wrote:
> >
> > Hello
> >
> > This patch implements the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
> > target hook for the AMD GCN architecture, such that when vectorized
On Thu, Feb 16, 2023, 11:10 LIU Hao via Gcc-patches
wrote:
>
> --
> Best regards,
> LIU Hao
>
Ping
>
Hi Richard, hi all,
On 01.03.23 09:18, Richard Biener via Gcc-patches wrote:
I thought we were moving towards using the simd attribute instead and
moving away from these kind of patches.
Though since gcn is a special target that including math.h normally
does not happen for offloading this migh
The function slpeel_can_duplicate_loop_p fails to verify we can
copy blocks, instead slpeel_tree_duplicate_loop_to_edge_cfg does
but that's too late. The following fixes this, also simplifying
error reporting which is somewhat pointless if we ICE immediately.
Bootstrapped and tested on x86_64-unk
Hi!
When these tree codes were introduced, expand_debug_expr hasn't been
updated to handle them. For the VEC_*_EXPR we currently mostly punt, the
non-vector ones can be handled easily. In release compilers this doesn't
ICE, but with checking we ICE so that we make sure to handle all the needed
t
On Wed, 1 Mar 2023, Jakub Jelinek wrote:
> Hi!
>
> When these tree codes were introduced, expand_debug_expr hasn't been
> updated to handle them. For the VEC_*_EXPR we currently mostly punt, the
> non-vector ones can be handled easily. In release compilers this doesn't
> ICE, but with checking
On Tue, Feb 28, 2023 at 11:04:42AM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Feb 28, 2023 at 12:51:06AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > And then there is a question whether we want to emit rtti for
> > _Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) regard
On Wed, Mar 1, 2023 at 9:52 AM NightStrike via Gcc-patches
wrote:
>
> On Thu, Feb 16, 2023, 11:10 LIU Hao via Gcc-patches
> wrote:
>
> >
> > --
> > Best regards,
> > LIU Hao
> >
>
> Ping
OK.
> >
Hi,
Please CC fortran@gcc for Fortran patches.
Fortraners: Please see my add-on suggestion/.diff for 'do_simply' below and
the original email at
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613019.html
On 01.03.23 08:09, HAO CHEN GUI via Gcc-patches wrote:
The patch escalates the failu
Hi!
On Tue, Feb 28, 2023 at 10:59:03PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Feb 28, 2023 at 07:19:40PM +, Qing Zhao wrote:
> > Understood.
> > So, your patch fixed this bug, and then [0] arrays are instrumented by
> > default with this patch.
> >
> > > Well, it would compl
On 2/28/23 10:41, Richard Biener wrote:
On Mon, 27 Feb 2023, Aldy Hernandez wrote:
On 2/27/23 14:58, Richard Biener wrote:
After fixing PR107561 the following avoids looking at VR_ANTI_RANGE
ranges where it doesn't seem obvious the code does the correct
thing here (lower_bound and upper_b
On 28/02/2023 23:01, Kwok Cheung Yeung wrote:
Hello
This patch implements the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
target hook for the AMD GCN architecture, such that when vectorized,
calls to builtin standard math functions such as asinf, exp, pow etc.
are converted to calls to the r
Ughh, you're touching everything I'm nuking next release ;-).
But yes, that's an oversight.
OK.
On Tue, Feb 28, 2023 at 2:48 PM Richard Biener via Gcc-patches
wrote:
>
> when vrange_printer::visit gets a VR_ANTI_RANGE it should print it
> as such, not just print the first element as range. Whe
OK.
Thanks.
On Tue, Feb 28, 2023 at 2:48 PM Richard Biener via Gcc-patches
wrote:
>
> The following avoids the need to special-case storage requirement
> and copying for irange_storage_slot by making sure we canonicalize
> such ranges to int_range<2>.
>
> * tree-ssanames.cc (range_info_s
"Li, Pan2" writes:
> Hi Richard Sandiford,
>
> Just tried the overloaded constant divisors with below print div, it works as
> you mentioned, 😉!
>
> printf ("can_div_away_from_zero_p (mode_precision[E_%smode], "
> "BITS_PER_UNIT, &mode_size[E_%smode]);\n", m->name, m->name);
>
> template
On Wed, 1 Mar 2023, Aldy Hernandez wrote:
>
>
> On 2/28/23 10:41, Richard Biener wrote:
> > On Mon, 27 Feb 2023, Aldy Hernandez wrote:
> >
> >>
> >>
> >> On 2/27/23 14:58, Richard Biener wrote:
> >>> After fixing PR107561 the following avoids looking at VR_ANTI_RANGE
> >>> ranges where it doesn
Hi!
I'd like to ping a few pending patches:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
- PR107846 - P1 - c-family: Account for integral promotions of left shifts
for -Wshift-overflow warning
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610285.html
- PR1084
On 3/1/23 11:12, Richard Biener wrote:
On Wed, 1 Mar 2023, Aldy Hernandez wrote:
On 2/28/23 10:41, Richard Biener wrote:
On Mon, 27 Feb 2023, Aldy Hernandez wrote:
On 2/27/23 14:58, Richard Biener wrote:
After fixing PR107561 the following avoids looking at VR_ANTI_RANGE
ranges where
On 2/28/23 14:47, Richard Biener via Gcc-patches wrote:
simplify_using_ranges::two_valued_val_range_p has odd code to
verify that an anti-range is two-valued which relies on
num_pairs () returning two for anti-ranges despite there's only
one pair and relying on lower/upper_bound treating that
I would prefer not touching this as it was intended, and about to be
removed. However, if we have actual regressions or missed optimizations
because of the current behavior I could be convinced otherwise.
Aldy
On 2/28/23 14:47, Richard Biener via Gcc-patches wrote:
irange::num_pairs has odd
Similar to my num_pairs comment. If we're fixing missed optimizations,
then yes. Otherwise I'd prefer to remove it soon.
That being said, you are the release manager and if you feel strongly
about this I would defer to you.
Aldy
On 2/28/23 14:47, Richard Biener via Gcc-patches wrote:
>> Is it right that, for RVV, a load or store of [4,4] will access [8,8]
>>bits, even when that means accessing fully-unused bytes? E.g. 4+4X
>>when X=3 would be 16 bits/2 bytes of useful data, but a bitsize of
>>8+8X would be 32 bits/4 bytes. So a store of [8,8] for a precision
>>of [4,4] would
On 01/03/2023 10:01, Andrew Stubbs wrote:
> On 28/02/2023 23:01, Kwok Cheung Yeung wrote:
>> Hello
>>
>> This patch implements the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
>> target hook for the AMD GCN architecture, such that when vectorized,
>> calls to builtin standard math functions suc
Thank you all for your quick response.
As juzhe mentioned, the memory access of RISC-V will be always aligned to the
bytes boundary with the compact mode, aka ceil(vl / 8) bytes for vbool*.
Actually, the data [4,4] comes from the self-test, the RISC-V precision mode as
below.
VNx64BI precision
盼 李 via Gcc-patches writes:
> Thank you all for your quick response.
>
> As juzhe mentioned, the memory access of RISC-V will be always aligned to the
> bytes boundary with the compact mode, aka ceil(vl / 8) bytes for vbool*.
OK, thanks to both of you. This is what I'd have expected.
In that c
Thank you for the explanation.
For [4,4] I need extra time to figure out which one, but I confirmed it occurs
from the log.
This PR precision adjustment part tries to align the ISA as juzhe mentioned, by
the underlying precision adjustment part.
VNx64BI precision [0x40, 0x40] // unchanged
VNx3
On Tue, 28 Feb 2023, Richard Sandiford wrote:
> Tamar Christina writes:
> >> -Original Message-
> >> From: Richard Sandiford
> >> Sent: Tuesday, February 28, 2023 11:09 AM
> >> To: Tamar Christina
> >> Cc: Tamar Christina via Gcc-patches ; nd
> >> ; rguent...@suse.de; j...@ventanamicro.
Currently, if the gcc toolchain is relocated and installed from shared state
cache, then you try and compile
preprocessed source (.i or .ii files), the compiler will try and access the
builtin sysroot location
rather than the --sysroot option specified on the commandline. If access to
that direc
Just have a test with the below code, the [0x4, 0x4] test comes from VNx4BI.
You can notice that the mode size is unchanged.
printf ("can_div_away_from_zero_p (mode_precision[E_%smode], "
"BITS_PER_UNIT, &mode_size[E_%smode]);\n", m->name, m->name);
VNx4BI Before precision [0x4, 0x4], size
盼 李 via Gcc-patches writes:
> Just have a test with the below code, the [0x4, 0x4] test comes from VNx4BI.
> You can notice that the mode size is unchanged.
>
> printf ("can_div_away_from_zero_p (mode_precision[E_%smode], "
> "BITS_PER_UNIT, &mode_size[E_%smode]);\n", m->name, m->name);
>
>
On 01/03/2023 10:52, Andre Vieira (lists) wrote:
On 01/03/2023 10:01, Andrew Stubbs wrote:
> On 28/02/2023 23:01, Kwok Cheung Yeung wrote:
>> Hello
>>
>> This patch implements the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
>> target hook for the AMD GCN architecture, such that when vecto
Actually, we just want to differentiate VNx1BI VNx2BI VNx4BI VNx8BI, and they
are considered the same in GCC which produce BUG in RVV currently.
This patch is just adjust precision to differentiate them but may not be (like
you say), they may not be handled accurately according precision.
Howeve
let me explain more about the test [4,4]. As I understand, the self test will
run more than 1 time for VNx4BI.
The first time, precision[VNx4BI] = [8, 8], then the PR precision part will
adjust it to [4, 4].
The rest times, precision[VNx4BI] = [4, 4], then can_* will return false and
hit the gc
Hi!
On Wed, Nov 16, 2022 at 12:51:14PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Nov 16, 2022 at 10:06:17AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > Thoughts on this? I guess my preference would be the BF -> SF -> TI
> > path because we won't need to waste
> > 32: 0
On Wed, 1 Mar 2023, Richard Sandiford wrote:
> 盼 李 via Gcc-patches writes:
> > Just have a test with the below code, the [0x4, 0x4] test comes from
> > VNx4BI. You can notice that the mode size is unchanged.
> >
> > printf ("can_div_away_from_zero_p (mode_precision[E_%smode], "
> > "BITS_P
The following patch
libstdc++: Update Solaris baselines for GCC 13.0
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612379.html
has remained unreviewed for a week.
Thanks.
Rainer
--
-
R
On Tue, Feb 28, 2023 at 05:18:25PM +0100, Tobias Burnus wrote:
> OpenMP/Fortran: Fix handling of optional is_device_ptr + bind(C) [PR108546]
>
> For is_device_ptr, optional checks should only be done before calling
> libgomp, afterwards they are NULL either because of absent or, by
> chance, becau
Hello
I don't have write access, could someone review and apply this?
Kind regards
Jonny
Forwarded Message
Subject: [PATCH] update copyright year in libstdcc++ manual
Date: Fri, 30 Dec 2022 10:30:22 +
From: Jonny Grant
To: gcc-patches@gcc.gnu.org
CC: Jonny Grant
2022-12-3
Hello
I don't have write access, could someone review and apply this please?
Kind regards
Jonny
Forwarded Message
Subject: Bugzilla Bug 81649 [PATCH]: Clarify LeakSanitizer in documentation
Date: Mon, 26 Dec 2022 20:50:23 +
From: Jonny Grant
To: gcc-patches@gcc.gnu.org
M
Hello
I don't have write access, could someone review and apply this please?
Kind regards
Jonny
Forwarded Message
Subject: [PATCHJ]: Bugzilla 88860 - Clarify online manual infelicities
Date: Mon, 26 Dec 2022 21:00:05 +
From: Jonny Grant
To: gcc-patches@gcc.gnu.org
2022-1
I am not very familiar with the memory pattern, maybe juzhe can provide more
information or correct me if anything is misleading.
The different precision try to resolve the below bugs, the second vlm(with
different size of load bytes compared to first one)
is eliminated because vbool8 and vbool1
On Tue, Feb 28, 2023 at 02:06:43PM +0100, Tobias Burnus wrote:
> (This is marked as P1 regression)
>
> Since the structure handling updates, a hash is now used to find expressions
> which are identical;
> unfortunately, this mishandles 'volatile' vars as expressions involving them
> are not rega
When combining -g1 with -flto we run into the DIE location annotation
machinery for globals calling dwarf2out_late_global_decl but not
having any early generated DIE for function scope statics. In
this process we'd generate a limbo DIE since also the function scope
doesn't have any early generated
On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote:
> When combining -g1 with -flto we run into the DIE location annotation
> machinery for globals calling dwarf2out_late_global_decl but not
> having any early generated DIE for function scope statics. In
> this process we'd generate a
On Wed, 1 Mar 2023, Pan Li wrote:
> I am not very familiar with the memory pattern, maybe juzhe can provide more
> information or correct me if anything is misleading.
>
> The different precision try to resolve the below bugs, the second
> vlm(with different size of load bytes compared to first
Pan Li via Gcc-patches writes:
> I am not very familiar with the memory pattern, maybe juzhe can provide more
> information or correct me if anything is misleading.
>
> The different precision try to resolve the below bugs, the second vlm(with
> different size of load bytes compared to first one
On Wed, 1 Mar 2023, Richard Sandiford wrote:
> Pan Li via Gcc-patches writes:
> > I am not very familiar with the memory pattern, maybe juzhe can provide
> > more information or correct me if anything is misleading.
> >
> > The different precision try to resolve the below bugs, the second vlm(wi
On Wed, 2023-03-01 at 04:01 +0100, Hans-Peter Nilsson wrote:
> > From: David Malcolm
> > Date: Tue, 28 Feb 2023 21:25:34 -0500
>
> > On Wed, 2023-03-01 at 01:59 +0100, Hans-Peter Nilsson wrote:
> > > > From: David Malcolm
> > > > Date: Tue, 28 Feb 2023 14:12:47 -0500
> > >
> > > > On Tue, 2023-
On 2/27/23 16:55, Richard Sandiford wrote:
Jonathan Yong via Gcc-patches writes:
Attached patch OK?
gcc.dg/memchr-3.c: fix for LLP64
gcc/testsuite/ChangeLog:
PR middle-end/97956
* gcc.dg/memchr-3.c (memchr): fix long to size_t in
On 2/28/23 18:15, Jakub Jelinek wrote:
On Wed, Feb 15, 2023 at 01:44:08PM +, Jonathan Yong via Gcc-patches wrote:
gcc/testsuite/ChangeLog:
* gcc.target/i386/harden-sls-6.c: fix warning on LLP64
targets.
Attached patch OK?
From c0572a1e95c6f569980d6b7454c8dc293f07389e
On 3/1/23 09:21, Richard Biener wrote:
On Wed, Mar 1, 2023 at 9:52 AM NightStrike via Gcc-patches
wrote:
On Thu, Feb 16, 2023, 11:10 LIU Hao via Gcc-patches
wrote:
--
Best regards,
LIU Hao
Ping
OK.
Done, pushed to master branch.
On 01.03.23 14:03, Jakub Jelinek wrote:
On Tue, Feb 28, 2023 at 02:06:43PM +0100, Tobias Burnus wrote:
[...]
Do we use that hashing even say for ARRAY_REFs with array indexes?
Using OEP_MATCH_SIDE_EFFECTS will mean that
volatile int idx;
a.b[idx] and a.b[idx] will compare equal. On the other sid
Let's me first introduce RVV load/store basics and stack allocation.
For scalable vector memory allocation, we allocate memory according to machine
vector-length.
To get this CPU vector-length value (runtime invariant but compile time
unknown), we have an instruction call csrr vlenb.
For example
Sorry for missleading typo.
>> VNx1BI: vsevl e8mf8 + vlm, loading 1/8 of poly (1,1) storage.
>> VNx2BI: vsevl e8mf8 + vlm, loading 1/4 of poly (1,1) storage.
>> VNx4BI: vsevl e8mf8 + vlm, loading 1/2 of poly (1,1) storage.
>> VNx8BI: vsevl e8mf8 + vlm, loading 1 of poly (1,1) storage.
It shou
On Wed, 1 Mar 2023, juzhe.zh...@rivai.ai wrote:
> Let's me first introduce RVV load/store basics and stack allocation.
> For scalable vector memory allocation, we allocate memory according to
> machine vector-length.
> To get this CPU vector-length value (runtime invariant but compile time
> un
On Wed, 1 Mar 2023, Richard Biener wrote:
> On Wed, 1 Mar 2023, juzhe.zh...@rivai.ai wrote:
>
> > Let's me first introduce RVV load/store basics and stack allocation.
> > For scalable vector memory allocation, we allocate memory according to
> > machine vector-length.
> > To get this CPU vector
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6393-g070523b9d4c6cf.
gcc/analyzer/ChangeLog:
PR analyzer/108935
* infinite-recursion.cc (contains_unknown_p): New.
(sufficiently_different_region_binding_p): New function, splitting
>> So given the above I think that modeling the size as being the same
>> but with accurate precision would work. It's then only the size of the
>> padding in bytes we cannot represent with poly-int which should be fine.
>> Correct?
Yes.
>> Btw, is storing a VNx1BI and then loading a VNx2BI from
On Mon, 27 Feb 2023, Jason Merrill wrote:
> On 2/22/23 14:45, Patrick Palka wrote:
> > Here we're mishandling the unevaluated array new-expressions due to a
> > supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
> > made us no longer perform constant evaluation of non-manifest
> From: David Malcolm
> Cc: gcc-patches@gcc.gnu.org
> Date: Wed, 01 Mar 2023 08:32:13 -0500
> Also, the analyzer uses region_model::set_errno in various
> known_function implementations, e.g. for functions that can succeed or
> fail, to set errno on the "failure" execution path to a new symbolic
Thanks all for so much valuable and helpful materials.
As I understand (Please help to correct me if any mistake.), for the VNx*BI
(aka, 1, 2, 4, 8, 16, 32, 64),
the precision and mode size need to be adjusted as below.
Precision size [1, 2, 4, 8, 16, 32, 64]
Mode size [1, 1, 1, 1, 2, 4, 8]
Giv
On Wed, Mar 01, 2023 at 10:40:15AM +0100, Tobias Burnus wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gfortran.dg/pr103628.f90
> > @@ -0,0 +1,14 @@
> > +! { dg-do compile { target powerpc*-*-* } }
> > +! { dg-options "-O2 -mabi=ibmlongdouble" }
> > +
> > +! Test to ensure that it reports an "Unc
Sorry for the typo and inconvenience.
The below
"The genmode will first get the precision, and then leverage the mode_size =
exact_div / 8 to generate"
should be:
"The genmode will first get the precision, and then leverage mode_size =
mode_precision / 8 to generate"
Pan
> From: Hans-Peter Nilsson
> Date: Wed, 1 Mar 2023 16:36:46 +0100
> ... this is what I intend to commit later
> today, just keeping the added comment as brief as
> reasonable:
Except I see the hook for errno magic took care of
gcc.dg/analyzer/flex-without-call-summaries.c so I'll add
that to the
"Li, Pan2" writes:
> Thanks all for so much valuable and helpful materials.
>
> As I understand (Please help to correct me if any mistake.), for the VNx*BI
> (aka, 1, 2, 4, 8, 16, 32, 64),
> the precision and mode size need to be adjusted as below.
>
> Precision size [1, 2, 4, 8, 16, 32, 64]
> Mo
> On Feb 28, 2023, at 4:59 PM, Jakub Jelinek wrote:
>
> On Tue, Feb 28, 2023 at 07:19:40PM +, Qing Zhao wrote:
>> Understood.
>> So, your patch fixed this bug, and then [0] arrays are instrumented by
>> default with this patch.
>>
>>> Well, it would complain about
>>> struct S { int a;
On 3/1/23 10:32, Patrick Palka wrote:
On Mon, 27 Feb 2023, Jason Merrill wrote:
On 2/22/23 14:45, Patrick Palka wrote:
Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
made us no longer perform constan
This patch introduces instruction patterns for conditional min and max
operations (cond_{f|s|u}{max|min}) in the GCN machine description. It
also allows the exec register to be saved in SGPRs to avoid spilling to
memory.
Tested on GCN3 Fiji gfx803.
OK for trunk?
--
PA
From 1cd86b4420d9d42bcde8
On Thu, Feb 23, 2023 at 11:39:51AM -0500, Andrew MacLeod via Gcc-patches wrote:
>
>
> Inheriting from operator_mult is also going to be hazardous because it also
> has an op1_range and op2_range...� you should at least define those and
> return VARYING to avoid other issues.� Same thing appli
On Wed, 1 Mar 2023, Jason Merrill wrote:
> On 3/1/23 10:32, Patrick Palka wrote:
> > On Mon, 27 Feb 2023, Jason Merrill wrote:
> >
> > > On 2/22/23 14:45, Patrick Palka wrote:
> > > > Here we're mishandling the unevaluated array new-expressions due to a
> > > > supposed non-constant array size ev
On 3/1/23 12:20, Patrick Palka wrote:
On Wed, 1 Mar 2023, Jason Merrill wrote:
On 3/1/23 10:32, Patrick Palka wrote:
On Mon, 27 Feb 2023, Jason Merrill wrote:
On 2/22/23 14:45, Patrick Palka wrote:
Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant a
If GCC is built with --enable-default-pie, a lot of aapcs64 tests fail
because relocation unsupported in PIE is used.
gcc/testsuite/ChangeLog:
PR testsuite/70150
* gcc.target/aarch64/aapcs64/aapcs64.exp (additional_flags):
Add -fno-pie -no-pie.
---
gcc/testsuite/gcc.targe
Hi,
This patch series fixes a lot of test failures with --enable-default-pie
or --enable-default-ssp for AArch64 target. Only test files are changed
to disable PIE or SSP to satisify the expectation of the developer who
programmed the test.
Bootstrapped and regtested on aarch64-linux-gnu. Ok fo
If GCC is configured with --enable-default-ssp, the stack protector can
make many sve-pcs tests fail.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp (sve_flags):
Add -fno-stack-protector.
---
.../gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp |
The test scans for "const_int 0" in the RTL dump, but stack protector
can produce more "const_int 0". To avoid a failure with
--enable-default-ssp, disable stack protector for this.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/auto-init-7.c (dg-options): Add
-fno-stack-protector
In PIE, symbol "fixed_regs" is addressed via GOT. It will break the
scan-assembler pattern and cause test failure with --enable-default-pie.
gcc/testsuite/ChangeLog:
PR testsuite/70150
* gcc.target/aarch64/fuse_adrp_add_1.c (dg-options): Add
-fno-pie.
---
gcc/testsuite/g
Storing stack guarding variable need one stp instruction, breaking the
scan-assembler-not pattern in the test. Disable stack protector to
avoid a test failure with --enable-default-ssp.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr104005.c (dg-options): Add
-fno-stack-protecto
These tests set large code model with -mcmodel=large or target pragma for
AArch64. But if GCC is configured with --enable-default-pie, it triggers
"sorry: unimplemented: code model large with -fpic". Disable PIE to make
avoid the issue.
gcc/testsuite/ChangeLog:
PR testsuite/70150
Hi
It seems that the win32_spawn function in libiberty/pex-win32.c is leaking
the cmdline buffer in 2/3 exit scenarios (it is only free'd in 1/3).The
problem here is that the cleanup code is written 3 times, one at each exit
scenario.
The proposed attached refactoring has the cleanup code app
Stack protector influence code generation and cause function body checks
fail.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr103147-10.c (dg-options): Add
-fno-stack-protector.
* g++.target/aarch64/pr103147-10.C: Likewise.
---
gcc/testsuite/g++.target/aarch64/pr103147-1
Stack protector needs a guard value on the stack and change the stack
layout. So we need to disable it for those tests, to avoid test failure
with --enable-default-ssp.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/shrink_wrap_1.c (dg-options): Add
-fno-stack-protector.
*
> -Original Message-
> From: Andrew Carlotti
> Sent: Wednesday, March 1, 2023 4:58 PM
> To: Andrew MacLeod
> Cc: Tamar Christina ; Richard Biener
> ; Richard Sandiford ;
> Tamar Christina via Gcc-patches ; nd
> ; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overma
On Sat, Jan 21, 2023 at 04:31:52PM +, i.nixman--- via Gcc-patches wrote:
> > Why?
>
> could you explain which of the nine lines are you talking about?
All the uselessly changed ones.
> > As for the rest, it would help if you could list the exact glibc commits
> > which you've ported to libqu
On Wed, 1 Mar 2023, Jason Merrill wrote:
> On 3/1/23 12:20, Patrick Palka wrote:
> > On Wed, 1 Mar 2023, Jason Merrill wrote:
> >
> > > On 3/1/23 10:32, Patrick Palka wrote:
> > > > On Mon, 27 Feb 2023, Jason Merrill wrote:
> > > >
> > > > > On 2/22/23 14:45, Patrick Palka wrote:
> > > > > > Her
This showed up as dynamic icount regression in SPEC 531.deepsjeng with upstream
gcc (vs. gcc 12.2). gcc was resorting to synthetic multiply using shift+add(s)
even when multiply had clear cost benefit.
|000133b8 :
| 133b8: srl a3,a1,s6
| 133bc: and a3,a3,s5
| 133c0:
On Wed, 1 Mar 2023 at 20:53, Vineet Gupta wrote:
>
> This showed up as dynamic icount regression in SPEC 531.deepsjeng with
> upstream
> gcc (vs. gcc 12.2). gcc was resorting to synthetic multiply using shift+add(s)
> even when multiply had clear cost benefit.
>
> |000133b8 .constprop.0]
On 3/1/23 08:09, Jakub Jelinek wrote:
On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote:
When combining -g1 with -flto we run into the DIE location annotation
machinery for globals calling dwarf2out_late_global_decl but not
having any early generated DIE for function scope statics.
-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,
template struct A { };
class A a;
it works by adding A to the class2loc hash table while parsing the
class-head and then, while parsing the elaborate type-specifier, we
add A. At the end of c_parse_file we go thro
Ping.
On Tue, Feb 07, 2023 at 11:46:10AM -0500, Marek Polacek wrote:
> On Sun, Feb 05, 2023 at 05:25:25PM -0800, Jason Merrill wrote:
> > On 1/24/23 17:49, Marek Polacek wrote:
> > > On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote:
> > > > On 1/19/23 21:03, Marek Polacek wrote:
> > >
Ping.
On Thu, Feb 02, 2023 at 07:28:25PM -0500, Marek Polacek via Gcc-patches wrote:
> Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't
> been completed yet, but that doesn't work:
>
> /* We can't lower this until the class is complete. */
> if (!COMPLETE_TYP
Okay there seems to be consensus on using constant_lower_bound (vf), but
I don't understand how that is a replacement for "vf.is_constant ()"? In
one case we are checking if "vf" is a constant, on the other we are
asking for the lower bound. For the crash in question
"constant_lower_bound (vf)
On 2/2/23 19:28, Marek Polacek wrote:
Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't
been completed yet, but that doesn't work:
/* We can't lower this until the class is complete. */
if (!COMPLETE_TYPE_P (DECL_CONTEXT (member)))
return cst;
a
Tested x86_64-linux and powerpc-aix. Pushed to trunk.
-- >8 --
This is consistent with the behaviour of glibc, which assumes UTC when
/etc/localtime and TZ do not identify a valid time zone. The fallback
tzdb used when no valid tzdata exists always contains the UTC zone, so
this change means we h
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/cow_string.h: Fix typo in comment.
---
libstdc++-v3/include/bits/cow_string.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/include/bits/cow_string.h
b/libstdc++-v3/include/bits/cow_
Hi!
Mere cosmetics.
- if (foo != NULL)
free (foo);
With the caveat that coccinelle ruins replacement whitespace or i'm
uneducated enough to be unable to _not_ run the diff through
sed -e 's/^+\([[:space:]]*\)free(/+\1free (/'
at least. If anybody knows how to improve replacement whitespace,
On 3/1/23 15:33, Marek Polacek wrote:
-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,
template struct A { };
class A a;
it works by adding A to the class2loc hash table while parsing the
class-head and then, while parsing the elaborate type-specifier, we
add
On 2/21/23 19:05, Patrick Palka wrote:
On Sun, 19 Feb 2023, Jason Merrill wrote:
On 2/15/23 12:11, Patrick Palka wrote:
On Wed, 15 Feb 2023, Jason Merrill wrote:
On 2/15/23 09:21, Patrick Palka wrote:
On Tue, 14 Feb 2023, Jason Merrill wrote:
On 2/13/23 09:23, Patrick Palka wrote:
[N.B.
On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote:
> On 3/1/23 15:33, Marek Polacek wrote:
> > -Wmismatched-tags warns about the (harmless) struct/class mismatch.
> > For, e.g.,
> >
> >template struct A { };
> >class A a;
> >
> > it works by adding A to the class2loc hash tabl
On 3/1/23 16:40, Marek Polacek wrote:
On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote:
On 3/1/23 15:33, Marek Polacek wrote:
-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,
template struct A { };
class A a;
it works by adding A to the class
On 2/7/23 11:46, Marek Polacek wrote:
On Sun, Feb 05, 2023 at 05:25:25PM -0800, Jason Merrill wrote:
On 1/24/23 17:49, Marek Polacek wrote:
On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote:
On 1/19/23 21:03, Marek Polacek wrote:
On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason Mer
1 - 100 of 133 matches
Mail list logo
