--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-02-18 08:36
---
Subject: Bug 26266
Author: mmitchel
Date: Sat Feb 18 08:36:11 2006
New Revision: 111229
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111229
Log:
PR c++/26266
* cp-tree.h (cp_finish_decl)
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-02-18 08:37
---
Subject: Bug 26266
Author: mmitchel
Date: Sat Feb 18 08:37:11 2006
New Revision: 111230
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111230
Log:
PR c++/26266
* g++.dg/template/static22.C
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
|
--- Comment #12 from mmitchel at gcc dot gnu dot org 2006-02-18 08:37
---
Subject: Bug 26266
Author: mmitchel
Date: Sat Feb 18 08:37:34 2006
New Revision: 111231
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111231
Log:
PR c++/26266
* cp-tree.h (cp_finish_decl)
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-02-18 09:40
---
Subject: Bug 26266
Author: mmitchel
Date: Sat Feb 18 09:40:03 2006
New Revision: 111233
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111233
Log:
PR c++/26266
* cp-tree.h (cp_finish_decl)
--- Comment #14 from mmitchel at gcc dot gnu dot org 2006-02-18 09:41
---
Subject: Bug 26266
Author: mmitchel
Date: Sat Feb 18 09:41:18 2006
New Revision: 111234
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111234
Log:
PR c++/26266
* cp-tree.h (cp_finish_decl)
--- Comment #15 from mmitchel at gcc dot gnu dot org 2006-02-18 09:41
---
Only the accepts-invalid in Comment #7 remains.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-02-18 09:51
---
The reason that the first and last examples are accepted is that, were there
dependent base classes, we would have no way of knowing whether or not those
base classes might declare a virtual function for which this
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #1 from schwab at suse dot de 2006-02-18 11:09 ---
Also seen on ia64, 2GB is not enough to compile this file.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #5 from jsm28 at gcc dot gnu dot org 2006-02-18 11:12 ---
Subject: Bug 24837
Author: jsm28
Date: Sat Feb 18 11:12:51 2006
New Revision: 111235
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111235
Log:
PR target/24837
* config.gcc: Define UCLIBC_DEFAU
--- Comment #2 from laurent at guerby dot net 2006-02-18 11:15 ---
Jeff mentionned "ping pong" between passes, I believe it's an infinite
ping-pong loop between two things with memory usage increasing linearly (either
leak or data structures) until the system kills the process. gdb trace
--- Comment #6 from jsm28 at gcc dot gnu dot org 2006-02-18 11:17 ---
Subject: Bug 24837
Author: jsm28
Date: Sat Feb 18 11:17:08 2006
New Revision: 111236
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111236
Log:
PR target/24837
* gcc/config.gcc: Define UCLIBC_D
--- Comment #7 from jsm28 at gcc dot gnu dot org 2006-02-18 11:20 ---
Fixed for 4.2.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
config/i386/i386.h suggests a value to force a 486, but the value would force a
pentium.
Matthias
/* configure can arrange to make this 2, to force a 486. */
#ifndef TARGET_CPU_DEFAULT
#define TARGET_CPU_DEFAULT TARGET_CPU_DEFAULT_generic
#endif
[...]
#define TARGET_CPU_DEFAULT_i386 0
#defi
--- Comment #19 from dcb314 at hotmail dot com 2006-02-18 12:09 ---
(In reply to comment #17)
> Created an attachment (id=10869)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10869&action=view) [edit]
> patch
>
> I'm currently testing this patch.
I tried out the suggested patch o
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-02-18 12:28
---
Also make sure not to trip on
typedef struct {
int len;
char str[4];
} String;
char foo(String *s)
{
return s->str[42];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
--- Comment #21 from mueller at gcc dot gnu dot org 2006-02-18 12:39
---
hmm, thanks. it should have looked like this:
+ case TRY_FINALLY_EXPR:
+ case TRY_CATCH_EXPR:
+array_offset_warning (&TREE_OPERAND (t, 0));
+array_offset_warning (&TREE_OPERAND (t, 1));
+
--- Comment #22 from mueller at gcc dot gnu dot org 2006-02-18 12:42
---
Richard: Under which assumption? because the array size is <= sizeof(int) ?
Why not suppressing the warning by changing the code to:
typedef struct {
int len;
char str[0];
} String;
?
--
http://gcc.gnu
--- Comment #23 from falk at debian dot org 2006-02-18 12:58 ---
(In reply to comment #21)
> hmm, thanks. it should have looked like this:
>
> + case TRY_FINALLY_EXPR:
> + case TRY_CATCH_EXPR:
> +array_offset_warning (&TREE_OPERAND (t, 0));
> +array_offset_warn
We ICE building hercules for powerpc32. Reduced testcase, build with
-O2 -fPIC -mlong-double-128:
typedef int int32_t __attribute__ ((__mode__ (__SI__)));
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
typedef struct REGS REGS;
typedef union { uint32_t F; } FW;
typedef
--- Comment #24 from rguenth at gcc dot gnu dot org 2006-02-18 13:15
---
(In reply to comment #22)
We need to allow offsetting beyond the declared array size if this array is the
last member of a structure. This is refered to as "malloc trick" to allocate
variable sized structures wit
--- Comment #25 from falk at debian dot org 2006-02-18 13:25 ---
(In reply to comment #24)
> We need to allow offsetting beyond the declared array size if this array is
> the
> last member of a structure. This is refered to as "malloc trick" to allocate
> variable sized structures with
Invoking java.util.ResourceBundle.getBundle(String) leaks some native memory.
A small sample program is attached. If you run it, you will see that the
process' virual memory size keeps growing while Java heap consumption stays at
a same level after some iteration.
The problem is in gnu.gcj.runti
--- Comment #26 from rguenth at gcc dot gnu dot org 2006-02-18 13:44
---
I agree that the false positives would be acceptable. One could even warn for
[0] and [1] arrays if std=c99 (I believe flexible array members were not in
c89, but i didn't check).
For a way to check if an array a
--- Comment #5 from steven at gcc dot gnu dot org 2006-02-18 14:32 ---
For the record, AMD64 (usr-)timings:
GCC 4.0 GCC 4.1
0m5.412s0m4.400s
0m5.388s0m4.404s
0m5.408s0m4.404s
So for AMD64 we in fact booked significant progress in GCC 4.1 wrt. GCC 4.0.
--- Comment #27 from dcb314 at hotmail dot com 2006-02-18 14:33 ---
(In reply to comment #21)
> hmm, thanks. it should have looked like this:
I tried your second patch, and the compile of the compiler got as far
as the following
/home/dcb/gnu/42-20060211/working/./prev-gcc/xgcc
-B/home
--- Comment #6 from steven at gcc dot gnu dot org 2006-02-18 14:36 ---
Timings with the same compilers on the same machine, but with -m32
-march=pentium4 (but still with -O2):
GCC 4.0 GCC 4.1
0m4.148s0m8.817s
0m4.140s0m8.785s
0m4.164s0m8.761s
So:
1) We p
--- Comment #7 from steven at gcc dot gnu dot org 2006-02-18 14:39 ---
Loop body with GCC 4.1:
:;
j = i + 1;
if (cnt > j) goto ; else goto ;
:;
ivtmp.49 = (int *) ivtmp.54;
j.56 = j;
:;
D.2857 = (int *) j;
D.2751 = MEM[base: lst, index: D.2857, step: 4B, offset: 4294967292B
--- Comment #8 from steven at gcc dot gnu dot org 2006-02-18 14:39 ---
Loop body with GCC 4.0:
:;
j = i + 1;
if (cnt > j) goto ; else goto ;
:;
ivtmp.22 = (int *) ivtmp.31;
ivtmp.19 = 0;
:;
D.2609 = *((int *) ivtmp.31 + 4294967292B);
D.2657 = (int *) ivtmp.22;
D.2614 = *
--- Comment #3 from law at redhat dot com 2006-02-18 14:47 ---
Subject: Re: ICE compiling a-textio.adb at -O1 -ftree-vrp
On Sat, 2006-02-18 at 11:15 +, laurent at guerby dot net wrote:
>
> --- Comment #2 from laurent at guerby dot net 2006-02-18 11:15 ---
> Jeff mentionne
--- Comment #28 from giovannibajo at libero dot it 2006-02-18 14:48 ---
Jakub, you have provided some infrastructure to compute object size and provide
warnings for unsafe use of builtins. Do you believe that infrastructure could
be reused/enhanced for this bug?
--
giovannibajo at li
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-18 14:56 ---
Would have been nice if you put the error message in the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-18 15:03 ---
This works in 4.2.0 20060218.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-18 15:08 ---
Error message is
ieee.min2.i:25: error: unrecognizable insn:
(insn 64 63 30 1 (set (reg:DF 8 8)
(mem/u/c/i:DF (symbol_ref/u:SI ("*.LC3") [flags 0x2]) [12 S8 A64])) -1
(nil)
(nil))
ieee.min2.i:25: interna
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-18 15:19 ---
The difference between 4.1 and 4.2 come in the schedule1 pass.
4.1 does something while it looks like 4.2 does not.
-fno-schedule-insns on 4.1 "fixes" the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2635
--- Comment #29 from jakub at gcc dot gnu dot org 2006-02-18 15:24 ---
Yes, fairly easily.
Just add another pass, probably into tree-object-size.c, where you:
init_object_sizes ();
and for each ARRAY_REF compute objsz = compute_builtin_object_size
(TREE_OPERAND (array_ref, 0), 0) and if
--
Summary: ICE
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gc
--- Comment #1 from igodard at pacbell dot net 2006-02-18 15:48 ---
Created an attachment (id=10873)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10873&action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
--- Comment #2 from igodard at pacbell dot net 2006-02-18 15:48 ---
Created an attachment (id=10874)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10874&action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
--- Comment #3 from sje at gcc dot gnu dot org 2006-02-18 15:58 ---
Subject: Bug 26189
Author: sje
Date: Sat Feb 18 15:58:06 2006
New Revision: 111237
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111237
Log:
PR target/26189
* inclhack.def (hpux_spu_info): New.
--- Comment #4 from sje at gcc dot gnu dot org 2006-02-18 16:00 ---
Subject: Bug 26189
Author: sje
Date: Sat Feb 18 15:59:57 2006
New Revision: 111238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111238
Log:
PR target/26189
* inclhack.def (hpux_spu_info): New.
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-18
16:00 ---
Subject: Re: FAIL: gfortran.dg/secnds.f -O0 execution test
> This test can sometimes fail if you have a lot of background tasks running.
I believe that the only taks running were those associated with
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-18 16:07 ---
g++: Internal error: Killed (program cc1plus)
means memory was over used.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
I saw 9% regression in SPEC CPU 2K 175.vpr -O2 number on Nocona between gcc
3.4.4 and gcc 4.2. Gcc 4.1 and 4.0 have similar regression.
--
Summary: [4.2/4.1/4.0]: 9% regresssion in SPEC CPU 2K 175.vpr on
Nocona
Product: gcc
Version: 4.2.0
--- Comment #13 from danglin at gcc dot gnu dot org 2006-02-18 16:12
---
Subject: Bug 13408
Author: danglin
Date: Sat Feb 18 16:12:20 2006
New Revision: 111240
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111240
Log:
PR ada/13408
* pa.h (WIDEST_HARDWARE_FP_SIZ
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26291
--- Comment #14 from danglin at gcc dot gnu dot org 2006-02-18 16:15
---
Subject: Bug 13408
Author: danglin
Date: Sat Feb 18 16:15:07 2006
New Revision: 111241
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111241
Log:
PR ada/13408
* pa.h (WIDEST_HARDWARE_FP_SIZ
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-18 16:16 ---
What is the issue here except for the fact vrp regressed? There is not enough
information even start to look into this bug until there is a testcase which
people who don't have access to SPEC (me) to start looking i
--- Comment #2 from pault at gcc dot gnu dot org 2006-02-18 16:16 ---
A patch is on its way - it's regtesting right now.
This fixes the problem with where_19.f90 as well.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from danglin at gcc dot gnu dot org 2006-02-18 16:17
---
Subject: Bug 13408
Author: danglin
Date: Sat Feb 18 16:17:46 2006
New Revision: 111242
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111242
Log:
PR ada/13408
* pa.h (WIDEST_HARDWARE_FP_SIZ
--- Comment #16 from danglin at gcc dot gnu dot org 2006-02-18 16:21
---
Subject: Bug 13408
Author: danglin
Date: Sat Feb 18 16:21:06 2006
New Revision: 111243
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111243
Log:
PR ada/13408
* pa.h (WIDEST_HARDWARE_FP_SIZ
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-18 16:22 ---
I cannot reproduce this at all in 4.0.2, 4.0.0, or 4.0.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
--- Comment #17 from danglin at gcc dot gnu dot org 2006-02-18 16:27
---
Fixed by patch.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #2 from hjl at lucon dot org 2006-02-18 16:37 ---
From
http://people.redhat.com/dnovillo/spec2000.em64t/gcc/log/20060118/CINT2000.759.asc
175.vpr 1400 315 444* 1400 317 442*
From
http://people.redhat.com/dnovillo/spec2000.em64t/baseli
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-18 16:38 ---
I would not trust Diego's numbers with my life.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26353
--- Comment #4 from danglin at gcc dot gnu dot org 2006-02-18 16:41 ---
Also seen on hppa-unknown-linux-gnu:
/home/dave/gnu/gcc-4.2/objdir/./gcc/xgcc -B/home/dave/gnu/gcc-4.2/objdir/./gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-
4.2.0/hppa-linux/
--- Comment #5 from dje at gcc dot gnu dot org 2006-02-18 16:47 ---
This appears to be related to -fpic. The SYMBOL_REF is considered small data
and rs6000_legitimate_small_data_p() includes !flag_pic. What is generating
this when -fpic?
--
dje at gcc dot gnu dot org changed:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-18 17:02 ---
Saw it too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-18 17:13 ---
Confirmed fixed. Thanks Roger.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from hjl at lucon dot org 2006-02-18 17:14 ---
I have seen 9% myself. We are trying to isolate the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26353
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-18 17:22 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-18 17:22 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #7 from dje at gcc dot gnu dot org 2006-02-18 17:24 ---
Reload is creating the symbol_ref from the extenddftf2 splitter, which is
trying to load 0.0. I think this is a case where we need to expand
legitimize_reload_address(). Darwin uses that to fix up these insns, but it
c
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-02-18 17:32 ---
Acutally f3 is not fixed but I don't understand how not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18908
--- Comment #4 from pault at gcc dot gnu dot org 2006-02-18 17:52 ---
A patch is on its way for the immediate problem; however, the more complicated
cases of loop reversal and of dependecy involving expressions will have to
wait.
Paul
--
pault at gcc dot gnu dot org changed:
* stmt.c (decl_overlaps_hard_reg_set_p): Use DECL_HARD_REGISTER
instead of DECL_REGISTER.
* gcc.c-torture/compile/20060217-1.c: New test.
* gcc.dg/20060218-1.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20060217-1.c
trunk/gcc/testsuite/gcc.dg/20060218-1.c
Modified:
--- Comment #7 from jakub at gcc dot gnu dot org 2006-02-18 19:04 ---
Subject: Bug 26334
Author: jakub
Date: Sat Feb 18 19:04:08 2006
New Revision: 111248
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111248
Log:
PR middle-end/26334
* gcc.dg/20060218-
--- Comment #7 from eedelman at gcc dot gnu dot org 2006-02-18 19:52
---
Here's a small one-liner patch that I think fixes the bug. I'll post it to the
mailing list later tonight if/when it passes regression testing.
Index: gcc/fortran/intrinsic.c
=
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-18 19:58 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from julius at zgod dot cjb dot net 2006-02-18 20:37 ---
On another system with Debian Sarge, I can compile it without problems. It is
then compiled for i686 though instead of i586. Could it be that only compiling
i586 is a problem? Should I try compiling it for i486 or i3
--- Comment #8 from dje at gcc dot gnu dot org 2006-02-18 20:43 ---
Created an attachment (id=10875)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10875&action=view)
patch to place constant 0.0 in MEM and validize to create GOT reference
--
dje at gcc dot gnu dot org changed:
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-18 21:09 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-18 21:09 ---
Subject: Bug 25680
Author: pinskia
Date: Sat Feb 18 21:09:35 2006
New Revision: 111251
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111251
Log:
2006-02-18 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #6 from law at redhat dot com 2006-02-18 21:36 ---
Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
-O1 -ftree-vrp
On Sat, 2006-02-18 at 17:02 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #5 from pinskia at gcc dot gnu dot org 2006-0
--- Comment #7 from law at redhat dot com 2006-02-18 21:49 ---
Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
-O1 -ftree-vrp
On Sat, 2006-02-18 at 17:02 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #5 from pinskia at gcc dot gnu dot org 2006-0
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-02-18 22:07
---
Subject: Bug 17106
Author: rsandifo
Date: Sat Feb 18 22:06:53 2006
New Revision: 111254
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111254
Log:
* cselib.c (cselib_init): Change RTX_SIZE to RTX_C
--- Comment #8 from rsandifo at gcc dot gnu dot org 2006-02-18 22:07
---
Subject: Bug 9703
Author: rsandifo
Date: Sat Feb 18 22:06:53 2006
New Revision: 111254
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111254
Log:
* cselib.c (cselib_init): Change RTX_SIZE to RTX_CO
I'm not 100% sure if this is a compiler bug or a bug in my code but I think
that what I'm trying to do should be valid according to 14.7.5/4 of the C++
Standard. Please consider the following example:
% cat stsp.cpp
enum V { V1, V2, V3 };
template struct Data { static int Value; };
int Data::Va
--- Comment #9 from rsandifo at gcc dot gnu dot org 2006-02-18 22:22
---
The patch I committed should provide the general infrastructure,
but an ARM patch will be needed to make use of it. ARM code
would also benefit if we tried to reuse addresses that the
function had to calculate any
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-02-18 22:25
---
With the patch that I just committed, you should be able to
get the desired behaviour using -fsection-anchors.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-18 22:26 ---
*** Bug 26355 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-18 22:26 ---
This is invalid code. This is a dup of bug 22095.
The diagnostic issue is filed under PR 20118.
*** This bug has been marked as a duplicate of 22095 ***
--
pinskia at gcc dot gnu dot org changed:
W
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-18 22:28 ---
Also see PR 11930 for more help with the issue adding template<> does not emit
the variable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26355
--- Comment #3 from vz-gcc at zeitlins dot org 2006-02-18 22:47 ---
First, thanks a lot Andrew for your lightning fast reply, this is really
amazing -- and incredibly helpful!
Second, really sorry, rereading the explicit specialization section once again
I see that I was indeed wrong an
--- Comment #8 from multix at gmail dot com 2006-02-18 23:04 ---
this happens on 3.3.6 too, but I read
http://gcc.gnu.org/ml/gcc/2003-10/msg00110.html
who was able to build 3.3.1 on an even older system. Differences are that he
disabled multilib and shared libraries. I don't see how th
--- Comment #9 from dje at gcc dot gnu dot org 2006-02-18 23:16 ---
libstdc++ configuration may have detected that the particular feature causing
problems was not present or the header may not have defined the function at
all, causing libstdc++ to provide its own implementation.
The usu
--- Comment #9 from dje at gcc dot gnu dot org 2006-02-18 23:19 ---
Subject: Bug 26350
Author: dje
Date: Sat Feb 18 23:19:02 2006
New Revision: 111255
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111255
Log:
PR target/26350
* config/rs6000/rs6000.md (extenddftf
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu
2006-02-18 23:54 ---
Subject: Re: [4.1/4.2 regression] __convert_i4_i8 written to a module.
On Sat, Feb 18, 2006 at 07:52:27PM -, eedelman at gcc dot gnu dot org
wrote:
>
>
> Index: gcc/fortran/intrinsic.c
> ===
Currently gcc/doc/contrib.texi has four lists:
- "main" gcc contributors.
- gnats contributors
- libgcj/classpath contributors
- testers
They should be merged.
--
Summary: contrib.texi contributors lists need merging
Product: gcc
Version: 4.1.0
Stat
--- Comment #8 from law at redhat dot com 2006-02-19 00:16 ---
Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
-O1 -ftree-vrp
On Sat, 2006-02-18 at 17:02 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #5 from pinskia at gcc dot gnu dot org 2006-0
--- Comment #9 from laurent at guerby dot net 2006-02-19 00:23 ---
May be Richard Kenner could help here?
--
laurent at guerby dot net changed:
What|Removed |Added
rguenth at gcc dot gnu dot org wrote:-
> Also make sure not to trip on
>
> typedef struct {
> int len;
> char str[4];
> } String;
>
> char foo(String *s)
> {
> return s->str[42];
> }
That definitely deserves a warning.
Neil.
--- Comment #30 from neil at daikokuya dot co dot uk 2006-02-19 00:52
---
Subject: Re: no compile time array index checking
rguenth at gcc dot gnu dot org wrote:-
> Also make sure not to trip on
>
> typedef struct {
> int len;
> char str[4];
> } String;
>
> char foo(String *s)
One of the SPEC CPU 2006 benchmark uses unformatted input and it failed at
the rune time.
--
Summary: Unformated input doesn't work
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: l
--- Comment #1 from hjl at lucon dot org 2006-02-19 01:15 ---
Created an attachment (id=10876)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10876&action=view)
A testcase
I got
[EMAIL PROTECTED] unformated]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/gfortran
-B/export/bui
--- Comment #2 from lucier at math dot purdue dot edu 2006-02-19 01:16
---
Subject: Re: Timouts in libgomp tests with --with-long-double-128
On Feb 16, 2006, at 2:41 PM, pinskia at gcc dot gnu dot org wrote:
> First --with-long-double-128 does nothing on Darwin.
Does it do nothing
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-19 01:19 ---
unformated input is not portable at all and should be baned from SPEC unless
the test is also writting out the unformated data.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-19 01:20 ---
I am tempting at closing this as invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-19 01:30 ---
http://gcc.gnu.org/onlinedocs/gcc-3.0.1/g77_20.html#SEC662
Says they are not portable.
Why are they trying to use unformatted input?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
1 - 100 of 121 matches
Mail list logo
