When I compile the following program with gcc 3.3.5 (debian unstable):
#include
int main()
{
int i=1;
float f;
__m128 m[i];
float f2;
__m128 n[i];
printf ("%x %x\n", m, n);
}
I get:
% ./align
a8ec a8dc
which is wrong, since m and n should
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-03
10:34 ---
Partial fix proposed here: http://gcc.gnu.org/ml/fortran/2005-03/msg00023.html
This fixes the bug when writing to files, but there still is the case of
preconnected units (stdout, stderr). This will need
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-03
10:37 ---
Hi,
I see this patch hasn't been commited yet, could you please send it again to the
mailing-lists? With the new approval rules, maybe it should hopefully get
reviewed...
--
http://gcc.gnu.org/bugzil
--- Additional Comments From micis at gmx dot de 2005-03-03 10:44 ---
I applied you patch and did a full bootstrap on x86_64.
No new regressions.
It fixes my problem.
Michael Cieslinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20122
It should be NULL pointer assignment, but it is not so.
Kernel version 2.4.10 RedHat Linux.
#include
#include
main(){
int err;
err=read(0,NULL,6);
printf("%d %dn",err,errno);
}
Please, reply part of source code with explaination of
bug. Thanks!
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
12:54 ---
I think this is very much related to PR 19199. I almost think when that bug is
fixed this one will also be
fixed.
Your current patch will not fix that PR either.
--
What|Removed
--- Additional Comments From schwab at suse dot de 2005-03-03 12:56 ---
Also happens on i386.
--
What|Removed |Added
Severity|normal |critical
--- Additional Comments From pinskia at physics dot uc dot edu 2005-03-03
12:58 ---
Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
On Mar 3, 2005, at 2:50 AM, Alexandre Oliva wrote:
> I'm bootstrapping this on x86_64-linux-gnu, along with the patch for
>
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20299
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
13:06 ---
Fixed in 3.4.0 and above as you noted that it is fixed in 3.4.4. This is not a
regression so closing as
fixed.
--
What|Removed |Added
-
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-03
13:08 ---
Complete patch is here: http://gcc.gnu.org/ml/fortran/2005-03/msg00024.html
Note: this just makes the limit higher (1 Gb), but there still is a limit on the
size of things you can write to preconnected u
--- Additional Comments From bob dot paddock at gmail dot com 2005-03-03
13:13 ---
(In reply to comment #5)
>Personally see no problem. The quote above has specifically to do with how to
>write a logical 16-bit timer/counter value into a pair of otherwise distinct
>8-bit registers, whi
The following program results in an ICE:
procedure Undefined_Derived_Char is
type Char is new Character;
C : Char;
begin
case C is
when XXX =>
null;
when others =>
null;
end case;
end Undefined_Derived_Char;
It seems that the checks in Sem_Ch8.Find_Dire
--- Additional Comments From bangerth at dealii dot org 2005-03-03 14:39
---
I think gcc is right, and icc rejects the code with an almost exact same
error message.
W.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
14:45 ---
(In reply to comment #3)
> I think gcc is right, and icc rejects the code with an almost exact same
> error message.
But we don't still don't reject the zero sized array which is a bug.
--
Wh
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2005-03-03 0
--- Additional Comments From olh at suse dot de 2005-03-03 14:48 ---
the breakage appeared between 20041027 and 20041101.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
--- Additional Comments From joern dot rennecke at st dot com 2005-03-03
14:59 ---
Subject: Re: If-conversion can't match equivalent code, and cross-jumping only
works for literal matches
pinskia at gcc dot gnu dot org wrote:
>--- Additional Comments From pinskia at gcc dot gnu d
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-03-
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-03
16:28 ---
I think NS::C should remain hidden so the declaration:
C c;
should be OK.
--
What|Removed |Added
-
--- Additional Comments From bangerth at dealii dot org 2005-03-03 17:00
---
That's correct, but that's a dup of PR 16859.
W.
--
What|Removed |Added
Status|REO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
17:06 ---
I knew I should have looked for this bug.
--
What|Removed |Added
CC|
I am compiling a large jar file.
/opt/gcc-3.4.3-cvs/bin/gcj -c ../../kernel/kernel.jar --classpath=..:../kernel
-o kernel.o
/var/tmp//cct7Jptt.s: Assembler messages:
/var/tmp//cct7Jptt.s:103992: Error: unknown pseudo-op: `.ll'
/var/tmp//cct7Jptt.s:143015: Error: unknown pseudo-op: `.ll'
/var/tmp//
GCJ does not handle compilation of sub classes with out explicitly defined
constructors to override the super class constructors when the constructors
throw exceptions.
[EMAIL PROTECTED] steve]$ gcj Test.java -c Test.o
Test.java: In class 'Test$1':
Test.java: In constructor '(Test,java.io.ByteArra
--- Additional Comments From steve at netfuel dot com 2005-03-03 17:32
---
Created an attachment (id=8317)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8317&action=view)
Inner class test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20302
--- Additional Comments From steve at netfuel dot com 2005-03-03 17:33
---
Created an attachment (id=8318)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8318&action=view)
Straigt sub class test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20302
--
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20302
When
#pragma GCC visibility push(default)
#pragma GCC visibility pop
are used for header file wrappers, we may have more 16
#pragma GCC visibility push(default)
Currently gcc will fail.
--
Summary: Can't push more than 16 nested visibility
Product: gcc
Version
Folks,
We are reporting this issue both to the GCC people and the libsigc++ people,
because the issue could be in either of them or both. On the surface, it looks
like a g++ issue, but when you look deeper, libsigc++ might be relying on a
behavior that is unspecified by any C++ standard.
Input
--
--- Additional Comments From hpreg at vmware dot com 2005-03-03 18:24
---
Created an attachment (id=8319)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8319&action=view)
The code for the small test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20304
--- Additional Comments From hpreg at vmware dot com 2005-03-03 18:25
---
Created an attachment (id=8320)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8320&action=view)
Pre-processed file output (.ii file), compressed with bzip2 (-9)
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--
What|Removed |Added
Severity|critical|normal
Component|target |middle-end
Keywords|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
18:42 ---
I think this is a dup of another bug, but I am too lazy to find the bug right
now.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
18:43 ---
This is a documented behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
--- Additional Comments From mark at codesourcery dot com 2005-03-03 18:47
---
Subject: Re: [3.4 Regression] const/pure functions result
in bad asm
ebotcazou at gcc dot gnu dot org wrote:
> 2. The tree-inliner inlines the call. Since the same tree is referenced twice
> in the expres
--- Additional Comments From hjl at lucon dot org 2005-03-03 18:47 ---
It makes it less useful for header file wrappers. Supporting the case of N
(N>16)
#pragma GCC visibility push(default)
followed by N
#pragma GCC visibility pop
shouldn't be very hard.
--
http://gcc.gnu.org/bug
--- Additional Comments From pcarlini at suse dot de 2005-03-03 18:47
---
Want to have a look, a fix seems easy...
--
What|Removed |Added
AssignedTo|unassigned at gc
--- Additional Comments From bugzilla at mdaniel dot scdi dot com
2005-03-03 19:03 ---
In case anyone is curious, this causes the Mozilla HEAD build to fail [at least
with gcc 3.4.3 20050124 and GNU ld 2.15.95 20050302 on x86_64] during link on
two separate occasions, once with nsprpub a
--- Additional Comments From hjl at lucon dot org 2005-03-03 19:11 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00248.html
FYI, gcc 3.4 from RH does include this pragma.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
19:06 ---
(In reply to comment #2)
> In case anyone is curious, this causes the Mozilla HEAD build to fail [at
> least
> with gcc 3.4.3 20050124 and GNU ld 2.15.95 20050302 on x86_64] during link on
> two separate oc
It seems that gcc-4_0-branch GCC (both 20050228 and 20050303) miscompiles
libcpp/macro.c if compiled at -O1 and higher. stage1 compiler built that
way dies with:
/usr/include/bits/stdio.h: In function printf':
/usr/include/bits/stdio.h:36: error: syntax error before _restrict__'
/usr/in
--- Additional Comments From bugzilla at mdaniel dot scdi dot com
2005-03-03 19:19 ---
$ gcc --version
gcc (GCC) 3.4.3 20050124 (Red Hat 3.4.3-17)
I stand corrected, Fedora Core 3 must be back-porting some of that
functionality. Should I open a bug with them pointing to this, or is it j
--- Additional Comments From hjl at lucon dot org 2005-03-03 19:19 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00238.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
The patch for PR rtl-opt/15289, changed the behavior of emit_move_insn_1 to
invoke emit_block_move on memory to memory moves for "optimal behavior",
instead of invoking a movMM pattern on the inner mode. emit_block_move
changes the mode to BLKmode masking the original mode. This sequence of
d
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
19:23 ---
I want to say this is a dup of bug 20282 which is for ppc64-linux.
--
What|Removed |Added
B
--
What|Removed |Added
OtherBugsDependingO||20305
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
19:24 ---
PR 20305 is the bootstrap failure for s390x and it looks like the same problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
--- Additional Comments From hjl at lucon dot org 2005-03-03 19:25 ---
RH bug is at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150157
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
19:25 ---
> It really seems like the C++ front end is doing the right thing,
> abstractly -- these functions don't have side-effects! So, either the
> inliner or stabilize reference seems like it needs fixing. M
--- Additional Comments From dje at gcc dot gnu dot org 2005-03-03 19:26
---
Example Fortran code derived from BLAS ZGEMM routine.
SUBROUTINE Z ( M, N, C, LDC )
* .. Scalar Arguments ..
INTEGERM, N, LDC
* .. Array Arguments ..
COMPLEX*16 C(
--- Additional Comments From steve at netfuel dot com 2005-03-03 19:31
---
I have looked for this bug and did not see one.
15501 is similar but is not the same problem or is a subset of the problems
defined in my report. As my bug also affects any Extends with Exceptions
defined in the
--- Additional Comments From mark at codesourcery dot com 2005-03-03 19:34
---
Subject: Re: [3.4 Regression] const/pure functions result
in bad asm
ebotcazou at gcc dot gnu dot org wrote:
> --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
> 19:25 ---
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Target Milestone|---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
19:48 ---
Confirmed, C testcase which shows that this is defintely a regression:
void f(double _Complex *f,int len)
{
int i = 0;
for(i = 0 ;i<20;i++)
{
*f = 0.0;
f++;
}
}
--
What|Remo
--- Additional Comments From ericw at evcohs dot com 2005-03-03 19:49
---
Subject: Re: AVR assignment of a value through a 16 bit
pointer generates out of order code
schlie at comcast dot net wrote:
>--- Additional Comments From schlie at comcast dot net 2005-03-03 19:47
>-
--
What|Removed |Added
Keywords||build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
19:52 ---
Just a note from 20282, since I think this is the same bug:
the breakage appeared between 20041027 and 20041101.
--
What|Removed |Added
--
--- Additional Comments From schlie at comcast dot net 2005-03-03 19:47
---
(In reply to comment #6)
Nope, these are peripheral i/o registers, and like any pheripheral interface
may have
access sequence requirements which need to be satsifyed within it's driver.
These
perpheral registe
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-03 20:10
---
There are two routines likely miscompiled in libcpp/macro.c:
replace_args and cpp_get_token (I removed all static keywords from the file,
then did a binary search on which routines cause this).
If all of macro
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-03
20:27 ---
Same thing on i686:
$ gfortran write-many.f
$ time ./a.out
real0m5.576s
user0m5.508s
sys 0m0.038s
$ g77 write-many.f
$ time ./a.out
real0m3.252s
user0m3.185s
sys 0m0.041s
--
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 20:51
---
Working on this.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
21:12 ---
> I don't think I'd try to be that clever. We might want the
> stabilization to occur even in other cases. In looking at it more
> closely, it definitely looks like stabilize_reference should deal with
In the program:
--
extern "C" int puts(const char*);
template
void foo(A a, B b)
{
puts("ERROR: foo");
}
template
void bar(X a)
{
#ifdef ERROR
::foo(a, a);
#else
foo(a, a);
#endif
}
template
void foo(A a, A b)
{
puts("OK: foo");
}
int main()
{
int a = 0;
bar(
--- Additional Comments From daney at gcc dot gnu dot org 2005-03-03 21:19
---
Thanks Richard,
The patch applies cleanly against 3.4.3 (with an offset of something like 9
lines). I found no regressions with a top level make -k check for an i686-linux
-> mipsel-linux cross compiler with
--- Additional Comments From mark at codesourcery dot com 2005-03-03 21:19
---
Subject: Re: [3.4 Regression] const/pure functions result
in bad asm
ebotcazou at gcc dot gnu dot org wrote:
> --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
> 21:12 ---
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 21:36
---
BTW I will also propose a patch to make -fno-second-underscore the default, once
this is fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
In the attached code, the parser gets confused by a use of operator< in the
body
of a function template. If the operator is changed (to ">" or "==" for example)
the code compiles. I've not been able to figure out why it thinks it's in a
constant expression. Changing the variable names involved
--- Additional Comments From igodard at pacbell dot net 2005-03-03 21:47
---
Created an attachment (id=8321)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8321&action=view)
Compiler output (-v -save-temps)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
--- Additional Comments From igodard at pacbell dot net 2005-03-03 21:48
---
Created an attachment (id=8322)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8322&action=view)
Source code (-save-temps) (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
--- Additional Comments From stevenj at fftw dot org 2005-03-03 21:49
---
Subject: Re: COMPLEX function returns incompatible with
g77
On Thu, 3 Mar 2005, tobi at gcc dot gnu dot org wrote:
> BTW I will also propose a patch to make -fno-second-underscore the
> default, once this is fi
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-03
21:59 ---
Subject: Bug 20292
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-03 21:59:23
Modified files:
libjava: Change
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 21:59
---
This is weird. I just came across code (written by me) that should ensure the
right behavior here.
--
What|Removed |Added
--
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
22:02 ---
> There are other places where TREE_SIDE_EFFECTS matters. (Like, "do we
> have to emit this expression at all, if its result is not used?")
OK.
> The counter to your argument is that I don't see why th
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:06
---
I agree with you that -ff2c should imply -fsecond-underscore. I don't agree
that the advantages of -ff2c outweigh the disadvantages of -fno-f2c so far that
-fno-f2c should be the default. If we don't switch t
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:08
---
Found the bug. Fixing.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:17
---
Hm, there seems to be some confusion between when to use sym and when
sym->result for a function. My fix won't make it worse, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-03
22:17 ---
Subject: Bug 20292
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-03 22:17:26
Modified files:
libjava: ChangeLog
libjava/testsuite/
--- Additional Comments From fitzsim at redhat dot com 2005-03-03 22:18
---
Fixed on mainline and gcc-4_0-branch. Closing.
--
What|Removed |Added
Status|NEW
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-03-03 22:21 ---
Hi,
in order to completely resolve this issue, IIUC, one would have to sacrifice
the post-increment addressing modes. In case of the X-Register, forcing the
high-byte first rule allways would resu
--- Additional Comments From fitzsim at redhat dot com 2005-03-03 22:22
---
What platform are you on? Can you paste the exact configure and make lines that
cause the build failure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20251
--- Additional Comments From fitzsim at redhat dot com 2005-03-03 22:28
---
Also, was this a clean rebuild? In other words, did you start with an empty
build directory and empty prefix before configuring and building? If not, I
suggest you try that.
--
http://gcc.gnu.org/bugzilla/
--- Additional Comments From doko at debian dot org 2005-03-03 22:38
---
The complete build logs can be found at
http://buildd.debian.org/build.php?&pkg=gcc-snapshot
check for the 2005027 logs for i.e. powerpc and ia64.
the build starts with a clean environment. I rechecked with an un
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-03 22:39
---
The replace_args miscompilation seems to matter e.g. on:
typedef int Elf64_Dyn;
#define ElfW(type) _ElfW (Elf, 64, type)
#define _ElfW(e,w,t) _ElfW_1 (e, w, _##t)
#define _ElfW_1(e,w,t) e##w##t
ElfW(Dyn) x;
wh
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-03
22:43 ---
Subject: Re: pointer function with RESULT specified returns pointer to "ptr"
rather than "*ptr"
I have become convinced that graphical/diagrammatic rendering of some of the
structures that we are using wo
--- Additional Comments From j dot gnu at uriah dot heep dot sax dot de
2005-03-03 22:49 ---
(In reply to comment #9)
> There has been the suggestion to 1.) distinguish between pointer variables
> that
> are marked "volatile" and pointer variables that are not declared "volatile"
> a
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20292
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-03 22:54
---
In this particular case (sym vs sym->result) the right thing IMO would be to
either *always* create a sym->result variable, which takes on all the functions
attributes, or to *always* copy the attributes of the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
22:55 ---
*** Bug 20307 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From joseph at codesourcery dot com 2005-03-03
22:58 ---
Subject: Re: Can't push more than 16 nested visibility
On Thu, 3 Mar 2005, pinskia at gcc dot gnu dot org wrote:
> This is a documented behavior.
Arbitrary limits are still generally undesirable, even wh
--- Additional Comments From giovannibajo at libero dot it 2005-03-03
23:00 ---
(In reply to comment #4)
I strongly agree with everything in JSM's post. There is simply no reason for
keeping such a stupid limit, and even less for manually optimizing conditions
to enhance the limit. Us
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
22:54 ---
Nope, qualified names bind right away, see PR 11828.
And from the standard:
>From [temp.dep.candidate]:
For a function call that depends on a template parameter, if the function name
is an "unqualified-id"
--
What|Removed |Added
CC||bernie at develer dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
--- Additional Comments From olh at suse dot de 2005-03-03 23:17 ---
After this patch, gcc could not boostrap itself anymore:
TZ=UTC cvs diff -pu -D '20041031 09:00' -D '20041031 10:00' gcc/
I'm testing this patch currently on mainline:
Index: gcc/ChangeLog.12
=
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-03
23:24 ---
Subject: Re: pointer function with RESULT specified returns pointer to "ptr"
rather than "*ptr"
Is this connected with functions that return character pointers being so
completely screwed up?
- Origi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
23:25 ---
Hmm, this is the reduced testcase (but I don't know if this is invalid as
Comeau also rejects it but I think
it is valid):
template int nick(int e);
template struct operation{int nick;};
template
bool alph
--- Additional Comments From fitzsim at redhat dot com 2005-03-03 23:26
---
What do you mean "installing into a temporary location"? What does the "make
install" line look like?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20251
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
23:30 ---
Adding olh, so he does not miss the updates from this side since both bugs
really the same bug.
--
What|Removed |Added
--
--- Additional Comments From olh at suse dot de 2005-03-03 23:31 ---
the change above allowed a bootstrap of gcc-4.0.0-20050228 with itself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
23:32 ---
Adding Jakub to the CC so he does not miss the updates from this bug since this
and PR 20305 look to
be the one and same bug really. Also note olh, has identified the patch which
caused it for PPC64,
Ja
--- Additional Comments From olh at suse dot de 2005-03-03 23:52 ---
can these errors still be reproduced with current gcc 4.0 branch?
the applied patch causes regressions:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20282
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20305
--
http:/
1 - 100 of 148 matches
Mail list logo
