Hi, Joseph and Jakub,
This is the 2nd ping to the 6th version of the patches -:)
Please let me know if you have any further comments on the patches, and whether
it’s Okay to commit them to trunk?
Thanks a lot for the help.
Qing
Begin forwarded message:
From: Qing Zhao
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109446
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #2 from Jonathan Wakely ---
Neither v nor v1 escapes the function, so I don't think operator delete can
inspect them.
The destructor doesn't inspect the contents, it just destroys the elements
(which is a no-op for int) and then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-04-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109440
--- Comment #2 from Richard Biener ---
There's that other bug which would be basically a duplicate, so I leave this
one tree-optimization, not C++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109469
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109462
--- Comment #3 from Jakub Jelinek ---
I have tried
struct Token {
unsigned char pad[4];
unsigned int uintdata;
unsigned long ptrdata;
unsigned short kind;
unsigned char pad2[6];
Token () : uintdata (0), ptrdata (0), kind (0) {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434
--- Comment #3 from Richard Biener ---
So the issue is that clear_bytes_written_by doesn't handle exceptions properly
and that's thru initialize_ao_ref_for_dse.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109369
--- Comment #7 from Alexander Monakov ---
Yes, ld should claim _pei386_runtime_relocator (even if later it becomes
unneeded due to zero relocations left to fix up) to make this work properly.
That's for Binutils to fix on their side.
"juzhe.zh...@rivai.ai" writes:
> Hi, Richards.
> Kindly Ping this patch.
> This is the most important patch for RVV auto-vectorization support.
> Bootstraped on X86 has passed.
Can it wait for GCC 14? It doesn't seem like stage 4 material.
Also, pinging after 5 days seems a bit soon. It's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109418
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109410
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109403
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109398
Richard Biener changed:
What|Removed |Added
Component|c |other
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |c
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109462
--- Comment #2 from Jakub Jelinek ---
Under debugger (trunk) what I see is that the block_result.intersect
(equiv_range)
in the code added by r13-1938 is only true in the VisitObjCMessageExpr function
twice, each time on the
# Result$16_552 =
Hi, Richards.
Kindly Ping this patch.
This is the most important patch for RVV auto-vectorization support.
Bootstraped on X86 has passed.
Feel free to comments.
Thanks.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-04-07 09:47
To: gcc-patches
CC: richard.sandiford; rguenther;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #11 from Costas Argyris ---
As I said before, I think adding the "-o" flag to
$(COMPILER) -c $< -o $@
is a good and harmless change, but, as per your own report, it didn't solve
your issues because you still got that mysterious
Hi Kito, Juzhe, Jeff,
Thanks for your kindly reviews. I have modified based on the comments and ran
the testsuite on my local. Could you please take another look ? If any more
comments please let me know.
Thanks
Yanzhang
> -Original Message-
> From: Wang, Yanzhang
> Sent: Tuesday,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109370
Richard Biener changed:
What|Removed |Added
Component|middle-end |rtl-optimization
--- Comment #2 from
A retry build has been detected on builder gccrust-opensuseleap-x86_64 while
building gccrust.
Full details are available at:
https://builder.sourceware.org/buildbot/#builders/104/builds/912
Build state: worker not available
Revision: (unknown)
Worker: bbo1-1
Build Reason: (unknown)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109369
--- Comment #6 from Richard Biener ---
(In reply to Alexander Monakov from comment #5)
> Indeed, sorry, __attribute__((used)) seems a much better solution for
> symbols that might be referenced implicitly, in a manner that LTO plugin
> cannot
From: Yanzhang Wang
This patch registers a riscv specific function to
TARGET_ZERO_CALL_USED_REGS instead of default in targhooks.cc. It will
clean gpr and vector relevant registers.
PR 109104
gcc/ChangeLog:
* config/riscv/riscv-protos.h (emit_hard_vlmax_vsetvl):
*
Oh, sorry for didn't explain this clearly.
In this example, the "vle32" should be using same VL as "vadd" that I didn't
mention.
But we do have other instructions doesn't care about VL operand. So let me
explain more clearly.
Same example I repeated again:
Loop:
{
bb 0:
vsetvl VL, e8,mf8,TA
Commit r13-7137 fixes thethe dump issue with -m32, cf. attachment.
Tobias
On 09.04.23 00:11, haochen.jiang via Gcc-patches wrote:
Fortran: Fix dg directives and remove trailing whitespaces in testsuite
caused
FAIL: gfortran.dg/gomp/affinity-clause-1.f90 -O scan-tree-dump-times
On Tue, Apr 11, 2023 at 11:19 AM juzhe.zh...@rivai.ai
wrote:
>
> No, we can only pass "available" to LCM.
> Passing "compatible" to LCM can not work for us.
>
> LCM can only help for eliminate vsetvls can not help for fuse vsetvls.
>
> For example:
>
> bb 0:
> vsetvl e8,mf8
> vadd (Demand SEW =
9 bit (512 modes) mode should be enough for RVV.
In the future, I would expect we will have BF16 vector, FP16 vector,.. matrix
modes.
And I think it will not be more 512 modes in the future.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-04-11 19:11
To: Richard Biener
CC:
Richard Biener writes:
> On Tue, 11 Apr 2023, Richard Sandiford wrote:
>
>> writes:
>> > ARM SVE has?svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
>> > As far as I known, they don't have tuple type for partial vector.
>>
>> Yeah, there are no separate types for partial vectors, but there
>> are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109446
--- Comment #1 from Mohamed ---
correction to scenario II should pass by value as follows
//void test(Bar b) // scenario II
On Tue, 11 Apr 2023, Richard Sandiford wrote:
> writes:
> > ARM SVE has?svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
> > As far as I known, they don't have tuple type for partial vector.
>
> Yeah, there are no separate types for partial vectors, but there
> are separate modes. E.g. VNx2QI is a
On Tue, Apr 11, 2023 at 06:25:58PM +0800, juzhe.zh...@rivai.ai wrote:
> Explicit sets multiple VNx1SImode with multiple dest operand and let RA to
> assign them with continguous regsiters
> will make RTL patterns in RVV hard to maintain.
Not necessarily. It can be handled through define_subst.
On Tue, 11 Apr 2023, LIU Hao wrote:
> ? 2023/4/11 16:00, Richard Biener via Gcc ??:
> > I think without NaNs MIN/MAX cannot raise any exceptions (I'm not
> > even sure whether MIN/MAX involving NaN will set invalid, but
> > most certainly with sNaN it will trap and return a quiet NaN?).
> > The C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109436
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109471
Bug ID: 109471
Summary: Missing loop unrolling for small std::vector?
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On Tue, 11 Apr 2023, Jakub Jelinek wrote:
> On Wed, Apr 05, 2023 at 02:11:08PM +0200, Richard Biener wrote:
> > Ok, but maybe there?s a gimple_build overload that meanwhile implements
> > the desired semantics? It would probably need to specify the valueization
> > hook to follow SSA edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109470
--- Comment #8 from Jonathan Wakely ---
No, "full-expression" is a formal term defined very precisely in the C++
standard. There is no opportunity for GCC to review that without failing to
conform to the C++ standard. Changing when temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109470
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
gcc/Changelog:
* gcc/config/arm/arm.cc(arm_print_asm_arch_directives): fix compatability
typo
* gcc/fortran/gfortran.texi(intrinsics): fix compatability typo
* gcc/fortran/invoke.texi(-fdec-math): fix compatability typo
* gcc/m2/gm2-compiler/M2Base.def(CannotCheckTypeInPass3): fix
Explicit sets multiple VNx1SImode with multiple dest operand and let RA to
assign them with continguous regsiters
will make RTL patterns in RVV hard to maintain.
Assume we have a new pattern flag to tell RA assign continguous registers for
multiple dest operand, and RA can handle this:
in RVV,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109470
--- Comment #6 from Johannes Kellner
---
Ok, Ok :)
It's not to me to argue this.
It's just an unexpected behavior (something I was unaware off/ something that
does not happen when doing the same code with other compilers clang/msvc).
And in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Richard Earnshaw writes:
> On 11/04/2023 10:46, Richard Sandiford via Gcc-patches wrote:
>> writes:
>>> ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
>>> As far as I known, they don't have tuple type for partial vector.
>>
>> Yeah, there are no separate types for partial vectors, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #10 from Costas Argyris ---
Hi Huaqi,
This is building a larger project, which gcc is part of.I am not familiar
with that larger project and I have never built it.
Could we extract only the gcc-specific part out of the entire
On Tue, Apr 11, 2023 at 05:46:15PM +0800, juzhe.zh...@rivai.ai wrote:
> I am not sure whether aggregate type without a tuple mode can work for us.
> Here is the example:
>
> We already had a vector type "vint8mf8_t", the corresponding mode is
> VNx1SImode.
>
> Now we have an intrinsic as
May RTX code grow faster than machine mode ?
Since RTX code grows target independent wheras
machine mode grows target dependent.
In the future, we may easily have more and more targets that some target may
have a lot of machine mode.
Maybe Richard Sandiford suggestion is a good idea to fix it?
Richard Biener via Gcc-patches writes:
> On Mon, Mar 27, 2023 at 6:02 PM Kevin Lee wrote:
>>
>> This patch is a proper fix to the previous patch
>> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614463.html
>> vect_grouped_store_supported checks if the count is a power of 2, but
>> doesn't
On 11/04/2023 10:46, Richard Sandiford via Gcc-patches wrote:
writes:
ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
As far as I known, they don't have tuple type for partial vector.
Yeah, there are no separate types for partial vectors, but there
are separate modes. E.g.
On Tue, Apr 11, 2023 at 10:46:25AM +0100, Richard Sandiford wrote:
> I agree with all the comments about the danger of growing the number of
> modes too much. But it looks like rtx_def should be easy to rearrange.
> Unless I'm missing something, there are less than 256 rtx codes at
> present. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80883
LIU Hao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109470
--- Comment #5 from Jonathan Wakely ---
(In reply to Johannes Kellner from comment #3)
> 'A temporary object bound to a reference parameter in a function call
> persists until the completion of the full-expression containing the call.'
>
> So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109470
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109470
Johannes Kellner changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
writes:
> ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
> As far as I known, they don't have tuple type for partial vector.
Yeah, there are no separate types for partial vectors, but there
are separate modes. E.g. VNx2QI is a partial vector of QIs,
with each QI stored in a 64-bit
I am not sure whether aggregate type without a tuple mode can work for us.
Here is the example:
We already had a vector type "vint8mf8_t", the corresponding mode is VNx1SImode.
Now we have an intrinsic as following:
vint8mf8x2_t test_vlseg2e8_v_i8mf8(const int8_t *base, size_t vl) {
return
Hi Evandro,
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Evandro
> Menezes via Gcc-patches
> Sent: Friday, April 7, 2023 11:34 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Evandro Menezes ; Richard Sandiford
>
> Subject: [PATCH] aarch64:
Hi Jeff,
on 2023/4/11 17:14, guojiufu wrote:
> Hi Kewen,
>
> Thanks a lot for your very helpful comments!
>
> On 2023-04-10 17:26, Kewen.Lin wrote:
>> Hi Jeff,
>>
>> on 2023/4/10 10:09, Jiufu Guo via Gcc-patches wrote:
>>> Hi,
>>>
>>> In this test case (float128-cmp2-runnable.c), the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #44 from Richard Biener ---
The larger testcase:
typedef struct __attribute__((__packed__)) _Atom { float x, y, z; int type; }
Atom;
typedef struct __attribute__((__packed__)) _FFParams { int hbtype; float
radius; float hphb; float
On Mon, Mar 27, 2023 at 6:02 PM Kevin Lee wrote:
>
> This patch is a proper fix to the previous patch
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614463.html
> vect_grouped_store_supported checks if the count is a power of 2, but
> doesn't check the size of the GET_MODE_NUNITS.
> This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108241
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108241
--- Comment #4 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:cb06a507073e4d6218a70a2d5b0738a0487d6d9a
commit r13-7136-gcb06a507073e4d6218a70a2d5b0738a0487d6d9a
Author: Martin Liska
Date:
On Thu, Apr 6, 2023 at 3:58 PM Martin Liška wrote:
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed after stage1 opens?
Did we release a compiler with version 1? If not we might want to sneak
this in before 13.1 ...
Up to Honza.
Thanks,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108722
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
On Wed, Apr 5, 2023 at 11:53 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 4/5/23 14:10, Andrew MacLeod via Gcc-patches wrote:
> > When a statement is first processed, any SSA_NAMEs that are dependencies
> > are cached for quick future access.
> >
> > if we ;later rewrite the statement (say
No, we can only pass "available" to LCM.
Passing "compatible" to LCM can not work for us.
LCM can only help for eliminate vsetvls can not help for fuse vsetvls.
For example:
bb 0:
vsetvl e8,mf8
vadd (Demand SEW = 8, LMUL = MF8)
bb 1:
vsetvl e32 mf2
vle32 (Demand RATIO (SEW/LMUL) = 64, so
On Mon, Apr 10, 2023 at 11:14:46PM +0800, juzhe.zh...@rivai.ai wrote:
> ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
> As far as I known, they don't have tuple type for partial vector.
> However, for RVV not only has vint8m1_t, vint8m1x2_t, vint8m1x3_t,
> vint8m1x4_t, vint8m1x5_t,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #9 from Huaqi ---
Hi, Costas Argyris,
I am using this repo to help build toolchain, the repo link is here:
https://github.com/riscv-collab/riscv-gnu-toolchain
clone this source code and its submodule, and change gcc to upstream
Hi Kewen,
Thanks a lot for your very helpful comments!
On 2023-04-10 17:26, Kewen.Lin wrote:
Hi Jeff,
on 2023/4/10 10:09, Jiufu Guo via Gcc-patches wrote:
Hi,
In this test case (float128-cmp2-runnable.c), the instruction
xscmpexpqp is used to support a few builtins e.g.
On Wed, Apr 5, 2023 at 4:06 PM wrote:
>
> Hi everyone,
>
> This patchset contains around 80 commits concerning the Rust frontend.
>
> We have been hard at work trying to get the Rust core library to
> compile, and hope to push more commits in the coming days as we try
> and upstream a more recent
On Wed, Apr 5, 2023 at 4:06 PM wrote:
>
> Hi everyone,
>
> This patchset contains around 80 commits concerning the Rust frontend.
>
> We have been hard at work trying to get the Rust core library to
> compile, and hope to push more commits in the coming days as we try
> and upstream a more recent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #7 from CVS Commits ---
The master branch has been updated by Andre Simoes Dias Vieira
:
https://gcc.gnu.org/g:58c8c1b383bc3c286d6527fc6e8fb62463f9a877
commit r13-7135-g58c8c1b383bc3c286d6527fc6e8fb62463f9a877
Author: Andre Vieira
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #8 from Costas Argyris ---
Are you building the cross-compiler itself or just using an existing
cross-compiler to build for the windows host?
You may have to build the cross-compiler first from the latest gcc sources, and
then use
On 4/11/23 10:21, Jakub Jelinek wrote:
Hi!
This patch was what I've tried first before the currently committed
PR109386 fix. Still, I think it is the right thing until we have proper
full set of VREL_* relations for NANs (though it would be really nice
if op1_op2_relation could be passed
在 2023/4/11 16:51, LIU Hao via Gcc 写道:
My interpretation is that if one argument is a SNaN and the other is not,
`fmax()` shall return the
SNaN unchanged, without converting it to a QNaN. (F.10.9.2 The fmax functions,
ISO/IEC 9899:2017)
'the other is not' means the other operand is a
On Wed, Apr 5, 2023 at 3:53 PM wrote:
>
> >> So fusion in this context is really about identifying cases where two
> >> configuration settings are equivalent and you "fuse" them together.
> >> Presumably this is only going to be possible when the vector insns are
> >> just doing data movement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #7 from Costas Argyris ---
Still can't do much without detailed info on how exactly you are building gcc,
what is your build setup, what is your cross-compiler version, OS, how you
configure etc etc...Ideally, solid reproduction
在 2023/4/11 16:00, Richard Biener via Gcc 写道:
I think without NaNs MIN/MAX cannot raise any exceptions (I'm not
even sure whether MIN/MAX involving NaN will set invalid, but
most certainly with sNaN it will trap and return a quiet NaN?).
The C standard doesn't
document any exceptions for
On Wed, 5 Apr 2023, Andre Vieira (lists) wrote:
> Hi,
>
> The original patch to fix this PR broke the if-conversion of calls into
> IFN_MASK_CALL. This patch restores that original behaviour and makes sure the
> tests added earlier specifically test inbranch SIMD clones.
OOps.
> Bootstrapped
On Wed, Apr 5, 2023 at 10:39 AM Prathamesh Kulkarni via Gcc-patches
wrote:
>
> Hi,
> For the following test:
>
> svint32_t f(svint32_t v)
> {
> return svrev_s32 (svrev_s32 (v));
> }
>
> We generate 2 rev instructions instead of nop:
> f:
> rev z0.s, z0.s
> rev z0.s, z0.s
On Tue, 4 Apr 2023, David Malcolm wrote:
> Richi, Jakub: I can probably self-approve this, but it's technically a
> new feature. OK if I push this to trunk in stage 4? I believe it's
> low risk, and is very useful for benchmarking -fanalyzer.
Please wait for stage1 at this point. One comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109470
--- Comment #2 from Xi Ruoyao ---
With "-Wall -O1" this is diagnosed properly, but with a spurious
maybe-uninitialized warning:
In file included from /usr/include/c++/12.2.0/cassert:44,
from t.c:2:
t.c: In function 'int
On Mon, Apr 3, 2023 at 11:03 AM Martin Liška wrote:
>
> Hi.
>
> The patch propagates noreturn attribute for MV functions. However, I noticed
> we've got the following ICE when we do the same for TREE_READONLY attr:
>
> $ cat tc.c
> double bar()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26724
Matthijs Kooijman changed:
What|Removed |Added
CC||matthijs at stdin dot nl
---
On Mon, Apr 3, 2023 at 10:46 AM Martin Liška wrote:
>
> The revision r13-259-g76db543db88727 moved a condition from one
> file to another, but now we do not drop x_flag_var_tracking_assignments
> as it was done before the mentioned revision.
>
> Patch can bootstrap on x86_64-linux-gnu and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109470
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Hi!
This patch was what I've tried first before the currently committed
PR109386 fix. Still, I think it is the right thing until we have proper
full set of VREL_* relations for NANs (though it would be really nice
if op1_op2_relation could be passed either type of the comparison
operands, or
On Tue, 4 Apr 2023, Jan Hubicka wrote:
> > On Tue, Apr 04, 2023 at 01:21:40AM +0200, Jan Hubicka via Gcc-patches wrote:
> > > It is however really side case and I am worried about dropping
> > > pure/const from builtin declarations...
> >
> > Yeah, that can certainly break stuff. See e.g. the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109392
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
On Tue, 4 Apr 2023, Jan Hubicka wrote:
> > On Tue, 28 Mar 2023, Richard Biener wrote:
> >
> > > When adjusting calls to reflect instrumentation we failed to handle
> > > calls to aliases since they appear to have no body. Instead resort
> > > to symtab node availability. The patch also avoids
Hi!
When working on the PR109040 fix, I wanted to test it on some
WORD_REGISTER_OPERATIONS target and tried sparc-solaris on GCC Farm.
My bootstrap failed in comparison failure on cp/module.o, because
Solaris date doesn't support the -r option and one stage's cp/module.o
was built before midnight
On Wed, Apr 05, 2023 at 02:11:08PM +0200, Richard Biener wrote:
> Ok, but maybe there’s a gimple_build overload that meanwhile implements
> the desired semantics? It would probably need to specify the valueization
> hook to follow SSA edges beyond the sequence we’re currently building.
Jeff has
On Sat, 1 Apr 2023, Andrew Pinski wrote:
> Hi,
> I noticed while working on phi-opt, that MIN/MAX EXPR (and the
> corresponding RTL codes) both can return true for trapping even if
> NANs are not honored (that is -ffinite-math-only). Is this true? I
> would have assumed when -ffinite-math-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109470
Bug ID: 109470
Summary: unexpected const & behavior
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109469
--- Comment #5 from Sam James ---
(In reply to Sam James from comment #4)
> This might be a dupe of PR108783 or PR109410 but I had to try reduce it to
> be relatively sure, so may as well file it here for completeness.
I thought it was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109469
--- Comment #4 from Sam James ---
This might be a dupe of PR108783 or PR109410 but I had to try reduce it to be
relatively sure, so may as well file it here for completeness.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109469
--- Comment #3 from Sam James ---
Created attachment 54828
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54828=edit
util2.i (reduced further, but check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109469
--- Comment #2 from Sam James ---
Created attachment 54827
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54827=edit
util.i (reduced)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109469
--- Comment #1 from Sam James ---
Created attachment 54826
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54826=edit
util.i.orig (unreduced)
101 - 200 of 203 matches
Mail list logo
