> From the documentation
> (https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html):
>
> %{S*}
>
> Substitutes all the switches specified to GCC whose names start
> with -S, but which also take an argument. This is used for switches like
> -o, -D, -I, etc. GCC considers -o foo as being one swit
ood also:
arm-rtems6-gcc -specs=test.spec -wrapper echo main.c -mfoo=bar+blub
-march=armv7-a+simd
... BEGIN -mfoo=bar+blub -marm -mlibarch=armv7-a -march=armv7-a END ...
arm-rtems6-gcc -specs=test.spec -wrapper echo main.c -mfoo=bar+blub
-march=armv7-a+simd -mfloat-abi=hard
... BEGIN -mfoo=ba
> Here, the "-march=armv7-a+simd" was moved after the "-gnatez". So this
> option is dropped in switch-c.adb and doesn't get added to the ALI file.
This comes from the spec magic implemented in ada/gcc-interface/lang-specs.h
and it looks like the '+' character is not matched by '*' or some such.
On 25.06.24 14:53, Sebastian Huber wrote:
On 24.06.24 16:06, Sebastian Huber wrote:
On 28.04.22 10:16, Sebastian Huber wrote:
Hello,
I test currently the Ada support for RTEMS in GCC 12. We have a
-mthumb -march=armv7-a+simd -mfloat-abi=hard multilib for which the
Ada RTS is built like this
On 24.06.24 16:06, Sebastian Huber wrote:
On 28.04.22 10:16, Sebastian Huber wrote:
Hello,
I test currently the Ada support for RTEMS in GCC 12. We have a
-mthumb -march=armv7-a+simd -mfloat-abi=hard multilib for which the
Ada RTS is built like this:
make[4]: Entering directory
'/tmp
On 28.04.22 10:16, Sebastian Huber wrote:
Hello,
I test currently the Ada support for RTEMS in GCC 12. We have a -mthumb
-march=armv7-a+simd -mfloat-abi=hard multilib for which the Ada RTS is
built like this:
make[4]: Entering directory
'/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/thumb/ar
Hello.
This is a draft FDPIC ABI specification for the Xtensa architecture.
Please send comments. I will be implementing the final ABI version in
gcc and binutils.
The Xtensa FDPIC ABI
April 8, 2024
Version 1
On Wed, Oct 11, 2023 at 10:59:10AM +0200, Florian Weimer wrote:
> * Andrew Carlotti via Gcc:
>
> > I've also seen the GCC documentation for the ifunc attribute [1].
> > This states that "the indirect function needs to be defined in the
> > same translation unit as the resolver function". This is
* Andrew Carlotti via Gcc:
> I've also seen the GCC documentation for the ifunc attribute [1].
> This states that "the indirect function needs to be defined in the
> same translation unit as the resolver function". This is not how
> function multiversioning is currently implemented. Instead, the
mplementations, and the symbol that
is resolved at run time used the original function symbol name. This would
allow the mangling of the function versions and the resolver function to be a
hidden implementation detail, with no need to specify it as part of an explicit
or implicit ABI. It would a
Can we debate in this mailing list? thanks
On 7/9/23 22:04, Paul Koning wrote:
Because implementing an ABI, or dealing with an incompatibnle change, is hard
work.
you could just use one ABI..(that's what you have)..you can use other
, only at a cost of specifying an ABI version
Because implementing an ABI, or dealing with an incompatibnle change, is hard
work. Also, ABI stability means that old binaries work. So ABI stability
isn't so much a requirement for the compiler as it is a requirement for any
sane operating system. An OS that changes ABI witho
If we can select the ABi for our program (using gcc), why is there a
need for ABI stability?!
why not put it on a define
#define abi v3
int main() {
}
Each user would just have to compile the code, to follow the abi...no
need to worry changing it
thanks
andre
On 07/07/2023 00:27, André Albergaria Coelho via Gcc wrote:
What if the user chooses in own ABI, say specifying a config file like
My abi
" Parameters = pushed in stack"
say
gcc -abi "My abi" some.c -o some
what would be the problems of specifying an ABI?? would that i
What if the user chooses in own ABI, say specifying a config file like
My abi
" Parameters = pushed in stack"
say
gcc -abi "My abi" some.c -o some
what would be the problems of specifying an ABI?? would that improve the
usage of user? less complex / more
simpler f
On Thu, 6 Jul 2023, 22:20 André Albergaria Coelho via Gcc,
wrote:
> Could gcc have an option to specify ABI?
>
> say
>
>
> gcc something.c -g -abi 1 -o something
>
Sure, it could do, but what would it do? What would "-abi 1" mean? Which
ABI would it relate to
It does, for machine architectures that have multiple ABIs. MIPS is an example
where GCC has supported this for at least 20 years.
paul
> On Jul 6, 2023, at 5:19 PM, André Albergaria Coelho via Gcc
> wrote:
>
> Could gcc have an option to specify ABI?
>
&g
Could gcc have an option to specify ABI?
say
gcc something.c -g -abi 1 -o something
thanks
andre
Last time aarch64 libmvec was discussed, the OpenMP
declare variant syntax support was not ready in gcc
and there were open questions around how simd isa
variants would be supported.
https://gcc.gnu.org/pipermail/gcc-patches/2019-October/532940.html
The vector function ABI for aarch64 allows the
On 28/04/2022 09:16, Sebastian Huber wrote:
/opt/rtems/7/lib/gcc/arm-rtems7/12.0.1/thumb/armv7-a+simd/hard/adainclude/s-secsta.ads:288:9:
sorry, unimplemented: Thumb-1 'hard-float' VFP ABI
Does that source file somehow attempt to change the architecture on that
line? This
On Thu, Apr 28, 2022, 3:17 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello,
>
> I test currently the Ada support for RTEMS in GCC 12. We have a -mthumb
> -march=armv7-a+simd -mfloat-abi=hard multilib for which the Ada RTS is
> built like this:
Hello,
I test currently the Ada support for RTEMS in GCC 12. We have a -mthumb
-march=armv7-a+simd -mfloat-abi=hard multilib for which the Ada RTS is
built like this:
make[4]: Entering directory
'/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/thumb/armv7-a+simd/hard/libada
t a marker to note that it was found. If, at the
end of walking the type, it's still a candidate for passing in FP regs,
then we've identified an ABI change because previously we would not have
behaved this way.
R.
On Fri, Mar 25, 2022 at 02:26:56PM +, Richard Earnshaw wrote:
> Just to confirm that this is our final position. The 'int:0 field should be
> ignored for the purposes of determining the parameter passing as it has no
> effect on the layout of the type.
>
> We do not feel that an update to the
in PR42217,
so on various backends where TYPE_FIELDS are analyzed for how to pass or
return certain aggregates starting with GCC 4.5 the C++ and C ABI
diverged.
In August, I have removed that zero width bitfield removal from C++ FE
as the FE needs to take those bitfields into account later on as
we still have a duck
here (if it walks like one and quacks like one...).
I'm still awaiting final confirmation of this from our internal ABI group,
but I'm pretty confident that this will be our final position.
PS. It looks like llvm and llvm++ are inconsistent on this one as well.
e an
> HFA.
> my preliminary conclusion is that for Arm and AArch64 we still have a duck
> here (if it walks like one and quacks like one...).
>
> I'm still awaiting final confirmation of this from our internal ABI group,
> but I'm pretty confident that this will be our
e analyzed for how to pass or
return certain aggregates starting with GCC 4.5 the C++ and C ABI diverged.
In August, I have removed that zero width bitfield removal from C++ FE
as the FE needs to take those bitfields into account later on as well.
The x86_64 backend was changed in r12-6418-g315
; so on various backends where TYPE_FIELDS are analyzed for how to pass or
> return certain aggregates starting with GCC 4.5 the C++ and C ABI diverged.
> In August, I have removed that zero width bitfield removal from C++ FE
> as the FE needs to take those bitfields into account later on a
s starting with GCC 4.5 the C++ and C ABI diverged.
In August, I have removed that zero width bitfield removal from C++ FE
as the FE needs to take those bitfields into account later on as well.
The x86_64 backend was changed in r12-6418-g3159da6c46 to match recently
approved clarification of the x8
I've been following
[RFC] Enabling -Wstrict-prototypes by default in C
<https://discourse.llvm.org/t/rfc-enabling-wstrict-prototypes-by-default-in-c/60521/25>
and I've just realized that treating
extern int foo();
as a prototype declaration (with the same ABI as extern &
Iain Sandoe writes:
> Hi Richard,
>> On 20 Jan 2022, at 22:32, Richard Sandiford
>> wrot>> Iain Sandoe writes:
>>>> On 10 Jan 2022, at 10:46, Richard Sandiford
>>>> wrot>> An alternative might be to make promote_function_arg a “prop
Hi Richard,
> On 20 Jan 2022, at 22:32, Richard Sandiford wrote:
>
> Iain Sandoe writes:
>>> On 10 Jan 2022, at 10:46, Richard Sandiford
>>> wrot>> An alternative might be to make promote_function_arg a “proper”
>>> ABI hook, taking a cumulative_a
Iain Sandoe writes:
>> On 10 Jan 2022, at 10:46, Richard Sandiford
>> wrot>> An alternative might be to make promote_function_arg a “proper”
>> ABI hook, taking a cumulative_args_t and a function_arg_info.
>> Perhaps the return case should become a separate hook at
e can run out of registers on all of them. The key
> >> property is the size/alignment of the argument differs depending on if
> >> it's pass in a register (get promoted) or passed in memory (not
> >> promoted). I'm not immediately aware of another ABI with that
>
in a register (get promoted) or passed in memory (not
promoted). I'm not immediately aware of another ABI with that
feature. Though I haven't really gone looking.
I think what AArch64 Darwin does is not compatible with a GCC extension
that allows calling functions defined with a prototype
o observe the same rules in this case.
>
> It will, however, break once we overflow the number of int regs.. :/
Exactly.
> The case that is fundamentally broken from scratch is of a variadic function
> called without a prototype - since the aarch64-darwin ABI places unnamed
> parm
gument differs depending on if
>> it's pass in a register (get promoted) or passed in memory (not
>> promoted). I'm not immediately aware of another ABI with that
>> feature. Though I haven't really gone looking.
>
> I think what AArch64 Darwin does i
> On 10 Jan 2022, at 10:46, Richard Sandiford wrote:
>
> Iain Sandoe writes:
>> Hi Folks,
>>
>> In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature
>> of the calling convention.
>>
>> When an argument is passed *in a regi
Iain Sandoe writes:
> Hi Folks,
>
> In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature of
> the calling convention.
>
> When an argument is passed *in a register* and it is integral and less than
> SI it is promoted (with appropriate signedness) to S
ed in memory (not
> promoted). I'm not immediately aware of another ABI with that
> feature. Though I haven't really gone looking.
I think what AArch64 Darwin does is not compatible with a GCC extension
that allows calling functions defined with a prototype without it (for
pre-ISO-C co
On 1/7/2022 2:55 PM, Paul Koning via Gcc wrote:
On Jan 7, 2022, at 4:06 PM, Iain Sandoe wrote:
Hi Folks,
In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature of
the calling convention.
When an argument is passed *in a register* and it is integral and less than SI
> On Jan 7, 2022, at 4:06 PM, Iain Sandoe wrote:
>
> Hi Folks,
>
> In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature of
> the calling convention.
>
> When an argument is passed *in a register* and it is integral and less than
> SI it is
Hi Folks,
In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature of
the calling convention.
When an argument is passed *in a register* and it is integral and less than SI
it is promoted (with appropriate signedness) to SI. This applies when the
function parm is named only
On Mon, Nov 01, 2021 at 10:56:33AM -0500, Bill Schmidt wrote:
> Would starting from Advance Toolchain 15 with the most recent glibc make
> things easier for Thomas to test?
The problem is gcc135 runs Centos 7.x which is not compatible with AT 13-15.
--
Michael Meissner, IBM
PO Box 98, Ayer, Mas
Would starting from Advance Toolchain 15 with the most recent glibc make things
easier for Thomas to test?
Thanks,
Bill
On 10/29/21 4:06 PM, Michael Meissner via Gcc wrote:
> On Fri, Oct 29, 2021 at 09:07:38PM +0200, Thomas Koenig wrote:
>> Hi Michael,
>>
>> I tried this out on the one POWER mac
actually think the
fourth one (the suggestion by Steve Lionel) is the best one.
That was the last option I was mentioning in the initial mail
https://gcc.gnu.org/pipermail/gcc/2021-October/237478.html
Copying it here:
Or the last option would be to try to make libgfortran.so.5 ABI compatible
with
would we want to pursue? I actually think the
> fourth one (the suggestion by Steve Lionel) is the best one.
That was the last option I was mentioning in the initial mail
https://gcc.gnu.org/pipermail/gcc/2021-October/237478.html
Copying it here:
Or the last option would be to try to make libgfo
Hi Michael,
It adds target hooks so the back end can overwrite the kind number for types.
I made the IBM long double type use KIND=15 instead of KIND=16, and Float128
uses KIND=16 as we've discussed. The tests for long double are still
failing, so I suspect we will need some way of signalling
This patch replaces the first patch.
Instead of disallowing long double and only dealing with float128 types, this
patch tries to accommodate the two.
It adds target hooks so the back end can overwrite the kind number for types.
I made the IBM long double type use KIND=15 instead of KIND=16, and
On Fri, Oct 29, 2021 at 09:07:38PM +0200, Thomas Koenig wrote:
> Hi Michael,
>
> I tried this out on the one POWER machine where I can get something
> installed :-) It runs Ubuntu 20.04, but does not appear to have the
> right glibc version; it has
>
> $ lsb_release -a
> No LSB modules are availa
Hi Michael,
I tried this out on the one POWER machine where I can get something
installed :-) It runs Ubuntu 20.04, but does not appear to have the
right glibc version; it has
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04.1 LTS
Release:
Here are the patches I worked on today. It does seem to fix KIND=16 to use
Float128, but by not considering long double for KIND processing, it breaks the
tests that want to do ISO C binding to long double.
Feel free to completely ignore the patches and go off in a different
direction. But I tho
I've played with some patches to PowerPC to set the defaults for fortran. But
without doing a full rebuild like you would do with a new distribution, I think
it will be problematical, unless you build everything with the default long
double set to IEEE 128-bit.
First off all, libquadmath is curre
; is non-zero then for all 'i' in range [0, n) the byte at
>offset 'i' of 's1' equals the byte at offset 'i' in 's2'.
>
> For a simple C implementation of '__memcmpeq()' could be as follows:
>
>
> int __memcmpeq(con
Sorry, I thought this was the libc list... :-)
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Okt 25 2021, Florian Weimer wrote:
> Sorry, I don't understand. _Unwind_Find_FDE is a key part of the
> unwinder used for exception handling. It's definitely still in use.
Not on new platforms. See libc_cv_gcc_unwind_find_fde.
> But it looks like an internal implementation detail that was
* Andreas Schwab:
> On Okt 25 2021, Florian Weimer via Gcc wrote:
>
>> What should we do with _Unwind_Find_FDE and similar exported functions
>> that require types which are not currently defined in ?
>
> Aren't they legacy only?
Sorry, I don't understand. _Unwind_Find_FDE is a key part of the
u
On Okt 25 2021, Florian Weimer via Gcc wrote:
> What should we do with _Unwind_Find_FDE and similar exported functions
> that require types which are not currently defined in ?
Aren't they legacy only?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69
_Unwind_Find_FDE is exported as a public symbol on GNU/Linux, with a
default symbol version. But it's not part of the install
header, and its struct types are not namespace-clean for C++,
potentially leading to ODR violations.
What should we do with _Unwind_Find_FDE and similar exported function
On Fri, 15 Oct 2021, Bill Schmidt via Gcc wrote:
> Beyond ABI and compiler support, glibc would also need to support IEEE
> QP for these other targets. Currently we only have support for
> powerpc64le.
And that would involve new syntax in glibc Versions files, as discussed i
ine. The first step towards
> this is to
> develop and document ABI for IEEE QP on those targets. The simplest approach
> that everyone
> seemed to like is for these ABIs to require AltiVec support in order for IEEE
> QP to be
> supported. This allows parameters and return values
On Fri, Oct 15, 2021 at 04:20:49PM +0200, Jakub Jelinek wrote:
> If we do implement double-double support, I think KIND=15 would be better
> than KIND=17, it is true that double-double has for certain numbers much
> higher precision than IEEE quad, but the precision depends on the numbers
> and mos
On 15.10.21 20:11, Jakub Jelinek wrote:
On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote:
with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble
33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither
precision of C long double if it is doubl
On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote:
> > with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble
> > 33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither
> > precision of C long double if it is double-double nor range matches
> > a
On 15.10.21 16:20, Jakub Jelinek wrote:
[...]
when one compiles
integer function foo ()
foo = precision (0.0_16)
end function foo
integer function bar ()
bar = range (0.0_16)
end function bar
with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble
33 and 4931. The 0
there was agreement. I'd also like to separate out short-term
> considerations
> for powerpc64le and GCC 12 from other topics like supporting more targets.
>
> ===
>
> First, for the short-term. For powerpc64le only (little-endian, ELFv2 ABI)
> Thomas sugge
ations
for powerpc64le and GCC 12 from other topics like supporting more targets.
===
First, for the short-term. For powerpc64le only (little-endian, ELFv2 ABI)
Thomas suggested
that Fortran's best course of action is:
- Change KIND=16 in GCC 12 from double-double to IEEE QP just for affected
targ
borrowing
> language from it. That may have been an excess of caution, or it may not...
I am not suggesting you should share this text with some other ABI.
Just that you can put it in the same repository :-)
> That said, with enough diligence I would hope we would be able to create
> mod
#x27;s a choice
> that should be made explicitly, and documented (in the relevant ABI if one
> is maintained), and coordinated between implementations when there's more
> than one implementation for the architecture trying to be compatible.
I don't disagree at all. But: GCC ma
e a struct or an
>>> array of ints will work fine, but it needs to be written down. This is
>>> more than just Fortran.
>> Is the 64-bit BE (ELFv1) ABI maintained somewhere? (The 32-bit ABI,
>> covering both hard float and soft float, is
>> <https://g
Am Donnerstag, dem 14.10.2021 um 13:17 + schrieb Michael Matz:
> Hello,
>
> On Wed, 13 Oct 2021, Martin Uecker wrote:
>
> > > [... static chain ...]
> > > If you mean that, then it's indeed psABI specific, and possibly
> > > not
> > > al ABIs specify it (in which case GCC will probably have s
Hello,
On Wed, 13 Oct 2021, Martin Uecker wrote:
> > [... static chain ...]
> > If you mean that, then it's indeed psABI specific, and possibly not
> > al ABIs specify it (in which case GCC will probably have set a de-
> > facto standard at least for unixy systems). The x86-64 psABI for
> > inst
(and C++ liaison list) of whether it would
be useful to have a public list of C-relevant ABIs and their maintainer
contacts and ABI-relevant new features in C language versions. I was
thinking of such a list as being to help people do due diligence after
making ABI-relevant C standard change
Am Mittwoch, dem 13.10.2021 um 15:21 + schrieb Michael Matz:
> Hello,
>
> On Wed, 13 Oct 2021, Martin Uecker wrote:
>
> > does anybody know if all architectures support passing
> > an environment pointer in their function call ABI?
>
...
>
> Or you could m
Hello,
On Wed, 13 Oct 2021, Martin Uecker wrote:
> does anybody know if all architectures support passing
> an environment pointer in their function call ABI?
Define "environment pointer". I can imagine two things you could mean:
the custom to pass envp as third argument to
Hi all,
does anybody know if all architectures support passing
an environment pointer in their function call ABI?
Are the some where this does not exist?
Is there are table somewhere which lists the
register (or stack slot) used for this for
all architectures?
Somehow I could not find
es with other choices - in
particular, whether to say some or all the higher bits in the register or
stack slot are sign-extended, zero-extended or undefined). It's a choice
that should be made explicitly, and documented (in the relevant ABI if one
is maintained), and coordinated be
* Andreas Schwab:
> On Okt 09 2021, Thomas Koenig via Fortran wrote:
>
>> There is no choice - we need to make object code compiled by the user
>> incompatible between the old and the new format on the systems where
>> we make the switch.
>
> If you link, but not recompile, object files compiled a
On Sat, Oct 09, 2021 at 11:11:51AM +0200, Thomas Koenig wrote:
> The question is still if we can avoid a new SONAME for >99% of our users
> for no gain at all for them. Is there a possibility of aliasing the
> SONAME somehow (grasping at straws here)?
I'd hope Debian can just
ln -sf libgfortran.s
> On 9 Oct 2021, at 10:11, Thomas Koenig wrote:
>
>
> On 09.10.21 01:18, Iain Sandoe wrote:
>>> I meant the case where the user writes, with an old, KIND=16 is double
>>> double compiler,
>>>
>>> subroutine foo(a)
>>>real(kind=16) :: a
>>>a = a + 1._16
>>> end subroutine foo
>>>
>
On 09.10.21 01:18, Iain Sandoe wrote:
I meant the case where the user writes, with an old, KIND=16 is double
double compiler,
subroutine foo(a)
real(kind=16) :: a
a = a + 1._16
end subroutine foo
and puts it in a library or an old object file, and in new code with an
IEEE QP compi
On Okt 09 2021, Thomas Koenig via Fortran wrote:
> There is no choice - we need to make object code compiled by the user
> incompatible between the old and the new format on the systems where
> we make the switch.
If you link, but not recompile, object files compiled against different
versions of
> On 8 Oct 2021, at 23:55, Thomas Koenig via Gcc wrote:
>
>
> Hi Iain,
>
>>> Things get interesting for user code, calling a routine compiled
>>> for double double with newer IEEE QP will result in breakage.
>> That would not happen with the proposal above, since the library would
>> have di
Hi Thomas,
recognising that this is complex - the intent here is to see if there are ways
to partition the problem (where the pain falls does depend on the choices
made).
perhaps:
*A library (interface, name)
*B compiler internals
*C user-facing changes
> On 8 Oct 2021, at 17:26, Thomas K
Hi Iain,
Things get interesting for user code, calling a routine compiled
for double double with newer IEEE QP will result in breakage.
That would not happen with the proposal above, since the library would
have different entry points for the two formats.
I meant the case where the user wri
On Wed, Oct 06, 2021 at 11:42:11PM -0400, Michael Meissner wrote:
> On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > > On 05.10.21 23:54, Segher Boessenkool wrote:
> > > >>There is also the issue of binary dat
scription get a working sofware floating point (for binary32 and
> > binary64 currently).
>
> Any architecture that supports a software floating-point ABI (i.e. one
> that does argument passing and return for floating-point in integer
> registers) should specify it in its ABI documen
Hi Iain,
If one wanted to prioritize library SO name stability - then, perhaps, the
approach Jonathan mentioned has been used for libstdc++ (add new
symbols for ieee128 with a different mangling to the existing r/c_16 ..)
would be preferable (the FE then has to choose the relevant symbol/
mangli
> On 8 Oct 2021, at 07:35, Thomas Koenig via Fortran
> wrote:
>
>
> On 07.10.21 17:33, Jakub Jelinek wrote:
>>> It will also be a compatibility issue if users have code compiled on a LE
>>> system with GCC 11 and earlier with KIND=16, it will not link with G
On 07.10.21 17:33, Jakub Jelinek wrote:
It will also be a compatibility issue if users have code compiled on a LE
system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.
libgfortran ABI changed multiple times in the past already, e.g. the
so.1 -> so.2 transition in 4.2
s
6.
Changing it on powerpc64le-linux doesn't imply we also have to change it
for powerpc64-linux, or perhaps can change it later than in GCC 12.
> It will also be a compatibility issue if users have code compiled on a LE
> system with GCC 11 and earlier with KIND=16, it will not link with GC
On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> On 07.10.21 05:35, Michael Meissner via Fortran wrote:
> > I tried this at one point. There are a lot of hidden assumptions that the
> > kind
> > number is the number of bytes. I'm sure it can be tracked down, but the
> > problem i
ro) updates libgfortran-dev to point to 6, drops libgfortran5 from
the Debian archive (but doesn't delete the package libgfortran5 from the
users' computer) and we rebuild and transition simultaneously all
packages that depend on libgfortran5.
So if we introduce libgfortran6 for ppc
On Thu, Oct 07, 2021 at 11:56:45AM +0200, Andreas Schwab wrote:
> On Okt 07 2021, Alastair McKinstry wrote:
>
> > I strongly advise against this -- identical SONAMEs for the libraries on
> > all architectures is a key assumption on all Debian-based distributions
> > and designs
>
> Even glibc ha
On Okt 07 2021, Alastair McKinstry wrote:
> I strongly advise against this -- identical SONAMEs for the libraries on
> all architectures is a key assumption on all Debian-based distributions
> and designs
Even glibc has differing sonames on some architectures. And libgcc_s,
too.
Andreas.
--
On 06/10/2021 07:59, Thomas Koenig via Fortran wrote:
On 05.10.21 23:54, Segher Boessenkool wrote:
Hi!
On Tue, Oct 05, 2021 at 10:16:47PM +0200, Thomas Koenig wrote:
On 04.10.21 16:14, Jakub Jelinek via Fortran wrote:
Based on some IRC discussion, yet another option would be bump
libgfortra
On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> On 07.10.21 05:35, Michael Meissner via Fortran wrote:
> > I tried this at one point. There are a lot of hidden assumptions that the
> > kind
> > number is the number of bytes. I'm sure it can be tracked down, but the
> > problem i
, for an environment variable, I'd say
we should use a new one and reuse the existing parsing routines.
Sounds like a reasonable minimum of user pain to me.
The rest I'll leave to the experts in all things ABI and POWER :-)
> > instructions, or would that be trap and emulate? What is the
> > plan there?
>
> The registers used by the QP insns are the VRs. Trying to use the QP
> insns on a p8 will trap. There is no kernel emulation for them afaik.
>
> But, for p8 there is software emulation,
1 - 100 of 809 matches
Mail list logo
