ret
.L19:
addsd %xmm1, %xmm0
ret
.LC1:
.long 0
.long 1072693248
Stefan
nt: https://godbolt.org/z/1ra7zcsnd
Replace
if (isnan(argx) || isnan(argy)) return argx + argy;
with
if ((argx != argx) || (argy != argy)) return argx + argy;
then feed the changed snippet to compiler explorer again, with and without
-ffast-math
Stefan
> --matt
>
> On Sat, Aug
Jakub Jelinek wrote:
> On Sat, Aug 21, 2021 at 09:40:16PM +0200, Stefan Kanthak wrote:
>> > I believe your example doesn't take into account that the values can be NaN
>> > which compares false in all situations.
>>
>> That's a misbelief!
>> P
Gabriel Ravier wrote:
> On 8/21/21 10:19 PM, Stefan Kanthak wrote:
>> Jakub Jelinek wrote:
[...]
>>> GCC doesn't do value range propagation of floating point values, not even
>>> the special ones like NaNs, infinities, +/- zeros etc., and without that the
&
Gabriel Ravier wrote:
> On 8/22/21 11:22 PM, Stefan Kanthak wrote:
[ 2bugzilla | !2bugzilla ]
>> You (and everybody else) if free to use GCC bugzilla.
>> Everybody and me is but also free NOT to use GCC bugzilla.
>>
>> Stefan
>
> Yes, you are free not
Gabriel Ravier wrote:
> On 8/23/21 3:46 PM, Stefan Kanthak wrote:
>> JFTR: do you consider your wild speculations to be on-topic here?
>
> I suppose I should apologize: I did not intend to make any accusations
> here.
No need to, I can stand a little heat.
[...]
> I
R incurs two cycles penalty on many Intel processors!
Better use XORPD there.
Stefan
pop esi
pop edi
pop ebp
ret
.L9:
mov ebx, edi # Ouch: GCC likes to play shell games!
mov ecx, esi #
mov edx, ebx #
mov eax, ecx #
pop ebx
pop esi
pop
re's no need to modify ECX!
cmovne rdx, rax
cmovne rax, rsi
ret
.L9:
mov rax, rsi
mov rdx, rdi
.L1:
ret
.L14:
mov r8, r9
xor r9d, r9d
mov rcx, r8
jmp .L4
20 superfluous instructio
sub eax, DWORD PTR [esp+4]
.endif
setoah
setzal
sub al, ah # al = ZF - OF
.if 0
cbw
cwde
.else
movsx eax, al
.endif
ret
Stefan Kanthak
ret
.end
JFTR: dependent on the magnitude of the numbers and the processor
it MIGHT be better to omit comparison and branch: there's a
trade-öff between the latency of the (un-pipelined) division
instruction and the latency of the conditional branch due to
misprediction.
Stefan Kanthak
LIU Hao wrote:
>在 2023/1/9 20:20, Stefan Kanthak 写道:
>> Hi,
>>
>> GCC (and other C compilers too) support the widening multiplication
>> of i386/AMD64 processors, but DON'T support their narrowing division:
>>
>>
>
> QWORD-DWORD division would c
"Paul Koning" wrote:
>> On Jan 9, 2023, at 7:20 AM, Stefan Kanthak wrote:
>>
>> Hi,
>>
>> GCC (and other C compilers too) support the widening multiplication
>> of i386/AMD64 processors, but DON'T support their narrowing division:
>
>
"Paul Koning" wrote:
>> On Jan 9, 2023, at 10:20 AM, Stefan Kanthak wrote:
>>
>> "Paul Koning" wrote:
>>
>>>> On Jan 9, 2023, at 7:20 AM, Stefan Kanthak wrote:
>>>>
>>>> Hi,
>>>>
>>>>
"Thomas Koenig" wrote:
> On 09.01.23 12:35, Stefan Kanthak wrote:
>> 20 superfluous instructions of the total 102 instructions!
>
> The proper place for bug reports is https://gcc.gnu.org/bugzilla/ .
OUCH: there's NO proper place for bugs at all!
> Feel fre
#ret
14 instructions in 33 bytes# 11 instructions in 32 bytes
OUCH: why does GCC abuse EBX (and ECX too) and performs a superfluous
memory write?
Stefan Kanthak
"Jonathan Wakely" wrote:
> On Fri, 26 May 2023, 08:01 Andrew Pinski via Gcc, wrote:
>
>> On Thu, May 25, 2023 at 11:56?PM Stefan Kanthak
>> wrote:
>>>
>>> Hi,
>>>
>>> compile the following function on a system with Core
"Jonathan Wakely" wrote:
> On Fri, 26 May 2023 at 09:00, Stefan Kanthak wrote:
>>
>> "Jonathan Wakely" wrote:
>>
>> > On Fri, 26 May 2023, 08:01 Andrew Pinski via Gcc, wrote:
>> >
>> >> On Thu, May 25, 2023 at 11:56?PM S
"Jakub Jelinek" wrote:
> On Fri, May 26, 2023 at 10:59:03AM +0200, Stefan Kanthak wrote:
>> 3) SSE4.1 is supported since Core2, but -march=core2 fails to enable it.
>>That's bad, REALITY CHECK, please!
>
> You're wrong.
> SSE4.1 first appe
"Jakub Jelinek" wrote:
> On Fri, May 26, 2023 at 10:59:03AM +0200, Stefan Kanthak wrote:
>> 3) SSE4.1 is supported since Core2, but -march=core2 fails to enable it.
>>That's bad, REALITY CHECK, please!
>
> You're wrong.
> SSE4.1 first appe
"Jonathan Wakely" wrote:
> On Fri, 26 May 2023 at 12:29, Stefan Kanthak wrote:
>>
>> "Jakub Jelinek" wrote:
>>
>> > On Fri, May 26, 2023 at 10:59:03AM +0200, Stefan Kanthak wrote:
>> >> 3) SSE4.1 is supported since Core2, but -marc
"Jonathan Wakely" wrote:
> On Fri, 26 May 2023 at 12:42, Stefan Kanthak wrote:
>> Why does the documentation FAIL to specify that CPU features given by
>> -m* override -m32 or enables them in ADDITION to those enabled by -march=?
>
> Because it's obvious. I
"Jonathan Wakely" wrote:
> On Fri, 26 May 2023 at 13:09, Stefan Kanthak wrote:
>>
>> "Jonathan Wakely" wrote:
>>
>> > On Fri, 26 May 2023 at 12:29, Stefan Kanthak
>> > wrote:
>> >> OUCH: as shown in https://godbolt.org/z
"Jonathan Wakely" wrote:
> On Fri, 26 May 2023 at 13:23, Stefan Kanthak wrote:
>>
>> "Jonathan Wakely" wrote:
>>
>> > On Fri, 26 May 2023 at 12:42, Stefan Kanthak wrote:
>> >> Why does the documentation FAIL to specify that CP
"Jakub Jelinek" wrote:
> On Fri, May 26, 2023 at 02:19:54PM +0200, Stefan Kanthak wrote:
>> > I find it very SURPRISING that you're only just learning the basics of
>> > how to use gcc NOW, after YELLING about all the OUCH.
>>
>> I'm NOT
"Jonathan Wakely" wrote:
> On Fri, 26 May 2023 at 14:55, Stefan Kanthak wrote:
[...]
>> NOT obvious is but that -m -march= does not clear any
>> not supported in , i.e the last one does NOT win here.
>
> The last -march option selects the base set of instructi
other words: although -march= selects a (documented sub)set of
-mISA options, it does NEITHER reset any -mISA option set NOR any
-mno-ISA option reset BEFORE or AFTER itself, i.e. all -m[no-]ISA
options have precedence even if they preceed -march=.
Just document that!
Stefan
"Jonathan Wakely" wrote:
> On Fri, 26 May 2023 at 15:48, Stefan Kanthak wrote:
>>
>> "Jakub Jelinek" wrote:
>>
>> [...]
>>
>> > And for -m32 it is also the last option that wins, but as with
>> > many other cases just
You wrote:
>在 2023-05-26 14:46, Stefan Kanthak 写道:
>> OOPS: why does GCC (ab)use the SSE2 alias "Willamette New Instruction Set"
>> (... ...)
>> OUCH: why does it FAIL to REALLY use SSE2, as shown in the comments on the
>>right side?
>
> Pleas
"Jonathan Wakely" wrote:
> On Fri, 26 May 2023 at 15:34, Stefan Kanthak wrote:
>>
>> "Jonathan Wakely" wrote:
>>
>> > On Fri, 26 May 2023 at 14:55, Stefan Kanthak
>> > wrote:
>>
>> [...]
>>
>> >> NOT obv
,
2 registers clobbered without need and reason, resulting in
2 superfluous memory writes
It's e REAL shame how bad GCC's code generator is!
Stefan
"Dave Blanchard" wrote:
> Hi Stefan, thanks for sharing this information.
> I was wondering if the code generators in earlier GCC
> versions were any better?
Just open one of the URLs I included, select another GCC version
and see the resulting code.
> Is this a proble
xmm0->ptest xmm1, xmm0
seteal->setzal
.L1:
ret ->ret
5 out of 14 instructions are superfluous here, or 18 of 50 bytes!
OUCH #3/#4: see above!
Will GCC eventually generate proper SSE4.1/AVX code?
Stefan
You wrote:
>在 2023-05-26 23:40, Stefan Kanthak 写道:
>> Feel free to propose this alternative here (better elsewhere, where you'll
>> earn less laughter).
>> But don't forget that this 23-bit mantissa will be all zeroes for quite some
>> 64-bit (and even 32-
zx eax, al# superfluous!
ret
Will GCC eventually generate properly optimised code instead of bloat?
Stefan
Ts
output?
See https://gcc.godbolt.org/z/jdjTc3EET for comparison!
FIX YOUR BUGS, KIDS!
Stefan
"Jakub Jelinek" wrote, completely clueless:
> On Sat, May 27, 2023 at 11:04:11PM +0200, Stefan Kanthak wrote:
>> OUCH: popcnt writes the WHOLE result register, there is ABSOLUTELY
>> no need to clear it beforehand nor to clear the higher 24 bits
>> aft
"Andrew Pinski" wrote:
> On Sat, May 27, 2023 at 2:38 PM Stefan Kanthak
> wrote:
>>
>> "Jakub Jelinek" wrote, completely clueless:
>>
>>> On Sat, May 27, 2023 at 11:04:11PM +0200, Stefan Kanthak wrote:
>>>> OUCH: popcnt writes
"Andrew Pinski" wrote:
> On Sat, May 27, 2023 at 2:25 PM Stefan Kanthak
> wrote:
>>
>> Just to show how SLOPPY, INCONSEQUENTIAL and INCOMPETENT GCC's developers
>> are:
>>
>> --- dontcare.c ---
>> int ispowerof2(unsigned __int12
"Andrew Pinski" wrote:
> On Sat, May 27, 2023 at 3:54 PM Stefan Kanthak
> wrote:
[...]
>> Nevertheless GCC fails to optimise code properly:
>>
>> --- .c ---
>> int ispowerof2(unsigned long long argument) {
>> return __builtin_popcountll(argu
"Andrew Pinski" wrote:
> On Sat, May 27, 2023 at 3:54 PM Stefan Kanthak
> wrote:
>> Nevertheless GCC fails to optimise code properly:
>>
>> --- .c ---
>> int ispowerof2(unsigned long long argument) {
>> return __builtin_popcountll(argument) =
instead
of code fiddling with the stack!
Stefan Kanthak
NNER;
// calc result
result=0;
for (int i = 0; i < OUTER; ++i)
for (int j = 1; j < INNER; ++j)
result += d[j]*d[j-1] + d[j-1];
}
else
exit(-1);
printf("result = %f\n",result);
return 0;
}
--- end testcase --
--
Stefan Strasser
edx
cmpl $1000, %eax
mulsd %xmm0, %xmm1
addsd %xmm1, %xmm0
addsd %xmm0, %xmm2
jne .L124
--
Stefan Strasser
(gc pages are released).
Thanks,
--
Stefan Strasser
not used at all(at least when compiling c++).
would it help to do leak checking on libiberty alloc functions or is
than done regularily anyway?
--
Stefan Strasser
> up a larger related question I've been meaning to open for a while: Are the
> FSF's goals best served by continuing to technically restrict GCC?
Let me repeat: please stop discussing such things on this list.
There are things like gnu.misc.discuss for that.
Stefan
At the company where I work, we have a large program using Boost
Python (1.54). We do our product builds for RHEL 5 and recently
started building using gcc 4.8 from RedHat devtoolset 2 for
performance. This works well, except for one system where it would
deterministically crash. I traced it to an
> I don't remember it well, but from re-reading the gcc-patches threads around
> that time like:
> http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00368.html
That thread is from 2009.
> it seems that the actually committed fix for the bug that the
> gcc41-unwind-restore-state.patch was meant to fix
>> http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00368.html
>
> That thread is from 2009.
>
>> it seems that the actually committed fix for the bug that the
>> gcc41-unwind-restore-state.patch was meant to fix was
>> http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00617.html committed as
>> http://gcc.
etermine
the correlations between loop features and best unroll factor
- integrate the result into gcc and measure the benchmarks again
Do you think it is ok to only consider inner-most loops? What about
the unroll factors? Should I consider bigger unroll factors? Do you
think the above setup is ok?
I welcome any feedback on this.
Thank you,
Stefan Ciobaca
etermine
the correlations between loop features and best unroll factor
- integrate the result into gcc and measure the benchmarks again
Do you think it is ok to only consider inner-most loops? What about
the unroll factors? Should I consider bigger unroll factors? Do you
think the above setup is ok?
I welcome any feedback on this.
Thank you,
Stefan Ciobaca
re are the questions
- how can I actually insert the code (I need to do this during the
loop-unrolling phase, when the code is already in RTL form)?
- what performance measurement should I try?
- what other related work is out there?
Thanks,
Stefan Ciobaca
On 6/8/07, Stefan Ciobaca <[EMAIL PR
leave
0x08048457 : leaesp,[ecx-0x4]
0x0804845a : ret
Only three times the constructor is called but four times the destructor
and a magic call to "0x8048480 <_ZN1AplERKS_>".
Can someone explain these results?
Best regards
Stefan
ays the same. But the object has
to be cv-unqualified and/or unnamed.
Thanks for your hint!
Best regards
Stefan
he size, I guess it might matter if you want to port your code
to AIX, Solaris, OpenBSD etc. I don't think all software is meant to
be portable, though (or portable to those platforms). Maybe a warning
is in order that, for portable code, developers should check its size
on the other platforms t
Hi Alex,
On Fri, Jan 20, 2023 at 2:40 PM Alejandro Colomar
wrote:
>
> Hi Stefan,
>
> On 1/20/23 11:06, Stefan Puiu wrote:
> > Hi Alex,
> >
> > On Thu, Jan 19, 2023 at 4:14 PM Alejandro Colomar
> > wrote:
> >>
> >> Hi!
> >>
> &g
such loops? Any comments?
Cheers,
Stefan
On Mon, Oct 26, 2020 at 01:46:52PM +0100, Richard Biener wrote:
> On Mon, Oct 26, 2020 at 10:59 AM Stefan Schulze Frielinghaus via Gcc
> wrote:
> >
> > I'm trying to detect loops of the form
> >
> > while (*x != y)
> > ++x;
> >
> > which
On Thu, Jul 28, 2022 at 08:53:37PM +0100, Jonathan Wakely via Gcc wrote:
> On Thu, 28 Jul 2022 at 20:49, Tim Lange wrote:
> >
> >
> >
> > On Thu, Jul 28 2022 at 02:46:58 PM -0400, David Malcolm via Gcc
> > wrote:
> > > Is there documentation on setting up text editors to work with our
> > > coding
On Mon, Aug 01, 2022 at 12:25:21PM +0100, Jonathan Wakely wrote:
> On Mon, 1 Aug 2022 at 09:24, Stefan Schulze Frielinghaus wrote:
> > I gave unexpand from GNU coreutils 8.32 a try. Looks like it cannot
> > deal with form feeds or maybe I'm missing something?
> >
> &
ually didn't expect that because I added -save-temps to all the
intermediate commands which is also reflected in the environment
variable COLLECT_GCC_OPTIONS. Thus, how do you keep temporary files?
Cheers,
Stefan
On Thu, Nov 24, 2022 at 05:53:53PM +0100, Richard Biener wrote:
>
>
> > Am 24.11.2022 um 17:28 schrieb Stefan Schulze Frielinghaus via Gcc
> > :
> >
> > Hi everyone,
> >
> > Currently I'm looking into a wrong-code bug and would like to unders
appear if I'm using e.g.
Fedora 34. Is this known and if so does there exist a workaround such
that building older versions on a recent OS works?
Cheers,
Stefan
probably better solved by having some
sort of masking support by the hardware but I'm still keen to know.
Cheers,
Stefan
On Tue, Jun 04, 2024 at 09:50:04AM +0200, Richard Biener wrote:
> On Tue, Jun 4, 2024 at 8:52 AM Stefan Schulze Frielinghaus via Gcc
> wrote:
> >
> > Hi all,
> >
> > Is there some sort of guarantee that the unused part of a partial vector has
> > all bits set t
ing alternatives be
set automagically. Not sure whether this is supported?
If all fails, I have another idea how to solve this by utilizing PRINT_OPERAND.
However, now I'm curious whether my current attempt is feasible or not.
Cheers,
Stefan
On Fri, Jun 21, 2024 at 09:50:43PM +0200, Georg-Johann Lay wrote:
>
>
> Am 17.06.24 um 21:13 schrieb Stefan Schulze Frielinghaus via Gcc:
> > Hi all,
> >
> > I'm trying to add an alternative to an existing insn foobar:
> >
> > (defi
On Sat, Jun 22, 2024 at 01:00:54PM +0200, Georg-Johann Lay wrote:
> Am 22.06.24 um 10:46 schrieb Stefan Schulze Frielinghaus:
> > On Fri, Jun 21, 2024 at 09:50:43PM +0200, Georg-Johann Lay wrote:
> > >
> > >
> > > Am 17.06.24 um 21:13 schrieb Stefan Schulze
I just ran into an unresolved iterator
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657360.html
which motivated me to dig into genoutput.cc where in process_template()
we already emit an error but only if the new compact syntax is used.
There is probably a reason for limiting the check to th
out if gen_lowpart
doesn't return a subreg since then most likely `expr` was a paradoxical subreg.
At least in this example this leads to a partial initialization of pseudo 61 in
insn 6. This is fixed up later by pass init-regs which is introducing insn 17
and zeroing the entire pseudo 61.
On Thu, Aug 08, 2024 at 06:03:13AM -0600, Jeff Law wrote:
>
>
> On 8/8/24 5:15 AM, Stefan Schulze Frielinghaus via Gcc wrote:
>
> >
> > However `(reg:DI 61 [ MEM[(const union T *)p_2(D)] ])` referencing the
> > same pseudo in a different mode is not substituted in
On Thu, Aug 08, 2024 at 07:57:43AM -0600, Jeff Law wrote:
>
>
> On 8/8/24 6:26 AM, Stefan Schulze Frielinghaus wrote:
> > On Thu, Aug 08, 2024 at 06:03:13AM -0600, Jeff Law wrote:
> > >
> > >
> > > On 8/8/24 5:15 AM, Stefan Schulze Frielinghaus via
ional
work---although the name is bit of a mouthful.
> If you want to throw a patch over the wall for testing, happy to put it into
> my tester and see what comes out the other side. I wouldn't be at all
> surprised if it tripped on other targets.
H
On Fri, Aug 09, 2024 at 09:49:03AM +0200, Stefan Schulze Frielinghaus wrote:
> On Thu, Aug 08, 2024 at 01:56:48PM -0600, Jeff Law wrote:
> > > I haven't tested it extensively but it triggers at least for the current
> > > case.
> > > I would have loved to also
(operands[1];
emit_insn (gen_rtx_SET (operands[2], gen_rtx_ASHIFT (DImode, operands[2],
GEN_INT (48;
emit_insn (gen_rtx_SET (gen_rtx_REG (DFmode, REGNO (operands[0])),
gen_rtx_REG (DFmode, REGNO (operands[2];
DONE;
})
That restores bootstrap. However, this feels a bit hacky and I'm wondering
whether first of all the initial implementation is wrong at all, or whether
there exists a more elegant solution? Any thoughts?
Cheers,
Stefan
automatically into some (build) directory which
dejagnu then sources? Any pointers are highly appreciated.
Cheers,
Stefan
On Mon, Jan 13, 2025 at 07:18:05AM -0700, Jeff Law via Gcc wrote:
>
>
> On 1/13/25 2:56 AM, Stefan Schulze Frielinghaus via Gcc wrote:
> > Hi everyone,
> >
> > In order to better test our s390 builtins, I have been coming up with a
> > small tool in order to a
blem by tying
all modes with size less than or equal to 8 bytes as long as we have
proper mov insns?
Cheers,
Stefan
about. Before I spend more time on that: is this kind of
testing actually supported? Any hint is highly appreciated.
Cheers,
Stefan
lue is stored in rax, too, the register is
clobbered before it is used in the Extended asm.
This behaviour is also documented in
https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html
Cheers,
Stefan
>
> Take this example on AVR:
>
> char func (char x) // incoming r24
> {
>
already
instruct IRA about preferred registers. Since everything could be fixed
up by LRA, I didn't want to prematurely implement something in IRA which
does not lead to better code and I never went on with that. My gut
feeling is that we see this especially on AVR since there values are
held
101 - 182 of 182 matches
Mail list logo
