https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106065
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
Jerry DeLisle changed:
What|Removed |Added
Attachment #52981|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106065
--- Comment #2 from Jerry DeLisle ---
I was a bit curious to see what flang would do with the test case. It gives
the exact same error message as gfortran, word for word.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #26 from Jerry DeLisle ---
I will be comitting it to trunk which is rev 13 if approved. John, I was not
expecting you to do anything. Since all my time on this is unpaid volunteer
work, I get to it when I have time.
I am not sure w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #9 from Jerry DeLisle ---
Created attachment 57365
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57365&action=edit
Preliminary patch
The attached patch fixes the stream I/O related tabbing. This regression tests
fine. There
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #10 from Jerry DeLisle ---
To clarify. The following is the remaining issue that is not related to stream
I/O:
> program tabs
> implicit none
> integer :: fd
> open(newunit=fd, file="test.txt", form="formatted")
> write(fd,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #11 from Jerry DeLisle ---
I am going to submit the attached patch to close this PR and open a new PR for
the lingering multiple tab edits in a row. The problem there is we have a
special case if we have different T, TL, and TR follo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #36 from Jerry DeLisle ---
I was looking for my damnit doll until I got to your last post. Is this one
worthy of backport?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836
Bug 85836 depends on bug 111022, which changed state.
Bug 111022 Summary: ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897
Bug ID: 113897
Summary: Consecutive tab edits in format are not processed
correctly.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210
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=99210
--- Comment #6 from Jerry DeLisle ---
I have reapplied the patch in comment #3 and it regression tests fine and
appears to fix the issue. I have need to work up the test case and submit this
for approval.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210
--- Comment #7 from Jerry DeLisle ---
Submitted for approval.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847
--- Comment #6 from Jerry DeLisle ---
I obviously did not get to this last May. Will try now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847
--- Comment #7 from Jerry DeLisle ---
Steve, I am getting a boatload of regressions on this. I wonder if something
in the sym structure needs to be guarded here. They appear to be segfaults. Can
you take a look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847
--- Comment #8 from Jerry DeLisle ---
There is an assert just above the patch that implies that sym can be NULL if c
is not. With gdb I checked, and sure enough thats the failure point. I am
testing with sym included in the condition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847
--- Comment #9 from Jerry DeLisle ---
This seems to work:
/* Build the namelist object name. */
-
- string = gfc_build_cstring_const (var_name);
+ if (sym && !sym->attr.use_only && sym->attr.use_rename)
+string = gfc_build_cstring_con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847
--- Comment #11 from Jerry DeLisle ---
Having done all this, I found:
C8102 (R868) The namelist-group-name shall not be a name accessed by use
association.
What does this mean in the context of renamed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
--- Comment #8 from Jerry DeLisle ---
After a bit of sleuthing it turns out that the '(' in the name was being
ignored and the comma in '(1,2)' was being treated as a delimiter. Since the
following '=' was not seen yet, the 2 was seen as a repe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282
--- Comment #5 from Jerry DeLisle ---
With -std=f95 we get:
$ gfc -std=f95 pr83282.f90
pr83282.f90:1:13:
1 |write(*,'(aa)') "ab", "bc"
| 1
Error: GNU Extension: Missing comma at (1)
pr83282.f90:2:17:
2 |write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282
--- Comment #6 from Jerry DeLisle ---
$ gfc -Wall -Werror -pedantic pr83282.f90
pr83282.f90:1:4:
1 |write(*,'(aa)') "ab", "bc"
|1
Error: Unclassifiable statement at (1)
This is not very useful either. :o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #16 from Jerry DeLisle ---
I think I was not being very clear when I opened pr113897. nX descriptors are
very similar to TR code and I meeantt to take care of those in the 113897. The
reason for the separate PR is that the problem i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456
--- Comment #4 from Jerry DeLisle ---
Created attachment 57504
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57504&action=edit
Proposed partial patch
Proposed patch for the original test case with a READ function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499
--- Comment #6 from Jerry DeLisle ---
This is an interesting puzzle. I took the -fdump-tree-original output of
compiling the test case and edited out all except the initialization of the two
variables char1 and char2.
I lined these up so we coul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499
--- Comment #7 from Jerry DeLisle ---
There two issues going on here. We do not interpret source code that is UTF-8
encoded. This is why in our current tests for UTF-8 encoding of data files we
us hexidecimal codes.
I will have to see what the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
--- Comment #2 from Jerry DeLisle ---
It looks like the 'selector' in this case is an expr.
The expr must be a pointer object or a 'designator'
A designator must be:
R901
designator
object-name
array-element
array-section
coindexed-named-obj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
--- Comment #9 from Jerry DeLisle ---
--- snip ---
> % gfcx -o z a.f90
> a.f90:5:6:
>
> 5 | x%im = 42
> | 1
> Error: 'x' at (1) associated to expression cannot be used in
> a variable definition context (assignment)
>
> Mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93550
--- Comment #4 from Jerry DeLisle ---
The LEADING_ZERO specifiers are now included in the 2023 standard, so away we
go! In support of lazy programmers lets make the compiler do it. ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727
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=106295
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109105
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |NEW
Assignee|unassigned at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #13 from Jerry DeLisle ---
Any luck getting a reduced case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #29 from Jerry DeLisle ---
Backported to 13 and closing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #31 from Jerry DeLisle ---
(In reply to john.harper from comment #30)
> Thank you!
>
I encourage folks to move to gcc/gfortran 13. However, if you need it on 12, I
can do so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727
--- Comment #5 from Jerry DeLisle ---
I have been studying this a bit by looking at the 2023 std and functionality of
printf().
Specifically printf() provides the 'A' descriptor which can be used for float
(kind=4) and double (kind=8). It will a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727
--- Comment #7 from Jerry DeLisle ---
(In reply to Thomas Henlich from comment #6)
--- snip ---
> Just some thoughts:
>
> Have you tried "%LA" for long double?
>
> Have you tried quadmath_snprintf
> (https://gcc.gnu.org/onlinedocs/libquadmath/q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
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=114304
--- Comment #9 from Jerry DeLisle ---
Patch on comment #8 breaks all sorts of things. Not so obvious. I will try
reverting the original hunk from pr105473 and then work from there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #11 from Jerry DeLisle ---
Created attachment 57676
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57676&action=edit
Proposed patch
This patch fixes the issue by reverting the troublesome hunk and regression
tests OK on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #33 from Jerry DeLisle ---
(In reply to Tobias Burnus from comment #32)
> See PR114304 for an issue that was caused by the fix in comment 27.
Reverted portion of offending commit to fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 105456, which changed state.
Bug 105456 Summary: Child I/O does not propage iostat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
Bug 105361 depends on bug 105456, which changed state.
Bug 105456 Summary: Child I/O does not propage iostat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #15 from Jerry DeLisle ---
(In reply to Tobias Burnus from comment #14)
--- snip ---
> The question is whether the following show give an error as shown above:
> real :: x(3)
> character(len=1) :: s
> ...
> write(99, '(a)') '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114023
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #17 from Jerry DeLisle ---
(In reply to Jeffrey A. Law from comment #16)
> Per c#12, c#13, c#14 & c#15, dropping the regression marker, but leaving
> open.
Interestingly, the remaining part of this bug is also a regression, it just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #20 from Jerry DeLisle ---
Some additional information from the 2023 standard.
13.10.3.1List-directed input forms
8 If the next effective item is default, ASCII, or ISO 10646 character and
• the character sequence does not cont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #21 from Jerry DeLisle ---
The following may be a helpful read.
https://www.ibm.com/docs/en/openxl-fortran-aix/17.1.2?topic=formatting-value-separators
I am auditing our list_read.c code for the various types. The NULL read plays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103715
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80012
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106295
--- Comment #7 from Jerry DeLisle ---
I don't think that is a bad idea. I realize that this comes up often enough to
consider some solution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |NEW
Assignee|unassigned at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031
--- Comment #9 from Jerry DeLisle ---
The following trivial patch changes gfortran behavior and regression tests Ok
on x86_64.
I will see if I can come up with a test case to catch this.
diff --git a/libgfortran/io/file_pos.c b/libgfortran/io/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #36 from Jerry DeLisle ---
Created attachment 57854
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57854&action=edit
Modified extended test case
I modified the extended test case so I could review this and summarize.
Currently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #37 from Jerry DeLisle ---
Created attachment 57855
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57855&action=edit
Preliminary patch to address some incorrect behavior
This attached patch, gives some better results for the t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397
--- Comment #15 from Jerry DeLisle ---
Working this now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456
Jerry DeLisle changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
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=111022
--- Comment #4 from Jerry DeLisle ---
The relative text in the standard is:
13.7.2.1 General rules
--- snip ---
(6) On output, with I, B, O, Z, D, E, EN, ES, EX, F, and G editing, the
specified value of the field width w may be zero. In such ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #6 from Jerry DeLisle ---
(In reply to john.harper from comment #5)
Thanks John, I had a moment to look at this. I know where to do the
implementation but I have not decided how yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #7 from Jerry DeLi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #9 from Jerry DeLisle ---
I am using this:
program teste0es0en0
integer,parameter::p1 = kind(1e0), p2 = kind(1d0), &
p3 = selected_real_kind(precision(1.0_p2)+1), &
hp = selected_real_kind(precision(1.0_p3)+1), &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #12 from Jerry DeLisle ---
(In reply to john.harper from comment #11)
I have the error check commented out during some of my checking on things. I
will revise the test case to test for the correct error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #16 from Jerry DeLisle ---
(In reply to john.harper from comment #15)
> My previous test program tried Ex0.0E0 output but not Ex0.0, where x is
> N,S, or absent. Below is a revised version which includes all 6 cases.
> It also trie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #17 from Jerry DeLisle ---
Preliminary patch:
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 5d47a6d25f7..aafbd96b65a 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1784,8 +1784,6 @@ write_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #18 from Jerry DeLisle ---
With Johns test case from Comment #15 and the patch in Comment #17 I get the
following:
$ ./a.out
real kinds 4 8 10 16
With (A,1X,EN0.0 ) 666.
With (A,1X,EN0.0 ) 666.
With (A,1X,EN0.0 ) 666.
With (A,1X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #21 from Jerry DeLisle ---
(In reply to john.harper from comment #20)
> With the first test case all the EN outputs were 666. but the Fortran 2018
> standard 13.7.2.3.4 paragraph 2 requires that EN0.0 produce 666.E+0 but
> Table 13.
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
Jerry DeLisle changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #14 from Jerry DeLi
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=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=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=105361
Jerry DeLisle changed:
What|Removed |Added
Attachment #58715|0 |1
is obsolete|
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=104626
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116221
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
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=105361
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #18 from Jerry DeL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116468
Jerry DeLisle changed:
What|Removed |Added
Last reconfirmed||2024-08-23
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109467
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
Ever c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109105
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
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=108369
--- Comment #18 from Jerry DeLisle ---
(In reply to anlauf from comment #17)
> (In reply to Jerry DeLisle from comment #16)
> > Works using the correct compiler option. We probably should get rid of or
> > change the -x option or document it.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109186
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
101 - 200 of 538 matches
Mail list logo
