On 11/25/20 1:22 PM, Stefan Kanthak wrote:
> Jeff Law <l...@redhat.com> wrote:
>
>> On 11/24/20 8:40 AM, Stefan Kanthak wrote:
>>> Andreas Schwab wrote:
>>>
>>>> On Nov 24 2020, Stefan Kanthak wrote:
>>>>
>>>>> 'nuff said
>>>> What's your point?
>>> Pinpoint deficiencies and bugs in GCC and libgcc, plus a counter
>>> example to your "argument"!
>>> I recommend careful reading.
>> Umm, you should broaden your horizons.
> My horizon is as wide as the cap^Winability of GCC available for the
> machines I use.
Then you should expect that some of your patches are going to simply be
inappropriate for GCC. When people with 20-30 years of experience with
GCC tell you what you're doing is wrong in the context of GCC, it would
be wise to listen. Continuing to argue doesn't change the fact that
what you're trying to do is fundamentally wrong.
>
>> The world is not an x86.
> The GCC available for the machines I use is only able to generate x86
> code.
You can certainly take GCC sources and use them to create cross
compilers for any architecture supported by GCC. People do it all the time.
>
>> I'm pretty sure Andreas was referring to non-x86 targets.
> | On most 32-bit targets with -Os.
>
> Are avr or cr16 32-bit processors?
I don't know offhand. And ultimately it doesn't matter, the shift
changes are simply wrong and will not be applied.
>
>> As Jakub has already indicated, your change will result in infinite
>> recursion on avr. I happened to have a cr16 handy and it looks like
>> it'd generate infinite recursion there too.
> JFTR: does GCC emit a warning then? If not: why not?
GCC doesn't try to warn for self-recursion.
>
> Since I neither have an avr nor a cr16 here, and also no TR-440, no S/3x0,
> no Spectra-70, no PDP-11, no VAX, no SPARC, no MIPS, no PowerPC, no MC68k,
> no NSC16xxx and no NSC32xxx any more, GCC only gives me access to the x86
> code it generates.
Read about building cross compilers. I don't have any of those things
either. But I'm still able to build and test them without anything
other than a generic x86_64 laptop.
Hell, I can *bootstrap* on things like m68k, mips, hppa, riscv, alpha,
and others using qemu emulation on a generic x86_64 laptop.
>
>> On other targets the routines you're changing won't be used because they
>> either have 64 bit shifts or the compiler can synthesize them from other
>> primitives that are available.
> These routines are documented in
> <https://gcc.gnu.org/onlinedocs/gccint/Integer-library-routines.html>
> and might be called by your users.
THose routines are not for direct use by users.  I've already stated
that. In fact, you're referring to the "gcc internals" manual which is
for developers working on GCC itself, not for end users. There's
separate documentation for end users and I'd fully expect it not to
document any of the routines in libgcc, because they're not for end users.
Also note the first sentence on the page you've referenced:
"The integer arithmetic routines are used on platforms that don’t
provide hardware support for arithmetic operations on some modes."
Which again is what Jakub, myself and others have been telling you. You
can't (for example) use a 64bit shift in any of the 64bit shift routines
in libgcc2. It's fundamentally wrong.
>> It's pointless to keep arguing on the shift stuff. What you've
>> submitted is fundamentally wrong in the context of gcc's libgcc2
>> routines. It's that simple. If you keep arguing about it you're likely
>> just going to annoy those who can help you to the point where they won't
>> bother.
> Is there any documentation for (the design and restrictions of) libgcc2?
Not that I'm immediately aware of.
> The patches I sent for the shift and the comparision routines are based
> on the assumption that GCC generates code for "double-word" arithmetic
> inline.
And that's a fundamentally incorrect assumption as myself and others
have pointed out.
Jeff
