on 2022/12/14 18:33, Jakub Jelinek wrote:
> On Wed, Dec 14, 2022 at 06:11:26PM +0800, Kewen.Lin wrote:
>>> The hacks with different precisions of powerpc 128-bit floating types are
>>> very unfortunate, it is I assume because the middle-end asserted that scalar
>>> floating point types with differe
On Wed, Dec 14, 2022 at 11:58 PM Thomas Schwinge
wrote:
>
> Hi!
>
> On 2022-12-13T14:40:36+0100, Arthur Cohen wrote:
> > We've also added one more commit, which only affects files inside the
> > Rust front-end folder. This commit adds an experimental flag, which
> > blocks the compilation of Rust
Hi!
The following testcase ICEs, because ccp1 replaced
s.0_1 = &s;
__asm__ goto("" : "=r" MEM[(T *)s.0_1] : : : "lab" lab);
with
__asm__ goto("" : "=r" s : : : "lab" lab);
and because s is no longer addressable, we are rewriting it into
ssa and want
__asm__ goto("" : "=r" s_7 : : : "
On Wed, 14 Dec 2022, Qing Zhao wrote:
> Hi, Richard,
>
> I guess that we now agreed on the following:
>
> “ the information that we ran into a trailing array but didn't consider
> it a flex array because of -fstrict-flex-arrays is always a useful
> information”
>
> The only thing we didn’t de
>> I bet the above workaround in generic code was added for a reason, it would
>> surprise me if _Float128 worked at all without that hack.
>
> OK, I'll have a look at those nan failures soon.
By investigating the exposed NaN failures, I found it's due to that it wants
to convert _Float128 type c
On Thu, Dec 15, 2022 at 3:39 PM Jakub Jelinek wrote:
>
> On Thu, Dec 15, 2022 at 02:21:37PM +0800, liuhongt via Gcc-patches wrote:
> > --- a/gcc/config/i386/i386.opt
> > +++ b/gcc/config/i386/i386.opt
> > @@ -420,6 +420,10 @@ mpc80
> > Target RejectNegative
> > Set 80387 floating-point precision
On Thu, Dec 15, 2022 at 02:21:37PM +0800, liuhongt via Gcc-patches wrote:
> --- a/gcc/config/i386/i386.opt
> +++ b/gcc/config/i386/i386.opt
> @@ -420,6 +420,10 @@ mpc80
> Target RejectNegative
> Set 80387 floating-point precision to 80-bit.
>
> +mdaz-ftz
> +Target
s/Target/Driver/
> +Set the
Forgot it indeed, thanks for notifying me!
I modified the commit message to add it and added it into this email.
Le mer. 14 déc. 2022 à 16:12, Antoni Boucher a écrit :
> Thanks!
>
> In your patch, you're missing this line at the end of the commit
> message:
>
>Signed-off-by: Guillaume Gomez
Update in v2:
1. Support -mno-daz-ftz, and make the the option effectively three state as:
if (mdaz-ftz)
link crtfastmath.o
else if ((Ofast || ffast-math || funsafe-math-optimizations)
&& !shared && !mno-daz-ftz)
link crtfastmath.o
else
Don't link crtfastmath.o
2. Still make the op
Update in V2:
Split -shared change into a separate commit and add some documentation
for it.
Bootstrapped and regtested on x86_64-pc-linu-gnu{-m32,}.
Ok of trunk?
Don't add crtfastmath.o for -shared to avoid changing the MXCSR register
when loading a shared library. crtfastmath.o will be used onl
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In these testcases, we weren't adequately verifying that constructing the
element type from an array element would have the same effect as
constructing it from one of the initializers.
PR c++/108071
PR c++/105838
gcc/cp/Cha
Hi Richard,
I will commit tomorrow the attached patches to the active branches gcc-10, 11,
and 12.
The patches passed bootstrap and regression test on arm64-linux.
Sebastian
From: Richard Sandiford
Sent: Thursday, December 8, 2022 1:38:07 AM
To: Pop, Sebasti
Hi,
"Kewen.Lin" writes:
> Hi Jeff,
>
> on 2022/12/12 09:38, Jiufu Guo via Gcc-patches wrote:
>> Hi,
>>
>> For constant C:
>> If '(c & 0x8000ULL) == 0x8000ULL' or say:
>> 32(1) || 16(x) || 1(1) || 15(x), using "li; xoris" would be ok.
>>
>> If '(c & 0x80008000ULL
Hi,
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> Segher Boessenkool writes:
>
>> Hi!
>>
>> Sorry for the tardiness.
>>
>> On Mon, Aug 29, 2022 at 11:42:16AM +0800, Jiufu Guo wrote:
>>> When checking eq/ne with a constant which has only 16bits, it can be
>>> optimized to check the rotated data.
o-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221214 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-B'
'/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/' '-B'
'/home/zopolis4/gcjbuild/./gcc/'
Here we're triggering an overzealous assert in unify during partial
ordering since the member function pointer constants are represented as
ordinary CONSTRUCTORs (with TYPE_PTRMEMFUNC_P TREE_TYPE) but the assert
expects only COMPOUND_LITERAL_P constructors.
Bootstrapped and regtested on x86_64-pc-
Patch 19 has been resolved.
I had a look-- issue fixed, rough patch below. Full patch will be part of v2.
>From b0d93d8212328fabcbdb32c266c265a4eed49e00 Mon Sep 17 00:00:00 2001
From: Maximilian Downey Twiss
Date: Thu, 15 Dec 2022 09:54:36 +1100
Subject: [PATCH] java: Adjustments to end_params_node and void_list_node.
gcc/
Hi!
On 2022-12-13T14:40:36+0100, Arthur Cohen wrote:
> We've also added one more commit, which only affects files inside the
> Rust front-end folder. This commit adds an experimental flag, which
> blocks the compilation of Rust code when not used.
(That's commit r13-4675-gb07ef39ffbf4e77a5866050
On Wed, Nov 30, 2022 at 04:30:13PM +0800, Kewen.Lin wrote:
> As PR104024 shows, the option -mpower10-fusion isn't guarded by
> -mcpu=power10, it causes compiler to fuse for some patterns
> even without power10 support and then causes ICE unexpectedly,
> this patch is to simply unmask it without pow
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4710-g41faa1d7beb90b.
gcc/analyzer/ChangeLog:
PR analyzer/108065
* region.cc (decl_region::get_svalue_for_initializer): Bail out to
avoid calling binding_key::make with an empty region.
This patch fixes two tests that are still failing when long double is IEEE
128-bit after the previous 2 patches for PR target/107299 have been applied.
The tests are:
gcc.target/powerpc/convert-fp-128.c
gcc.target/powerpc/pr85657-3.c
This patch is a rewrite of the patch submitted
This patch fixes the issue that GCC cannot build when the default long double
is IEEE 128-bit. It fails in building libgcc, specifically when it is trying
to buld the __mulkc3 function in libgcc. It is failing in gimple-range-fold.cc
during the evrp pass. Ultimately it is failing because the cod
This patch reworks how the complex multiply and divide built-in functions are
done. Previously we created built-in declarations for doing long double complex
multiply and divide when long double is IEEE 128-bit. The old code also did not
support __ibm128 complex multiply and divide if long double
This set of patches was first submitted on November 1st. Kewen.Lin
asked for some changes to the first set of patches. I
also tried to clean up the comments in the second patch about types that Segher
Boessenkool mentioned.
I had just re-submitted the first patch yesterday, but Segher asked th
Dear all,
this is a patch to print the gcov annotations (fallthrough or throw) als
to uncovered branches.
Best regards,
Michael
From b65cfc8a837cd9d1b6421978865210e59ba62e0e Mon Sep 17 00:00:00 2001
From: Spacetown
Date: Sun, 4 Dec 2022 21:03:34 +0100
Subject: [PATCH] gcov: annotate uncovered
Hi Tobias,
thanks for your explanation! Now things are clearer.
Am 14.12.22 um 08:57 schrieb Tobias Burnus:
@@ -63 +66 @@ cfi_desc_to_gfc_desc (gfc_array_void *d,
- d->dtype.version = s->version;
+ d->dtype.version = 0;
I was wondering what the significance of "version" is.
In ISO_Fortran_
We substitute the qualifying scope of a TYPENAME_TYPE directly using
tsubst_aggr_type (so that we can pass entering_scope=true) instead of
going through tsubst, which means we don't properly reuse typedefs
during this substitution. This ends up causing us to reject the below
testcase because we su
On 14/12/2022 17:00, Richard Earnshaw via Gcc-patches wrote:
On 14/12/2022 16:40, Andrea Corallo via Gcc-patches wrote:
Hi Richard,
thanks for reviewing.
Richard Earnshaw writes:
On 28/10/2022 17:40, Andrea Corallo via Gcc-patches wrote:
Hi all,
please find attached the third iteratio
On 14/12/2022 16:40, Andrea Corallo via Gcc-patches wrote:
Hi Richard,
thanks for reviewing.
Richard Earnshaw writes:
On 28/10/2022 17:40, Andrea Corallo via Gcc-patches wrote:
Hi all,
please find attached the third iteration of this patch addresing
review
comments.
Thanks
Andrea
On 14/12/2022 16:35, Andrea Corallo via Gcc-patches wrote:
Richard Earnshaw writes:
[...]
+ if (TARGET_TPCS_FRAME)
+error ("Return address signing and %<-mtpcs-frame%> are
incompatible.");
So really this is 'not implemented' rather than not compatible - I
don't see why we co
Hi Richard,
thanks for reviewing.
Richard Earnshaw writes:
> On 28/10/2022 17:40, Andrea Corallo via Gcc-patches wrote:
>> Hi all,
>> please find attached the third iteration of this patch addresing
>> review
>> comments.
>> Thanks
>>Andrea
>>
>
> @@ -23374,12 +23374,6 @@ output_probe_stac
Hi, Richard,
I guess that we now agreed on the following:
“ the information that we ran into a trailing array but didn't consider
it a flex array because of -fstrict-flex-arrays is always a useful information”
The only thing we didn’t decide is:
A. Amend such new information to -Warray-bounds
Richard Earnshaw writes:
[...]
>
> + if (TARGET_TPCS_FRAME)
> +error ("Return address signing and %<-mtpcs-frame%> are
> incompatible.");
>
> So really this is 'not implemented' rather than not compatible - I
> don't see why we couldn't implement this if we really wanted to. It's
>
> Hi,
>
> The discussion about scan_expr_access in ipa-sra.cc brought my
> attention to a missing case of handling an ADDR_EXPR. As the added
> testcase shows, the heuristics which looks for parameters which are
> local variables that are only written to and passed by reference in
> calls can mis
> Hi,
>
> Honza requested this after reviewing the patch that taught IPA-SRA
> that REFERENCE_TYPEs are always non-NULL that the pass also handles
> the first parameters of methods, this pointers, in the same way. So
> this patch does that.
>
> The patch is undergoing bootstrap and testing on an
Hi,
Honza requested this after reviewing the patch that taught IPA-SRA
that REFERENCE_TYPEs are always non-NULL that the pass also handles
the first parameters of methods, this pointers, in the same way. So
this patch does that.
The patch is undergoing bootstrap and testing on an x86_64-linux ri
Hi,
The discussion about scan_expr_access in ipa-sra.cc brought my
attention to a missing case of handling an ADDR_EXPR. As the added
testcase shows, the heuristics which looks for parameters which are
local variables that are only written to and passed by reference in
calls can miss a case where
Thanks!
In your patch, you're missing this line at the end of the commit
message:
Signed-off-by: Guillaume Gomez
On Wed, 2022-12-14 at 14:39 +0100, Guillaume Gomez via Jit wrote:
> Hi,
>
> This fixes bug 107999.
>
> Thanks in advance for the review.
On 12/8/22 19:41, Jason Merrill via Gcc-patches wrote:
Tested x86_64-pc-linux-gnu, applying to trunk.
Bisecting shows this started to break
$ cat test.cc
#include
template struct ConstCharArrayDetector;
template struct ConstCharArrayDetector { using Type =
int; };
struct OUString {
temp
> On Dec 14, 2022, at 9:08 AM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Dec 14, 2022, at 4:03 AM, Richard Biener wrote:
>>
>> On Tue, 13 Dec 2022, Qing Zhao wrote:
>>
>>> Richard,
>>>
>>> Do you have any decision on this one?
>>> Do we need this warning option For GCC?
>>
>> Lo
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The number of elements gets stored in _M_capacity so use a separate
variable for the number of bytes to allocate.
libstdc++-v3/ChangeLog:
PR libstdc++/108097
* include/std/stacktrace (basic_stracktrace::_Impl): Do not
multip
> On Dec 14, 2022, at 4:03 AM, Richard Biener wrote:
>
> On Tue, 13 Dec 2022, Qing Zhao wrote:
>
>> Richard,
>>
>> Do you have any decision on this one?
>> Do we need this warning option For GCC?
>
> Looking at the testcases it seems that the diagnostic amends
> -Warray-bounds diagnostics
Hi,
On Wed, Dec 14 2022, Martin Liška wrote:
> gcc/ChangeLog:
>
> * doc/invoke.texi: Document ipa-sra-ptrwrap-growth-factor.
Thanks or spotting this. Seeing the email also averted me to the fact
that what I wrote in the parameter description is almost the opposite of
what it should say. I
Hello,
Ping https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605685.html
I would like to remind that Gerald Pfeifer already volunteered to commit this
patch
when it is approved. However the patch has not been approved yet.
Thanks,
Lorenzo Salvadore
> --- Original Message ---
>
On 12/14/22 14:22, Jan Hubicka via Gcc-patches wrote:
>>> PR middle-end/105818
>>>
>>> gcc/ChangeLog:
>>>
>>> * predict.cc (optimize_function_for_size_p): Further check
>>> optimize_size of fun->decl when it is valid but no cgraph node.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * gcc
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Friday, December 9, 2022 7:08 AM
>> To: Richard Earnshaw
>> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org;
>> nd ; Richard Earnshaw ;
>> Marcus Shawcroft ; Kyrylo Tkachov
>>
>> Subject: Re: [PATCH]AArch64
Hi,
This fixes bug 107999.
Thanks in advance for the review.
From e6db0cb107e54789095f4585dd279a2c984d2ca1 Mon Sep 17 00:00:00 2001
From: Guillaume Gomez
Date: Wed, 14 Dec 2022 14:28:22 +0100
Subject: [PATCH] Fix a failing test by updating its error string.
gcc/testsuite/ChangeLog:
* jit.dg/t
> > PR middle-end/105818
> >
> > gcc/ChangeLog:
> >
> > * predict.cc (optimize_function_for_size_p): Further check
> > optimize_size of fun->decl when it is valid but no cgraph node.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/powerpc/pr105818.c: New test.
> > * gc
Hi,
On Tue, Dec 13 2022, Richard Biener wrote:
> On Mon, 12 Dec 2022, Jan Hubicka wrote:
>
>> > > Hi,
>> > >
>> > > I'm re-posting patches which I have posted at the end of stage 1 but
>> > > which have not passed review yet.
>> > >
>> > > 8<--
On 12/14/22 14:11, Jakub Jelinek wrote:
> On Wed, Dec 14, 2022 at 02:07:38PM +0100, Martin Liška wrote:
>> Hi.
>>
>> The Copyright year will be updated automatically with a next patch
>> I'm going to send.
>
> Shouldn't that be added as 2016-2022 etc.?
Let it be updated automatically, then we can
On Wed, Dec 14, 2022 at 02:10:32PM +0100, Martin Liška wrote:
> +class ContribFilder(GenericFilter):
s/Filder/Filter/g ?
> +def __init__ (self):
> +GenericFilter.__init__ (self)
> +
> +self.skip_files |= set ([
> +# A different copyrights.
> +'u
On Wed, Dec 14, 2022 at 02:07:38PM +0100, Martin Liška wrote:
> Hi.
>
> The Copyright year will be updated automatically with a next patch
> I'm going to send.
Shouldn't that be added as 2016-2022 etc.?
Jakub
Hi.
I would like to automatically update copyright in contrib folder.
The updated version of copyright can be seen in attachment and can be done
at the beginning of the next year.
Thoughts?
Cheers,
Martin
contrib/ChangeLog:
* update-copyright.py: Add contrib folder.
---
contrib/update
Hi.
The Copyright year will be updated automatically with a next patch
I'm going to send.
Cheers,
Martin
contrib/ChangeLog:
* analyze_brprob.py: Add copyright header.
* analyze_brprob_spec.py: Likewise.
* check-params-in-docs.py: Likewise.
* check_GNU_style.py: L
Hi,
On Mon, Dec 12 2022, Jan Hubicka wrote:
>> Hi,
>>
>> I'm re-posting patches which I have posted at the end of stage 1 but
>> which have not passed review yet.
>>
>> 8<
>>
>> Fortran descriptors are structures which are ofte
From: Ju-Zhe Zhong
Since store instructions doesn't care about tail policy, we remove
vste from "ta" attribute. Hence, we could have more fusion chances
and better optimization.
gcc/ChangeLog:
* config/riscv/vector.md: Remove vste.
---
gcc/config/riscv/vector.md | 2 +-
1 file change
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607527.html
BR,
Kewen
on 2022/11/30 16:30, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO
> if fun->decl is not null but no cgraph node is available for it.
> As P
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607526.html
BR,
Kewen
on 2022/11/30 16:30, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR104024 shows, the option -mpower10-fusion isn't guarded by
> -mcpu=power10, it causes compiler to fuse for some patterns
> even wit
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603350.html
BR,
Kewen
> on 2022/10/12 16:12, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> PR106680 shows that -m32 -mpowerpc64 is different from
>> -mpowerpc64 -m32, this is determined by the way how we
>> handle opti
Hi,
Gentle ping this series:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607146.html
BR,
Kewen
on 2022/11/24 17:15, Kewen Lin wrote:
> Hi,
>
> Following Segher's suggestion, this patch series is to rework
> function rs6000_emit_vector_compare for vector float and int
> in multiple
Hi,
As PR106736 shows, it's unexpected to use __vector_quad and
__vector_pair types without MMA support, it would cause ICE
when expanding the corresponding assignment. We can't guard
these built-in types registering under MMA support as Peter
pointed out in that PR, because the registering is gl
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, December 9, 2022 7:08 AM
> To: Richard Earnshaw
> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org;
> nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Kyrylo Tkachov
>
> Subject: Re: [PATCH]AArch64 div-by-255, ensure that arguments
This patch adds parsing/argument-checking support for
'!$omp allocators allocate([align(int),allocator(a) :] list)'
This is kind of logical follow-up and prep patch for the
'!$omp allocate(list) [align(v) allocator(a)]'
support that was submitted as part of a larger patchset by Abid; cf.
revi
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Arthur Cohen
> Sent: Wednesday, December 14, 2022 10:05 AM
> To: Jakub Jelinek ; gcc-r...@gcc.gnu.org; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] rust: Fix up aarch64-linux bootstrap
contrib/ChangeLog:
* mklog.py: Check for number of hunks and not if a modified
file is binary.
---
contrib/mklog.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/contrib/mklog.py b/contrib/mklog.py
index 358b7fc6b8b..5dea8a05c0c 100755
--- a/contrib/mklo
On Wed, Dec 14, 2022 at 06:11:26PM +0800, Kewen.Lin wrote:
> > The hacks with different precisions of powerpc 128-bit floating types are
> > very unfortunate, it is I assume because the middle-end asserted that scalar
> > floating point types with different modes have different precision.
> > We no
Hi Jeff,
on 2022/12/12 09:38, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> For constant C:
> If '(c & 0x8000ULL) == 0x8000ULL' or say:
> 32(1) || 16(x) || 1(1) || 15(x), using "li; xoris" would be ok.
>
> If '(c & 0x80008000ULL) == 0x8000ULL' or say:
> 32(0) ||
Ubuntu 20.04.5 LTS (focal) unfortunately has an too old unidiff.PatchSet
for the feature added on Monday.
Solution: use is_binary_file only when it is available.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Ges
Hi Jakub,
Thanks for the comments!
on 2022/12/14 17:36, Jakub Jelinek wrote:
> On Wed, Dec 14, 2022 at 04:46:07PM +0800, Kewen.Lin via Gcc-patches wrote:
>> on 2022/12/6 19:27, Kewen.Lin via Gcc-patches wrote:
>>> Hi Mike,
>>>
>>> Thanks for fixing this, some comments are inlined below.
>>>
>>> o
Hi Jakub,
On 12/14/22 10:14, Jakub Jelinek via Gcc-rust wrote:
Hi!
Bootstrap fails on aarch64-linux and some other arches with:
.../gcc/rust/parse/rust-parse-impl.h: In member function ‘Rust::AST::ClosureParam
Rust::Parser::parse_closure_param() [with
ManagedTokenSource = Rust::Lexer]’:
.../g
Hi Jeff,
on 2022/12/12 09:44, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> Compare with previous patch, this patch updates accoding to comments; fixes
> conflicts with trunk, and recheck bootstrap®test.
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607333.html
>
> For a complicate 64bi
On Tue, 13 Dec 2022, Tamar Christina wrote:
> Hi Richi,
>
> This is a respin of the mid-end patch. Changes since previous version:
> - The mismatch in Boolean types is now fixed, and it generates an OR
> reduction when it needs to.
> - I've refactored things around to be a bit neater
> - I'v
On Wed, Dec 14, 2022 at 04:46:07PM +0800, Kewen.Lin via Gcc-patches wrote:
> on 2022/12/6 19:27, Kewen.Lin via Gcc-patches wrote:
> > Hi Mike,
> >
> > Thanks for fixing this, some comments are inlined below.
> >
> > on 2022/11/2 10:42, Michael Meissner wrote:
> >> This patch fixes the issue that
Hi!
Bootstrap fails on aarch64-linux and some other arches with:
.../gcc/rust/parse/rust-parse-impl.h: In member function
‘Rust::AST::ClosureParam
Rust::Parser::parse_closure_param() [with
ManagedTokenSource = Rust::Lexer]’:
.../gcc/rust/parse/rust-parse-impl.h:8916:49: error: ‘this’ pointer is
On Wed, Dec 14, 2022 at 9:52 AM Richard Biener
wrote:
>
> On Wed, Dec 14, 2022 at 9:34 AM Liu, Hongtao wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Richard Biener
> > > Sent: Wednesday, December 14, 2022 4:23 PM
> > > To: Jakub Jelinek
> > > Cc: Liu, Hongtao ; gcc-patches@gcc
On Tue, 13 Dec 2022, Qing Zhao wrote:
> Richard,
>
> Do you have any decision on this one?
> Do we need this warning option For GCC?
Looking at the testcases it seems that the diagnostic amends
-Warray-bounds diagnostics for trailing but not flexible arrays?
Wouldn't it be better to generally
On Wed, Dec 14, 2022 at 9:34 AM Liu, Hongtao wrote:
>
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, December 14, 2022 4:23 PM
> > To: Jakub Jelinek
> > Cc: Liu, Hongtao ; gcc-patches@gcc.gnu.org;
> > crazy...@gmail.com; hjl.to...@gmail.com; ubiz...@gmail.com
>
From: Ju-Zhe Zhong
I found that I forgot to remove these redundant attributes.
Sorry about that.
gcc/ChangeLog:
* config/riscv/vector.md (): Remove redundant attributes.
---
gcc/config/riscv/vector.md | 20
1 file changed, 20 deletions(-)
diff --git a/gcc/config/
on 2022/12/6 19:27, Kewen.Lin via Gcc-patches wrote:
> Hi Mike,
>
> Thanks for fixing this, some comments are inlined below.
>
> on 2022/11/2 10:42, Michael Meissner wrote:
>> This patch fixes the issue that GCC cannot build when the default long double
>> is IEEE 128-bit. It fails in building l
on 2022/12/13 14:14, Michael Meissner wrote:
> On Mon, Dec 12, 2022 at 06:20:14PM +0800, Kewen.Lin wrote:
>> Without or with patch #1, the below ICE in libgcc exists, the ICE should have
>> nothing to do with the special handling for building_libgcc in patch #1. I
>> think patch #2 which makes _Fl
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc: Fix annotation.
---
gcc/config/riscv/riscv-vsetvl.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index c602426b542..3ca3fc15e5a
Richard Biener writes:
> On Wed, Dec 14, 2022 at 8:48 AM Gaius Mulley wrote:
>>
>>
>>
>> This patch set adds a re-exp ACX_CHECK_PROG_VER to detect python3.
>> HAVE_PYTHON is then checked in gcc/m2/Make-lang.in to generate library
>> chapters if python3 is available. If python3 is unavailable th
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, December 14, 2022 4:23 PM
> To: Jakub Jelinek
> Cc: Liu, Hongtao ; gcc-patches@gcc.gnu.org;
> crazy...@gmail.com; hjl.to...@gmail.com; ubiz...@gmail.com
> Subject: Re: [PATCH] [x86] x86: Don't add crtfastmath.o for -shared a
Hi,
Segher Boessenkool writes:
> Hi!
>
> Sorry for the tardiness.
>
> On Mon, Aug 29, 2022 at 11:42:16AM +0800, Jiufu Guo wrote:
>> When checking eq/ne with a constant which has only 16bits, it can be
>> optimized to check the rotated data. By this, the constant building
>> is optimized.
>>
>>
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-1.c: New test.
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-10.c: New test.
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-11.c: New test.
* gcc.target/riscv/rvv/vsetvl/vlmax
On Wed, Dec 14, 2022 at 9:16 AM Jakub Jelinek wrote:
>
> On Wed, Dec 14, 2022 at 09:08:02AM +0100, Richard Biener via Gcc-patches
> wrote:
> > On Wed, Dec 14, 2022 at 3:21 AM liuhongt via Gcc-patches
> > wrote:
> > >
> > > Don't add crtfastmath.o for -shared to avoid changing the MXCSR
> > > reg
On Tue, Dec 13, 2022 at 5:29 PM Tobias Burnus wrote:
>
> This is a 12/13 regression as come changes to fix the GFC/CFI descriptor
> that went into GCC 12 fail with the (bogus) descriptor passed via by a
> GCC-11-compiled program.
>
> As later GCC 12 changes moved the descriptor to the front end, t
On Wed, Dec 14, 2022 at 09:08:02AM +0100, Richard Biener via Gcc-patches wrote:
> On Wed, Dec 14, 2022 at 3:21 AM liuhongt via Gcc-patches
> wrote:
> >
> > Don't add crtfastmath.o for -shared to avoid changing the MXCSR
> > register when loading a shared library. crtfastmath.o will be used
> > on
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/vlmax_miss_default-1.c: New test.
* gcc.target/riscv/rvv/vsetvl/vlmax_miss_default-10.c: New test.
* gcc.target/riscv/rvv/vsetvl/vlmax_miss_default-11.c: New test.
* gcc.target/riscv/rvv/vse
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c: New test.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-10.c: New test.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-11.c: New test.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-12.c: New tes
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.exp: Adjust to enable tests for VSETVL PASS.
* gcc.target/riscv/rvv/vsetvl/dump-1.c: New test.
* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-1.c: New test.
* gcc.target/riscv/rvv/vsetvl/vlma
On Wed, Dec 14, 2022 at 3:21 AM liuhongt via Gcc-patches
wrote:
>
> Don't add crtfastmath.o for -shared to avoid changing the MXCSR
> register when loading a shared library. crtfastmath.o will be used
> only when building executables.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
If there is no objection, I'm going to backport the m_SAPPHIRERAPIDS
and m_ALDERLAKE change to GCC 12.
Uros Bizjak via Gcc-patches 于2022年12月7日周三 15:11写道：
>
> On Wed, Dec 7, 2022 at 7:36 AM Hongyu Wang wrote:
> >
> > For Alderlake there is similar issue like PR 81616, enable
> > avoid_fma256_chai
94 matches
Mail list logo
