https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #43 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:9ade70bb86c8744f4416a48bb69cf4705f00905a
commit r14-3254-g9ade70bb86c8744f4416a48bb69cf4705f00905a
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #42 from Mikael Morin ---
(In reply to anlauf from comment #41)
> (In reply to Mikael Morin from comment #40)
> > Harald, I have just closed the followup PR110419.
> > I think this PR can be closed as well, or is there something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #41 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #40)
> Harald, I have just closed the followup PR110419.
> I think this PR can be closed as well, or is there something left to be done?
It is pretty much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #40 from Mikael Morin ---
Harald, I have just closed the followup PR110419.
I think this PR can be closed as well, or is there something left to be done?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #39 from CVS Commits ---
The master branch has been updated by Mikael Morin :
https://gcc.gnu.org/g:564b637f4a32883cbf3c3019d3cfcf0b0aec9b82
commit r14-3207-g564b637f4a32883cbf3c3019d3cfcf0b0aec9b82
Author: Mikael Morin
Date:
on||83077
--- Comment #2 from Jonathan Wakely ---
(In reply to Iain Sandoe from comment #1)
> so, FAOD, that means that
> versioned namespace => disables dual ABI
> => forces the old string impl?
Yes, that's PR 83077
> What's the blocker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65762
--- Comment #1 from Iain Sandoe ---
so, FAOD, that means that
versioned namespace => disables dual ABI
=> forces the old string impl?
What's the blocker to making it work?
(just time - or ABI issues?)
The patch series add loongarch32 and ilp32 abi support to gcc. One can
build libgcc, libatomic and glibc etc and generate a complete
loongarch32-unknown-linux-gnu-toolchain with minimal patches at:
- binutils: https://github.com/jiegec/binutils-gdb/tree/loongarch32
- glibc: https://github.com
Ping!
Forwarded Message
Subject: [PING^2] PATCH v5 4/4] ree: Improve ree pass for rs6000 target using
defined ABI interfaces.
Date: Tue, 18 Jul 2023 13:28:08 +0530
From: Ajit Agarwal
To: gcc-patches
CC: Jeff Law , Richard Biener
, Segher Boessenkool ,
Peter Bergner
Ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
David Edelsohn changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #37 from anlauf at gcc dot gnu.org ---
Created attachment 55661
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55661=edit
Tentative patch for the bind(c) case
The attached lightly-tested patch tries to fix (at least at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759
--- Comment #16 from Sergey Fedorov ---
(In reply to Iain Sandoe from comment #15)
Would be nice to have it fixed, otherwise `jack` is broken:
https://github.com/jackaudio/jack2/issues/950
Which, in turn, leaves broken dependencies.
,
||i686-*-darwin
--- Comment #15 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #14)
> (In reply to Eric Gallager from comment #8)
With current trunk on a cross to powerpc-apple-darwin9 this reproduces for the
runtime ABI 01 - which is used on 32b Darwin. (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759
--- Comment #14 from Sergey Fedorov ---
(In reply to Eric Gallager from comment #8)
> I'd need to rebuild gcc with debug info to get a better backtrace.
Have you been able to?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759
--- Comment #13 from Sergey Fedorov ---
Any update on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #36 from David Edelsohn ---
I don't know enough FORTRAN90 to instruct the compiler to use an external
function as if it were native.
EXTERNAL :: MYFUNC
changes the calling convention.
But if I manually change the assembly code so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #35 from anlauf at gcc dot gnu.org ---
(In reply to David Edelsohn from comment #34)
> AIX POWER BE output:
>
> $ ./a.out
> val(fortran): 65 A
> val(fortran):0
> val(fortran):0
> val_c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #34 from David Edelsohn ---
AIX POWER BE output:
$ ./a.out
val(fortran): 65 A
val(fortran):0
val(fortran):0
val_c: char(65)='A'
val_c: char(65)='A'
val_c: char(804399656)='('
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #33 from anlauf at gcc dot gnu.org ---
(In reply to David Edelsohn from comment #32)
> I'm leaning back to big-endian vs little-endian, and not a struct issue. A
> little-endian STRING will start at the lowest address and a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #32 from David Edelsohn ---
i think that I see part of the difference. The 005t.original dump shows
(intermingled with sources)
! call val ("B","B")
val (&"B"[1]{lb: 1 sz: 1}, "B", 1, 1);
! call val ("A",char(65))
val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #31 from David Edelsohn ---
Yes, &"B"[1], is not shifted because it is a reference. The important
different is "B" is passed left-shifted, but 65 is passed right-shifted.
call val ("B","B") OK
call val
1]{lb: 1 sz: 1};
> val (&"1"[1]{lb: 1 sz: 1}, _37, 1, 1);
> _38 = c[1]{lb: 1 sz: 1};
> val (&"1"[1]{lb: 1 sz: 1}, _38, 1, 1);
>
> &"B"[1] is not shifted. 65 is not shifted. "B" is shifted.
>
> GFORTRAN is passing the v
1]{lb: 1 sz: 1}, _37, 1, 1);
_38 = c[1]{lb: 1 sz: 1};
val (&"1"[1]{lb: 1 sz: 1}, _38, 1, 1);
&"B"[1] is not shifted. 65 is not shifted. "B" is shifted.
GFORTRAN is passing the value in different ways that trigger different parts of
the target ABI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #28 from anlauf at gcc dot gnu.org ---
(In reply to David Edelsohn from comment #27)
> If GFORTRAN assumes that a scalar value and a value in a struct are passed
> in registers with the same padding, that is not a valid, general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #27 from David Edelsohn ---
GFORTRAN parse output describes the characters as follow
symtree: 'char'|| symbol: 'char'
type spec : (UNKNOWN 0)
attributes: (PROCEDURE INTRINSIC-PROC FUNCTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Jonathan Wakely ---
> I hope this is fixed now.
It is indeed. Thanks a lot.
scan-tree-dump-times gimple
"struct allocator D" 1
=== g++ Summary for unix/-D_GLIBCXX_USE_CXX11_ABI=0 ===
=== g++ Summary for unix ===
because in the old ABI we get two "struct allocator D". This patch
follows r14-658 although I'm not quite sure I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #17 from Jonathan Wakely ---
I hope this is fixed now.
is not useful (and caused an ABI
change on Solaris x86).
Making the definition depend on USE_STRTOF128_FOR_FROM_CHARS again
partially reverts the change for PR 109921, however that should still be
fixed because the changes to make USE_STRTOF128_FOR_FROM_CHARS depend
g the lossy fallback using
long double is not useful (and caused this ABI change on Solaris x86).
locator D" 1
> FAIL: g++.dg/tree-ssa/allocator-opt1.C -std=c++20 scan-tree-dump-times
> gimple "struct allocator D" 1
>
> === g++ Summary for unix/-D_GLIBCXX_USE_CXX11_ABI=0 ===
>
> === g++ Summary for unix ===
>
> because in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.0
g account of endianness for the layout of values in
> memory compared to constants loaded into registers. This isn't an ABI issue
> of the target, this is a memory layout and register layout issue of GFortran.
Frankly speaking, this is a place where I have zero knowledge.
> Let me kno
Ping^2.
Please review.
Thanks & Regards
Ajit
This new version of patch 4 use improve ree pass for rs6000 target using
defined ABI interfaces.
Bootstrapped and regtested on power64-linux-gnu.
Review comments incorporated.
Thanks & Regards
Ajit
Improve ree pass for rs6000 targ
or do the save/restore
> themself in the codepaths that needs them, hello memcpy again).
> So we want to introduce a way to specify this, via an ABI attribute
> that basically says "doesn't clobber the high XMM regs".
>
> I've opted to do only the obvious: do something special only for
quot;A",mychar(a))
li 6,1
li 5,1
li 4,65 <- c NOT SHIFTED
mr 3,30 <- x
bl .val.4
GFortran is not taking account of endianness for the layout of values in memory
compared to constants loaded into registers. This isn't an ABI issue of the
target, this is a memory layout and register layout issue of GFortran.
Let me know if you need more information or tests.
On Tue, 11 Jul 2023, Michael Matz wrote:
> Hey,
>
> On Tue, 11 Jul 2023, Alexander Monakov via Gcc-patches wrote:
>
> > > > > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered
> > > >
> > > > This is the weak/active form; I'd suggest "preserve_high_sse".
> > >
> > > But it
Hey,
On Tue, 11 Jul 2023, Alexander Monakov via Gcc-patches wrote:
> > > > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered
> > >
> > > This is the weak/active form; I'd suggest "preserve_high_sse".
> >
> > But it preserves only the low parts :-) You swapped the two in your
On Tue, 11 Jul 2023, Michael Matz wrote:
> > > To that end I introduce actually two related attributes (for naming
> > > see below):
> > > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered
> >
> > This is the weak/active form; I'd suggest "preserve_high_sse".
>
> But it
mind when writing the reply?
> > I would welcome any comments, about the names, the approach, the attempt
> > at documenting the intricacies of these attributes and anything.
>
> I hope the new attributes are supposed to be usable with function
> pointers? From the c
used for argument passing. Arguments are
by default callee clobbered, and we do not want to change this (or limit
the number of register arguments for the alternate ABI).
Ciao,
Michael.
ou suggest
> the name applies to the caller which has to preserve high parts
> when calling nosseclobber.
This is the form where the function annnotated with this attribute
consumes 128 bytes on the stack to "blindly" save/restore xmm8-15
if it calls anything with a vanilla ABI.
> > > When a function doesn't contain calls to
> > > unknown functions we can be a bit more lenient: we can make it so that
> > > GCC simply doesn't touch xmm8-15 at all, then no save/restore is
> > > necessary.
One may also take into account that first 8 registers are cheaper to
encode than the
calls.
> >
> > But in reality many functions can be written such that they only need
> > to clobber a subset of the 16 XMM registers (or do the save/restore
> > themself in the codepaths that needs them, hello memcpy again).
> > So we want to introduce a way to spe
tition we already automatically enable regparm with -m32
> see ix86_function_regparm and tests for target->local and
> can_change_attribute
>
> Enabling SSE at the same spot should be easy.
It's probably slightly different since we want to enable it for a "leaf"
sub
> > > FWIW, this particular patch was regstrapped on x86-64-linux
> > > with trunk from a week ago (and sniff-tested on current trunk).
> >
> > This looks really cool.
>
> The biggest benefit might be from IPA with LTO where we'd carefully place
> those
> attributes at WPA time (at that time
calls.
> >
> > But in reality many functions can be written such that they only need
> > to clobber a subset of the 16 XMM registers (or do the save/restore
> > themself in the codepaths that needs them, hello memcpy again).
> > So we want to introduce a way to spe
On Mon, 10 Jul 2023, Alexander Monakov wrote:
> > I chose to make it possible to write function definitions with that
> > attribute with GCC adding the necessary callee save/restore code in
> > the xlogue itself.
>
> But you can't trivially restore if the callee is sibcalling — what
> happens
=== g++ Summary for unix/-D_GLIBCXX_USE_CXX11_ABI=0 ===
=== g++ Summary for unix ===
because in the old ABI we get two "struct allocator D". This patch
follows r14-658 although I'm not quite sure I follow the logic there.
Tested on x86_64-pc-linux-gnu, ok for trunk?
g
registers (or do the save/restore
> themself in the codepaths that needs them, hello memcpy again).
> So we want to introduce a way to specify this, via an ABI attribute
> that basically says "doesn't clobber the high XMM regs".
I think the main question is why you're going wit
er a subset of the 16 XMM registers (or do the save/restore
> themself in the codepaths that needs them, hello memcpy again).
> So we want to introduce a way to specify this, via an ABI attribute
> that basically says "doesn't clobber the high XMM regs".
>
> I've opted to
to introduce a way to specify this, via an ABI attribute
that basically says "doesn't clobber the high XMM regs".
I've opted to do only the obvious: do something special only for
xmm8 to xmm15, without a way to specify the clobber set in more detail.
I think such half/half split is reasonable
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 without
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102105
Richard Biener changed:
What|Removed |Added
Target Milestone|10.5|---
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91710
Richard Biener changed:
What|Removed |Added
Known to fail||10.5.0
Target Milestone|10.5
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 tha
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
simple
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #14 from Jonathan Wakely ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #13)
> That would mean an implementation of C23 Annex H, right? IIUC,
> implementing that is optional.
Right (on both counts).
> However, I can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Jonathan Wakely ---
> (In reply to Jonathan Wakely from comment #9)
>> One solution would be to just add the declaration to the header, and adjust
>> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to Jonathan Wakely from comment #9)
> > One solution would be to just add the declaration to the header, and adjust
> > the exports so this new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> This affects aarch64 too:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620335.html
> And probably other targets where long double uses binary128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #9)
> One solution would be to just add the declaration to the header, and adjust
> the exports so this new symbol is exported at GLIBCXX_3.4.32 not
>
T128_T__) && defined(_GLIBCXX_HAVE_FLOAT128_MATH)
...
#endif
and that means we the header doesn't declare from_chars for _Float128.
With my changes for PR 109921 (r14-1431) that from_chars overload gets defined
in the library, causing the abi-check error. But if it's not present in the
head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #8 from Rainer Orth ---
(In reply to Jonathan Wakely from comment #6)
> This is going to be hard for me to figure out without access to a Solaris
> x86 system.
There's hope that at least one, maybe two, Solaris 11.4/x86 systems can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #7 from Rainer Orth ---
Created attachment 55426
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55426=edit
32-bit i386-pc-solaris2.11 charconv.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #6 from Jonathan Wakely ---
This is going to be hard for me to figure out without access to a Solaris x86
system.
Could you please attach the output of this command using GCC trunk on solaris
x86?
g++ -std=c++23 -include charconv
8736d6b14a4dfdfb58c80ccd398981b0fb5d00aa Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 28 Jun 2023 22:16:18 +0200
Subject: [PATCH] Fortran: ABI for scalar CHARACTER(LEN=1),VALUE dummy argument
[PR110360]
gcc/fortran/ChangeLog:
PR fortran/110360
* trans-expr.cc (gfc_conv_procedure_call): For non-constant
: Wed Jun 28 22:16:18 2023 +0200
Fortran: ABI for scalar CHARACTER(LEN=1),VALUE dummy argument [PR110360]
gcc/fortran/ChangeLog:
PR fortran/110360
* trans-expr.cc (gfc_conv_procedure_call): For non-constant string
argument passed to CHARACTER(LEN=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #23 from Mikael Morin ---
(In reply to anlauf from comment #22)
> Created attachment 55418 [details]
> Slighty revised version of 3rd patch
>
> I've looked at gfc_conv_string_parameter, which I was not aware of.
> This can be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #22 from anlauf at gcc dot gnu.org ---
Created attachment 55418
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55418=edit
Slighty revised version of 3rd patch
I've looked at gfc_conv_string_parameter, which I was not aware of.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #21 from Mikael Morin ---
(In reply to anlauf from comment #20)
> Created attachment 55407 [details]
> Third patch set
>
> Here's a lightly tested 3rd patch that tries to handle the chaos I created...
>
> Can you have a look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #20 from anlauf at gcc dot gnu.org ---
Created attachment 55407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55407=edit
Third patch set
Here's a lightly tested 3rd patch that tries to handle the chaos I created...
Can you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #19 from Mikael Morin ---
(In reply to Mikael Morin from comment #18)
> There is the "obvious" problem that gfc_build_wide_string_const creates a
> bare array, whereas gfc_string_to_single_character expects a pointer
> wrapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #18 from Mikael Morin ---
(In reply to Mikael Morin from comment #15)
> I have asked for an account on the compile farm (see
> https://gcc.gnu.org/wiki/CompileFarm) to have access to a powerpc machine.
It was pretty fast to get the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #17 from anlauf at gcc dot gnu.org ---
It appears that gfc_string_to_single_character does not fulfill my expectation.
The following ICEs now:
subroutine s
implicit none
interface
subroutine ref (c)
character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #16 from anlauf at gcc dot gnu.org ---
In the meantime Bill opened pr110419 and posted:
spawn [open ...]
by value(kind=1): B
by value(kind=1): A
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #15 from Mikael Morin ---
(In reply to anlauf from comment #14)>
> Let's hope that somebody with access to such a system can run the testcase
> manually and append the output to this PR.
I have asked for an account on the compile
All:
>>
>> This new version of patch 4 use improve ree pass for rs6000 target using
>> defined ABI interfaces.
>> Bootstrapped and regtested on power64-linux-gnu.
>>
>> Review comments incorporated.
>>
>> Thanks & Regards
>> Ajit
>
All:
Ok for trunk. Please review.
Thanks & Regards
Ajit
On 01/06/23 10:53 am, Ajit Agarwal via Gcc-patches wrote:
> Hello All:
>
> This new version of patch 4 use improve ree pass for rs6000 target using
> defined ABI interfaces.
> Bootstrapped and regtested on power64-lin
All:
Ok for trunk. Please review.
Thanks & Regards
Ajit
On 01/06/23 10:53 am, Ajit Agarwal via Gcc-patches wrote:
> Hello All:
>
> This new version of patch 4 use improve ree pass for rs6000 target using
> defined ABI interfaces.
> Bootstrapped and regtested on power64-lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #14 from anlauf at gcc dot gnu.org ---
After r14-2064, gcc-testresults shows the following for big-endian Power
platforms:
Running target unix/-m32
FAIL: gfortran.dg/value_9.f90 -O0 execution test
FAIL: gfortran.dg/value_9.f90
float16 tuple type abi
On 6/21/23 01:46, juzhe.zh...@rivai.ai wrote:
> LGTM. Thanks.
OK from me as well.
jeff
: [PATCH] Fortran: ABI for scalar CHARACTER(LEN=1),VALUE dummy argument
[PR110360]
gcc/fortran/ChangeLog:
PR fortran/110360
* trans-expr.cc (gfc_conv_procedure_call): Truncate constant string
argument of length > 1 passed to scalar CHARACTER(1),VALUE dummy.
---
gcc/fortran/trans-expr.cc |
: Sat Jun 24 20:36:53 2023 +0200
Fortran: ABI for scalar CHARACTER(LEN=1),VALUE dummy argument [PR110360]
gcc/fortran/ChangeLog:
PR fortran/110360
* trans-expr.cc (gfc_conv_procedure_call): Truncate constant string
argument of length > 1 passed to sca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #11)
> Created attachment 55393 [details]
> Patch to truncate string argument longer than 1
>
> This truncates the string to length 1 and appears to work on x86
On 6/21/23 01:46, juzhe.zh...@rivai.ai wrote:
LGTM. Thanks.
OK from me as well.
jeff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456
--- Comment #14 from Xi Ruoyao ---
(In reply to Andreas Schwab from comment #10)
> Or "other ABI-mandated fixed roles". This also includes return value
> registers.
Hmm, even "ABI-mandated fixed roles" is not enoug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456
--- Comment #13 from Xi Ruoyao ---
(In reply to gccriscvuser from comment #12)
> Updating the documentation is good, but there should also be an error
> diagnostic, right?
It would be a backward-incompatible change. IMO it's perfectly legal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #11 from anlauf at gcc dot gnu.org ---
Created attachment 55393
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55393=edit
Patch to truncate string argument longer than 1
This truncates the string to length 1 and appears to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #10 from anlauf at gcc dot gnu.org ---
Hmm, the testers show failures for the new testcase for the following cases:
x86 / -m32 / -O1 and higher,
Power9 BE, all optimization levels.
I can reproduce the case of x86 / -m32 / -O1 for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456
--- Comment #12 from gccriscvuser at proton dot me ---
Updating the documentation is good, but there should also be an error
diagnostic, right?
: Thu Jun 22 22:07:41 2023 +0200
Fortran: ABI for scalar CHARACTER(LEN=1),VALUE dummy argument [PR110360]
gcc/fortran/ChangeLog:
PR fortran/110360
* trans-expr.cc (gfc_conv_procedure_call): Pass actual argument
to scalar CHARACTER(1),VALUE dummy argument
301 - 400 of 5007 matches
Mail list logo
