After revision 133909 building libgfortran is broken at:
...
libtool: compile: /opt/gcc/darwin_buildw/./gcc/xgcc
-B/opt/gcc/darwin_buildw/./gcc/ -B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/include -isy
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
|
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-04-06 12:44
---
We need more information: for each compiler that fails, what is the output of
"gfortran -v"?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #2 from oder at eleks dot lviv dot ua 2008-04-06 13:21 ---
(In reply to comment #1)
> You need to report this with apple or at least try a still maintained gcc
> version and provide a testcase without Mac specific headers.
Well, it's not so easy. ./configure for GCC 4.3.0 fa
The following gives an ICE:
==18935== Invalid read of size 1
==18935==at 0x4C25D82: strlen (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==18935==by 0x438ABE: compare_to_allowed_values (io.c:1404)
==18935==by 0x43A892: match_io (io.c:2883)
==18935==by 0x451BA9: match_w
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-06 13:57 ---
Please attach preprocessed source then, it is likely that apples
OSAtomicIncrement32Barrier implementation is simply bogus (which is why I
suggested reporting this bug to apple).
--
http://gcc.gnu.org/bugzilla/s
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-04-06 13:51 ---
Confirmed that this works for 4.3 and 4.4.
Also, using 1 (instead of the illegal 0) as
format generates the right error in 4.2, as well:
$ gfortran-4.2 foo.f90
foo.f90:1.10:
write(18,1) 'trtot= ',trtot
1
Hi,
during the configure run for libgcc xgcc fails with a segfault.
Here is a backtrace:
#0 0x2b9b80f4e07b in raise () from /lib/libc.so.6
(gdb) bt
#0 0x2b9b80f4e07b in raise () from /lib/libc.so.6
#1 0x2b9b80f4f84e in abort () from /lib/libc.so.6
#2 0x00511845 in diagnost
--- Comment #2 from mstein dot lists at googlemail dot com 2008-04-06
14:31 ---
OK, using -Os together with -ftree-ch / -ftree-pre seem to help in some cases.
It would be nice if gcc could add/remove these flags automaticaly when
using -Os :)
--
mstein dot lists at googlemail dot
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-06 14:49 ---
The problem is that usually those options increase code size, which is why
they are disabled for -Os. In your case while they initially increase code
size they expose optimization opportunity that in the end reduce
--- Comment #1 from nightstrike at gmail dot com 2008-04-06 14:55 ---
Created an attachment (id=15434)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15434&action=view)
Preprocessed source
This is the preprocessed source that causes the ICE.
--
http://gcc.gnu.org/bugzilla/show
gcc version 4.3.0 and 4.4.0 have an ICE when compiling a small piece of Firefox
code. It happens with -O1, 2, or 3 and does not with -O0 or -Os.
The ICE is as follows:
x86_64-pc-mingw32-g++: warning: -pipe ignored because -save-temps specified
/mnt/dump/src/mozilla/mozilla/security/manager/ssl/s
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-04-06 15:04
---
(In reply to comment #0)
> c) In configure.ac
> ZW_GNU_GETTEXT_SISTER_DIR
No, the configury is probably going to be more tricky than that. The macro
above (defined in config/gettext-sister.m4) relates to host, an
--- Comment #1 from hjl dot tools at gmail dot com 2008-04-06 15:16 ---
They were introduced by 133930:
http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00154.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #21 from d at domob dot eu 2008-04-06 15:28 ---
Created an attachment (id=15435)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15435&action=view)
Handles bounds checking and fixes regressions.
This patch handles the bounds checking correctly, adds a test case if -std=f
--- Comment #2 from nightstrike at gmail dot com 2008-04-06 15:07 ---
To clarify the title, the ICE goes away with all optimization levels when
-fno-tree-ch is used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35842
From
http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00420.html
ERROR: gcc.dg/pr30957-1.c: no files matched glob pattern
"hard_float9950.c.[0-9][0-9][0-9]r.expand" for " dg-require-effective-target 8
hard_float "
UNRESOLVED: gcc.dg/pr30957-1.c: no files matched glob pattern
"hard_float9950.c.[0-
I think it makes sense to be able to overwrite the Fortran standard passed to
the library (f95, f2003, f2008, gnu, legacy). The reason is that we have
several cases where with -std=f95 GNU extensions are rejected. I think not all
users are aware of this and combining a compliant Fortran program wit
--- Comment #18 from nightstrike at gmail dot com 2008-04-06 16:03 ---
What is the status on this? I am having a lot of test timeouts when testing
the x86_64-pc-mingw cross compiler, as sometimes there are slow programd and
annoying ssh network delays. Extending the timeout in a robust
--- Comment #22 from burnus at gcc dot gnu dot org 2008-04-06 16:22 ---
> Created an attachment (id=15435)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15435&action=view) [edit]
> Handles bounds checking and fixes regressions.
Great.
> However, I'm not quite sure about some thin
--- Comment #1 from danglin at gcc dot gnu dot org 2008-04-06 16:27 ---
Running under gdb, I see
16.xg:
/home/dave/gnu/gcc-4.4/gcc/libstdc++-v3/testsuite/22_locale/num_get/get/char/16.cc:57:
void test01(): Assertion `err == ios_base::eofbit' failed.
Program received signal SIGABRT, Abo
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-06 16:06 ---
-fno-tree-ch probably just hides the bug. -linux targets work for me.
(gdb) call debug_generic_expr (tmp)
&SSL_ImplementedCiphers
(gdb) call is_gimple_min_invariant (tmp)
$1 = 0 '\0'
which is the problem.
static
The following program gives an ICE. One reason could be the global variables.
(cf. PR27997 comment 21).
implicit none
integer i
character(len=2) :: c(3)
c = 'a'
c = [ [ trim(c(1)), 'a' ]//'c', 'cd' ]
print *, c
end
Variants to check (or combinations of those):
- Compile with -fbounds-check
- Use
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-06 16:37 ---
Reduced C testcase:
extern __attribute__((dllimport)) const int SSL_ImplementedCiphers[];
extern void SSL_GetCipherSuiteInfo(int cipherSuite);
void nsCipherInfo(int SSL_NumImplementedCiphers)
{
int i;
for (i = 0;
Hi,
building score-elf fails with
configure:2398: /home/mstein/inst/trunk/score-elf/./gcc/xgcc
-B/home/mstein/inst/trunk/score-elf/./
gcc/ -B/home/mstein/cross-install/score-elf-trunk/score-elf/bin/
-B/home/mstein/cross-install/score
-elf-trunk/score-elf/lib/ -isystem
/home/mstein/cross-install/sco
Hi,
the entry for the port "score" is missing in the MAINTAINERS file.
--
Summary: Missing port entry in MAINTAINERS file
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
--- Comment #7 from ktietz at gcc dot gnu dot org 2008-04-06 18:20 ---
Created an attachment (id=15436)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15436&action=view)
Patch for i386.c:7666 fixing dllimport symbol handling
This patch is a try for fixing the new ICE.
It is current
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-06 18:05 ---
This is now a target issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-06 18:05 ---
Subject: Bug 35842
Author: rguenth
Date: Sun Apr 6 18:04:47 2008
New Revision: 133963
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133963
Log:
2008-04-06 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #8 from ktietz at gcc dot gnu dot org 2008-04-06 18:29 ---
Ok, the patch fixes the ICE by test without any regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35842
--- Comment #2 from tobi at gcc dot gnu dot org 2008-04-06 18:59 ---
Subject: Bug 35832
Author: tobi
Date: Sun Apr 6 18:58:34 2008
New Revision: 133964
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133964
Log:
2008-04-06 Tobias Schlter <[EMAIL PROTECTED]>
PR fortran/35832
f
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-06 19:19 ---
Since powerpc-apple-darwin9 enables Altivec by default, the vectorizer happens
in libgfortran.
Almost all the vectorizer tests are now failing too.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #3 from tobi at gcc dot gnu dot org 2008-04-06 19:27 ---
Fixed on the trunk.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-06 19:32 ---
Simple testcase:
void
foo (float a[32], float b[2][32])
{
int i;
for (i = 0; i < 32; i++)
a[i] = (b[0][i] > b[1][i]) ? b[0][i] : b[1][i];
}
Compile with -O2 -maltivec -ftree-vectorize and you get the failure
--- Comment #4 from brian at dessent dot net 2008-04-06 19:49 ---
Subject: Re: Wrong instruction generated for comparison with zero
on PPC 64 bit
> after all. If there are no prebuilt binaries publicly available that means
> there must be some reason for it.
Where in the world do yo
--- Comment #5 from oder at eleks dot lviv dot ua 2008-04-06 20:14 ---
(In reply to comment #4)
> Both Fink and Macports have
> gcc 4.1, 4.2, and 4.3 packages, and Macports even has a 4.4 snapshot.
Could you please provide a link to gcc archive?
On gcc.gnu.org there is no MacOS in Downl
The following prints:
INTEGER, PARAMETER, DIMENSION(10) :: A = [(i, i = 1,10)]
1
Error: Magnitude of second argument of ISHFTC exceeds third argument at (1)
However, the error actually occurs in the second line.
NAG f95 gets t
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-06 20:38 ---
With the following patch, the message shown is:
INTEGER, PARAMETER, DIMENSION(10) :: B = ISHFTC(3, A, 5) !ICE
1
Error: Magnitude of second argument of IS
--- Comment #6 from brian at dessent dot net 2008-04-06 20:44 ---
Subject: Re: Wrong instruction generated for comparison with zero
on PPC 64 bit
> Could you please provide a link to gcc archive?
> On gcc.gnu.org there is no MacOS in Download->Binaries
gcc.gnu.org doesn't supply any
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-04-06 21:21 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-04-06 21:21
---
Subject: Bug 35400
Author: rguenth
Date: Sun Apr 6 21:20:49 2008
New Revision: 133967
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133967
Log:
2008-04-06 Richard Guenther <[EMAIL PROTECTED]>
It might by that gfortran wrongly rejects the following program. Or it might be
that it is invalid. This PR is mostly about checking whether the program is
valid. It can be found at:
http://groups.google.com/group/comp.lang.fortran/msg/077a30ae15edd3cc
Compiling only the MODULE - with [ ] repla
glibc-2.7 test for ssp support and use ssp if no error is reported
configure:6449: gcc -B/tools_alpha/bin/ -g -O2 -fstack-protector
-o conftest conftest.c 1>&5
conftest.c:1: warning: -fstack-protector not supported for this target
configure:6452: $? = 0
configure:6461
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-06 21:28 ---
Use -Werror.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
--- Comment #1 from tobi at gcc dot gnu dot org 2008-04-06 21:03 ---
I'm on it.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-06 21:45 ---
Simplified test case.
gfortran: "external f" -> function or procedure; "call callSub(f)" -> f :=
subroutine. And thus: "call callFunc(f)" => error.
NAG f95 & sunf95: Without the "implicit integer(f)": missmatch real
--- Comment #2 from burnus at gcc dot gnu dot org 2008-04-06 21:51 ---
Hmm, I think gfortran is right:
"12.4.1.3 Actual arguments associated with dummy procedure entities"
[...]
"If the interface of the dummy argument is implicit and either the name of the
dummy argument is explicitly t
--- Comment #3 from burnus at gcc dot gnu dot org 2008-04-06 22:03 ---
Close as invalid.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|
g++-4.3.0 -ansi -pedantic-errors -std=c++0x -Wall -Wconversion
issues the following diagnostic on the following code:
// test case:
typedef unsigned short ushort;
enum {
FOO = 0x13
};
template
inline
void
andnot(T& lv, T&& rv) {
lv &= ~rv;
}
template
inline
void
andnot(T& lv,
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-07 01:13 ---
-fdump-rtl-expand no longer works, -fdump-tree-expand does though.
We do document -fdump-rtl-expand and not -fdump-tree-expand:
-fdump-rtl-expand
Dump after RTL generation, to file.104r.expand.
Thanks,
Andrew Pins
When I noticed PR 35843, I saw that some -dletter was still referenced in some
cases:
-dv
For each of the other indicated dump files (either with -d or -fdump-rtl-pass),
dump a representation of the control flow graph suitable for viewing with VCG
to file.pass.vcg.
-dx
Just generate RTL for a func
When looking into the documentation for the other two bugs which I just
confirmed/filed, I noticed that we still document the life passes dump option
but the life pass was removed when dataflow branch was merged in:
-fdump-rtl-cfg
-fdump-rtl-life
-fdump-rtl-cfg enable dumping after control and data
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||zadeck at gcc dot gnu dot
|
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-04-07 01:22 ---
Can you provide the .ii file which is generated when you add the -save-temps
option. I want to say this is a bug in Apple's header's inline-asm.
--
pinskia at gcc dot gnu dot org changed:
What|Re
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-07 01:24 ---
The removal of -d letter support for the RTL passes was done by:
2008-04-05 Jan Hubicka <[EMAIL PROTECTED]>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35853
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-07 01:28 ---
Hmm, if we change r to be an array, fre does the correct thing but shouldn't it
do the correct thing for the non array case too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29751
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-04-07 01:32
---
Hmm, we do get something different on the trunk:
bar ()
{
struct example * ex1.0;
:
ex1.0 = ex1;
ex1.0->a = 1;
ex1.0->b = 2;
ex1.0->c = 3;
if (ex1.0->b != 2)
goto ;
else
goto ;
:
link_erro
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-07 01:36 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-07 01:37 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-07 01:38 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-07 01:40 ---
Yes this is the same as PR 23455.
*** This bug has been marked as a duplicate of 23455 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-04-07 01:40
---
*** Bug 35286 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-04-07 01:44 ---
This turns out to be PRE for global decl issue as the following is done
correctly (at least on the trunk):
int g(int);
int f(int tt, int *t)
{
if (tt)
*t = 2;
else
*t = 3;
return g(*t);
}
--- CUT ---
f
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-04-07 01:44
---
*** Bug 25553 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23455
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-07 01:46 ---
(In reply to comment #1)
> Confirmed. I think this is the same issue as PRE of globals.
It is as if you change the source to be:
int g, g2;
int foo(int p, int *gp)
{
int t = 0;
if (p)
t = *gp + 1;
r
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-04-07 01:46
---
*** Bug 35287 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23455
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|heisenbug in tree vectorizer|[4.4 Regression] heisenbug
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35755
This report relates to your message:
of Mon, 7 Apr 2008 11:14:32 +0900
Your message was not delivered to: [EMAIL PROTECTED]
for the following reason: unable-to-transfer
and the following diagonostic: recipient-reassignment-prohibited
* The following informat
eTrust Secure Content Manager SMTPMAIL could not deliver the e-mail below
because at least one of recipients was rejected by the mail server
Please check the recipients e-mail address before you try again:
[EMAIL PROTECTED]
Original message header:
===
X-eSCM-
--- Comment #3 from zuxy dot meng at gmail dot com 2008-04-07 06:00 ---
Created an attachment (id=15437)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15437&action=view)
Proposed patch against 4.3.0, marking .text.unlikely as executable.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #3 from vapier at gentoo dot org 2008-04-07 06:00 ---
this is in gcc-4.3.0 and that's fine by me
--
vapier at gentoo dot org changed:
What|Removed |Added
the gcc build system has some awk scripts that use unsafe character ranges:
$ grep a-z gcc/*.awk
gcc/optc-gen.awk: gsub( "[^A-Za-z0-9_]", "X", macros[i] )
gcc/optc-gen.awk: gsub ("[^A-Za-z0-9]", "_", enum)
gcc/opt-functions.awk: gsub ("[^A-Za-z0-9]", "_", name)
gcc/opth-gen.awk:
Hello.
I have binutils 2.18
$ ld --version
GNU ld (GNU Binutils) 2.18
...
But during compilation of gcc-4.3.0 I get following:
configure: WARNING: === Linker version 1800 is too old for
configure: WARNING: === full symbol versioning support in this release of GCC.
configure: WARNING: ==
78 matches
Mail list logo
