On 1/3/18 11:43 AM, Janne Blomqvist wrote:
On Wed, Jan 3, 2018 at 8:34 PM, Bob Deen wrote:
On 12/29/17 5:31 AM, Janne Blomqvist wrote:
In order to handle large character lengths on (L)LP64 targets, switch
the GFortran character length from an int to a size_t.
This is an ABI change, as proced
On Thu, Jan 4, 2018 at 4:21 AM, Jerry DeLisle wrote:
> On 01/03/2018 03:37 AM, Janne Blomqvist wrote:
>> On Sat, Dec 30, 2017 at 10:58 PM, Jerry DeLisle
>> wrote:
>>> On 12/30/2017 12:35 PM, Janne Blomqvist wrote:
On Sat, Dec 30, 2017 at 7:16 PM, Thomas Koenig
wrote:
>>> ---snip---
>
On 01/03/2018 03:37 AM, Janne Blomqvist wrote:
> On Sat, Dec 30, 2017 at 10:58 PM, Jerry DeLisle wrote:
>> On 12/30/2017 12:35 PM, Janne Blomqvist wrote:
>>> On Sat, Dec 30, 2017 at 7:16 PM, Thomas Koenig
>>> wrote:
>> ---snip---
>>>
>>> I can provide that stuff as a separate patch, or merge it
On Wed, Jan 3, 2018 at 8:34 PM, Bob Deen wrote:
> On 12/29/17 5:31 AM, Janne Blomqvist wrote:
>>
>> In order to handle large character lengths on (L)LP64 targets, switch
>> the GFortran character length from an int to a size_t.
>>
>> This is an ABI change, as procedures with character arguments ta
On 12/29/17 5:31 AM, Janne Blomqvist wrote:
In order to handle large character lengths on (L)LP64 targets, switch
the GFortran character length from an int to a size_t.
This is an ABI change, as procedures with character arguments take
hidden arguments with the character length.
Did this chang
On Wed, Jan 3, 2018 at 2:10 PM, Thomas Koenig wrote:
> Hi Janne,
>
>> attached is a patch that makes the two attached testcases work. It
>> applies on top of the charlen->size_t patch. In the formatted I/O
>> stuff, I have mostly used ptrdiff_t to avoid having to deal with
>> signed/unsigned issue
Hi Janne,
attached is a patch that makes the two attached testcases work. It
applies on top of the charlen->size_t patch. In the formatted I/O
stuff, I have mostly used ptrdiff_t to avoid having to deal with
signed/unsigned issues, as the previous code was using int.
Did you regression-test?
On Sat, Dec 30, 2017 at 10:58 PM, Jerry DeLisle wrote:
> On 12/30/2017 12:35 PM, Janne Blomqvist wrote:
>> On Sat, Dec 30, 2017 at 7:16 PM, Thomas Koenig wrote:
> ---snip---
>>
>> I can provide that stuff as a separate patch, or merge it into the
>> original megapatch and resubmit that, whichever
Hi Janne,
FWIW, by changing your example to use unformatted I/O, it works
correctly.
Not for me (again, on gcc110):
program main
character(len=2_8**33), parameter :: a = ""
write (10) a
end program main
with strace results in
open("fort.10", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = 3
fstat(3,
On 12/30/2017 12:35 PM, Janne Blomqvist wrote:
> On Sat, Dec 30, 2017 at 7:16 PM, Thomas Koenig wrote:
---snip---
>
> I can provide that stuff as a separate patch, or merge it into the
> original megapatch and resubmit that, whichever way you prefer.
I would prefer we split into two patches. Thi
On Sat, Dec 30, 2017 at 7:16 PM, Thomas Koenig wrote:
> Hi Janne,
>
>> To be honest, I haven't really done much testing with big strings, so
>> far my focus has been on getting the existing testsuite to pass and
>> getting the ABI right.
>
>
> I agree that some of the test cases can be fixed later
Hi Janne,
To be honest, I haven't really done much testing with big strings, so
far my focus has been on getting the existing testsuite to pass and
getting the ABI right.
I agree that some of the test cases can be fixed later. However, I
would really prefer if the I/O worked, because that is v
On Sat, Dec 30, 2017 at 4:59 PM, Thomas Koenig wrote:
> That's all I could find for the moment. I will continue looking.
> Thanks for tackling this!
Thanks for testing!
To be honest, I haven't really done much testing with big strings, so
far my focus has been on getting the existing testsuite t
Hi Janne,
In order to handle large character lengths on (L)LP64 targets, switch
the GFortran character length from an int to a size_t.
Just running some tests on gcc110 (the big-endian PPC machine from
the compile farm).
Something does not seem to work with I/O with long strings.
With
progr
On 01/14/2017 12:46 AM, Janne Blomqvist wrote:
> On Sat, Jan 14, 2017 at 1:13 AM, Jerry DeLisle wrote:
>> On 01/13/2017 11:46 AM, David Edelsohn wrote:
>>> On Fri, Jan 13, 2017 at 12:09 PM, Janne Blomqvist
>>> wrote:
On Thu, Jan 12, 2017 at 10:46 AM, FX wrote:
>> I was finally able to g
On Sat, Jan 14, 2017 at 10:46 AM, Janne Blomqvist
wrote:
> On Sat, Jan 14, 2017 at 1:13 AM, Jerry DeLisle wrote:
>> On 01/13/2017 11:46 AM, David Edelsohn wrote:
>>> On Fri, Jan 13, 2017 at 12:09 PM, Janne Blomqvist
>>> wrote:
On Thu, Jan 12, 2017 at 10:46 AM, FX wrote:
>> I was finall
> The following patch fixes these issues for me, does it work for you?
Yes, it does!
Dominique
> Janne Blomqvist
On Sat, Jan 14, 2017 at 1:13 AM, Jerry DeLisle wrote:
> On 01/13/2017 11:46 AM, David Edelsohn wrote:
>> On Fri, Jan 13, 2017 at 12:09 PM, Janne Blomqvist
>> wrote:
>>> On Thu, Jan 12, 2017 at 10:46 AM, FX wrote:
> I was finally able to get a 32-bit i686 compiler going (my attempts to
>
On Sun, Jan 8, 2017 at 4:29 PM, Dominique d'Humières wrote:
>> r244027 reverts r244011. Sorry for the breakage. It seems to affect
>> all i686 as well in addition to power, maybe all 32-bit hosts.
>
> For the record, I see the following failures with an instrumented r244026 (as
> in pr78672)
>
>
On 01/13/2017 11:46 AM, David Edelsohn wrote:
> On Fri, Jan 13, 2017 at 12:09 PM, Janne Blomqvist
> wrote:
>> On Thu, Jan 12, 2017 at 10:46 AM, FX wrote:
I was finally able to get a 32-bit i686 compiler going (my attempts to
do this on a x86_64-pc-linux-gnu host failed, in the end I res
On Fri, Jan 13, 2017 at 12:09 PM, Janne Blomqvist
wrote:
> On Thu, Jan 12, 2017 at 10:46 AM, FX wrote:
>>> I was finally able to get a 32-bit i686 compiler going (my attempts to
>>> do this on a x86_64-pc-linux-gnu host failed, in the end I resorted to
>>> running 32-bit builds/tests on a i686 co
On Thu, Jan 12, 2017 at 10:46 AM, FX wrote:
>> I was finally able to get a 32-bit i686 compiler going (my attempts to
>> do this on a x86_64-pc-linux-gnu host failed, in the end I resorted to
>> running 32-bit builds/tests on a i686 container). At least on i686,
>> the patch below on top of the bi
> I was finally able to get a 32-bit i686 compiler going (my attempts to
> do this on a x86_64-pc-linux-gnu host failed, in the end I resorted to
> running 32-bit builds/tests on a i686 container). At least on i686,
> the patch below on top of the big charlen->size_t patch fixes the
> failures
Pat
On Sun, Jan 8, 2017 at 4:29 PM, Dominique d'Humières wrote:
>> r244027 reverts r244011. Sorry for the breakage. It seems to affect
>> all i686 as well in addition to power, maybe all 32-bit hosts.
>
> For the record, I see the following failures with an instrumented r244026 (as
> in pr78672)
[sn
> r244027 reverts r244011. Sorry for the breakage. It seems to affect
> all i686 as well in addition to power, maybe all 32-bit hosts.
For the record, I see the following failures with an instrumented r244026 (as
in pr78672)
FAIL: gfortran.dg/char_length_20.f90 -O* execution test
FAIL: gfortr
On Tue, Jan 3, 2017 at 9:21 PM, FX wrote:
>> r244027 reverts r244011. Sorry for the breakage. It seems to affect
>> all i686 as well in addition to power, maybe all 32-bit hosts.
>
> The breakage is surprising, as the rejects-valid does not involve character
> length at all.
> Jane, any chance yo
> r244027 reverts r244011. Sorry for the breakage. It seems to affect
> all i686 as well in addition to power, maybe all 32-bit hosts.
The breakage is surprising, as the rejects-valid does not involve character
length at all.
Jane, any chance you might have accidentally committed some unrelated c
On Tue, Jan 3, 2017 at 4:07 PM, David Edelsohn wrote:
> This patch broke bootstrap. I now am seeing numerous errors when
> building libgomp.
>
> Please fix or revert immediately.
r244027 reverts r244011. Sorry for the breakage. It seems to affect
all i686 as well in addition to power, maybe all
This patch broke bootstrap. I now am seeing numerous errors when
building libgomp.
Please fix or revert immediately.
Thanks, David
omp_lib.f90:184:40:
logical (4) :: omp_test_lock
1
Error: Symbol 'omp_test_lock' at (1) has already been host
On Tue, 20 Dec 2016, FX wrote:
> Finally, if we’re making this change, we welcome any feedback on how
> to make it as easy as possible to handle in user code. Documentation,
> preprocessor macros, etc.
I believe including this in the (yet to be created) gcc-7/porting_to.html,
would be great.
Hi
Hi Janne, hi FX,
On Tue, 27 Dec 2016 12:56:19 +0200
Janne Blomqvist wrote:
> >> I also changed the _size member in vtables from int to size_t, as
> >> there were some cases where character lengths and sizes were
> >> apparently mixed up and caused regressions otherwise. Although I
I can confirm
> The _size member is the size of the object; for polymorphic objects
> the size isn't known at compile time, so it is to be stored in the
> vtable (in principle, since the vtable tells the exact class of a
> polymorphic object, it should be possible to figure out the size
> without an explicit _si
On Tue, Dec 27, 2016 at 12:47 PM, Andre Vehreschild wrote:
> Hi Janne,
>
> sorry for being late in voicing my opinion, but I personally would prefer to
> have this patch in a separately. That way bisecting for performance
> regressions points only to the offending code and not to the change of the
On Mon, Dec 26, 2016 at 12:32 PM, FX wrote:
> Hi Janne,
>
> Thanks for the patch, it is hard and tedious work. Here is the formal review.
> I don’t want to be a pain, but I have several questions about the patch, and
> given its size and the importance I think we should be double-sure :)
Thanks
Hi Janne,
sorry for being late in voicing my opinion, but I personally would prefer to
have this patch in a separately. That way bisecting for performance
regressions points only to the offending code and not to the change of the
character length (the latter might add a tiny bit of cost, too).
Re
Hi Janne,
Thanks for the patch, it is hard and tedious work. Here is the formal review. I
don’t want to be a pain, but I have several questions about the patch, and
given its size and the importance I think we should be double-sure :)
> I also changed the _size member in vtables from int to si
On Wed, Dec 21, 2016 at 3:14 PM, Andre Vehreschild wrote:
>> Now when I think about this some more, I have a vague recollection
>> that a long time ago it used to be something like that. The problem
>> is that MIN_EXPR will of course be
>> NON-CONSTANT, so the memcpy call can't be inlined. Hence
> Now when I think about this some more, I have a vague recollection
> that a long time ago it used to be something like that. The problem
> is that MIN_EXPR will of course be
> NON-CONSTANT, so the memcpy call can't be inlined. Hence it was
> changed to two separate __builtin_memmove() calls to h
On Wed, Dec 21, 2016 at 1:50 PM, Andre Vehreschild wrote:
>> Here p is the character variable, and _p is the charlen. My guess is
>> that the problem is that with -O1 it sees that the second memmove
>> would overflow p, but it doesn't realize that branch is never taken.
>> Cranking up the optimiza
> Here p is the character variable, and _p is the charlen. My guess is
> that the problem is that with -O1 it sees that the second memmove
> would overflow p, but it doesn't realize that branch is never taken.
> Cranking up the optimization level to -O2 and beyond makes it realize
> it, and thus th
On Wed, Dec 21, 2016 at 12:33 PM, Andre Vehreschild wrote:
> Hi Janne,
>
>> But yes, I'm still seeing the warning messages with -O1 for
>> allocate_deferred_char_scalar_1.f03. AFAICT it's a bogus warning, but
>> I don't know how to get rid of it..
>
> No, that warning isn't at all bogus. The warni
Hi Janne,
> But yes, I'm still seeing the warning messages with -O1 for
> allocate_deferred_char_scalar_1.f03. AFAICT it's a bogus warning, but
> I don't know how to get rid of it..
No, that warning isn't at all bogus. The warning in fact is astonishingly
precise. When I remember correctly, then
On Wed, Dec 21, 2016 at 12:05 PM, Andre Vehreschild wrote:
> Hi all,
>
> so I have learned that proposing to write "speaking code" is not very well
> taken.
If you want to make a patch introducing gfc_size_t_zero_node, go
ahead, at least I won't object. I don't think
build_zero_cst(size_type_nod
Hi all,
so I have learned that proposing to write "speaking code" is not very well
taken.
Anyway, there is a patch (in two parts) hanging about changing the character
length from int to size_t. It looks ok to me, but I do not have the privilege
to ok it. Furthermore am I still not convinced that
On Tue, Dec 20, 2016 at 05:04:54PM +0100, Andre Vehreschild wrote:
> Well, then how about:
>
> #define gfc_size_t_zero_node build_int_cst (size_type_node, 0)
>
> We can't get any faster and for new and old gfortran-hackers one identifier's
> meaning is faster to grasp than two's.
Such macros can
On Tue, 20 Dec 2016 16:40:13 +0100
Jakub Jelinek wrote:
> On Tue, Dec 20, 2016 at 04:29:07PM +0100, Andre Vehreschild wrote:
> > > The first one is GCC internal type for representing sizes, the latter is
> > > the C size_t (usually they have the same precision, they always have the
> > > same s
On Tue, Dec 20, 2016 at 04:29:07PM +0100, Andre Vehreschild wrote:
> > The first one is GCC internal type for representing sizes, the latter is
> > the C size_t (usually they have the same precision, they always have the
> > same signedness (unsigned)).
> > In the past sizetype actually has been a
On Tue, 20 Dec 2016 16:00:19 +0100
Jakub Jelinek wrote:
> On Tue, Dec 20, 2016 at 04:55:29PM +0200, Janne Blomqvist wrote:
> > On Tue, Dec 20, 2016 at 3:42 PM, Andre Vehreschild wrote:
> > > Hi all,
> > >
> > >> I think you should use build_zero_cst(size_type_node) instead of
> > >> size_z
On Tue, Dec 20, 2016 at 04:55:29PM +0200, Janne Blomqvist wrote:
> On Tue, Dec 20, 2016 at 3:42 PM, Andre Vehreschild wrote:
> > Hi all,
> >
> >> I think you should use build_zero_cst(size_type_node) instead of
> >> size_zero_node as size_zero_node is of type sizetype which is not the
> >> same as
On Tue, Dec 20, 2016 at 3:42 PM, Andre Vehreschild wrote:
> Hi all,
>
>> I think you should use build_zero_cst(size_type_node) instead of
>> size_zero_node as size_zero_node is of type sizetype which is not the
>> same as size_type_node. Otherwise looks good.
>
> In the software design classes I t
Hi all,
> I think you should use build_zero_cst(size_type_node) instead of
> size_zero_node as size_zero_node is of type sizetype which is not the
> same as size_type_node. Otherwise looks good.
In the software design classes I took this was called a design error: Not
choosing sufficiently differ
Dear Bob,
First, regarding the ABI vs. API question: there is no consistent API for how
to pass between Fortran and C strings, unless one uses Fortran 2003’s
ISO_C_BINDING. It’s an ABI detail, in the sense that every compiler will choose
to do things their own way: most compilers who pass a hid
On 12/19/16 11:33 AM, Janne Blomqvist wrote:
On Mon, Dec 19, 2016 at 6:43 PM, Bob Deen wrote:
Hi all...
I never saw any followup on this...?
It's one thing to break the ABI between the compiler and the gfortran
library; those can generally be expected to be in sync. It's another to
break the
On Mon, Dec 19, 2016 at 6:43 PM, Bob Deen wrote:
> Hi all...
>
> I never saw any followup on this...?
>
> It's one thing to break the ABI between the compiler and the gfortran
> library; those can generally be expected to be in sync. It's another to
> break the ABI between two *languages*, when t
On Mon, Dec 19, 2016 at 08:43:01AM -0800, Bob Deen wrote:
>
> It's one thing to break the ABI between the compiler and the gfortran
> library; those can generally be expected to be in sync. It's another to
> break the ABI between two *languages*, when there might be no such
> expectation (espe
Hi all...
I never saw any followup on this...?
It's one thing to break the ABI between the compiler and the gfortran
library; those can generally be expected to be in sync. It's another to
break the ABI between two *languages*, when there might be no such
expectation (especially if gcc does
> Le 16 déc. 2016 à 19:06, Janne Blomqvist a écrit :
>
> On Fri, Dec 16, 2016 at 5:50 PM, Dominique d'Humières
> wrote:
>> Hi Janne,
>>
>> I have applied your two patches and found that I had to skip the patches for
>> resolve.c and match.c due to the errors
>>
>> ../../p_work/gcc/fortran/re
On Fri, Dec 16, 2016 at 5:50 PM, Dominique d'Humières
wrote:
> Hi Janne,
>
> I have applied your two patches and found that I had to skip the patches for
> resolve.c and match.c due to the errors
>
> ../../p_work/gcc/fortran/resolve.c: In function 'void
> resolve_select_type(gfc_code*, gfc_names
On Fri, Dec 16, 2016 at 5:34 PM, Andre Vehreschild wrote:
> Hi Janne, hi all,
>
> as promised please find attached the change from int32 to size_t for the
> caf-libraries. Because the caf-libraries do not require special notions
> indicated by negative values I went for using size_t there. I assum
Hi Janne,
I have applied your two patches and found that I had to skip the patches for
resolve.c and match.c due to the errors
../../p_work/gcc/fortran/resolve.c: In function 'void
resolve_select_type(gfc_code*, gfc_namespace*)':
../../p_work/gcc/fortran/resolve.c:8731:58: error: format '%lld'
Hi Janne, hi all,
as promised please find attached the change from int32 to size_t for the
caf-libraries. Because the caf-libraries do not require special notions
indicated by negative values I went for using size_t there. I assume this will
be easier to keep in sync for all caf-libraries, because
On Mon, Dec 12, 2016 at 9:39 PM, Janne Blomqvist
wrote:
> On Mon, Dec 12, 2016 at 7:39 PM, Andre Vehreschild wrote:
>> Hi Janne,
>>
>> I found that you are favoring build_int_cst (size_type_node, 0) over
>> size_zero_node. Is there a reason to this?
>
> Yes. AFAIU size_zero_node is a zero constan
Hi Janne,
How about adding charlen_zero_node and one_node like the others have it to
prevent repeating ourselves?
- Andre
Am 12. Dezember 2016 20:39:38 MEZ, schrieb Janne Blomqvist
:
>On Mon, Dec 12, 2016 at 7:39 PM, Andre Vehreschild
>wrote:
>> Hi Janne,
>>
>> I found that you are favoring b
On Mon, Dec 12, 2016 at 7:39 PM, Andre Vehreschild wrote:
> Hi Janne,
>
> I found that you are favoring build_int_cst (size_type_node, 0) over
> size_zero_node. Is there a reason to this?
Yes. AFAIU size_zero_node is a zero constant for sizetype which is not
the same as size_type_node.
AFAIK the
> However, this will also affect people doing C->Fortran calls the
> old-fashioned way without ISO_C_BINDING, as they will have to change
> the string length argument from int to size_t in their prototypes.
> Then again, Intel Fortran did this some years ago so I guess at least
> people who care a
Hi Janne,
I found that you are favoring build_int_cst (size_type_node, 0) over
size_zero_node. Is there a reason to this?
Furthermore did I have to patch this:
diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index 585f25d..f374558 100644
--- a/gcc/fortran/dump-parse-tr
On Mon, Dec 12, 2016 at 3:35 PM, Janus Weil wrote:
> Hi guys,
>
>> there is already an ABI change. DTIO needed it.
>
> maybe it would be a good idea to document this in places like:
> * https://gcc.gnu.org/wiki/GFortran/News
> * https://gcc.gnu.org/gcc-7/changes.html
>
> On the first page there ar
Hi guys,
> there is already an ABI change. DTIO needed it.
maybe it would be a good idea to document this in places like:
* https://gcc.gnu.org/wiki/GFortran/News
* https://gcc.gnu.org/gcc-7/changes.html
On the first page there are "Compatibility notices" for several
earlier versions which menti
On Mon, Dec 12, 2016 at 12:29 PM, Andre Vehreschild wrote:
> I will take on the coarray ABI changes in the next days and also emit a
> pull-request to the opencoarrays to get them to sync. Janne, please wait until
> I have added those changes to prevent people from having to re-compile
> multiple
On Mon, Dec 12, 2016 at 12:20 PM, FX wrote:
> Hi Janne,
>
> This is an ABI change, so it is serious… it will require people to recompile
> older code and libraries with the new compiler. Do we already plan to break
> the ABI in this cycle, or is this the first ABI-breaking patch of the cycle?
A
Hi FX,
there is already an ABI change. DTIO needed it.
I will take on the coarray ABI changes in the next days and also emit a
pull-request to the opencoarrays to get them to sync. Janne, please wait until
I have added those changes to prevent people from having to re-compile multiple
times.
- A
Hi Janne,
This is an ABI change, so it is serious… it will require people to recompile
older code and libraries with the new compiler. Do we already plan to break the
ABI in this cycle, or is this the first ABI-breaking patch of the cycle? And do
we have real-life examples of character strings
72 matches
Mail list logo
