https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 51492, which changed state.
Bug 51492 Summary: vectorizer does not support saturated arithmetic patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
--- Comment #23 from Uroš Bizjak ---
Current compiler produces (-O3):
f:
movl$4194368, %edx
movl$head, %eax
movd%edx, %xmm1
pshufd $0, %xmm1, %xmm1
.L2:
movdqa (%rax), %xmm0
addq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
--- Comment #17 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #16)
> > Unfortunately, x86 has no vector mode .SAT_TRUNC instruction.
> No, AVX512 supports both signed and unsigned saturation
Indeed.
BTW: PACKUSmn (despite the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #22 from Uroš Bizjak ---
(In reply to Sam James from comment #21)
> I think the instructions were for OP's benefit.
True ;)
@Maciej: I'd like to keep the testcase that also exercises the assembler,
because the error is best
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
--- Comment #15 from Uroš Bizjak ---
(In reply to Li Pan from comment #14)
> Hi Uroš,
>
> > Please note two new instructions in the second asm dump. These are expanded
> > from .SAT_TRUNC and are not present in the first asm dump.
>
> > The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #18 from Uroš Bizjak ---
> make -k check-gcc RUNTESTFLASG=alpha.exp=pr115526.c
s/RUNTESTFLASG/RUNTESTFLAGS/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #17 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #16)
> Can you please test this slightly cleaned up testcase?
Just put it in gcc/testsuite/gcc.target/alpha and do:
make -k check-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #16 from Uroš Bizjak ---
Created attachment 58666
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58666=edit
Cleaned up testcase
Can you please test this slightly cleaned up testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
--- Comment #11 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #10)
> Created attachment 58650 [details]
> Testcase that illustrates performance issue
Without ustrunc{m}{m}2 optab the loop in the testcase compiles to (gcc -O2):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
--- Comment #10 from Uroš Bizjak ---
Created attachment 58650
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58650=edit
Testcase that illustrates performance issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
--- Comment #9 from Uroš Bizjak ---
(In reply to Li Pan from comment #8)
> Thanks Richard.
> Yes, the .SAT_TRUNC doesn't pay any attention the other possible use of
> MIN_EXPR.
>
> As your suggestion, we may need one additional check here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115881
--- Comment #5 from Uroš Bizjak ---
(In reply to Richard Sandiford from comment #4)
> As expected, the results weren't pretty. Things like:
>
> (define_split
> [(set (match_operand:SWI48 0 "register_operand")
> (and:SWI48 (match_dup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115881
Uroš Bizjak changed:
What|Removed |Added
Keywords|ice-checking|
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115881
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
Uroš Bizjak changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
Uroš Bizjak changed:
What|Removed |Added
Component|target |middle-end
--- Comment #11 from Uroš
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
Uroš Bizjak changed:
What|Removed |Added
CC||macro at orcam dot me.uk
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #12 from Uroš Bizjak ---
(In reply to Andreas K. Huettel from comment #11)
> > Can someone please regression test the attached patch?
>
> More in a bit, but:
Any progress with testing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #35 from Uroš Bizjak ---
(In reply to Mayshao-oc from comment #34)
> Can we extend this patch to Zhaoxin processors as well?
Just post the enablement patch to gcc-patches@ mailing list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |11.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
Uroš Bizjak changed:
What|Removed |Added
Attachment #58618|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
--- Comment #8 from Uroš Bizjak ---
Some more explanation:
Later in emit_store_flag_1 we have:
if (icode != CODE_FOR_nothing)
{
do_pending_stack_adjust ();
rtx tem = emit_cstore (target, icode, code, mode,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
--- Comment #7 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #6)
> Proposed patch.
Here is the problem:
The compiler enters emit_store_flag_1 with:
op0=(subreg:SF (reg:SI 424 [ _676 ]) 0)
op1=(reg:SF 1308)
First, the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
--- Comment #5 from Uroš Bizjak ---
ICE happens in:
#1 0x018e82a7 in ix86_expand_int_movcc (operands=0x7fffc140) at
../../git/gcc/gcc/config/i386/i386-expand.cc:3821
3821 out = expand_simple_binop (mode, PLUS,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
--- Comment #2 from Uroš Bizjak ---
The testcase compiles OK for me with today's compiler:
xgcc (GCC) 15.0.0 20240709 (experimental) [master r15-1905-g23ab7f632f4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #10 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #9)
> Created attachment 58549 [details]
> Proposed patch
Can someone please regression test the attached patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #7 from Uroš Bizjak ---
(In reply to Richard Biener from comment #6)
> So it likely expects f1@GOTPCREL(%rip) to be CSEd?
>
> f2:
> .LFB2:
> .cfi_startproc
> subq$8, %rsp
> .cfi_def_cfa_offset 16
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #8 from Uroš Bizjak ---
(In reply to Sam James from comment #7)
> Uros, is there any chance you'd be so kind to take a look?
I'm afraid that this is not some dead-simple issue that I can fix without the
access to the alpha machine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643
--- Comment #8 from Uroš Bizjak ---
(In reply to Evgeny Karpov from comment #7)
> Thanks for pointing that out! The fix will be included in the patch that
> fixes the regression.
While there, can you perhaps rename:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115655
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521
--- Comment #2 from Uroš Bizjak ---
Similar to PR114942.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115506
--- Comment #2 from Uroš Bizjak ---
For the original testcase tree optimizers optimize to:
[local count: 114863530]:
_30 = _2 & 240;
if (_30 == 224)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 75809929]:
if (_30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115452
--- Comment #1 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #0)
> cut from i386-features.cc:1056---
>
> if (dump_file)
> fprintf (dump_file, " Preloading operand for insn %d into r%d\n",
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387
--- Comment #6 from Uroš Bizjak ---
The testcase is at [1].
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115404#c4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115404
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115404
--- Comment #3 from Uroš Bizjak ---
(In reply to Sergei Trofimovich from comment #0)
> if (__builtin_add_overflow ((uintptr_t) string, maxlen, ))
> end = -1;
>
> Could it be that dead store to `` somehow conflicts with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115404
Uroš Bizjak changed:
What|Removed |Added
CC||pan2.li at intel dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115374
--- Comment #8 from Uroš Bizjak ---
When compiling the following testcase:
--cut here--
#include
double
__attribute__((noinline))
do_fmod (double x, double y)
{
return fmod(x, y);
}
--cut here--
one can find in _.265t.optimized:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600
Uroš Bizjak changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115297
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115321
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115321
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115297
--- Comment #1 from Uroš Bizjak ---
Created attachment 58315
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58315=edit
Proposed patch
any_divmod instructions are modelled with invalid RTX:
[(set (match_operand:DI 0 "register_operand"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115102
--- Comment #4 from Uroš Bizjak ---
(In reply to Richard Biener from comment #1)
> though on x86 there's no high word preserving swap of the lower 2 bytes.
There is, please try:
asm ("xchgb %h0, %b0" : "+Q" (val));
like:
--cut here--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #5 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 58261 [details]
> gcc15-pr115172.patch
>
> Full untested patch.
I can confirm that this patch fixes boot for the kernel config from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #3 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #1)
> What the kernel does is terrible, why they just don't declare the extern
> with __seg_gs attribute?
This is how kernel currently handles percpu variables. They
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #50 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #49)
> Will do in a moment.
PR 115172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
Bug ID: 115172
Summary: Invalid -fsanitize=bool sanitization of variable from
named address space
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #47 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #46)
> Created attachment 58259 [details]
> Preprocessed file
>
> gcc -O2 -fsanitize=kernel-address -fasan-shadow-offset=0xdc00
> --param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #46 from Uroš Bizjak ---
Created attachment 58259
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58259=edit
Preprocessed file
gcc -O2 -fsanitize=kernel-address -fasan-shadow-offset=0xdc00
--param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #17 from Uroš Bizjak ---
(In reply to Haochen Jiang from comment #15)
> I am doing like this way. Suppose should be same as Comment 8.
Yes, but IMO the patch in Comment #8 better describes where the problem is.
Please note that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #13 from Uroš Bizjak ---
(In reply to Haochen Jiang from comment #12)
> (In reply to Hongtao Liu from comment #11)
> > (In reply to Haochen Jiang from comment #10)
> > > A patch like Comment 8 could definitely solve the problem. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
--- Comment #8 from Uroš Bizjak ---
(In reply to Levy Hsu from comment #5)
> case E_V16QImode:
> mode = V8HImode;
> gen_shr = gen_vlshrv8hi3;
> gen_shl = gen_vashlv8hi3;
Hm, why vector-by-vector shift here? Should there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #9 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #8)
> A better patch:
The real issue is that the following permutation (truncation):
+ for (i = 0; i < d.nelt; ++i)
+ d.perm[i] = i * 2;
+
+ ok =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #7 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #5)
> (In reply to Krzysztof Kanas from comment #4)
> > I bisected the issue and it seems that commit
> > 0368fc54bc11f15bfa0ed9913fd0017815dfaa5d introduces regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
--- Comment #3 from Uroš Bizjak ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942
--- Comment #2 from Uroš Bizjak ---
This is the insn in question:
;; Alternative 1 is needed to work around LRA limitation, see PR82524.
(define_insn_and_split "*qi_ext_1_slp"
[(set (strict_low_part (match_operand:QI 0 "register_operand"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|13.3|11.5
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #14 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #13)
> Created attachment 58013 [details]
> gcc14-pr114810.patch
>
> So like this? Tried hard to reduce the testcase, but it didn't progress at
> all, so at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #12 from Uroš Bizjak ---
(In reply to Vladimir Makarov from comment #9)
> (In reply to Uroš Bizjak from comment #7)
> >
> >
> > Please note that the insn is defined as:
> >
> > (define_insn_and_split "*andn3_doubleword_bmi"
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #11 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Uroš Bizjak from comment #7)
> > (define_insn_and_split "*andn3_doubleword_bmi"
> > [(set (match_operand: 0 "register_operand" "=,r,r")
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #7 from Uroš Bizjak ---
(In reply to Vladimir Makarov from comment #6)
> The problem is that the alternative assumes 3 DI values live simultaneously.
> This means 6 regs and we have only 6 available ones. One input reg is
> assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #4 from Uroš Bizjak ---
An interesting observation, when the insn is defined only with problematic
alternative:
(define_insn_and_split "*andn3_doubleword_bmi"
[(set (match_operand: 0 "register_operand" "=")
(and:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #13 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #12)
> short a;
> short c;
> short d;
> void
> foo (short b, short f)
> {
> c = b + a;
> d = f + a;
> }
>
> foo(short, short):
> addwa(%rip), %di
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #13 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #12)
> You cannot use a :CC value as argument of an unspec, as explained before.
>
> The result of a comparison is expressed as a comparison, in RTL. This patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #11 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #10)
> It is still wrong. You're trying to sweep tour wrong assumptions under the
> rug,
> but they will only rear up elsewhere. Just fix the actual *target*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #10 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #5)
> > My experience is memory cost for the operand with rm or separate r, m is
> > different which impacts RA decision.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #8 from Uroš Bizjak ---
BTW: The reason for the original change:
(define_insn "*movhi_internal"
- [(set (match_operand:HI 0 "nonimmediate_operand" "=r,r ,r ,m ,*k,*k
,*r,*m,*k,?r,?v,*v,*v,*m")
- (match_operand:HI 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #7 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #5)
> > My experience is memory cost for the operand with rm or separate r, m is
> > different which impacts RA decision.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #6 from Uroš Bizjak ---
LRA starts with this:
5: r98:SI=[`v1']
REG_EQUIV [`v1']
6: [`v2']=zero_extend(r98:SI)
7: r101:HI=r98:SI#0
REG_DEAD r98:SI
12: ax:HI=r101:HI
REG_DEAD r101:HI
13: use ax:HI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #3 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #2)
> This changed with r12-5584-gca5667e867252db3c8642ee90f55427149cd92b6
Strange, if I revert the constraints to the previous setting with:
--cut here--
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #9 from Uroš Bizjak ---
(In reply to Richard Biener from comment #8)
> Fixed I suppose.
Yes - I plan backport the patch to at least gcc-13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #9 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #2)
> /* If we didn't see a full return value copy, verify that there
>is a plausible reason for this. If some, but not all of the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114547
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > Adding -msse to the second compilation works OK, removing -mfpmath=sse from
> > the first compilation also works OK.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
--- Comment #3 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #2)
> Adding -msse to the second compilation works OK, removing -mfpmath=sse from
> the first compilation also works OK.
Which makes this PR a LTO reincarnation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
--- Comment #2 from Uroš Bizjak ---
(In reply to Richard Biener from comment #1)
> (insn 6 5 0 (set (reg/v:SF 99 [ gamma ])
> (reg:SF 20 xmm0)) "testautomation-testautomation_pixels.i":15:17 -1
> (nil))
>
> I'm not sure what's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #29 from Uroš Bizjak ---
Do we also need to adjust TSAN? There is a bugreport that KCSAN does work
correctly with the named address spaces.(In reply to Jakub Jelinek from comment
#28)
> Created attachment 57807 [details]
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #26 from Uroš Bizjak ---
Do we also need to adjust TSAN? There is a bugreport that KCSAN does work
correctly with the named address spaces.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #19 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #16)
> (In reply to Richard Biener from comment #13)
> > The original testcase is fixed, appearantly slapping 'extern' on the int
> > makes it not effective.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #16 from Uroš Bizjak ---
(In reply to Richard Biener from comment #13)
> The original testcase is fixed, appearantly slapping 'extern' on the int
> makes it not effective.
>
> Possibly better amend the
>
> if (VAR_P (inner) &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #12 from Uroš Bizjak ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #11 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #10)
> Huh, is this really fixed?
IMO, this patch is also needed:
--cut here--
diff --git a/gcc/asan.cc b/gcc/asan.cc
index cfe83106460..54dcc3a38db 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #22 from Uroš Bizjak ---
Fixed also for TImode STV.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #18 from Uroš Bizjak ---
When we split
(insn 37 36 38 10 (set (reg:DI 104 [ _18 ])
(mem:DI (reg/f:SI 98 [ CallNative_nclosure.0_1 ]) [6 MEM[(struct
SQRefCounted *)CallNative_nclosure.0_1]._uiRef+0 S8 A32])) "test.C":22:42 84
1 - 100 of 884 matches
Mail list logo