https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #32 from Jerry DeLisle ---
commit a1f0d227481fe143f8c15b3f268e2d5964a3c90a (HEAD -> master, origin/master,
origin/HEAD)
Author: Jerry DeLisle
Date: Fri Dec 15 13:05:18 2023 -0800
fortran: Update degree trigs documentation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #31 from Jerry DeLisle ---
(In reply to anlauf from comment #30)
> (In reply to Jerry DeLisle from comment #29)
> > Created attachment 56883 [details]
> > Updated Descriptions
> >
> > Fixed a few more things, The return value of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #29 from Jerry DeLisle ---
Created attachment 56883
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56883=edit
Updated Descriptions
Fixed a few more things, The return value of tand is not in degrees.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #27 from Jerry DeLisle ---
Created attachment 56882
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56882=edit
Description changes
This is what I arrived at going through. OK?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
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=112873
--- Comment #23 from Jerry DeLisle ---
I am going to suggest the following. The wording was confusing around the
functionality of the option vs the intrinsics. Hope this is OK?
@opindex @code{fdec-math}
@item -fdec-math
Obsolete flag. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #22 from Jerry DeLisle ---
(In reply to anlauf from comment #20)
> (In reply to Jerry DeLisle from comment #18)
> > I have the patch applied.
> >
> > make pdf and make info work as expected. I fixed a minor typo in a comment
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #18 from Jerry DeLisle ---
I have the patch applied.
make pdf and make info work as expected. I fixed a minor typo in a comment for
intrinsic.cc. I have a few of the git magics to do. Shall I submit to the list
before commit?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #16 from Jerry DeLisle ---
(In reply to Steve Kargl from comment #15)
--- snip ---
>
> Jerry, are you starting with the patch submitted by Harald that
> fixes the doc issue. It seems 'gmake pdf', which is what I use
> to check doc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #13 from Jerry DeLisle ---
(In reply to anlauf from comment #12)
> Jerry or myself can do the commit later.
>
> Looking at my addition again, I think that this change to invoke.texi:
>
> "... These functions are now GNU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #22 from Jerry DeLisle ---
Sorry for delays. I am back looking at this.
My take on the table 13.2 for the case: EN0.0E0
No matter what the E for the exponent must be shown.
If the exponent is 0 then a plus sign must be shown.
at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
CC||jvdelisle at gcc dot gnu.org
--- Comment #8 from Jerry DeLisle ---
Taking this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53962
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
||jvdelisle at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--- Comment #5 from Jerry DeLisle ---
assigning to myself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282
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=83829
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88052
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97017
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
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109105
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
||jvdelisle at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--- Comment #3 from Jerry DeLisle ---
I am going to add this to my list since we are now going through the 2018
compliance matrix. I will update this as I get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
Ever
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
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
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 @@
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
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 #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
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #7 from Jerry
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
--- 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=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
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
|NEW
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
CC||jvdelisle at gcc dot gnu.org
Last reconfirmed||2023-08-15
--- Comment #3 from Jerry DeLisle ---
On my list.
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=107397
--- Comment #15 from Jerry DeLisle ---
Working this now.
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=110888
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103796
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #6 from Jerry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847
--- Comment #5 from Jerry DeLisle ---
Hi Steve,I will see if I can get all this tested and committed this coming
weekend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
--- Comment #7 from Jerry DeLisle ---
In list_read.c we have this comment:
/* To read a logical we have to look ahead in the input stream to make sure
there is not an equal sign indicating a variable name. To do this we use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
--- Comment #6 from Jerry DeLisle ---
What is happening here is that in the name list input, the variable flp is also
a legal LOGICAL value, so our read is interpreting it as the second value of
the array flc and trying to continue to read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #19 from Jerry DeLisle ---
Created attachment 55024
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55024=edit
An enhanced test case
This test case from Herald illustrates a variety of combinations.
Giving:
$ gfc -std=f2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
Jerry DeLisle changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #13 from Jerry DeLisle ---
(In reply to Jerry DeLisle from comment #12)
That recent patch regression tests fine. I should mention, there is one of our
original test cases in gfortran.dg that does use a comma. We definitely have
see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #12 from Jerry DeLisle ---
A additional adjustment to reject the semi-colon always.
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 78bfd9e8787..db3330060ce 100644
--- a/libgfortran/io/list_read.c
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #8 from Jerry DeLisle ---
A side comment. We have a runtime function called "notify_std". Every time I
try to use it I struggle as it is not intuitively obvious how it works. We
ought to provide some better documentation on using it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #5 from Jerry DeLisle ---
Is this acceptable:
$ ./a.out
Compiler version = GCC version 14.0.0 20230424 (experimental)
Compiler options = -mtune=generic -march=x86-64 -Wpedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #4 from Jerry DeLisle ---
I knew this looked familiar. We did it on purpose. From list_read.c:
/* A trailing space is required, we give a little latitude here, 10.9.1. */
c = next_char (dtp);
if (!is_separator(c) && c !=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #4 from Jerry DeLisle ---
Well this is getting quite interesting. There is a bit of discussion going on
the Fortran Discourse about this.
https://fortran-lang.discourse.group/t/tab-formatting-with-stream-access/5466/47
After
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109453
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108131
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109453
--- Comment #5 from Jerry DeLisle ---
Correction, this must be a duplicate of something.
With gfortran gcc version 12.2.1 20221121 I get the error.
With gfortran gcc version 12.2.1 20230327 it is fixed.
As far as I can tell it has been fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109453
Jerry DeLisle changed:
What|Removed |Added
Summary|UBOUND incorrect when used |[REGRESSION] UBOUND
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jvdelisle at gcc dot gnu.org
Target Milestone: ---
The following program illustrates:
integer, parameter :: a(0:19)=(/(i,i=0,19)/)
integer :: b(-1:ubound(a,dim=1)) ! <<<< This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101047
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109186
Jerry DeLisle changed:
What|Removed |Added
CC||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=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=109105
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109099
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109080
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109076
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #8 from Jerry DeLisle ---
FWIW : I think the typespec is being lost because the initial call into
gfc_match_array_constructor which finds and matches the typespec sets a local
variable seen_ts which is used later in that function to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #7 from Jerry DeLisle ---
I should mention, this also fails:
print *, [real:: ((/2, 3/))] ** 2
So we also have to deal with this. I think I have it figured out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #6 from Jerry DeLisle ---
I had to go back in the Standard to deepen my understanding. Yes simplifying
it would help. I think what we need to do is acknowledge that we should match
'(' and if found, recursively call the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #4 from Jerry DeLisle ---
Well folks, I like to document my thought process.
>From the 2022 draft standard we have:
R781 ac-value is expr or ac-implied-do
R782 ac-implied-do is ( ac-value-list , ac-implied-do-control )
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #3 from Jerry DeLisle ---
I have a copy of the standard so I will answer my own question. This is a
comment:
In a situation like this:
print *, [integer :: ([1.0])] ** 2
My brain wants to say reject it because 1.0 is not an
||jvdelisle at gcc dot gnu.org
Last reconfirmed||2023-02-03
Status|UNCONFIRMED |NEW
--- Comment #6 from Jerry DeLisle ---
Thanks for giving test cases. I have not looked in detail but I will say that
finalization bugs are being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
--- Comment #3 from Jerry DeLisle ---
(In reply to Steve Kargl from comment #2)
> On Wed, Feb 01, 2023 at 06:13:33PM +, kargl at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
> >
> > This appears to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
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=107721
Jerry DeLisle changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107820
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||jvdelisle at gcc dot gnu.org
Last reconfirmed||2023-01-30
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107820
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
||jvdelisle at gcc dot gnu.org
Status|REOPENED|RESOLVED
--- Comment #20 from Jerry DeLisle ---
As far as I can tell this is fixed on branches 10 thru 13. I do not know why
it was reopened. I am closing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #14 from Jerry DeLisle ---
This is interesting. Simply doing the following eliminates the ice.
diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 0fb19cc9f0f..a9e538cc2a1 100644
--- a/gcc/fortran/parse.cc
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #13 from Jerry DeLisle ---
(In reply to anlauf from comment #11)
> (In reply to Jerry DeLisle from comment #8)
> > Doing the search in bugzilla, 137 bugs are marked as ic-on-invalid-code. I
> > suggest we make all of these P5 or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #9 from Jerry DeLisle ---
There are 162 marked as ice-on-valid-code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #8 from Jerry DeLisle ---
Doing the search in bugzilla, 137 bugs are marked as ic-on-invalid-code. I
suggest we make all of these P5 or Wont fix.
As my time and others is scarce, I plan to focus on the valid-code bugs. This
one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #7 from Jerry DeLisle ---
The only other way would be some sort of built in memory management scheme that
would guarantee all "objects" are freed implicitly. Of course gfortran itself
implements this type of thing as does I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #5 from Jerry DeLisle ---
I found that the attached patch does not work. At the point of assertion many
of the other functions to free memory have null pointers which leads to
segfaults all along the way.
The following approach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #15 from Jerry DeLisle ---
Do we close this bug as invalid or do we need to adjustsomething?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
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=102331
--- Comment #8 from Jerry DeLisle ---
Fixed ChangeLogs PR number referenced.
commit 04d7cc165387d19e1433a4b2157d2bde7b95305b (HEAD -> master, origin/master,
origin/HEAD)
Author: Jerry DeLisle
Date: Tue Jan 17 17:30:49 2023 -0800
Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
--- Comment #13 from Jerry DeLisle ---
I will backport to 12 as it is an ice on Valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
--- Comment #8 from Jerry DeLisle ---
I started to do some variations on the z1.f90 case:
program p
complex, parameter :: x(0) = 2
!data x%im /3.0/
print *, x
end
Running this prints a blank line;
Looking at the -fdump-tree-original
101 - 200 of 2081 matches
Mail list logo
