https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #10 from Jerry DeLisle ---
(In reply to Thomas Koenig from comment #9)
> Question is, what should we permit...
>
> For 'normal' operations, only unsigned op unsigned is permitted,
> so unsigned**unsigned is obviously ok.
>
> What a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118471
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118406
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118372
--- Comment #2 from Jerry DeLisle ---
Also appears to be OK on 14 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118372
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117798
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #28 from Jerry DeLisle ---
--- snip ---
> In iso-c-binding.def, one finds
>
> NAMED_CHARKNDCST (ISOCBINDING_CHAR, "c_char",gfc_default_character_kind)
>
> so kind('a') == kind(c_char_'a') on all targets.
This implies that is_c_in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #26 from Jerry DeLisle ---
Why not set it in gfc_resolve_expr near the top before any other actions?
also
Are there any systems where c_char is not equal to 1? If not then BT_CHARACTER
and KIND==1 is always C interoperable. ??
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #25 from Jerry DeLisle ---
I clearly see where my logic was incorrect. I do wonder if there is a resolve
string expr that would allow us to set the interop for all cases of kind=1
BT_CHARACTER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47928
--- Comment #5 from Jerry DeLisle ---
I was not thinking about rewriting the whole thing, but rearranging enmasse may
be helpful if you know how to do that. I think we need to hear from others
though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47928
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #19 from Jerry DeLisle ---
(In reply to kargls from comment #17)
> On 12/24/24 10:03, jvdelisle at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
> >
> > --- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
Jerry DeLisle changed:
What|Removed |Added
Attachment #59960|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #16 from Jerry DeLisle ---
Needed a minor tweak:
+ if (string->ts.type != BT_CHARACTER
+ || (string->ts.type == BT_CHARACTER
// && on the inner paren instead of ||
+ && (string->ts.kind != 1 && string->ts.is_c_interop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #15 from Jerry DeLisle ---
>From Harald's post. "There is another case I found while playing which is
rejected:
print *, f_c_string(c_char_"abc", asis)"
I bet the parsing does not handle c_char_ with the two underscores. I h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #13 from Jerry DeLisle ---
Created attachment 59960
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59960&action=edit
Cleaned up patch with Harald's addition.
This patch fixes some white space and merges in Haralds patch for op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #12 from Jerry DeLisle ---
The following additional patch from Harald posted on the gfortran list:
https://gcc.gnu.org/pipermail/fortran/2024-December/061452.html
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118159
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51820
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #11 from Jerry DeLisle ---
I get a clean sweep on x86_64_linux_gnu. I will try some jerry-code to see if I
can break it. If anyone else has comments, chime in. I think you submit to
the list Steve.
gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
CC||jvdelisle at gcc dot gnu.org
Last reconfirmed||2024-12-18
Ever confirmed|0 |1
--- Comment #9 from Jerry DeLisle ---
Patch applies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102689
--- Comment #10 from Jerry DeLisle ---
(In reply to Jerry DeLisle from comment #9)
--- snip ---
>
> The mention of binutils jogged my memory. I had a test failure that showed
> up randomly one time. It was related to class_transformational_2.f9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102689
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117819
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117820
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109105
--- Comment #10 from Jerry DeLisle ---
I found the back-port ready to go in my branch. Decided to push it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109105
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117819
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Jerry DeLi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117820
--- Comment #7 from Jerry DeLisle ---
The root of the problem here is that the function write_boz uses a type int to
pass in the value n, this value is then tested for zero which fails for a 64
bit integer.
The following hack makes it work but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117820
--- Comment #6 from Jerry DeLisle ---
With kind=4 we do treat the sign bit as part of the value.
program test
integer(4) :: x
x = -huge(x) - 1_4
print '("-huge -1 = <",B32.32,">")', x
print '("zero = <",B32.32,">")', 0_4
prin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117820
--- Comment #5 from Jerry DeLisle ---
Back to the Standard
>From the standard, the relevent text is: 13.7.2.4 B, O, and Z editing
---
The value of m shall not exceed the value of w, except when w is zero. If m is
zero and the internal value co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117820
--- Comment #4 from Jerry DeLisle ---
(In reply to anlauf from comment #3)
--- snip ---
> > The error at line 16 is not correct.
>
> Of course it is! But when you add _8 you get what you want.
>
> BTW: why does the integer(4) case not show th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117820
--- Comment #2 from Jerry DeLisle ---
>From the standard, the relevent text is: 13.7.2.4 B, O, and Z editing
---
The value of m shall not exceed the value of w, except when w is zero. If m is
zero and the internal value consists of all zero bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
Jerry DeLisle changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117820
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
Assignee: unassigned at gcc dot gnu.org
Reporter: jvdelisle at gcc dot gnu.org
Target Milestone: ---
This test case couttesy of Malcom Cohen shows a formatted write problem.
Program oops
Integer,Parameter :: i64 = Selected_Int_Kind(18)
Integer(i64) x
x = -Huge(x
: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jvdelisle at gcc dot gnu.org
Target Milestone: ---
The following test case courtesy Malcolm Cohen:
Program xe1
Implicit None
Character(6) string
Integer x
Logical :: ok = .True.
string = '11
|1
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
Last reconfirmed||2024-11-28
--- Comment #1 from Jerry DeLisle ---
I am investigating this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117791
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117791
--- Comment #2 from Jerry DeLisle ---
Oh I see 14.2.1, it is fixed on trunk, gfortran 15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117791
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
--- Comment #4 from Jerry DeLisle ---
In the test case dg-error there is a missing space at the end of the quote
before the brace } Fixing and tested here. It fixes one test failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
--- Comment #3 from Jerry DeLisle ---
(In reply to Jerry DeLisle from comment #2)
> In the test case dg-error there is a missing space at the end of the before
> the brace } Fixing and tested here. It fixes one test failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
--- Comment #2 from Jerry DeLisle ---
In the test case dg-error there is a missing space at the end of the before the
brace } Fixing and tested here. It fixes one test failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88190
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117730
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84674
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106507
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #18 from Jerry DeLisle ---
(In reply to Bálint Aradi from comment #17)
> Checked with gfortran 14.1, the file created is the same as with the other
> compilers (and which is the standard conforming behavior IMO). Issue can be
> close
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
--- Comment #6 from Jerry DeLisle ---
Info:
-ftrampoline-impl=[stack|heap]
By default, trampolines are generated on stack. However, certain platforms
(such as the Apple M1) do not permit an executable stack. Compiling with
-ftrampoline-imp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
--- Comment #2 from Jerry DeLisle ---
I am using:
$ ld --version
GNU ld version 2.41-37.fc40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #13 from Jerry DeLisle ---
(In reply to kargls from comment #12)
--- snip ---
> > If you consider that the warning should be treated as significant, then
> > there's an alternate implementation for the trampoline which places the
> >
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jvdelisle at gcc dot gnu.org
Target Milestone: ---
When compiling the test case from PR117434 here:
module julienne_test_description_m
implicit none
abstract interface
logical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #21 from Jerry DeLisle ---
(In reply to Richard Biener from comment #20)
--- snip ---
>
> so you can instead do
>
> gfc_symbol_buffer the_buf;
>
> and have it behave like a char the_buf[GFC_MAX_SYMBOL_LEN] declaration.
>
> The au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
Jerry DeLisle changed:
What|Removed |Added
Severity|normal |enhancement
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #14 from Jerry DeLisle ---
(In reply to anlauf from comment #9)
--- snip ---
> So do we want a limit close to
>
> 6.3.2.6 ... A statement shall not have more than one million characters.
>
> ?
This ridiculous number seems to be t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032
--- Comment #15 from Jerry DeLisle ---
Created attachment 59515
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59515&action=edit
Example illustrating kicker
This simple patch adds a custom procedure to be run on a test case. I am using
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032
--- Comment #13 from Jerry DeLisle ---
(In reply to Jonathan Wakely from comment #11)
> It needs to be on a line on its own, and start with dg-
>
> So:
>
> ! { dg-gfortran-onepass }
>
> And rename the proc to match.
Did this:
! { dg-do run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032
Jerry DeLisle changed:
What|Removed |Added
CC||jwakely.gcc at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032
--- Comment #9 from Jerry DeLisle ---
Created attachment 59395
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59395&action=edit
Patch to clean-up dg-do run directives.
This patch cleans up the dg-do run options and adds in a -O option for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #8 from Jerry DeLis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 105361, which changed state.
Bug 105361 Summary: Incorrect end-of-file condition for derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116025
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116040
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109467
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
Ever
||jvdelisle at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Jerry DeLisle ---
Confirmed on latest trunk.
$ gfc -g pr116468.f90
$ ./a.out
Program received signal SIGSEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #18 from Jerry DeL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109105
--- Comment #5 from Jerry DeLisle ---
Created attachment 58853
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58853&action=edit
Proposed patch to clean this up.
Attached patch uses a simple helper macro, CHECK_INTERFACES, to avoid the use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116221
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104626
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104626
Jerry DeLisle changed:
What|Removed |Added
Attachment #58798|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
Jerry DeLisle changed:
What|Removed |Added
Attachment #58715|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104626
--- Comment #5 from Jerry DeLisle ---
(In reply to Jerry DeLisle from comment #4)
> Created attachment 58798 [details]
> Revised test case with careful precision and tolerance values.
>
> New suggested test case which passes on x86-64-linux.
O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104626
--- Comment #4 from Jerry DeLisle ---
Created attachment 58798
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58798&action=edit
Revised test case with careful precision and tolerance values.
New suggested test case which passes on x86-64-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
--- Comment #15 from Jerry DeLisle ---
One other possible flaw in the test is comparison of floating point values. I
will tidy up this part with some tolerance.and post a new version of the test
here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
Jerry DeLisle changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #14 from Jerry DeLi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116132
--- Comment #3 from Jerry DeLisle ---
(In reply to Richard Biener from comment #1)
> Confirmed also on x86-64-linux.
I have not been able to see this failure on my system. I pushed a change to the
test case and do noy know if this fixed it or n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
--- Comment #11 from Jerry DeLisle ---
(In reply to Thomas Schwinge from comment #9)
> In some of my test runs (have not yet been able to deduce any pattern), I'm
> seeing this new test case FAIL its execution test:
>
Can you try this minor ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 105361, which changed state.
Bug 105361 Summary: Incorrect end-of-file condition for derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #15 from Jerry DeLisle ---
(In reply to Matt Thompson from comment #14)
> Never mind. I'll send attachment to Jerry offline. It's too big for here.
Got it. It works quite well for our purposes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #11 from Jerry DeLisle ---
I am able to run your reproducer and I can see the increasing times as the
number of modules goes up. I am curious if you could randomize the subroutine
names? These appear fairly repetitive and I wonder if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #8 from Jerry DeLisle ---
Martin or Matt,
Can you test the following variation to see if you get better results.
return st;
}
retval = NULL;
if (c <= 0)
retval = find_symbol (st->left, name, module, generic);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
Jerry DeLisle changed:
What|Removed |Added
Last reconfirmed||2024-04-24
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
--- Comment #6 from Jerry DeLisle ---
Created attachment 57965
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57965&action=edit
Preliminary patch to fix several issues.
The attached patch is very preliminary and appears to fix the X forma
1 - 100 of 2168 matches
Mail list logo
