Found on the J3 mailing list. gfortran is the compiler which prints "0.0"as
second number (4.1 to 4.4); ifort, g95, NAG f95, openf95 and sunf95 print the
3742 twice.
Van Snyder writes:
The list items in subclause 10.8.5 "P editing" of 08-007
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-27 09:37 ---
This is a regression with regards to g77.
The email itself (for completeness):
http://j3-fortran.org/pipermail/j3/2008-November/002084.html
The problem only occurs for a d (Fw.d) of "0", for, e.g., "4PF14.1" gfortra
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-27 10:18 ---
Still -fipa-pta is necessary to reproduce the failure. ipa-pta is broken, so,
wontfix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-27 11:14 ---
(In reply to comment #0)
> POPCNT and POPPAR are present in many other compilers
And (even) more interestingly they are part of the Fortran 2008 Candidate
Release (as you also mentioned):
13.7.128 POPCNT (I)
Des
--- Comment #1 from brian at dessent dot net 2008-11-27 11:29 ---
Subject: Re: New: configure: error: cannot compute suffix of
object files - cannot find as
The assembler is not part of gcc. You need to build and install
binutils for your target (which will result in the cross-asse
--- Comment #13 from tehila at il dot ibm dot com 2008-11-27 12:20 ---
(In reply to comment #12)
Thanks, Andrey.
I think there are 2 "issues" here:
1. register-renaming. (more related to this PR, I think)
2. schuedule-insns.
Both of them slows compilation.
With ARG4, on SPU, I see:
-O1:
--- Comment #14 from abel at gcc dot gnu dot org 2008-11-27 12:50 ---
(In reply to comment #13)
> (In reply to comment #12)
> Thanks, Andrey.
> I think there are 2 "issues" here:
> 1. register-renaming. (more related to this PR, I think)
> 2. schuedule-insns.
> Both of them slows compila
--- Comment #15 from burnus at gcc dot gnu dot org 2008-11-27 13:21 ---
I think PR is fixed on the trunk (4.4) [-> back porting?], except of the issue
of comment 13 (-> different PR?).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
I just tried to build the GNU gcc version 4.4.0 snapshot 20081121
with the Intel C compiler, which said
../../src/gcc-4.4-20081121/gcc/config/i386/i386.c(4315): warning #593: variable
"f" was set but never used
../../src/gcc-4.4-20081121/gcc/config/i386/i386.c(7479): warning #593: variable
"total_
--- Comment #16 from burnus at gcc dot gnu dot org 2008-11-27 13:24 ---
(Most problems have been fixed, except of the one in comment 0.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32795
[forwarded from http://bugs.debian.org/506713]
seen with 4.1, 4.2, 4.3 branches, not on the trunk
Functions compiled for SPARC with both -O2 and -fPIC options, which
return structures and require global data, may have incorrect code
generated for them.
The following example is based on Qt 3, whi
Found at
http://de.wikibooks.org/wiki/Fortran:_Fortran_2003:_Zeiger
The following is rejected because of the space in "( )". With "()" it compiles:
procedure( ), pointer :: pptr => null()
1
Error: Syntax error in PROCEDURE statement at (1)
--
Summary: "procedure( ), poi
--- Comment #15 from tehila at il dot ibm dot com 2008-11-27 12:57 ---
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > Thanks, Andrey.
> > I think there are 2 "issues" here:
> > 1. register-renaming. (more related to this PR, I think)
> > 2. schued
Found at http://de.wikibooks.org/wiki/Fortran:_Fortran_2003:_Zeiger
The following program gives an ICE:
hjff.f90:4.34:
procedure( up ), pointer :: pptr => null()
1
Error: Interface 'up' of procedure 'pptr' at (1) must be explicit
hjff.f90:4.15:
procedure( up
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-27 13:44 ---
Something for you?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #8 from dennis dot wassel at googlemail dot com 2008-11-27
10:32 ---
(In reply to comment #6)
> This ICE is different than the one you reported first: this fails in the
> debug dumps function. Could you report the backtrace using the following
> flags:
>
> gfortran -O3 -ft
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-27 10:29 ---
Introduced by PR28513 fix
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142056
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from jakub at gcc dot gnu dot org 2008-11-27 10:01 ---
Yeah, that looks reasonable (though I wonder if other places that use PATTERN
in
distribute_notes don't need similar treatment).
Simplified testcase below. Are you going to post it to gcc-patches?
inline unsigned shor
--- Comment #7 from dennis dot wassel at googlemail dot com 2008-11-27
10:09 ---
(In reply to comment #6)
> This ICE is different than the one you reported first: this fails in the
> debug dumps function. Could you report the backtrace using the following
> flags:
>
> gfortran -O3 -ft
Create build dir:
$ mkdir -p /home/paul/Programs/gcc/arm
$ cd /home/paul/Programs/gcc/arm
Ran configure:
$ /home/paul/Programs/gcc/gcc-4.3.2/configure --target arm-linux-elf
--srcdir=/home/paul/Programs/gcc/gcc-4.3.2/
--prefix=/home/paul/Programs/gcc/gcc-arm --program-prefix=arm-
--with-local-pre
Found at
http://de.wikibooks.org/wiki/Fortran:_Fortran_2003:_Ein-_und_Ausgabe
The following is valid and the error message is bogus:
read( 50, *, pos = 1 )
1
Error: FMT=* is not allowed with a REC= specifier at (1).
open(50,access='stream')
read( 50, *, pos = 1 )
end
--
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-11-27 14:20
---
I am on it.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-11-27 14:21
---
I will see what I can do.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from steven at gcc dot gnu dot org 2008-11-27 15:26 ---
Created an attachment (id=16784)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16784&action=view)
less unpolished version of tree code hoisting
This fixes some bugs in the proof-of-concept patch:
1. Don't hoi
--- Comment #3 from dominiq at lps dot ens dot fr 2008-11-27 15:31 ---
*** This bug has been marked as a duplicate of 37012 ***
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #52 from dominiq at lps dot ens dot fr 2008-11-27 15:31 ---
*** Bug 37105 has been marked as a duplicate of this bug. ***
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #3 from dominiq at lps dot ens dot fr 2008-11-27 15:33 ---
Fixed by revision 142163. Closing.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Component|c |bootstrap
h
--- Comment #5 from mikael at gcc dot gnu dot org 2008-11-27 15:40 ---
(In reply to comment #4)
> I will investigate more next week-end (unless someone beats me ;-))
>
I'm investigating now.
The first patch was probably wrong.
I'm testing this one at the moment:
Index: parse.c
===
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from huffton at googlemail dot com 2008-11-27 16:19 ---
Brian
Thanks for the speedy response. I hadn't realised that "as" was not part of the
compiler (I am new at this). I have compiled binutils and all is fine now.
Marking bug as invalid as it is not a bug.
Cheers
Pa
seen with a profiled build (make profile-opt
PROFILE_TASK='$(srcdir)/Lib/test/regrtest.py') building python-3.0rc3 on
i486-linux-gnu. Using pybench as the PROFILE_TASK doesn't show this bug). Seen
PR22471, but this one was reported long ago. What other information should be
provided for this kind o
--- Comment #2 from ghazi at gcc dot gnu dot org 2008-11-27 16:59 ---
(In reply to comment #1)
> Can you use ./contrib/gcc_update to update your gcc source tree
> so that we can tell which revisions you are using? Thanks.
Done, however it only works for 4.3 and trunk, not 4.2. I assume
libgfortran fails to build on the trunk when building a cross compiler
targeting spu-elf. Fixing the first two build failures and seeing more.
This is a regression compared to 4.3
see http://gcc.gnu.org/ml/fortran/2008-11/msg00090.html
--
Summary: [4.4 regression] libgfortran build
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|grosser at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-11-27 17:31 ---
Setting to P4, please restore to P3 if a C or C++ test showing this problem is
found.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-11-27 17:32 ---
Setting to P4, please restore to P3 if a C or C++ test showing this problem is
found.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
---
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.4.0
http://gcc.g
--- Comment #2 from jsm28 at gcc dot gnu dot org 2008-11-27 17:36 ---
Setting to P5, please restore to P3 if the assembler for some primary or
secondary target complains about the multiple directives or incorrectly
assembles the file because of them.
--
jsm28 at gcc dot gnu dot org c
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P1
http://
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P1 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38278
Now that we have a viable header set and libraries for x86_64-pc-mingw32, we
are able to support multilib. This needs to be enabled.
--
Summary: Enable multilib support for mingw
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: n
--
nightstrike at gmail dot com changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38281
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38079
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38278
--- Comment #1 from nightstrike at gmail dot com 2008-11-27 17:43 ---
Created an attachment (id=16785)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16785&action=view)
My first crack at enabling the support
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
The feature I'm proposing is not supported by the C standard, so I'm proposing
a gcc extension.
I am wondering if it's possible to make the difference of two function pointer
be a constant value if the two functions are defined as static and in the same
file. That would allow for function pointer
Because __builtin_constant_p() is sometimes (ab)used as a static analyzer, the
documentation should give more details what is expected to work, and what you
should not use it for. (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359)
Here is my suggestion, please incorporate it into the gcc 4.4.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-27 18:28 ---
Differences between two different arrays don't make sense really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
--- Comment #2 from gnu at behdad dot org 2008-11-27 18:31 ---
I'm not following. Why arrays? Those are pointers, and their difference is
known at compile time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
--- Comment #3 from gnu at behdad dot org 2008-11-27 18:32 ---
Oh, I see what you mean. Yes, I said in my report that this is
undefined/unsupported/... according to the C standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-11-27 18:33 ---
(In reply to comment #2)
> I'm not following. Why arrays? Those are pointers, and their difference is
> known at compile time.
Not at compile time really, the difference is known at link time.
--
http://gcc.
--- Comment #5 from gnu at behdad dot org 2008-11-27 18:35 ---
If the two functions are in the same compilation unit (and static), it's known
at compile time, isn't it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-11-27 18:52 ---
(In reply to comment #5)
> If the two functions are in the same compilation unit (and static), it's known
> at compile time, isn't it?
Not always since they could be in different sections via -ffunction-sections or
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-11-27 18:53 ---
Also the linker could do some branch relaxation which causes the size to be
different based on the layout of the functions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
--- Comment #8 from gnu at behdad dot org 2008-11-27 18:55 ---
If they are asked to be put in different sections, sure, it will err. But
doesn't gcc already use relative calls for many static functions in the same
unit?
Let me back out: my request is: add gcc extension to support some
--- Comment #2 from w6ws at earthlink dot net 2008-11-27 19:32 ---
Tobias, Steven,
If you would like to usurp this request and use it to implement the complete
set
of F2008 bit intrinsics, please feel free to do so.
For completeness, one other HPF bit intrinsic is ILEN - which counts t
--- Comment #2 from vmakarov at redhat dot com 2008-11-27 20:32 ---
The problem was in violation of allocno order in regno_allocno_map list.
This order is very important for many algorithms (allocno info propagation,
conflict propagation and IR flattening). For example,
loop 0:
--- Comment #2 from mikael at gcc dot gnu dot org 2008-11-27 21:12 ---
Is this enough?
Index: decl.c
===
--- decl.c (révision 142242)
+++ decl.c (copie de travail)
@@ -4094,6 +4094,7 @@ match_procedure_decl (void)
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-11-27 21:14
---
Reproducible on Solaris as well (with -mcpu=v8 since -mcpu=v9 is the default).
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-11-27 21:20
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #1 from janus at gcc dot gnu dot org 2008-11-27 22:09 ---
The test case can be further compressed to a 3-liner
procedure( up ) :: p
call p
end
and is fixed by the following simple patch
Index: gcc/fortran/resolve.c
==
--- Comment #3 from janus at gcc dot gnu dot org 2008-11-27 22:16 ---
(In reply to comment #2)
> Is this enough?
I guess so :)
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pault at gcc dot gnu dot org 2008-11-27 22:21 ---
Subject: Bug 36526
Author: pault
Date: Thu Nov 27 22:20:27 2008
New Revision: 142248
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142248
Log:
2008-11-27 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #7 from pault at gcc dot gnu dot org 2008-11-27 22:23 ---
Fixed on trunk and 4.3.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from janus at gcc dot gnu dot org 2008-11-27 22:50 ---
I also tried to compile the other procptr examples from the WikiBooks page,
which is linked in comment #0.
The only remaining problem I found was:
program bsp
implicit none
abstract interface
subroutine u
--- Comment #3 from hjl at gcc dot gnu dot org 2008-11-27 23:30 ---
Subject: Bug 38280
Author: hjl
Date: Thu Nov 27 23:28:44 2008
New Revision: 142250
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142250
Log:
2008-11-27 Vladimir Makarov <[EMAIL PROTECTED]>
PR rtl-opt
--- Comment #4 from danglin at gcc dot gnu dot org 2008-11-27 23:49 ---
Size of __emutls_v.testcom_ block is wrong, as well as generated code.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--
I am compiling with g++ on a 64 bit Ubuntu OS. I spent days trying to find out
why my programs kept crashing. I found that when using O2 optimizations the
problem is there, when using O1 it is not a problem.
I am not using any compiler options other than stripping symbols, hiding
warnings, and O
--- Comment #1 from andrew at warnux dot com 2008-11-28 00:32 ---
I guess you want this too:
gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--en
--- Comment #5 from jan dot kratochvil at redhat dot com 2008-11-28 01:36
---
(In reply to comment #4)
> First, I think the DIE representing the defining declaration of A::elsewhere
> in class2.c should have a DW_AT_specification pointing back to the DIE
> representing the declaration o
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-28 01:38 ---
What is byte typedef? Is it unsigned char or signed char? If so then you are
violating aliasing rules by modifying a char* via that pointer type. Yes
char/unsigned char/signed char are special but their pointer ty
--- Comment #3 from andrew at warnux dot com 2008-11-28 01:59 ---
unsigned char
char and byte are the same size (1 byte), so why is there a problem?
--
andrew at warnux dot com changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-11-28 02:20 ---
Yep you are violating C++ aliasing rules as you are accessing a char * as an
unsigned char*. It would be ok if you accessed a char as an unsigned char but
you are accessing the pointers instead.
It is not the size
--- Comment #131 from pinskia at gcc dot gnu dot org 2008-11-28 02:20
---
*** Bug 38297 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
during building latest 4.4 snapshot i've got a linker error:
(...)
/bin/sh ./libtool --tag=GCJ --mode=link
/home/users/pluto/rpm/BUILD/gcc-4.4-20081121/builddir/gcc/gcj
-B/home/users/pluto/rpm/BUILD/gcc-4.4-20081121/builddir/x86_64-pld-linux/libjava/
-B/home/users/pluto/rpm/BUILD/gcc-4.4-20081121/
--- Comment #5 from andrew at warnux dot com 2008-11-28 02:33 ---
Thanks! I guess I learned something new today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297
--- Comment #5 from danglin at gcc dot gnu dot org 2008-11-28 03:35 ---
(gdb) p debug_tree ($r26)
unit size
align 32 symtab 0 alias set -1 canonical type 7af7ec30
fields
unsigned SI file
/test/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/pr25162.f
--- Comment #4 from Joey dot ye at intel dot com 2008-11-28 03:39 ---
142250 doesn't fix this regression. 416.gamess and 481.wrf still fail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38280
--- Comment #6 from danglin at gcc dot gnu dot org 2008-11-28 04:44 ---
(gdb) p debug_tree (decl)
unit size
align 64 symtab 0 alias set -1 canonical type 7af79af8
fields
BLK file
/test/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/pr25162.f line 9
--- Comment #10 from geoffk at gcc dot gnu dot org 2008-11-28 07:34 ---
Yes, the test is still valid. It is reporting a real problem. I will suggest
a change to __GCC_HAVE_DWARF2_CFI_ASM that permits the testcase to continue
working.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu
|org
85 matches
Mail list logo
