--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-05-
--- Additional Comments From amodra at bigpond dot net dot au 2005-05-07
00:33 ---
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00551.html
--
What|Removed |Added
K
--- Additional Comments From rth at gcc dot gnu dot org 2005-05-07 00:54
---
Testing fixes.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc
Hmmm... I just read through the bug reports you cited. Sounds to me like
this is still somewhat of an open issue, as to whether the compiler should
issue an error in these cases or simply silently discard any templated
function as a possible match for an operation involving an unnamed type. As
wa
gcc-4.0.0 configures aparently OK from the directory the tarball was unzipped,
but fails during "make all". The error message is:
updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: executing default-1 commands
./config.status: line 910
This also works on ifort
gfortran -c -O3 -g input.F -o input.o
In file input.F:694
if(iprcor.ne.0) print cor
1
--
Summary: Another code sample that gfortran dies on
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
--- Additional Comments From joe at confucius dot gnacademy dot org
2005-05-07 01:54 ---
Created an attachment (id=8833)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8833&action=view)
code sample that breaks gfortran
code sample that breaks gfortran
--
http://gcc.gnu.org/bugz
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-07 03:08
---
I've extended Steven's patch to handle nested aggregates
(i.e. any combination of ARRAY_REF and COMPONENT_REF).
--
What|Removed |Added
---
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-07 03:26
---
No offense intended, but a 1085 line source file is fairly
useless to us. In particular, NAG's F95 compiler can't
compile this code. In addition, a single print statement
without additional context (such as
We have the following coverage for the COMPONENT_REF case.
-: 6997:case COMPONENT_REF:
-: 6998: /* If the operand is a CONSTRUCTOR, we can just extract
the
-: 6999: appropriate field if it is present. */
75549: 7000: if (TREE_CODE (TREE_OPERAND (
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-07 03:33
---
(In reply to comment #2)
>
> But note I get a warning with ICC:
> fortcom: Warning: t.f, line 8: All active combinations of index-names are not
used within the variable
> being defined (i.e., leftside) of th
--- Additional Comments From joe at confucius dot gnacademy dot org
2005-05-07 03:43 ---
Sorry for the spew. The code is generated by a preprocessor and I didn't
realize how large it would end up.
The bug is that gfortran apparently does not support printing of namelists. I
don't kn
--- Additional Comments From joe at confucius dot gnacademy dot org
2005-05-07 03:45 ---
Created an attachment (id=8834)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8834&action=view)
better file
--
What|Removed |Added
---
--- Additional Comments From green at redhat dot com 2005-05-07 03:52
---
I've posted a patch.
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00555.html
--
What|Removed |Added
--
Including a blanket save after other state statements triggers error in
gfortran. It doesn't in Intel Fortran.
This could be annoying when you have a subroutine with includes to common
blocks.
[EMAIL PROTECTED] ~]$ cat test1.F
subroutine net
implicit real*8(a-h,o-z)
save/k
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-07 04:02
---
Thanks for cutting it down! The code is nonstandard according to
both the NAG compiler and Lahey's web base source code checker.
Lahey will compile the code if one does not ask for strict conformance
to the
Not sure what the standard says but the difference should probably be at least
release noted.
[EMAIL PROTECTED] ~]$ ifort -o testf test.f
[EMAIL PROTECTED] ~]$ ./testf
well done
[EMAIL PROTECTED] ~]$ gfortran -o testf test.f
[EMAIL PROTECTED] ~]$ ./testf
3
STOP io-err 91
[EMAIL PROTE
--- Additional Comments From joe at confucius dot gnacademy dot org
2005-05-07 04:19 ---
No problem. First things first :-) :-) :-)
In case you are wondering the bug reports I've been submitting come from trying
to compile a 2 line iron core collapse supernova simulation. It's the
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-07 04:48
---
My patch for PR14841 also works for this case.
--
What|Removed |Added
AssignedTo|dnov
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-07 05:05
---
I believe the code is invoking processor (ie compiler) defined behavior.
The standard states "If the STATUS= specifier has the value SCRATCH, the
FILE= specifier shall be absent." This isn't a constraint, so
--- Additional Comments From schlie at comcast dot net 2005-05-07 05:12
---
(In reply to comment #17)
> I've extended Steven's patch to handle nested aggregates
> (i.e. any combination of ARRAY_REF and COMPONENT_REF).
Does it also work with terminating static const char "strings" which
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-07 05:14
---
In *.final_cleanup of cc1-i files with --enable-checking, I see
1308 occurrences of tree_code_type[CST]
979 occurrences of tree_code_length[CST]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-07
06:22 ---
Related to 19425.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21434
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-07
06:43 ---
*** Bug 21431 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-07
06:43 ---
*** This bug has been marked as a duplicate of 17383 ***
--
What|Removed |Added
101 - 125 of 125 matches
Mail list logo
