Well,
/usr/local/src/trunk/objdir/./prev-gcc/xgcc
-B/usr/local/src/trunk/objdir/./prev-gcc/
-B/usr/local/i686-pc-cygwin/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
* Mark Mitchell [EMAIL PROTECTED] [2006-05-18 15:33]:
GCC 4.1.1 RC1 is available from:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.1-20060517
Running make check after make gives me:
| Newly fixed header: ia64/sys/getppdp.h
|
| There were fixinclude test FAILURES
--
Martin Michlmayr
[EMAIL
Richard, Roger --
Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change for
MIPS on the GCC 4.1 branch?
(My brain failed to digest the fact that the patch was on 4.1 as well as
on mainline, perhaps in part because there doesn't seem to be a PR;
Richard indicated to me that he would
Mark Mitchell [EMAIL PROTECTED] writes:
(My brain failed to digest the fact that the patch was on 4.1 as well as
on mainline, perhaps in part because there doesn't seem to be a PR;
Richard indicated to me that he would locate or open one now.)
Opened as 27681. (And Roger: sorry for all the
OK, Here is an official patch proposal to replace the contents of the
src/intl tree with the bits from gcc/intl.
I tested the change on HPPA and IA64 HP-UX and on IA64 Linux. The Linux
build didn't prove much because it used the system gettext bits but the
HP-UX builds built and used the new
Hi Steve,
OK, Here is an official patch proposal to replace the contents of the
src/intl tree with the bits from gcc/intl.
2006-05-19 Steve Ellcey [EMAIL PROTECTED]
* MAINTAINERS: Change intl updating instructions.
* config.rpath: Copy from GCC tree.
* intl:
On Fri, May 19, 2006 at 04:54:17PM +0100, Nick Clifton wrote:
Hi Steve,
OK, Here is an official patch proposal to replace the contents of the
src/intl tree with the bits from gcc/intl.
2006-05-19 Steve Ellcey [EMAIL PROTECTED]
* MAINTAINERS: Change intl updating instructions.
Bootstrap failure in gnattools for ia64-unknown-linux-gnu. Complaining on
missing libunwind.so.7
gmake[3]: Entering directory
`/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.1-RC1/gcc-4.1.1-RC1/gnattools'
rm -rf ../gcc/ada/tools
mkdir -p ../gcc/ada/tools
(cd ../gcc/ada/tools; ln -s
Hi Mark and Richard,
On Fri, 19 May 2006, Mark Mitchell wrote:
Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change
for MIPS on the GCC 4.1 branch?
(My brain failed to digest the fact that the patch was on 4.1 as well as
on mainline, perhaps in part because there doesn't seem
Hi Richard,
On Fri, 19 May 2006, Richard Sandiford wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
(My brain failed to digest the fact that the patch was on 4.1 as well as
on mainline, perhaps in part because there doesn't seem to be a PR;
Richard indicated to me that he would locate or
On Fri, 19 May 2006, Roger Sayle wrote:
Indeed, no good deed ever goes unpunished. In fact, isn't it the MIPS
backend's use of the GOFAST libraries which is one of the major blockers
The GOFAST support is almost certainly unused and can probably be removed;
at least, no-one has cared enough
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Michlmayr wrote:
* Mark Mitchell [EMAIL PROTECTED] [2006-05-18 15:33]:
GCC 4.1.1 RC1 is available from:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.1-20060517
Running make check after make gives me:
| Newly fixed header:
Roger Sayle wrote:
Hi Mark and Richard,
On Fri, 19 May 2006, Mark Mitchell wrote:
Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change
for MIPS on the GCC 4.1 branch?
(My brain failed to digest the fact that the patch was on 4.1 as well as
on mainline, perhaps in part
On May 19, 2006, at 9:59 AM, Mark Mitchell wrote:
Am I correct PR 22209 is only a Fortran problem? This is not a
rhetorical question; I'm trying to gather data
No, you can invoke it via using the attribute mode(TI), yes people
are not going to do that but who knows.
-- Pinski
Andrew Pinski wrote:
On May 19, 2006, at 9:59 AM, Mark Mitchell wrote:
Am I correct PR 22209 is only a Fortran problem? This is not a
rhetorical question; I'm trying to gather data
No, you can invoke it via using the attribute mode(TI)
Sure, but I'm not worried about that case.
--
On May 19, 2006, at 10:12 AM, Mark Mitchell wrote:
Andrew Pinski wrote:
On May 19, 2006, at 9:59 AM, Mark Mitchell wrote:
Am I correct PR 22209 is only a Fortran problem? This is not a
rhetorical question; I'm trying to gather data
No, you can invoke it via using the attribute mode(TI)
On Fri, 19 May 2006, Mark Mitchell wrote:
No, you can invoke it via using the attribute mode(TI)
Sure, but I'm not worried about that case.
That would be the only class of C or C++ failures that I could easily
construct by hand. Although the RTL optimizers will introduce TImode
moves and
! intl/; config.rhost; libiberty/; libiberty's part
! ...
! merge. Otherwise, changes are automatically merged, usually
! within a day.
Who signed up to do the automatic merge?
Andrew Pinski wrote:
Also why revert a patch which obvious works in the default configurations?
It eliminates a Fortran problem, but causes a C problem.
I'm evaluating the options. It would be helpful if someone has time to
apply and test Richard's patch on 4.1, as that would let us know
! intl/; config.rhost; libiberty/; libiberty's part
! ...
! merge. Otherwise, changes are automatically merged, usually
! within a day.
Who signed up to do the automatic merge?
I will unless you want to add this to the libiberty merge you do now.
intl changes even less than
On Fri, May 19, 2006 at 06:00:09PM +0200, Rainer Emrich wrote:
Bootstrap failure in gnattools for ia64-unknown-linux-gnu. Complaining on
missing libunwind.so.7
It is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464
H.J.
Andrew Pinski wrote:
Also why revert a patch which obvious works in the default configurations?
It eliminates a Fortran problem, but causes a C problem.
I thought it only caused the problem with C code when supplying -msoft-float
which is not a default configuration?
It eliminates more
Andrew Pinski wrote:
Andrew Pinski wrote:
Also why revert a patch which obvious works in the default configurations?
It eliminates a Fortran problem, but causes a C problem.
I thought it only caused the problem with C code when supplying -msoft-float
which is not a default configuration?
With the memory SSA patches we fail gcc.dg/noncompile/920507-1.c:
int *
x(void)
{
register int *a asm(unknown_register); /* { dg-error invalid
register } */
int *v[1] = {a};
return v[1];
}
The expected error message on the invalid register used for 'a' does not
trigger because the store
With the memory SSA patches we fail gcc.dg/noncompile/920507-1.c:
int *
x(void)
{
register int *a asm(unknown_register); /* { dg-error invalid
register } */
int *v[1] = {a};
return v[1];
}
This should fail in the front-end really.
Thanks,
Andrew Pinski
Diego Novillo wrote:
With the memory SSA patches we fail gcc.dg/noncompile/920507-1.c:
int *
x(void)
{
register int *a asm(unknown_register); /* { dg-error invalid
register } */
int *v[1] = {a};
return v[1];
}
The expected error message on the invalid register used for 'a' does
Mark Mitchell wrote on 05/19/06 14:54:
Yes, this test case is valid; the code is ill-formed GNU C, since the
machine in question know not have a register named unknown register.
^
I can't parse this.
Yes, I think the check
I will unless you want to add this to the libiberty merge you do now.
I don't mind adding it to my script, if people agree that's what they
want. It's just that nobody asked :-P
Some basic blocks may represent a (self) loop, but GCC's internal basic
block representation won't show such information explicitly (i.e., it won't
store a self-loop edge).
My question is, when I walk through basic blocks, can I identify then
easily?
E.g., Let's say,
sean yang wrote:
Some basic blocks may represent a (self) loop, but GCC's internal basic
block representation won't show such information explicitly (i.e., it won't
store a self-loop edge).
My question is, when I walk through basic blocks, can I identify then
easily?
E.g., Let's say,
Although BASIC_BLOCK array contains BBs in an unspecified order as the GCC
internal doc says, can I assume that the final virtual address for an
instruction in BB_m is always higher than the virtual address for an
instruction in BB_n, when m n. (Let's assume the linker for the target
machine
On May 19, 2006, at 12:48 PM, sean yang wrote:
Although BASIC_BLOCK array contains BBs in an unspecified order
as the GCC internal doc says, can I assume that the final virtual
address for an instruction in BB_m is always higher than the
virtual address for an instruction in BB_n, when m
From: Daniel Berlin [EMAIL PROTECTED]
To: sean yang [EMAIL PROTECTED]
CC: gcc@gcc.gnu.org, [EMAIL PROTECTED]
Subject: Re: identifying a BB representing a self-loop
Date: Fri, 19 May 2006 15:41:30 -0400
sean yang wrote:
Some basic blocks may represent a (self) loop, but GCC's internal basic
On May 19, 2006, at 6:57 AM, Christian Joensson wrote:
../../gcc/gcc/objc/objc-act.c:5573: warning: implicit declaration of
function 'default_conversion'
Update and build again... :-)
On May 19, 2006, at 12:01 PM, Diego Novillo wrote:
Mark Mitchell wrote on 05/19/06 14:54:
Yes, this test case is valid; the code is ill-formed GNU C, since the
machine in question know not have a register named unknown
register.
From: Dale Johannesen [EMAIL PROTECTED]
To: sean yang [EMAIL PROTECTED]
CC: Dale Johannesen [EMAIL PROTECTED], gcc@gcc.gnu.org
Subject: Re: address order and BB numbering
Date: Fri, 19 May 2006 12:54:56 -0700
On May 19, 2006, at 12:48 PM, sean yang wrote:
Although BASIC_BLOCK array
sean yang wrote on 05/19/06 15:48:
can I assume that the final virtual address for
an instruction in BB_m is always higher than the virtual address for an
instruction in BB_n, when m n.
No. Think code insertion.
Then this must be a very dummy question. How the compiler keep the
instruction order in the RTL IR format in a function? By the information
like insn 50 56 51 ? e.g.,
(insn 50 56 51 4 (clobber (reg/i:SI 0 ax)) -1 (nil) )
It's a linked list. The 56 and 51 link to the previous and next
Diego Novillo wrote:
Mark Mitchell wrote on 05/19/06 14:54:
Yes, this test case is valid; the code is ill-formed GNU C, since the
machine in question know not have a register named unknown register.
^
I can't parse this.
Roger Sayle [EMAIL PROTECTED] writes:
Indeed, no good deed ever goes unpunished. In fact, isn't it the MIPS
backend's use of the GOFAST libraries which is one of the major blockers
of adding -msoft-float tests to the testsuite? :-)
No. As I've explained earlier this week, -msoft-float code
Andrew Pinski [EMAIL PROTECTED] writes:
If the back-end was not lying to the front-ends, this would never
have been a problem, hint hint.
I'm not sure what you mean here. In what way is the back end lying
to the front end?
Richard
Snapshot gcc-4.1-20060519 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060519/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
DJ Delorie wrote:
I will unless you want to add this to the libiberty merge you do now.
I don't mind adding it to my script, if people agree that's what they
want. It's just that nobody asked :-P
I hereby request that you add automatic intl/ merging to your script. :-)
--
Mark Mitchell
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27558
--- Comment #12 from mrs at apple dot com 2006-05-19 06:09 ---
Ok, finished a:
configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert
--prefix=/usr/gcc-4.2 --with-local-prefix=/usr/local
gcc refuses to compile this admittedly completely useless code:
int main(void) {
if(0) hello[0] = 'H';
return 0;
}
with
bug.c: In function #8216;main#8217;:
bug.c:2: error: assignment of read-only location
Obviously, this assignment will cause problems if it is ever executed, and a
warning
--- Comment #14 from rsandifo at gcc dot gnu dot org 2006-05-19 08:05
---
Subject: Bug 22209
Author: rsandifo
Date: Fri May 19 08:05:39 2006
New Revision: 113903
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113903
Log:
* libgcc2.c (MIN_UNITS_PER_WORD): Move default
With the 4.1.0 built yesterday, bootstrapped with Apple gcc 5247, I get the
following:
[EMAIL PROTECTED]:/tmp cat t.cc
__thread int int_tls = 2;
int get_tls()
{
return int_tls;
}
int main()
{
return get_tls();
}
[EMAIL PROTECTED]:/tmp /opt/gcc-4.1.0-32/bin/g++ -O3 -Wall -Wextra
--- Comment #13 from mrs at gcc dot gnu dot org 2006-05-19 10:07 ---
Subject: Bug 27673
Author: mrs
Date: Fri May 19 10:06:17 2006
New Revision: 113904
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113904
Log:
PR c/27673
* c-parser.c (c_parser_parms_declarator):
--- Comment #1 from jsm28 at gcc dot gnu dot org 2006-05-19 10:17 ---
Technically a regression; compilers up to EGCS 1.1.2 accepted this, then it
became a pedwarn, and later a hard error.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed
The following example should be self explanatory.
I was expecting same content to be written onto
the files goodstr.txt and whyptr.txt.
-- yotam
[EMAIL PROTECTED]:C:444 g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
Nick Clifton wrote:
I am not sure how this should be fixed however. Should the
functions in lib1funcs-02-4-200.asm be protected by another #ifdef
so that they are not built for this target ? Or maybe the rules in
t-sh need to be updated to include an architecture selection switch
? (eg
Hi Joern,
I have a patch for it, but due to problems with our hardware, newlib, and
issues with the way the linux libgcc is built, I have not been able to
test the
patch satisfactorily.
I can confirm that the patch allows GCC to build for both an sh64-elf
and an sh-elf target. I am now
--- Comment #1 from rsandifo at gcc dot gnu dot org 2006-05-19 15:10
---
The use of $f14 was an unintentional historical accident,
not a deliberate decision. It has since been fixed.
I realise this isn't going to be very helpful to you,
but you should just treat 3.4 and 4.x as being
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-05-19 15:13
---
Any update on this?
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
libgcc no longer provides __fixuns*si(), __fix*di() and __floatdi*()
functions. This causes many testsuite failures on soft-float
mipsisa64-elf.
--
Summary: [4.1 regression] Missing DImode float conversion
functions
Product: gcc
Version:
--- Comment #1 from rsandifo at gcc dot gnu dot org 2006-05-19 15:24
---
This was fixed for 4.2 by:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00806.html
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-05-19 16:04
---
Subject: Bug 26433
Author: mmitchel
Date: Fri May 19 16:04:22 2006
New Revision: 113911
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113911
Log:
PR c++/26433
* cp-tree.h
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-05-19 16:06
---
Fixed in 4.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
GCC claims to follow C99 Annex F when converting a floating value to an integer
type when the integral part exceeds the range of the integer type (C99 6.3.1.4
and F.4). Annex F says that in this case the conversion raises the invalid
floating-point exception. On powerpc64-linux and x86_64-linux,
--- Comment #1 from janis at gcc dot gnu dot org 2006-05-19 16:13 ---
This is related to PR21360, although that one is about the result of an
out-of-range conversion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27682
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-19 16:21 ---
First we don't yet implement FENV_ACCESS. There is a bug about that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27682
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-19 16:28 ---
If this is revert, PR 22209 is reintroduced.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-19 16:35 ---
*** This bug has been marked as a duplicate of 9925 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-05-19 16:35
---
*** Bug 27678 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from joseph at codesourcery dot com 2006-05-19 16:35 ---
Subject: Re: New: float to int conversion doesn't raise
invalid exception
On Fri, 19 May 2006, janis at gcc dot gnu dot org wrote:
GCC claims to follow C99 Annex F when converting a floating value to an
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-19 16:38 ---
Well TLS is not supported on Darwin and you did --enable-TLS which is just
wrong as there is no support at all in the kernel or even ABI wise.
I almost want to say this is invalid even though we ICE as you used
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-05-19 16:38
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2006-05-19 16:43
---
Andrew, any news on this one? If I remember correctly, you're waiting for
paperwork with your new employer?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19777
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-19 16:45
---
I think we can close this one, now, can't we?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #41 from fxcoudert at gcc dot gnu dot org 2006-05-19 16:51
---
I'm puzzled by this PR and PR 26893: what is the status on those reports? Did
you reproduce this on a given platform, with *known good* GMP and MPFR and with
a gfortran = 4.1 ?
Otherwise, I supposed we might
-in specs.
Target: i386-linux
Configured with: ../gcc/configure --prefix=/tmp/gfortran-20060519/irun
--enable-languages=c,fortran --host=i386-linux
--with-gmp=/tmp/gfortran-20060519/gfortran_libs
Thread model: posix
gcc version 4.2.0 20060519 (experimental)
$ gfortran bounds.f90 ./a.out
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-19 17:04
---
We currently have the following warnings when building libgfortran on
i686-linux:
../../../gcc/libgfortran/io/transfer.c: In function 'read_block':
../../../gcc/libgfortran/io/transfer.c:279: warning: 'return'
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-19 17:05
---
Adding Jerry in CC list since he's likely to be the one who introduced the
warning in transfer.c :)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #42 from quanah at stanford dot edu 2006-05-19 17:09 ---
I will be working on this after the students leave, starting in June. Please
keep this ticket open.
I note that the versions of GMP MPFR I'm using work *fine* on linux, so I
consider them known good. They only
--- Comment #7 from quanah at stanford dot edu 2006-05-19 17:09 ---
I will be working on this after the students leave, starting in June. Please
keep this ticket open.
I note that the versions of GMP MPFR I'm using work *fine* on linux, so I
consider them known good. They only don't
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-05-19 17:14
---
(In reply to comment #7)
I will be working on this after the students leave, starting in June. Please
keep this ticket open.
OK.
I note that the versions of GMP MPFR I'm using work *fine* on linux, so I
--- Comment #4 from janis at gcc dot gnu dot org 2006-05-19 17:25 ---
This has been brought up to the glibc developers in the past:
http://sourceware.org/ml/libc-alpha/2005-03/msg00196.html
It's unfortunate that they don't agree that an implementation of C consists
of a combination
--- Comment #4 from aldot at gcc dot gnu dot org 2006-05-19 17:29 ---
This also fails on the gcc-4_1-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27516
--- Comment #11 from patchapp at dberlin dot org 2006-05-19 17:35 ---
Subject: Bug number PR c/27273
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00964.html
--
--- Comment #2 from patchapp at dberlin dot org 2006-05-19 17:35 ---
Subject: Bug number PR25058
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00969.html
--
/testsuite/gfortran/../../gfortran version 4.2.0
20060519 (experimental)
--
Summary: Many new GFORTRAN testsuite failures
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
--- Comment #2 from gcc at cohi dot at 2006-05-19 18:23 ---
Ah.
I, obviously wrongly, assumed that TLS would work if I could build gcc with
--enable-tls.
(Chapter 5.51 of the GCC 4.1.0 docs, which talks about thread local storage,
says that TLS is not available everywhere, but fails
Supplied main.ii file compiles but doesn't link. When I reduce the number of
template parameters in the line 37070 from 4 to 3 it compiles and links ok.
I guess it's an issue of the enormous length of instantiated mpl templates
names.
N.B. In case it matters : I doesn't now how to obtain target
--- Comment #1 from grayyoga at gmail dot com 2006-05-19 19:19 ---
Created an attachment (id=11488)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11488action=view)
Command line parameters and output of gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27684
--- Comment #2 from grayyoga at gmail dot com 2006-05-19 19:20 ---
Created an attachment (id=11489)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11489action=view)
Preprocessed output of the buggy program.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27684
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-19 19:36 ---
Infinite recursion is going on in CSE. Here is what happens.
At cse.c:4278 in fold_rtx, we have
(gdb) call debug_rtx(x)
(plus:SI (reg/v/f:SI 60 [ first ])
(const_int 4 [0x4]))
(gdb) call debug_rtx(y)
/mnt/gnu/gcc-3.3/objdir/./prev-gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/./prev-gcc/
-B
/opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/bin/ -c -g -O2 -DIN_GCC -W
-Wal
l -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-l
ong -Wno-variadic-macros -Wno-overlength-strings
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-19 20:27 ---
Fixed by:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00997.html
http://gcc.gnu.org/ml/gcc-cvs/2006-05/msg00518.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from zadeck at gcc dot gnu dot org 2006-05-19 21:18 ---
Subject: Bug 26855
Author: zadeck
Date: Fri May 19 21:18:23 2006
New Revision: 113915
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113915
Log:
2006-05-19 Daniel Berlin [EMAIL PROTECTED]
Kenneth
--- Comment #4 from schwab at suse dot de 2006-05-19 21:32 ---
Halfway fixed by http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00996.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27611
--- Comment #7 from hjl at gcc dot gnu dot org 2006-05-20 00:28 ---
Subject: Bug 27662
Author: hjl
Date: Sat May 20 00:28:14 2006
New Revision: 113922
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113922
Log:
gcc/fortran/
2006-05-19 H.J. Lu [EMAIL PROTECTED]
PR
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-20 01:39 ---
This really should be filed to binutils and not to GCC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27684
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-05-20 02:56
---
I will fix the one in transfer.c as obvious.
I don't understand the issue in list_read.c I have a namelist patch pending
for that file so if someone could give me a hint I would be happy to fix that
as well.
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-05-20 03:30
---
Subject: Bug 22423
Author: jvdelisle
Date: Sat May 20 03:29:58 2006
New Revision: 113923
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113923
Log:
2006-05-19 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #2 from kazu at gcc dot gnu dot org 2006-05-20 04:57 ---
The whole problem is reduced to the combiner doing wrong simplification
of XOR. Here are some details.
Consider:
extern void abort (void) __attribute__ ((noreturn));
extern void exit (int) __attribute__
96 matches
Mail list logo
