https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #10 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #9)
> Although, preferably we should not allow assigning one opaque type to another
> opaque type just because they will eventually use the same mode, not without
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #11 from Kewen Lin ---
One modified case from pr102347.c (same option set is used), which can
reproduce the ICE without any gcc source adjustment.
#pragma GCC target "cpu=power10"
int main ()
{
float *b;
const __vector_quad c;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #12 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #11)
> (In reply to Peter Bergner from comment #10)
> > (In reply to Segher Boessenkool from comment #9)
> > > When MMA is not enabled,
> > ...
> > > the __vector_{q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100645
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100645
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #6 fr
Severity: minor
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, hubicka at gcc dot gnu.org,
rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106941
Bug 106941 depends on bug 106833, which changed state.
Bug 106833 Summary: Miss to handle OPAQUE_TYPE specially in verify_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
What|Removed |Added
---
dot gnu.org |linkw at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #14 from Kewen Lin ---
Should be fixed on trunk, opened PR106941 for conversion as Segher's comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #16 from Kewen Lin ---
(In reply to Peter Bergner from comment #15)
> (In reply to Kewen Lin from comment #14)
> > Should be fixed on trunk
>
> I assume this is broken on the release branches too and we'll need backports?
Good ques
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105485
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104482
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #54 from Kewen Lin ---
(In reply to Mathieu Malaterre from comment #53)
> Closing. I do not believe that Debian gcc-12 (12.2.0-3) really is an update
> to git 20220920 from the gcc-12 branch. Sorry for the noise.
OK. Thanks for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||linkw at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #4 from Kewen Lin ---
r13-2984 makes gcc emit error for -fpatchable-function-entry=1 on ppc64le if
the relavant function needs dual entry, I think we can close this one.
*** This bug has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
Kewen Lin changed:
What|Removed |Added
CC||giuliano.belinassi at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99889
Bug 99889 depends on bug 99888, which changed state.
Bug 99888 Summary: Add powerpc ELFv2 support for -fpatchable-function-entry*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
--- Comment #9 from Kewen Lin ---
>
> The above doesn't look wrong (but may miss the rest of the IL). On
> x86_64 this looks like
>
>[local count: 105119324]:
> # sum0_41 = PHI
> # sum1_39 = PHI
> # sum2_37 = PHI
> # sum3_35 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
--- Comment #11 from Kewen Lin ---
> > > Btw, I've fixed a SLP reduction issue two days ago in
> > > r13-3226-gee467644c53ee2
> > > though that looks unrelated?
> >
> > Thanks for the information, I'll double check it.
> >
To rebase to r13-32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
--- Comment #18 from Kewen Lin ---
Thanks for the prompt fix! I just verified it fixed the SPEC2006 447.dealII
regression perfectly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
--- Comment #7 from Kewen Lin ---
Well, it does helps vect-bitfield-write-{2,3}.c, but it doesn't help
vect-bitfield-write-{2,3,4}.c since they do require vector/vector shift
supports.
I guess it might be a good idea to add the vect_long_long e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
--- Comment #8 from Kewen Lin ---
(In reply to Kewen Lin from comment #7)
> Well, it does helps vect-bitfield-write-{2,3}.c, but it doesn't help
> vect-bitfield-write-{2,3,4}.c since they do require vector/vector shift
Oops, typo here, should b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100645
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|NEW
CC||linkw at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Kewen Lin ---
Confirmed, this issue is BE specific.
vect__ifc__10.14_55 = MEM [(struct s *)_22];
vect__ifc__10.15_57 = MEM
gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #4 from Kewen Lin ---
(In reply to avieira from comment #3)
> Hi Kewen,
>
> I believe you are right. I was waiting for a powerpc machine in the board
> farm, but I suspect I can reproduce this with an aarch64 BE target and I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #12 from Kewen Lin ---
(In reply to Arseny Solokha from comment #11)
> Unfortunately, I still have exactly the same ICE on this testcase w/ 12.0.0
> alpha20211219 snapshot:
>
> % powerpc-e300c3-linux-gnu-gcc-12.0.0 -mcpu=401 tt.c
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #14 from Kewen Lin ---
> % powerpc-e300c3-linux-gnu-gcc-12.0.0 -v
> Using built-in specs.
> COLLECT_GCC=powerpc-e300c3-linux-gnu-gcc-12.0.0
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-e300c3-linux-gnu/12.0.0/lto-
> wrapper
> Targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #15 from Kewen Lin ---
>
> I tried it on a x86_64 cfarm machine:
>
> /home/linkw/gcc/gcc-test/configure --host=x86_64-pc-linux-gnu
> --target=powerpc-e300c3-linux-gnu --build=x86_64-pc-linux-gnu
> --prefix=/home/linkw/gcc/install/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #17 from Kewen Lin ---
(In reply to Arseny Solokha from comment #16)
> Could there be any ld, or as, or glibc features involved that gcc's
> configure detects at build time?
Good point, what's the version of binutils you used? Does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #20 from Kewen Lin ---
(In reply to Arseny Solokha from comment #19)
> (In reply to Kewen Lin from comment #17)
> > (In reply to Arseny Solokha from comment #16)
> > > Could there be any ld, or as, or glibc features involved that gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Kewen Lin changed:
What|Removed |Added
Last reconfirmed|2021-12-10 00:00:00 |2021-12-27
--- Comment #21 from Kewen Lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104004
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
|1
CC||avieira at gcc dot gnu.org,
||linkw at gcc dot gnu.org
Last reconfirmed||2022-01-14
--- Comment #1 from Kewen Lin ---
I think it's caused by r12-6240, si
||rguenth at gcc dot gnu.org,
||rsandifo at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #2 from Kewen Lin ---
With further investigation, this isn't duplicated. Now we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #4 from Kewen Lin ---
Hi Andre,
Thanks for the detailed explanations all below!
(In reply to avieira from comment #3)
> Hi Kewen,
>
> Thanks for the analysis. The param_vect_partial_vector_usage suggestion
> seems valid, but that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #9 from Kewen Lin ---
(In reply to rsand...@gcc.gnu.org from comment #6)
> I think the patch in comment 2 is the correct fix (OK to commit).
>
Thanks for the review and approval Richard!
I totally agree this test case can be fragi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103702
--- Comment #4 from Kewen Lin ---
Patch was posted with the link
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587309.html, still
pending on review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #11 from Kewen Lin ---
(In reply to rsand...@gcc.gnu.org from comment #10)
> Checking the number of tries might be useful, but if so, I think
> it should be done by a test that was written for that specific
> purpose. The tst can th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103702
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #30 from Kewen Lin ---
(In reply to pc from comment #27)
> There was a commit related to this bug, but it is still in ASSIGNED state,
> so I'm not sure if this was to be considered "fixed", but...
>
> Chip discovered that, with a bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #32 from Kewen Lin ---
(In reply to Michael Meissner from comment #31)
> Created attachment 52383 [details]
> Simpler patch to fix the problem with power8-fusion.
>
> This patch just ignores the -mpower8-fusion option in the callee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
Kewen Lin changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #35 from Kewen Lin ---
> I don't think the r12-6219 commit qualifies for backporting. What about the
> comment#31 patch? Does it address the issue for Eigen on the branches?
Got it. comment#31 patch can only address the mismatch i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103627
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||linkw at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2022-02-16
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
Confirmed.
Can't reproduce
|NEW
CC||linkw at gcc dot gnu.org
Last reconfirmed||2022-02-17
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104004
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99197
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #25 from Kewen Lin ---
The key difference from the previous bif support is that: previously we checked
TARGET_HARD_FLOAT but now we didn't. I think we still need to check it, as the
document here
https://gcc.gnu.org/onlinedocs/gcc/Ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #26 from Kewen Lin ---
Created attachment 52474
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52474&action=edit
Untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104024
--- Comment #2 from Kewen Lin ---
Created attachment 52475
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52475&action=edit
Tested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104024
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
For the case:
#include "stdbool.h"
#define N 256
typedef char T;
extern T a[N];
extern T b[N];
extern T c[N];
extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
Kewen Lin changed:
What|Removed |Added
CC||segher at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #25 from Kewen Lin ---
Status update:
>
> The fusion related flags have been considered in the posted patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578552.html.
>
It's still being ping-ed for review since it'
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
Test case:
gcc/testsuite/g++.dg/torture/pr81360.C
Option:
-fno-early-inlining -Os
For function rs6000_can_inline_p, I tried to test if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103515
Kewen Lin changed:
What|Removed |Added
Target||powerpc
--- Comment #1 from Kewen Lin ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103515
--- Comment #2 from Kewen Lin ---
Here I assumed that the current cl optimization/option save and restore scheme
wants to keep the global_option/global_option_set same as the one from the
initial option processing. After we parsing all attribut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103515
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
For the test case:
vector double test(double *a, double *b) {
return (vector double) { *a, *b };
}
On Power10, we generate the
,
||linkw at gcc dot gnu.org,
||segher at gcc dot gnu.org,
||wschmidt at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
Confirmed, this requires one e300c3 cross build to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622
--- Comment #2 from Kewen Lin ---
Got exposed from r12-5752, r12-5751 we got the error msg like:
test.c: In function ‘get_float128_exponent’:
test.c:6:5: note: builtin ‘__builtin_vec_scalar_extract_exp’ requires builtin
‘__builtin_vsx_scalar_ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622
--- Comment #3 from Kewen Lin ---
> One thought seems to check instance->fntype first and take (skip) it as
> mismatch if it's NULL.
This looks like a bad idea, to use long double as the type instead of float128
when type float128 isn't suppor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #1
,
||linkw at gcc dot gnu.org,
||segher at gcc dot gnu.org,
||wschmidt at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
Probably started to fail from r12-5752.
In the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #2 from Kewen Lin ---
> One fix seems to introduce one stanza for 128bit long double like previous
> RS6000_BTM_LDBL128 which is enabled only if (TARGET_LONG_DOUBLE_128 &&
> TARGET_HARD_FLOAT && !TARGET_IEEEQUAD), and guard
> __buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
||2021-12-10
CC||bergner at gcc dot gnu.org,
||linkw at gcc dot gnu.org,
||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103627
--- Comment #2 from Kewen Lin ---
Confirmed. But even if I reverted my previous commit r12-5590 which introduced
this test case (from PR102347) into testsuites, this ICE still exists. So it's
not a regression related to the commit but a latent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625
--- Comment #6 from Kewen Lin ---
(In reply to Bill Schmidt from comment #4)
> Kewen, how did you confirm this? My cross doesn't accept -mvsx as valid.
>
> $ /home/wschmidt/gcc/build/gcc-e300/gcc/xgcc -c -O2 -mvsx pr103625.c
> -B/home/wschmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103702
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103702
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622
--- Comment #10 from Kewen Lin ---
> test.c: In function ‘get_float128_exponent’:
> test.c:4:5: note: overloaded builtin ‘__builtin_vec_scalar_extract_exp’ is
> implemented by builtin ‘__builtin_vsx_scalar_extract_expq’
>4 | return __bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
As PR102347 discussed and tested, aarch64 also does too strict built-in
function decl check. Here is one test case copied from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
--- Comment #19 from Kewen Lin ---
Filed PR103727 for aarch64 issue tracking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103627
--- Comment #3 from Kewen Lin ---
Also failed with r12-0.
I looked into the ICE with -mcpu=power6 -m32 on BE, the direct reason is that
we turn off VSX flag but still leave MMA, when it wants to emit one move for
V16QI it has to use multiple wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103627
--- Comment #4 from Kewen Lin ---
For test.c, even we are on ppc64le P9, it can also get ICE:
extern float *dest;
extern __vector_quad src;
int
foo ()
{
__builtin_mma_disassemble_acc (dest, &src);
return 0;
}
$ gcc test.c -mcpu=power10 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #20 from Kewen Lin ---
Thanks for the detailed explanation, Mike!
The fusion related flags have been considered in the posted patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578552.html.
One RFC/Patch
https://gcc.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102054
--- Comment #2 from Kewen Lin ---
Yet another reduced test case from 526.blender_r.
#include
typedef struct QMCSampler {
struct QMCSampler *next, *prev;
int type;
int tot;
int used;
double *samp2d;
double offs[1][2];
} QMCSampler;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #23 from Kewen Lin ---
(In reply to Chip Kerchner from comment #22)
> (In reply to Chip Kerchner from comment #21) - Forgot one line of code
> > --
> > #pragma GCC target "cpu=power10"
> > int main() {
> > float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
--- Comment #3 from Kewen Lin ---
This seems not a target specific issue. I noticed the target_option tree node
is created expectedly when seeing target pragma, it explains why it works well
without lto. When lto does streaming out, it does stre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102383
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
--- Comment #4 from Kewen Lin ---
I found i386 port seems doesn't have this issue.
#include
#include
typedef union
{
__m128 x;
float a[4];
} union128;
#pragma GCC target("sse")
int main() {
union128 u;
__m128 a = _mm_set_ps (24.43,
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
The UInteger type in Opt/Param declaration can easily confuse people that the
variable for this option/parameter is unsigned. But actually the internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102440
Kewen Lin changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Severit
401 - 500 of 967 matches
Mail list logo
