https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830
--- Comment #10 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #8)
> In particular, it is combine_simplify_rtx that is called on:
> (zero_extend:SI (subreg:QI (ior:TI (and:TI (reg/v:TI 103 [ f ])
> (const_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830
--- Comment #7 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> In the end on the actual instruction the clobber is optimized away
That is a very serious bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830
--- Comment #5 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #3)
> In normal insns such clobbers would be rejected by recog, but for
> DEBUG_INSNs we don't have strict validity tests, but guess we need to throw
> away at lea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99930
--- Comment #10 from Segher Boessenkool ---
That is a USE of a constant, which is a no-op always. Here we have a USE
of a register, which is not. We actually have *two* uses of pseudos, and
combine cannot know what that means for the target (al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #10 from Segher Boessenkool ---
You cannot fix a simplify-rtx problem in much earlier passes! It may be
useful of course (I have no idea, I don't know gimple well enough), but
it is no solution to the problem at all. The xor/and/xor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927
--- Comment #14 from Segher Boessenkool ---
distribute_notes says
Any clobbers from i2 or i1 can only exist if they were added by
recog_for_combine.
which is not true apparently. But all of this code *does* depend
on that, it just doesn't ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927
--- Comment #13 from Segher Boessenkool ---
Yes, combine just drops that clobber of flags, that was a thinko :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927
--- Comment #11 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #7)
> Ah, create_log_links wants to work like that.
> So, the bug seems to be that insn 108 has REG_DEAD (reg:CC 17 flags) note.
> It doesn't initially, but it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99930
--- Comment #8 from Segher Boessenkool ---
That patch is no good. The combination is not allowed because it is not
known what the "use"s are *for*. Checking if something is from the constant
pools is not enough at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927
--- Comment #9 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #5)
> But what is wrong is that try_combine has been called at all, because
> (reg:CCZ 17 flags) is used in 3 instructions rather than just one.
That is not a pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99930
--- Comment #3 from Segher Boessenkool ---
What happens here is
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/combine.c;h=3294575357bfcb19e589868da34364498a860dcf;hb=HEAD#l1884
"*2_1" for absneg:MODEF has a bare "use". And then we trigger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #18 from Segher Boessenkool ---
(In reply to luoxhu from comment #12)
> Not sure whether TARGET_DIRECT_MOVE_64BIT is the right MACRO to correctly
> differentiate m32 and m64?
It is not. It looks at TARGET_POWERPC64 only, and that ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #17 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #10)
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567215.html
Ah, that is more recent than anything I have replied to :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #7 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> I did not know whether it is implementable (in VSX or in Altivec) for 32-bit
> targets etc., all I was suggesting was what to do if it is not implementable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #6 from Segher Boessenkool ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Segher Boessenkool from comment #3)
> > In an ideal world the user can just assume those types exist always.
> Arguably a __SIZEOF_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #5 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #3)
> If the non-constant vec_set can't be supported when
> !(TARGET_P8_VECTOR && TARGET_DIRECT_MOVE_64BIT)
I don't see why not? It may need different code, sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #10 from Segher Boessenkool ---
GCC 11 stage 4 will be fine.
I doubt you can ever measure a difference, but you can try :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #3 from Segher Boessenkool ---
The only such __SIZEOF_* macro that is not about a standards-required type
is for int128. Not the best example ;-)
There are not predefines for __SIZEOF_FLOAT128__ etc. either.
In an ideal world the u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #1 from Segher Boessenkool ---
Yes, the __SIZEOF_* macros do not say whether some type can be used. This is
true for all targets!
What would it be useful for to define these macros? They all are equivalent to
#define SIXTEEN 16
:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97926
Segher Boessenkool changed:
What|Removed |Added
Component|target |testsuite
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #14 from Segher Boessenkool ---
Well, V=m-o (not the same thing, these are sets) -- but, it is clear that "o"
should be a subset of "m":
(define_memory_constraint "TARGET_MEM_CONSTRAINT"
"Matches any valid memory."
(define_memory_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97926
--- Comment #5 from Segher Boessenkool ---
It helps if you test the compiler you just built, not something old. Sigh.
Patch is testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97926
Segher Boessenkool changed:
What|Removed |Added
Assignee|acsawdey at gcc dot gnu.org|segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092
Segher Boessenkool changed:
What|Removed |Added
Attachment #50040|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #7 from Segher Boessenkool ---
>From the offending patch:
-/* Return true if the eliminated form of AD is a legitimate target address.
*/
+/* Return true if the eliminated form of AD is a legitimate target address.
+ If OP is a ME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99496
--- Comment #13 from Segher Boessenkool ---
Hi Nathan,
I think you didn't push the branch that is on?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #5 from Segher Boessenkool ---
Thanks Vladimir. It is indeed a problem in LRA (or triggered by it).
We have
8: {[r121:DI+low(unspec[`*.LANCHOR0',%2:DI]
47+0x92a4)]=asm_operands;clobber
so this is an offset that is too big for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99352
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #20 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #14)
> We should definitely not be allowing the AltiVec "& ~16" flavors into these
> patterns. I'm not certain whether your fix is the best way to achieve that,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99496
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99352
--- Comment #3 from Segher Boessenkool ---
rs6000 has check_effective_target_powerpc_fprs already (with slightly
different semantics).
||powerpc*-*-*
Last reconfirmed||2021-03-02
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Segher Boessenkool ---
Mine.
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
It just just says
[istarget powerpc*-*-*]
but it should test whether the preprocessor symbol "_ARCH_PPCSQ" is defined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #9 from Segher Boessenkool ---
The i386 port has
===
(define_insn "trap"
[(trap_if (const_int 1) (const_int 6))]
""
{
#ifdef HAVE_AS_IX86_UD2
return "ud2";
#else
return ASM_SHORT "0x0b0f";
#endif
}
[(set_attr "length" "2")]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #7 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #5)
> For the naming I suggest __builtin_debugtrap() to align with clang. Maybe
> with an aliased __debugbreak() on Windows platforms.
Those are terrible names. Thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #6 from Segher Boessenkool ---
(In reply to Richard Biener from comment #4)
> I'm not sure what your proposed not noreturn trap() would do in terms of
> IL semantics compared to a not specially annotated general call?
Nothing I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #3 from Segher Boessenkool ---
Ah, thank you. Well except there is no keyword called that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93353
--- Comment #9 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #7)
> if (low_int >= 0x8000 - extra)
> is not true and 0x7fff - -1 is 0x8000 (with UB on the compiler side).
These are HWIs, so there is no UB.
> B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93353
--- Comment #8 from Segher Boessenkool ---
(In reply to Arseny Solokha from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > I cannot get the reduced testcase to fail. Are any special options needed?
>
> If you've been asking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99293
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93353
--- Comment #4 from Segher Boessenkool ---
I cannot get the reduced testcase to fail. Are any special options needed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98181
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #26 from Segher Boessenkool ---
Can you show the code you tried in comment 23? It is near impossible to see
what happened there without that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
--- Comment #8 from Segher Boessenkool ---
Using update form instructions constrains register allocation and scheduling.
It is *not* always a good idea.
That is one of the reasons why we currently use update form instructions only
when insns jus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
--- Comment #6 from Segher Boessenkool ---
(In reply to Brian Grayson from comment #4)
> (In reply to Segher Boessenkool from comment #3)
> > Then you get
> >
> > addi 9,9,-2
> > lhau 10,2(9)
> > addi 9,9,2
> >
> > which is worse than just
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98468
--- Comment #3 from Segher Boessenkool ---
git tag -l 'releases*' --contains 8d2d39587d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99048
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99048
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
|--- |INVALID
CC||segher at gcc dot gnu.org
--- Comment #1 from Segher Boessenkool ---
Because it would be incorrect? lhau is pre-modify (like all update
form instructions).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
--- Comment #7 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #6)
> The mma_assemble_pair/mma_assemble_acc patterns both generate lxv or lxvp
> at, which both use a DQ offset and we already have function to
> test for that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
--- Comment #6 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #4)
> So this is where the "autogenerated" part comes in. We should have
> an idea what might be useful and what isn't even worth trying by
> looking at the m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
--- Comment #5 from Segher Boessenkool ---
(In reply to rsand...@gcc.gnu.org from comment #3)
> FWIW, another similar thing I've wanted in the past is to try
> recognising multiple possible constants in an (and X (const_int N))
> when X is known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #24 from Segher Boessenkool ---
I do see the problems for savegpr/restgpr with that suggestion, but maybe
something
in that vein can be done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #23 from Segher Boessenkool ---
savegpr/restgpr are special ABI-defined functions that do not have all the same
ABI
calling conventions as normal functions. They indeed write into the parent's
frame
(red zone, in this case).
Maybe y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #16 from Segher Boessenkool ---
(In reply to Mark Wielaard from comment #13)
> ==25741== Use of uninitialised value of size 8
> ==25741==at 0x1504: main (pr9862.C:16)
r4 is argv here
>0x14f0 <+16>: ld r3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #15 from Segher Boessenkool ---
(In reply to Will Schmidt from comment #14)
> The _restgpr* and _savegpr* functions are not referenced when the test is
> built at other optimization levels. (I've looked at disassembly from -O0 ..
> -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
--- Comment #5 from Segher Boessenkool ---
(As Jakub said; I'm just slow).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
--- Comment #4 from Segher Boessenkool ---
combine always asks recog(), so that must have said it is okay?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
--- Comment #2 from Segher Boessenkool ---
I agree it makes sense to have the one arm with vec_duplicate first in the
canonical order. Problem is that this is deep in the arms, but it can be
done of course.
Autogenerating part of combine? Nono
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98952
--- Comment #2 from Segher Boessenkool ---
And after that it always copies r4 bytes, too (rounded down to a multiple
of four bytes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #22 from Segher Boessenkool ---
Don't replace the constraints. For one thing, this is very hard to do
correctly. Just make the "m" constraint not allow prefixed memory in
asms, like I said above. (So all "general_operand" even!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98093
--- Comment #6 from Segher Boessenkool ---
(In reply to Martin Liška from comment #5)
> It's fixed on master, can we close it now or do we need a backport to active
> branches?
If someone filled in the known-to-work / known-to-fail fields we wou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
--- Comment #11 from Segher Boessenkool ---
Please open a separate bug for x86 problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960
--- Comment #26 from Segher Boessenkool ---
(In reply to Richard Biener from comment #23)
> (that combine number prevails on trunk as well, I can't spot any code
> that disables combine on large BBs so not sure what goes on here)
There is no suc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #8 from Segher Boessenkool ---
I say nothing like that. I say that
.text.hot.
is nasty (is easily mistaken for .text.hot).
I also say that and that named-per-function sections are better as
.text%name
than as
.text.name
(just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #6 from Segher Boessenkool ---
I was under the impression this unique section thing needed the trailing
dot thing. This probably is not true.
I still think the old "%" thing is much superior to the trailing dot thing,
but that then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092
--- Comment #3 from Segher Boessenkool ---
Created attachment 50040
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50040&action=edit
Patch
Patch in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #19 from Segher Boessenkool ---
We cannot allow "m" to allow pcrel memory accesses, because most
existing inline assembler code will break then. So we then need
some way to tell the compiler that some instruction *does* allow
pcrel m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Segher Boessenkool changed:
What|Removed |Added
Attachment #49996|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #18 from Segher Boessenkool ---
Created attachment 49996
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49996&action=edit
Patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #17 from Segher Boessenkool ---
(In reply to jos...@codesourcery.com from comment #15)
> Only if the undefined behavior is a property of the program, or of all
> possible executions of the program, as opposed to a property of a
> pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #16 from Segher Boessenkool ---
Needs -mcpu=power8. Confirmed with that (and the given options).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #14 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #13)
> For UB at runtime, we can warn, but shouldn't error because the code might
> never be invoked at runtime.
As far as I can see at least the C standard disa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #12 from Segher Boessenkool ---
for (long i; i != compress_n_blocks; ++i)
"i" is uninitialized; accessing it is UB. So this is ice-on-invalid.
I have no doubt there is an actual bug somewhere here. We just do not
have valid code y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #2 from Segher Boessenkool ---
Can't we use ".text%name" for -ffunction-sections, like we did originally,
in 1996? See cf4403481dd6. This does not conflict with other section
names, and does not have all the problems you get from do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #10 from Segher Boessenkool ---
(And that new test case is full of obvious invalid code as well, fwiw.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #9 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> The warning often warns on dead code.
> But even if the warning is right, that doesn't make it ice-on-invalid-code.
> The code may have UB at runtime, but th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
Segher Boessenkool changed:
What|Removed |Added
CC||acsawdey at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #4 from Segher Boessenkool ---
Are you sure that target is correct?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #5 from Segher Boessenkool ---
The "warninb" says
warning: ‘void* memcpy(void*, const void*, long unsigned int)’ writing 32
bytes into a region of size 8 overflows the destination [-Wstringop-overflow=]
It says it is wrong, so it i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Segher Boessenkool changed:
What|Removed |Added
Priority|P1 |P4
--- Comment #3 from Segher Boess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #17 from Segher Boessenkool ---
(What i was referring to in Comment 4 was asm_operand_ok in recog.c --
it may need some surgery if we need to hook into that).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #16 from Segher Boessenkool ---
No, this cannot be fixed in this hook, or in any other hook. The compiler
can never see *at all* what instructions there are, the template is just a
piece of text to it (there could be assembler macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98643
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-01-13
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98645
--- Comment #1 from Segher Boessenkool ---
(In reply to Michael Meissner from comment #0)
> I am tuning up the final patches for providing support to enable the PowerPC
> server compilers to change the default long double from using the IBM
> 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #11 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #10)
> But it seems we would also need a new constraint that does permit
> PC-relative addresses, since new code will/may not have a TOC.
How could that work? Yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #8 from Segher Boessenkool ---
Yes, "m" can not allow PC-relative, in inline asm (just think of all existing
code that uses "m").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #6 from Segher Boessenkool ---
You cannot look at the instruction, ever. The inline asm template is
just text, nothing else. You cannot assume it is valid instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #4 from Segher Boessenkool ---
"m" is already handled differently for inline asm, so perhaps we can just
extend that? ("m" in machine descriptions is "m<>" in asm, for example).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
--- Comment #6 from Segher Boessenkool ---
(In reply to Fangrui Song from comment #5)
> Please read my first comment why copy relocs is a bad name.
Since I reply to some of that (namely, your argument 1)), you could assume I
have read your comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #20 from Segher Boessenkool ---
Yes, that is clear... But we have ***double*** x in that example even,
as the declared type of the parameter, so converting that to float is
almost certainly a bad idea?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #18 from Segher Boessenkool ---
Why is it correct to convert the double x to single precision here?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98020
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
701 - 800 of 3178 matches
Mail list logo
