http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149
--- Comment #3 from Zaak 2011-08-31 19:49:20 UTC ---
When I pass -E some strange behaviour occurs. First of all the code is
preprocessed with the c preprocessor and unless the -o flag is passed the
output is written to standard out, so this text w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149
--- Comment #4 from Zaak 2011-08-31 19:58:41 UTC ---
Created attachment 25155
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25155
test case files with Makefile
The Makefile.alt is configured to pass -E and -o /dev/null when building the
dep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44526
Zaak changed:
What|Removed |Added
CC||zbeekman at gmail dot com
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149
--- Comment #6 from Zaak 2011-08-31 22:01:06 UTC ---
I ma not saying gfortran is entirely broken, i'm merely claiming that there is
a bug in the dependency resolution feature. Please see GNU Make documentation
here for more information about Gener
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149
--- Comment #8 from Zaak 2011-08-31 22:27:40 UTC ---
(In reply to comment #7)
> On Wed, Aug 31, 2011 at 10:01:06PM +0000, zbeekman at gmail dot com wrote:
> >
> > I hope you are less confused now.
> >
>
> I'm n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149
--- Comment #9 from Zaak 2011-08-31 22:34:46 UTC ---
Additionally, if my entire premise is wrong what do you anticipate the use of
the -M flag will be for? It's not hard to figure out that .o files depend on
the .f90 files with the same name. I do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149
--- Comment #12 from Zaak 2011-09-01 01:14:40 UTC
---
> Can you show me a specific passage in the GNU Make documentation
> that states -M can be used to generate dependencies for
> Fortran USE statements without the actual *.mod being
> present?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149
--- Comment #13 from Zaak 2011-09-01 01:27:46 UTC
---
As for intrinsic F2003 modules, like ISO_C_BINDING, ISO_FORTRAN_ENV, etc. I
would expect the compiler to be able to handle this appropriately, i.e. not
require the presence of a iso_c_binding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149
--- Comment #14 from Zaak 2011-09-03 14:46:57 UTC
---
cricket
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
--- Comment #6 from Zaak ---
Thanks, I'll check it out.
On Sat, Apr 21, 2018 at 8:20 AM dominiq at lps dot ens.fr <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
>
> --- Comment #5 from Dominique d'Humiere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85507
--- Comment #14 from Zaak ---
Damn, it would have been nice if this patch made it in.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888
--- Comment #18 from Zaak ---
(In reply to Iain Sandoe from comment #17)
> by the way, I haven't been able to find a C reproducer for this issue - if
> you feel we should have a testcase for it perhaps a link test for the
> fortran example would
Assignee: unassigned at gcc dot gnu.org
Reporter: zbeekman at gmail dot com
Target Milestone: ---
Created attachment 46026
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46026&action=edit
Broken repeat example
The non-elemental intrinsic string function REPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89830
--- Comment #5 from Zaak ---
Sorry about the bad reproducer code (name conflict).
To create reproducible builds one must be able to strip or at least map source
file references from the source/build directory to something more generic or
univers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #84 from Zaak ---
Ian, Jurgen, et al.,
Thanks for your hard work getting the patch created and validated!
I'm a mac Homebrew maintainer, and was hoping to get a patch into the GCC-8
formula sooner rather than later as this Xcode reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #86 from Zaak ---
> (In reply to fink from comment #85)
>
> Zaak,
> I have patches for Fink for gcc5-gcc8 release tarballs. I'm waiting for the
> gcc5 build to finish before I make a public commit, which should be tonight.
Thanks! I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888
Zaak changed:
What|Removed |Added
CC||zbeekman at gmail dot com
--- Comment #15 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #89 from Zaak ---
Anyone have a patch for 4.9? A user wants one, but I can't build 4.9 from
source on Mojave.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88154
Zaak changed:
What|Removed |Added
CC||zbeekman at gmail dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88154
--- Comment #3 from Zaak ---
Some additional test cases from the OC bug tracker. These fail using
gfortran -fcoarray=single
and when linking against opencoarrays, so it seems there is an issue on the GCC
side (possibly the OC side too, but let'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90133
--- Comment #2 from Zaak ---
Hi Dominique,
So this is fixed on GCC 6? But not Trunk? (Or more recent releases?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90133
--- Comment #4 from Zaak ---
Sure, I understand regresion, but perhaps I don't understand what you mean by
"has been backported to GCC6".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90133
--- Comment #6 from Zaak ---
Oh, I see, so the *bug* has been backported... sigh. Well thanks for localizing
it to the range r243909-r244868.
I may try to do a bisection search to find the culprit and work up a
fix/patch... I haven't contributed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #92 from Zaak ---
Is my interpretation correct that the patch did not make it in time for GCC
9.1? (I( want to make sure we're applying it in Homebrew if not.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #94 from Zaak ---
OK, great. I was confused by the target changing from 9.1 to 9.2. Thanks!
On Fri, May 3, 2019 at 10:11 AM iains at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86863
Zaak changed:
What|Removed |Added
CC||zbeekman at gmail dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
--- Comment #1 from Zaak ---
I have confirmed this is a problem on OS X as well, although perhaps the
diagnostics are slightly different?
$ /usr/local/bin/gfortran -I/usr/local/homebrew/Cellar/mpich/3.2/include
-fcoarray=lib -fprofile-arcs -ftes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
--- Comment #2 from Zaak ---
I have confirmed this is a problem on OS X as well, although perhaps the
diagnostics are slightly different?
$ /usr/local/bin/gfortran -I/usr/local/homebrew/Cellar/mpich/3.2/include
-fcoarray=lib -fprofile-arcs -ftes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71729
Zaak changed:
What|Removed |Added
CC||zbeekman at gmail dot com
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505
Zaak changed:
What|Removed |Added
CC||zbeekman at gmail dot com
--- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
--- Comment #4 from Zaak ---
Fabulous, I'll verify soon (for my own satisfaction)
On Sun, Jan 22, 2017 at 12:31 PM vehre at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
>
> vehre at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83021
Zaak changed:
What|Removed |Added
CC||zbeekman at gmail dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
--- Comment #3 from Zaak ---
I have confirmed this bug. Are has anyone else looked at this?
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zbeekman at gmail dot com
Created attachment 34810
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34810&action=edit
reproducer program
I am on OS X Yosemite, 10.10.2 with a 64bit Intel CPU.
Gfortran is vers
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zbeekman at gmail dot com
Substring references with ISO_10646 kind characters cause the resulting
expression to be DEFAULT kind rather than ISO_10646.
Reproducer
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zbeekman at gmail dot com
Created attachment 34820
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34820&action=edit
reproducer program
This bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65144
--- Comment #2 from Zaak ---
Try this:
program test3
INTEGER,PARAMETER :: ucs4 = selected_char_kind("ISO_10646")
CHARACTER(3,UCS4),PARAMETER ::
unip=CHAR(INT(Z'5e74'),UCS4)//CHAR(INT(Z'6708'),ucs4)//CHAR(INT(Z'65e5'),ucs4)
character(3,UCS4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65144
--- Comment #3 from Zaak ---
Similarly if I try to use a substring in an if statement:
program test3
INTEGER,PARAMETER :: ucs4 = selected_char_kind("ISO_10646")
CHARACTER(3,UCS4),PARAMETER ::
unip=CHAR(INT(Z'5e74'),UCS4)//CHAR(INT(Z'6708'),u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65144
--- Comment #4 from Zaak ---
My apologies, I responded too quickly to Dominique... I thought we were talking
about: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65125 and failed to realize
that this was something (related?) different that that bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65144
Zaak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65144
--- Comment #5 from Zaak ---
Alright, I agree with Dominique, this bug report was erroneous on my part. In
the two follow up programs I posted, (modifing Dominique's) I accidentally used
`unip` substrings instead of `uni` substrings.
In my origi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149
Zaak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149
--- Comment #16 from Zaak ---
*** Bug 49150 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49150
Zaak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65125
Zaak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65144
--- Comment #7 from Zaak ---
(In reply to Dominique d'Humieres from comment #1)
> AFAICT the substring problem occurs for PARAMETER only:
>
> program test3
> INTEGER,PARAMETER :: ucs4 = selected_char_kind("ISO_10646")
> CHARACTER(3,UCS4),PAR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65144
--- Comment #8 from Zaak ---
(In reply to Dominique d'Humieres from comment #1)
> AFAICT the substring problem occurs for PARAMETER only:
>
> program test3
> INTEGER,PARAMETER :: ucs4 = selected_char_kind("ISO_10646")
> CHARACTER(3,UCS4),PAR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65144
--- Comment #9 from Zaak ---
I'm sorry for the duplicate commet and typo... it should be PR 65141 NOT 151
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47720
Zaak changed:
What|Removed |Added
CC||zbeekman at gmail dot com
--- Comment #1 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149
Summary: Dependency autogeneration with `-M` rendered useless
by requiring .mod files
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: critical
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49150
Summary: Preprocessing fortran code with the `-M` flag to
automatically resolve dependencies and produce
makefile rules rendered useless by requiring .mod
files be present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47720
--- Comment #4 from Zaak 2011-05-25 19:56:38 UTC ---
I'm not a gfortran dev, but the duplicates are likely due to the fact the the
source code is being parsed and there is need to remove duplicates, since the
output is intended for consumption by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47720
--- Comment #5 from Zaak 2011-05-25 20:01:01 UTC ---
In comment 4, in the first sentence there is a typo. I meant:
I'm not a gfortran dev, but the duplicates are likely due to the fact the the
source code is being parsed and there is *NO* need t
53 matches
Mail list logo
