*** gcc-4.0-20051124/gcc/config/i386/i386.c Mon Nov 7 18:55:03 2005
--- gcc-4.0-20051201/gcc/config/i386/i386.c Thu Dec 1 01:53:01 2005
! #if defined(HAVE_GAS_HIDDEN) defined(SUPPORTS_ONE_ONLY)
! #if defined(HAVE_GAS_HIDDEN) (SUPPORTS_ONE_ONLY - 0)
Why did he remove the 'defined'
Snapshot gcc-4.2-20051203 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20051203/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
I've been watching the LLVM/LTO discussion with interest.
I'm learning that I need to express myself carefully, because people
read a lot into what I say, so I've been watching, and talking with lots
of people, but not commenting. But, I've gotten a couple of emails
asking me what my thoughts
Is anyone seeing this? With current 4.1 sources, on a machine with only
1GB of main memory + 1GB swap, the following part of `make install`
Adding java source files from srcdir '/cvs/gcc/trunk/libjava/classpath'.
Adding java source files from VM directory /cvs/gcc/trunk/libjava
On Sun, Dec 04, 2005 at 12:35:31AM +0100, Gerald Pfeifer wrote:
spawns a recursive make (GNU make 3.80) that consumes some 450MB of memory
and triggers a system load of 12+, basically rendering the machine dead
for about a minute.
On a different machine with only 512MB + 1GB swap, this
Domagoj D [EMAIL PROTECTED] writes:
Does GCC front- and middle-end keep the source code line numbers all
the way until the RTL is generated? I'd need that for the tool I'm
developing.
Yes. They have to, in order to generate correct debugging
information.
Also, are there any simple source
--- Comment #3 from pluto at agmk dot net 2005-12-03 09:35 ---
I think this is a dup of PR25121
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25239
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2005-12-03 09:49
---
(In reply to comment #8)
The bug seems to have disappeared from current mainline and is not present
on gomp branch either. Should it be closed?
It is fixed on both mainline and 4.1 (probably by one of Paul T's
#define weak_extern(symbol) _weak_extern (weak symbol)
#define _weak_extern(expr) _Pragma (#expr)
extern void foo (void);
weak_extern (foo)
void bar (void)
{
if (foo)
foo ();
}
gives:
./xgcc -B ./ -O2 a.c -S
a.c:4: warning: malformed #pragma weak, ignored
a.c: In function ar':
a.c:8:
--- Comment #1 from jakub at gcc dot gnu dot org 2005-12-03 10:06 ---
This prevents glibc build.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Our testsuite should be distinguishing between errors and warnings
based on GCC diagnostic markers error: , warning: , etc.
--
Summary: DejaGNU does not distinguish between errors and warnings
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
--- Comment #2 from jsm28 at gcc dot gnu dot org 2005-12-03 13:36 ---
Patch posted http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00253.html which
fixes the problems except for on ia64-hpux, and includes a discussion of the
problems on ia64-hpux and how they might be fixed.
--
jsm28
When running the 3.4 testsuite on x86_64-unknown-linux-gnu, I'm getting the
following error:
FAIL: gcc.dg/i386-sse-2.c (test for excess errors)
as shown here:
http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00083.html
The logfile says:
In file included from gcc/include/xmmintrin.h:1216,
static const int e[4] = { 16, 16, 20, 20 };
extern void foo (unsigned long *);
void
baz (unsigned long *r)
{
unsigned long i;
for (i = 0; i 4; i++)
if (e[i] == 16)
break;
if (i == 4)
{
foo (r);
}
}
We have the following in the .vars tree dump:
;; Function baz
--- Comment #1 from steven at gcc dot gnu dot org 2005-12-03 14:22 ---
I should have said, this is at -O1 -fthread-jumps. I guess VRP catches this
at -O2 and better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25243
--- Comment #2 from steven at gcc dot gnu dot org 2005-12-03 14:37 ---
Actually VRP doesn't catch it.
Do:
-if (e[i] == 16)
+if (e[i] == 16)
so that store-CCP doesn't load e[0] anymore to find that it is 16. With that,
the .vrp dump at -O2 looks like this:
baz (r)
{
long
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-12-03 15:32
---
Subject: Bug 25106
Author: fxcoudert
Date: Sat Dec 3 15:32:04 2005
New Revision: 107999
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107999
Log:
PR fortran/25106
* parse.c (next_free):
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-12-03 15:33
---
Patch commited to mainline, waiting some time before commiting to 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2005-12-03 15:46 ---
With a minor hack, we optimize the test case in dom3:
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c (revision 107822)
+++ tree-ssa-dom.c
Trying to build mainline on ia64-hpux, I get an error when building
libgfortran, which is due to the following ICE:
$ cat tmp28181.f90
integer (kind=1) :: i
end
$ /tmp/debug/ibin//gcc/f951 tmp28181.f90
built-in:0: internal compiler error: Segmentation fault
--
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||gerald at pfeifer dot com
Status|UNCONFIRMED
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-12-03 16:30
---
Backtrace:
(gdb) where
#0 0x4d4f690:0 in __gmpn_copyi+0xa0 ()
#1 0x4d38180:0 in __gmpz_set () at set.c:53
#2 0x425cd80:0 in gfc_arith_init_1 () at gmp.h:1629
#3 0x42d1750:0 in gfc_init_1 () at
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Component|preprocessor|c
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-03 16:39 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-03 16:44 ---
You have a broken GMP installed, for some reason there have been a couple
reports about this. Maybe gfortran is the stress tester of GMP which nothing
else was before.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-03 17:01 ---
This looks very much related to PR 21829.
Hmm, in 4.0.0 we got Before DOM (likewise for 4.1.0 and above):
L1:;
i_2 = i_10 + 1;
if (i_2 != 4) goto L0; else goto L3;
# i_7 = PHI i_2(2);
L3:;
if (i_7 == 4)
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-03 17:04 ---
It might be, it works correctly on i686-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25239
--- Comment #5 from steven at gcc dot gnu dot org 2005-12-03 17:46 ---
Actually, it's more related to Bug 21488. What happens is that we record a
value for the left hand side of a single-argument PHI node (i.e. for
rhs=PHI(lhs) we record an equivalence rhs==lhs), but the left hand side
The attached file uninitialized_field.adb demonstrates a case where a
discriminant of a record isn't initialized. I compile and run it like this:
$ gnatmake uninitialized_field.adb
gcc -c uninitialized_field.adb
gnatbind -x uninitialized_field.ali
gnatlink uninitialized_field.ali
$
--- Comment #1 from listor1 dot rombobeorn at comhem dot se 2005-12-03
17:54 ---
Created an attachment (id=10397)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10397action=view)
demonstrates uninitialized discriminant
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25245
--- Comment #2 from listor1 dot rombobeorn at comhem dot se 2005-12-03
17:55 ---
Created an attachment (id=10398)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10398action=view)
demonstrates strange error message
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25245
--- Comment #6 from law at redhat dot com 2005-12-03 18:27 ---
Subject: Re: [4.1/4.2 Regression] Jump
threading opportunity missed in tree-ssa but caught in jump1
On Sat, 2005-12-03 at 17:46 +, steven at gcc dot gnu dot org wrote:
--- Comment #5 from steven at gcc
--- Comment #5 from danglin at gcc dot gnu dot org 2005-12-03 19:16 ---
The problem went away when I removed the old headers, so closing as
invalid.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
#pragma pack(1)
struct S
{
char h;
int i;
#pragma pack()
int j;
};
struct S s;
void *i = s.i, *j = s.j;
(distilled from Linux kernel) used to compile in 4.0.x, though the whole struct
wasn't really packed at all (i at offset 4, j at offset 8).
gomp #pragma handling rejects this.
Another
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-12-03 19:39 ---
I configured with --enable-checking=yes,rtl however I don't think that's
necessary to trigger the error. I see another report without checking here
that fails the test.
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-12-03 19:41 ---
Here's a reduced testcase, compile it with cc1 targetted to
x86_64-unknown-linux-gnu:
cc1 -fpreprocessed i386-sse-2.i -quiet -dumpbase i386-sse-2.c -msse -mtune=k8
-auxbase-strip i386-sse-2.s -O0 -version -o
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-12-03 20:06 ---
Here's a reduced testcase, configure 4.0.x with --enable-checking=yes,rtl
--target=i686-pc-linux-gnu and compile with:
cc1plus -fpreprocessed mmx2.ii -quiet -dumpbase mmx2.C -mmmx -mtune=pentiumpro
-auxbase mmx2 -O2
Hi,
i want send word (16 bit) to I/O
in borland C V3.0 i write for send 0xf
to port address ox56
#include conio.h
int main(void)
{
asm {
mov dx,0x56
mov ax,0xf
out dx,ax
}
return 0;
}
OR
#include conio.h
int main(void)
{
outport(0x56,0xf);
return 0;
}
but when write this
Hi,
i want send word (16 bit) to I/O
in borland C V3.0 i write for send 0xf
to port address ox56
#include conio.h
int main(void)
{
asm {
mov dx,0x56
mov ax,0xf
out dx,ax
}
return 0;
}
OR
#include conio.h
int main(void)
{
outport(0x56,0xf);
return 0;
}
but when write this
--
gerald at pfeifer dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |gerald at pfeifer dot com
|dot org
--- Comment #11 from reichelt at gcc dot gnu dot org 2005-12-03 23:18
---
Taking care of the backport.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from reichelt at gcc dot gnu dot org 2005-12-03 23:20
---
Taking care of the backport.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ghazi at gcc dot gnu dot org 2005-12-03 23:32 ---
3.4 patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00284.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Test gcc.dg/torture/fp-int-convert-float128-timode.c fails with
ERROR: gcc.dg/torture/fp-int-convert-float128-timode.c: syntax error in target
selector target ia64-*-* lp64 for dg-xfail-if 5 { ia64-*-* lp64
} { * } { }
This happens several platforms, including:
i686-pc-cygwin
--- Comment #1 from billingd at gcc dot gnu dot org 2005-12-03 23:35
---
Seen on multiple platforms by different testers.
--
billingd at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-03 23:35 ---
Confirmed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25247
--- Comment #3 from jsm28 at gcc dot gnu dot org 2005-12-03 23:42 ---
Janis is testing a patch:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02167.html.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #7 from pda at freeshell dot org 2005-12-04 00:06 ---
Subject: Re: Failure to build, command line:1:2: error: missing '(' after
predicate
On Tue, Nov 29, 2005 at 10:00:39PM -, dave at hiauly1 dot hia dot nrc dot
ca wrote:
--- Comment #6 from dave at hiauly1 dot
current kernels do not boot, they hang after 'returning from prom_init'
gcc4.1 and mainline miscompile arch/powerpc/mm/hash_utils_64.c.
Taking the object file from a gcc4.0 compiled tree fixes booting.
gcc-mainline r108000 binutils-mainline - fails
gcc-4_0-branch r107977 binutils-mainline - works
--- Comment #1 from olh at suse dot de 2005-12-04 01:36 ---
Created an attachment (id=10400)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10400action=view)
PR25248.tar.bz2
buildscripts and preprocessed files.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
--- Comment #9 from ghazi at gcc dot gnu dot org 2005-12-04 01:37 ---
Subject: Bug 25022
Author: ghazi
Date: Sun Dec 4 01:37:23 2005
New Revision: 108010
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108010
Log:
2005-12-03 Kaveh R. Ghazi [EMAIL PROTECTED]
PR
--- Comment #10 from ghazi at gcc dot gnu dot org 2005-12-04 01:54 ---
Fixed on all active branches
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from hhinnant at apple dot com 2005-12-04 02:12 ---
(In reply to comment #15)
Subject: Re: exception_defines.h #defines try/catch
I don't think anybody is disputing that. It is also a simple fact
that GCC documents what happens with -fno-exceptions.
I think it is
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-04 02:19 ---
As far as I can see, the tree level is fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
--- Comment #17 from gdr at integrable-solutions dot net 2005-12-04 02:54
---
Subject: Re: exception_defines.h #defines try/catch
hhinnant at apple dot com [EMAIL PROTECTED] writes:
[...]
| But I won't apologize for being customer focused.
Geeat! And people disagreeing with you
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25125
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-12-04 04:22 ---
(In reply to comment #8)
What are the issues that get in the way of having --enable-mapped-location
always?
Getting Ada fixed and getting some regressions fixed with
--enable-mapped-location.
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-12-04 04:27 ---
I am no longer going to fix the fold issue, it is too much hasle to get this
fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-04 04:28 ---
I am no longer going to work on this, it is too much hasle to get this fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from duraid at octopus dot com dot au 2005-12-04 04:36
---
Marking this bug invalid - the code in question turned out to have a GC that
did not correctly support IA64's RSE. With optimization, stuff was getting
hidden from the GC in the RSE backing store and incorrectly
--- Comment #9 from halcy0n at gentoo dot org 2005-12-04 04:49 ---
Created an attachment (id=10401)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10401action=view)
preprocessed output that causes ICE
This patch seems to cause another ICE. I applied the patch on gcc-4.0 to fix
--- Comment #6 from gdr at gcc dot gnu dot org 2005-12-04 05:00 ---
Working on a patch.
Fixing this issue has a deep type implications on the way we currently
hand inputs with erronous types whereas trying to progress as much as possible.
--
gdr at gcc dot gnu dot org changed:
--- Comment #8 from gdr at gcc dot gnu dot org 2005-12-04 05:04 ---
(In reply to comment #0)
The following code:
struct S
{ int x[3]; };
void f()
{ S s = {1,2,3};}
With -Wmissing-braces (which is implied by -Wall, among others) gives:
warning: missing braces around
--- Comment #4 from gdr at gcc dot gnu dot org 2005-12-04 05:09 ---
this issue should be resolved one way of the other based on the
core issue about argument dependent lookup specification, when a
non-function is found. The obvious solution would be to do overload
resolution based on
--- Comment #2 from gdr at gcc dot gnu dot org 2005-12-04 05:14 ---
The behaviour is what Standard C++ mandates. Explicit qualification in
the template instructs the compiler to consider only the overload set
avaliable at the definition context, not instantiation context,
-- Gaby
--- Comment #7 from gdr at gcc dot gnu dot org 2005-12-04 05:17 ---
(In reply to comment #3)
right now if we don't gimplify with -fsyntax-only, we would not be able to
diagnostic the following:
void f(void)
{
break;
}
If that is true, then it should be considered a bug in the
67 matches
Mail list logo
