https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87875
--- Comment #15 from Sebastien Bardeau ---
I confirm that my duplicate bug report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110157 faces this issue in Fortran
code; to my viewpoint it is not so useless to fix it. Anyway for the time being
I ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
--- Comment #4 from Sebastien Bardeau ---
Thanks for the hints. It seems to me that an intent(out) class without
component initialization values is probably out of the standard (unpredictable
results). So on my side the work-around I choose is t
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bardeau at iram dot fr
Target Milestone: ---
Hi,
gfortran 14.0.1 raises an ICE in the following context:
~> uname -a
Linux bardeau-lap 6.8.8-300.fc40.x86_64 #1
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bardeau at iram dot fr
Target Milestone: ---
Hi everyone,
with gfortran version 13.2.0, the -w compilation switch modifies the code
behavior at execution time. This was not
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: bardeau at iram dot fr
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740
Sebastien Bardeau changed:
What|Removed |Added
CC||bardeau at iram dot fr
--- Comment
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bardeau at iram dot fr
Target Milestone: ---
Calling the legacy MIN0 function with integer(8) arguments is probably not in
the F77 standard, might be a GNU extension. It used to be accepted with
gfortran 10 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298
--- Comment #8 from Sebastien Bardeau ---
I am experiencing an ICE looking pretty much the same as this one.
gfortran version and messages:
bardeau ~> gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/bardeau/Soft
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298
Sebastien Bardeau changed:
What|Removed |Added
CC||bardeau at iram dot fr
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51991
--- Comment #18 from Sebastien Bardeau ---
(In reply to kargl from comment #17)
> I just realized that your code isn't even close to conforming.
>
> subroutine sav
> integer :: save1
> save1 = something wrong
> end subroutine sav
>
> What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63689
--- Comment #3 from Sebastien Bardeau ---
My concern was more about -fcheck=array-temps (runtime) which does not behave
symmetrically to -Warray-temporaries (compilation time).
pr48655 does not plan to modify the verbosity of -Warray-temporaries
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bardeau at iram dot fr
Target Milestone: ---
Hi,
the following code raises an ICE. The error was seen with gfortran 5.3.0 and
6.1.0.
Cheers
$ cat ice.f90
subroutine foo
: enhancement
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bardeau at iram dot fr
Hi!
please consider this code:
program test
real(kind=4), pointer :: a(:),b(:)
allocate(a(2),b(2))
b = a
end program test
In the
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bardeau at iram dot fr
Dear gfortran developers,
gfortran issues an incorrect error message using the (invalid on purpose)
program below. It refers to the module
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: bardeau at iram dot fr
According to http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Standards.html the C
pre-precessor includes implicitly the file /usr/include/stdc-predef.h to any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57663
--- Comment #6 from Sebastien Bardeau ---
(In reply to Dominique d'Humieres from comment #5)
> > Well, I am "only" a Fortran programmer, I have no idea of how
> > the GNU compilers are written...
>
> Obviously you know how to build gfortran, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57663
--- Comment #4 from Sebastien Bardeau ---
(In reply to Dominique d'Humieres from comment #3)
> > Is there any chance that someone has a look to this bug?
>
> No, but you can do it yourself.
Well, I am "only" a Fortran programmer, I have no idea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57663
--- Comment #2 from Sebastien Bardeau ---
(In reply to Mikael Morin from comment #1)
> (In reply to Sebastien Bardeau from comment #0)
> > It seems that the gcc 4.6 branch is still receiving bug fixes, so could you
> > have a look?
> >
> Unfotuna
Assignee: unassigned at gcc dot gnu.org
Reporter: bardeau at iram dot fr
Created attachment 30328
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30328&action=edit
Print is incorrect with gfortran 4.6.4
Dear gfortran developers,
the attached Fortran program fails to make a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51991
--- Comment #12 from Sebastien Bardeau 2012-02-08
16:22:47 UTC ---
Ok, I did not realize that this patch was just a fix candidate.
This bug is not a problem to me, so there is no hurry.
Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51991
--- Comment #10 from Sebastien Bardeau 2012-02-08
10:38:42 UTC ---
I checked the gfortran trunk revision 183991 and the "bug" does not seem to be
fixed. I can also add that the DATA*-named variables give also erroneous
messages.
gfortran -v:
Us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51991
--- Comment #8 from Sebastien Bardeau 2012-01-25
13:36:51 UTC ---
(In reply to comment #7)
> > ... I do observe the error reported in my first message with gfortran trunk
> > ...
>
> I am quite confused: in order to have 'savej' in the error me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51991
--- Comment #6 from Sebastien Bardeau 2012-01-25
13:29:41 UTC ---
Created attachment 26461
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26461
Correct version this time.
Sorry, previous version had no problem. The symptom is the following:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51991
--- Comment #5 from Sebastien Bardeau 2012-01-25
13:19:21 UTC ---
(In reply to comment #4)
> > Well, ok, the 2 tests are just different and should raise different errors.
>
> Your original test gives
>
> pr51991.f90:11.11:
>
> j = a%j
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51991
--- Comment #3 from Sebastien Bardeau 2012-01-25
12:39:59 UTC ---
(In reply to comment #1)
> I wonder why it does not work for you with GCC 4.7 2011-11-19.
>
> I do not recall any issue, but it might have been some intermediate glitch.
> Does a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51993
Bug #: 51993
Summary: Erroneous type component initialization leads to
internal compiler error
Classification: Unclassified
Product: gcc
Version: fortran-dev
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51991
Bug #: 51991
Summary: Wrong error message with variables named "SAVE*"
Classification: Unclassified
Product: gcc
Version: fortran-dev
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638
--- Comment #12 from Sebastien Bardeau 2012-01-09
09:23:41 UTC ---
Dear Tobias,
many thanks for your help and for the many alternatives you gave us. We are
still discussing which one is the best to choose in our context, but at least
we have sev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638
Sebastien Bardeau changed:
What|Removed |Added
Attachment #26153|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638
--- Comment #6 from Sebastien Bardeau 2012-01-05
10:43:52 UTC ---
Dear all,
(In reply to comment #4)
> Your
> Fortran code is invalid. We have a clear diagnostic.
> The bug is in your code not the Fortran compiler.
This code is like it is sinc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638
--- Comment #3 from Sebastien Bardeau 2012-01-03
10:21:08 UTC ---
(In reply to comment #1)
>
> I can reproduce it with
> -O -m32
> on x86-64-linux.
Fine you can reproduce it easily.
> In terms of code validity, there are two other issues:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638
Bug #: 51638
Summary: gfortran optimization breaks a single variable used as
both input and output for subroutine call
Classification: Unclassified
Product: gcc
Version: fortran-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268
--- Comment #10 from Sebastien Bardeau 2011-11-29
14:33:08 UTC ---
Indeed this is a workaround that we will probably adopt.
I would say that although I partially disagree the choices made in the Fortran
Standards in this context, gfortran is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268
--- Comment #8 from Sebastien Bardeau 2011-11-24
15:58:31 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
>
> > "Within a scoping unit, identifiers of entities in the following classes:
> > (1) ..., abstract interfaces, generic inter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268
--- Comment #6 from Sebastien Bardeau 2011-11-24
13:23:18 UTC ---
(In reply to comment #5)
> It should be buried in "16 Scope, association, and definition", but I need
> some
> time to extract it.
Ok, so did I. Here is what I can read section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268
--- Comment #4 from Sebastien Bardeau 2011-11-23
13:56:19 UTC ---
(In reply to comment #3)
> For links to the standards see:
> http://gcc.gnu.org/wiki/GFortranStandards
Ok thank you for this link, very useful.
> I think the following of "11.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268
--- Comment #2 from Sebastien Bardeau 2011-11-23
09:22:12 UTC ---
Well, we are definitely interested in what the standard says exactly. Because
if this is explicitly forbidden, we are wondering what the Fortran committee
had in mind for programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268
Bug #: 51268
Summary: [Regression] A subroutine can not know anymore its own
interface
Classification: Unclassified
Product: gcc
Version: fortran-dev
Status: UNCONFIR
--- Comment #7 from bardeau at iram dot fr 2007-06-21 13:08 ---
(In reply to comment #6)
> Fixed on mainline and 4.2. Unless you really want to backport it to 4.1.3, I'm
> closing this bug.
>
The bug still appears under cygwin with gcc 4.3:
program test
integer*4 a
39 matches
Mail list logo
