https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94248
--- Comment #3 from Andrew Stubbs ---
Actually, I think that recent changes to the register alignment mean that this
can't happen any more, so the whole check is probably obsolete.
I thought that --enable-checking=yes was already covering this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94282
--- Comment #3 from Andrew Stubbs ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Tobias Burnus from comment #1)
> > The symbol __gxx_personality_v0 is part of libsupc++ – which I believe is
> > not build to to lacking/restricted C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
--- Comment #11 from Andrew Stubbs ---
(In reply to Jakub Jelinek from comment #10)
> or if instead we should drop the "status = " for the cases where nothing
> checks it. Andrew?
I think checking the status is probably good practice, even thoug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94248
--- Comment #5 from Andrew Stubbs ---
(In reply to Thomas Schwinge from comment #4)
> (In reply to Andrew Stubbs from comment #3)
> > Actually, I think that recent changes to the register alignment mean that
> > this can't happen any more, so the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94278
--- Comment #2 from Andrew Stubbs ---
Well, it works for me:
PASS: libgomp.c/examples-4/async_target-2.c (test for excess errors)
PASS: libgomp.c/examples-4/async_target-2.c execution test
That's with an unmodified LLVM 9 we built ourselves.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94248
--- Comment #7 from Andrew Stubbs ---
I'd rather remove the whole if branch, but given you've tested this already
then it's probably the best short term fix. Please go ahead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94278
--- Comment #4 from Andrew Stubbs ---
Almost all the tests listed in pr81430 pass for me (and the exception I found
is a link error).
I don't understand what's happening with your build, but from my point of view
the patch fixes an issue that do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94282
--- Comment #6 from Andrew Stubbs ---
I think we've decided to with Thomas's approach.
Thomas, please go ahead and commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
--- Comment #23 from Andrew Stubbs ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Andrew Stubbs from comment #11)
> > (In reply to Jakub Jelinek from comment #10)
> > > or if instead we should drop the "status = " for the cases w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94725
Andrew Stubbs changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93488
Andrew Stubbs changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95730
--- Comment #1 from Andrew Stubbs ---
GCN uses TImode for a few special purposes, but lacks real TImode support.
(Basically, it allows TImode loads and stores for the SLP fake vectorization,
and there's one instruction that needs two DImode valu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95730
--- Comment #3 from Andrew Stubbs ---
The GCN port does not define a scalar_mode_supported, and I think the default
definition is allowing TImode (as long long int). As I said, the SLP
fake-vector load/store use it fine as a substitute for V4SI o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95864
--- Comment #1 from Andrew Stubbs ---
I'm aware of these issues.
I fixed all the test failures that were definitely bugs in the HSACOv3
implementation, and the ones that remain appear to be either latent bugs
uncovered by the new driver configur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96306
--- Comment #3 from Andrew Stubbs ---
TImode was added for use by a few instructions that take two 64-bit values in
consecutive registers. It's also useful for the SLP fake vectorization stuff.
It wasn't intended for use with user types; I proba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96306
--- Comment #5 from Andrew Stubbs ---
GCC will automatically generate libgcc calls for types up to 2*BITS_PER_WORD,
but no further. Since BITS_PER_WORD is 32 on GCN this means no automatic TImode
support for anything that would go that route (suc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95730
--- Comment #4 from Andrew Stubbs ---
In fact default_scalar_mode_supported_p does return *false* for TImode (because
LONG_LONG_TYPE_SIZE == 64, and BITS_PER_WORD == 32).
Therefore int128_t does not exist, as far as users are concerned. I'm not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96306
--- Comment #8 from Andrew Stubbs ---
I'm loath to enable TImode if it's going to ICE all over the place, and I can't
just drop everything else and implement working TImode unless there's an easy
solution. It's always been on the nice-to-have lis
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ams at gcc dot gnu.org
Target Milestone: ---
The testcase pr65947-10.c fails on amdgcn because there are more vector lanes
than there is data, and the algorithm created doesn't allow for this. (Actually
there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92772
--- Comment #3 from Andrew Stubbs ---
The GCN architecture can handle the masking, but I don't know how we'd
represent or apply that in the middle end?
I can probably implement extract_last, and that might be more efficient, but I
don't see how
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92772
--- Comment #6 from Andrew Stubbs ---
(In reply to Richard Biener from comment #4)
> Btw, isn't the issue that the reduction looks at all lanes? That is,
> I think the code simply assumes that for fully masked loops at least
> one iteration is p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92772
Andrew Stubbs changed:
What|Removed |Added
Priority|P3 |P5
Severity|critical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93409
Andrew Stubbs changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47976
Summary: Recent fortran testsuite regressions
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42947
--- Comment #4 from Andrew Stubbs ---
With multilibs enabled this is usually the correct behaviour, but I wouldn't
have expected this with --disable-multilib.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50128
--- Comment #1 from Andrew Stubbs 2011-08-19 16:24:09
UTC ---
I believe this is fixed in 177910, if not before.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43862
Andrew Stubbs changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #3
||2011-09-01
CC||ams at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |ams at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from Andrew
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50318
Bug #: 50318
Summary: ICE optimizing widening multiply-and-accumulate
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Pr
||2011-09-07
AssignedTo|unassigned at gcc dot |ams at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Andrew Stubbs 2011-09-07 11:08:06
UTC ---
The problem is a bug in my recent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50318
--- Comment #2 from Andrew Stubbs 2011-09-08 19:45:41
UTC ---
Author: ams
Date: Thu Sep 8 19:45:37 2011
New Revision: 178708
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178708
Log:
2011-09-08 Andrew Stubbs
PR tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50318
Andrew Stubbs changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50193
Andrew Stubbs changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50717
Andrew Stubbs changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #4
||2011-10-14
AssignedTo|unassigned at gcc dot |ams at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #5 from Andrew Stubbs 2011-10-14 15:25:49
UTC ---
I think I've identified the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50717
--- Comment #6 from Andrew Stubbs 2011-10-15 21:29:12
UTC ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01397.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50717
--- Comment #7 from Andrew Stubbs 2011-10-18 19:57:19
UTC ---
Author: ams
Date: Tue Oct 18 19:57:15 2011
New Revision: 180164
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180164
Log:
2011-10-18 Andrew Stubbs
PR tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50717
Andrew Stubbs changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50809
--- Comment #2 from Andrew Stubbs 2011-10-21 10:31:53
UTC ---
Author: ams
Date: Fri Oct 21 10:31:48 2011
New Revision: 180289
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180289
Log:
2011-10-21 Andrew Stubbs
PR target/50809
||FIXED
AssignedTo|unassigned at gcc dot |ams at gcc dot gnu.org
|gnu.org |
--- Comment #3 from Andrew Stubbs 2011-10-21 10:40:16
UTC ---
Fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53189
Bug #: 53189
Summary: DImode and/or/not/xor optimized poorly in
core-registers
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53189
--- Comment #1 from Andrew Stubbs 2012-05-02 11:25:35
UTC ---
I do mean "anddi3" not "adddi3" in the description. :(
My fingers have bad habits ...
||2012-05-14
AssignedTo|unassigned at gcc dot |ams at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from Andrew Stubbs 2012-05-14 09:24:02
UTC ---
I'm working on some patche
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52260
Andrew Stubbs changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88898
Andrew Stubbs changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #5 from Andrew Stubbs ---
The llvm_binutils check is needed because those tools emit blank lines all over
the place, so we end up with hundreds of stupid failures.
I'll look into caching it though.
at gcc dot gnu.org |ams at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #7 from Andrew Stubbs ---
I'm not sure that an assembler or linker can be labelled "insane" for choosing
to include some blank lines amongst its diagnostics. :-)
In any case, there's no other tool available, and no time/money availab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #9 from Andrew Stubbs ---
(In reply to Jakub Jelinek from comment #8)
> First of all, I thought the current trunk amdgcn support is non-offloading
> only, so you could at least for now always return 0 from
> check_effective_target_off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #11 from Andrew Stubbs ---
Created attachment 45481
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45481&action=edit
Cache test
This patch caches the result so that the (harmless) error message occurs only
once.
Is there a way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89095
--- Comment #2 from Andrew Stubbs ---
There's a patch on pr88920, but no review yet. I was planning to chase it
today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #12 from Andrew Stubbs ---
Author: ams
Date: Wed Jan 30 11:26:31 2019
New Revision: 268384
URL: https://gcc.gnu.org/viewcvs?rev=268384&root=gcc&view=rev
Log:
Cache effective-target llvm_binutils result.
2019-01-30 Andrew Stubbs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
Andrew Stubbs changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
Andrew Stubbs changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89095
Andrew Stubbs changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82089
Andrew Stubbs changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91198
--- Comment #1 from Andrew Stubbs ---
I don't believe GCC detects that operation automatically.
It does support the instruction via intrinsics (builtin functions that
correspond to low-level machine features). You should investigate
"__builtin_i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #17 from Andrew Stubbs ---
If this is going to annoy a lot of people then I suppose I could add an
additional message stating that the error can safely be ignored?
Or, maybe there's a way to silence/hide the output from
check_no_comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920
--- Comment #23 from Andrew Stubbs ---
It's caused by the llvm_binutils check, which is used by pretty much every test
to determine whether to complain about blank lines in compile output, or not.
Right now the easiest way to determine if it's u
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ams at gcc dot gnu.org
Target Milestone: ---
Initializing arrays (or just assigning them) using implied do loops (or
whatever the proper Fortran name is) does not work within OpenMP "target"
regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #3 from Andrew Stubbs ---
My code now compiles successfully, with the patch, but it hangs at runtime.
I need to investigate, but debugging runtime issues on the GPU is slow work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #4 from Andrew Stubbs ---
The problem is that the variables are added to the offload_var_table but not
exported so that libgomp cannot find the symbol at load time. This causes a
fatal error in a mutex-locked section, which causes lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #6 from Andrew Stubbs ---
There's not observable difference. I don't quite follow what the patch is
trying to achieve, but seems like adding the variable to the offload variables
does not address the issue here.
I've added a hack to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #8 from Andrew Stubbs ---
On GCN I get the lto_priv names, but not the globalization. I think that shows
what the expected behaviour is, thanks ... I just need to find that magic.
That being so, I think I can confirm that your origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #14 from Andrew Stubbs ---
(In reply to Jakub Jelinek from comment #7)
> if I compile just the first TU without the foo () call in there, and
> .global .align 4 .u32 var$lto_priv$1[1] = { 5 };
> .global .align 4 .u32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82089
--- Comment #7 from Andrew Stubbs ---
Author: ams
Date: Thu Sep 27 11:15:48 2018
New Revision: 264666
URL: https://gcc.gnu.org/viewcvs?rev=264666&root=gcc&view=rev
Log:
[pr82089] Don't sign-extend SFV 1 in BImode
This is an update of the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82089
Andrew Stubbs changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438
Andrew Stubbs changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102
Andrew Stubbs changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491
--- Comment #15 from Andrew Stubbs ---
Yeah, I've not managed to come up with a better solution, so I think I'll just
revert the patch, for now. :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64032
--- Comment #7 from Andrew Stubbs ---
Author: ams
Date: Wed Mar 18 14:27:13 2015
New Revision: 221492
URL: https://gcc.gnu.org/viewcvs?rev=221492&root=gcc&view=rev
Log:
Fix PR64491
2015-03-18 Andrew Stubbs
PR middle-end/64491
Revert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491
--- Comment #16 from Andrew Stubbs ---
Author: ams
Date: Wed Mar 18 14:27:13 2015
New Revision: 221492
URL: https://gcc.gnu.org/viewcvs?rev=221492&root=gcc&view=rev
Log:
Fix PR64491
2015-03-18 Andrew Stubbs
PR middle-end/64491
Rever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491
Andrew Stubbs changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491
--- Comment #8 from Andrew Stubbs ---
Just silencing the warning may not be enough. The compiler may optimize away
loop exit conditions based on this analysis. The warning mirrors the logic
rather than shares it (due to the way the logic is distr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491
--- Comment #10 from Andrew Stubbs ---
I'm trying to look at this problem, but so far all my builds are failing.
Probably I have some local cruft.
In the meantime, the workaround is to use -Wno-aggressive-loop-optimizations, I
think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491
--- Comment #11 from Andrew Stubbs ---
The compiler has constructed the loop such that it reads like this:
f = 0;
tmp = 0;
do {
B[f] = tmp | A[f + 1];
if (f + 1 == 8)
break;
if (f + 1 > 0)
tmp = A[f];
if (f + 1 == 7) {
B[f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491
--- Comment #13 from Andrew Stubbs ---
I thought of that, but my testcase has 2 exits.
I thought of only warning when all the exits were being removed, but the
loop->bounds list does not include all the exits, so that can't happen either.
I tho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64032
--- Comment #2 from Andrew Stubbs ---
When I configure for powerpc-linux-gnu, undefined-loop-2.c.003t.original
contains this:
if (((p != 0 ? (unsigned char) array1[i] != 0 : (unsigned char) array2[i] !=
0) && i <= 4) && i <= 99) goto ; else go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64032
--- Comment #5 from Andrew Stubbs ---
Author: ams
Date: Wed Dec 24 14:27:06 2014
New Revision: 219059
URL: https://gcc.gnu.org/viewcvs?rev=219059&root=gcc&view=rev
Log:
Fix undefined-loop-2.c test case.
2014-12-24 Andrew Stubbs
PR tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64032
Andrew Stubbs changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48250
Summary: ICE in reload_cse_simplify_operands, at
postreload.c:403
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
Andrew Stubbs changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
--- Comment #4 from Andrew Stubbs 2011-04-27 11:08:10
UTC ---
Somewhat reduced testcase:
static void
f (unsigned int a)
{
unsigned long long __res;
if (~0ULL % (a / (a & -a)) == 0)
{
asm ("": "+&r" (__res));
}
}
int
g (unsign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721
Andrew Stubbs changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46888
Summary: missed optimization of zero_extract with constant
inputs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46888
--- Comment #1 from Andrew Stubbs 2010-12-10 17:02:05
UTC ---
Two different patches have been posted to fix this:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00778.html
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00784.html
One, or both sh
||ams at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |ams at gcc dot gnu.org
|gnu.org |
--- Comment #2 from Andrew Stubbs 2010-12-10 17:23:51
UTC ---
I've posted a patch to fix this issue (among others):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46092
--- Comment #3 from Andrew Stubbs 2010-12-10 17:27:04
UTC ---
Oh, I should say, what it actually does is this:
subhi r0, r0, #65280 ; 0xff00
subhi r0, r0, #241 ; 0x00f1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100208
--- Comment #1 from Andrew Stubbs ---
LLVM changed the default parameters, so we either have to change the
expectations in the ".amdgcn_target" string (which is basically an assert), or
set the attributes be want explicitly on the assembler comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84958
--- Comment #6 from Andrew Stubbs ---
(In reply to Tom de Vries from comment #5)
> I've removed the xfail for nvptx.
>
> The only remaining xfail is for gcn. Is that one still necessary?
The test still fails for gcn.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97521
--- Comment #21 from Andrew Stubbs ---
(In reply to Richard Biener from comment #19)
> GCN also uses MODE_INT for the mask mode and thus may be similarly affected.
> Andrew - are the bits in the mask dense? Thus for a V4SImode compare
> would th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97521
--- Comment #22 from Andrew Stubbs ---
(In reply to Andrew Stubbs from comment #21)
> (In reply to Richard Biener from comment #19)
> > GCN also uses MODE_INT for the mask mode and thus may be similarly affected.
> > Andrew - are the bits in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97332
Andrew Stubbs changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
--- Comment #4 from Andrew Stubbs ---
Alexandre's patch has this:
emit_move_insn (rem, plus_constant (ptr_mode, rem, -blksize));
Is that generally a valid thing to do? It seems like other places do similar
things...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
Andrew Stubbs changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
--- Comment #9 from Andrew Stubbs ---
I found a couple of other places to put force_operand and the full case works
now.
Running more tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
--- Comment #13 from Andrew Stubbs ---
I found a lot more ICEs when testing my patch. They look to be unrelated
(TImode come back to haunt us), but it makes it hard to be sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
Andrew Stubbs changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108898
--- Comment #1 from Andrew Stubbs ---
I tested it on i686-pc-linux-gnu before I posted the patch, and it was working
then. Can you be more specific what configuration you were testing, please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108898
--- Comment #4 from Andrew Stubbs ---
I did not know there was a way to do that! I'll add this to my to-do list.
1 - 100 of 183 matches
Mail list logo
