https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|
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 left
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: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
David Edelsohn changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
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&action=edit
Tentative patch for the bind(c) case
The attached lightly-tested patch tries to fix (at least at t
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: char(65)
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 big-endia
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 ("A",char(65))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #30 from anlauf at gcc dot gnu.org ---
(In reply to David Edelsohn from comment #29)
> Maybe something about the way that GFORTRAN is passing the string by value.
> 257.optimized shows
>
> val (&"B"[1]{lb: 1 sz: 1}, "B", 1, 1);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #29 from David Edelsohn ---
I don't know if this is a BE issue or a struct issue. AIX doesn't pass
characters in structs normally.
Is there any other debugging output from the GFORTRAN other than parse?
-fdump-lang-all doesn't see
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 assum
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 ARRAY-OUTER-DEP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #26 from anlauf at gcc dot gnu.org ---
(In reply to David Edelsohn from comment #25)
> The problem on big endian systems is that GFortran is passing the character
> with the wrong padding.
[...]
> GFortran is not taking account of end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #24 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:8736d6b14a4dfdfb58c80ccd398981b0fb5d00aa
commit r14-2171-g8736d6b14a4dfdfb58c80ccd398981b0fb5d00aa
Author: Harald Anlauf
Date:
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 f
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&action=edit
Slighty revised version of 3rd patch
I've looked at gfc_conv_string_parameter, which I was not awa
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?
This
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&action=edit
Third patch set
Here's a lightly tested 3rd patch that tries to handle the chaos I created...
Can
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 aroun
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.
Back
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 f
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 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #13 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:3f97d10aa1ff5984d6fd657f246d3f251b254ff1
commit r14-2064-g3f97d10aa1ff5984d6fd657f246d3f251b254ff1
Author: Harald Anlauf
Date:
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
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&action=edit
Patch to truncate string argument longer than 1
This truncates the string to length 1 and appears
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 th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #9 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:d130ae8499e0c615e1636258d6901372316dfd93
commit r14-2050-gd130ae8499e0c615e1636258d6901372316dfd93
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #8 from Mikael Morin ---
(In reply to anlauf from comment #6)
> (In reply to Mikael Morin from comment #4)
>
> > Looks good.
> > I would suggest to create an overload that avoids duplicating the
> > build_int_cst (integer_type_node,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #7 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-June/059503.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #4)
> (In reply to anlauf from comment #0)
> > but the second line contains junk, as the tree-dump shows:
> >
> > static void val (character(kind=1)[1:1],
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #5 from Mikael Morin ---
This is out of the scope of this PR, but in the [character, value, bind(c)]
case, only constant values and variables are supported?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Attachment #55380|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #2 from anlauf at gcc dot gnu.org ---
For reference: testcase, cross-checked with NAG 7.1:
! { dg-do run }
! PR fortran/110360
program p
implicit none
character, allocatable :: ca
character, pointer :: cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #1 from anlauf at gcc dot gnu.org ---
Created attachment 55380
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55380&action=edit
Patch
The attached patch fixes up the case of non-constant string expressions passed
to CHARACTER,V
45 matches
Mail list logo
