--- Additional Comments From d dot yu dot bolkhovityanov at inp dot nsk dot su
2004-10-13 06:53 ---
I've encountered the very same problem when trying to compile gcc-3.4 on
RedHat-7.3. The key to the problem is more obvious in Joseph's report than it
was in my case: /usr/openwin/bin/msg
--- Additional Comments From namsh at kldp dot org 2004-10-13 06:48 ---
It seems this bug was fixed. Today, I made the m6811-elf-gcc from CVS.
$ m6811-elf-gcc --version
m6811-elf-gcc (GCC) 3.4.3 20041013 (prerelease)
...
No more ICE.
I didn't use m6811-elf-gcc recently.
The previous ve
--- Additional Comments From pkprasoon at gmail dot com 2004-10-13 06:15 ---
Created an attachment (id=7334)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7334&action=view)
file correspoding to s2.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17969
--- Additional Comments From pkprasoon at gmail dot com 2004-10-13 06:14 ---
Created an attachment (id=7333)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7333&action=view)
file corresponding to s1.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17969
System: Linux columbia 2.4.21-4.EL #1 Fri Oct 3 18:13:58 EDT 2003 i686 i686 i386
GNU/Linux
Architecture: i686
$ gcc -v
Reading specs from /home/pkpras/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.2/specs
Configured with: ./configure --prefix=/home/pkpras/usr/local
Thread model: posix
gcc version 3.4.2
--
What|Removed |Added
Summary|assigning size_t to int - |assigning variable of type
|warning needs to be flagged |size_t to a variable of type
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 04:14
---
The related testcase is filed under PR 17967.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 04:02
---
4.0.0:
Execution times (seconds)
preprocessing : 0.06 ( 0%) usr 0.12 (17%) sys 0.16 ( 1%) wall
lexical analysis : 0.12 ( 1%) usr 0.23 (32%) sys 0.47 ( 3%) wall
parser
Description:
If I were to assign a size_t to an int, there is a possible data loss
(overflow error) because of that conversion, especially if the value of size_t
is > INT_MAX (as defined in limits.h ), there would be an overflow error then
and the compiler would overflow to given -
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967
3.3 can do this in 4.39s while 4.0.0 needs 14.60s.
#define ELSEIF1 else if (!a) f();
#define ELSEIF2 ELSEIF1 else if (a) ;
#define ELSEIF4 ELSEIF2 ELSEIF2
#define ELSEIF8 ELSEIF4 ELSEIF4
#define ELSEIF16ELSEIF8 ELSEIF8
#define ELSEIF32ELSEIF16ELSEIF16
#defin
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 03:55
---
Confirmed, I have found a related testcase where we are slower than 3.3.3. This one
we are faster.
The way to fix this would be run on the BB backwards.
--
What|Removed
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-13 03:20 ---
tree_redirect_edge_and_branch needs O(n) time to redirect an edge of
a SWITCH_EXPR in the worst case, where n is the number of case labels
in a SWITHC_EXPR.
Therefore, redirecting O(n) edges costs O(n^2) in ti
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 03:17
---
I had forgot to uncomment the needed line in the given source:
//for (int i = 0; i < 5; i++) test<1024>();
The comment in the source says it all though:
// As soon as I uncomment the following line
#define ELSEIF1 else if (a) b = a;
#define ELSEIF2 ELSEIF1 ELSEIF1
#define ELSEIF4 ELSEIF2 ELSEIF2
#define ELSEIF8 ELSEIF4 ELSEIF4
#define ELSEIF16ELSEIF8 ELSEIF8
#define ELSEIF32ELSEIF16ELSEIF16
#define ELSEIF64ELSEIF32ELSEIF32
#define ELSEIF128 EL
--- Additional Comments From bangerth at dealii dot org 2004-10-13 03:07 ---
Can you post the complete command line? I can't reproduce with Giovanni's
options as well as -O2 with a snapshot from 20040930.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17965
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-10-13 02:56 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 02:35
---
Confirmed (I can do this because this was basically PR 16578).
--
What|Removed |Added
#include
#include
#include
template < typename atom, int n > struct StrassenMatrix {
atom data[n][n];
StrassenMatrix < atom, n / 2 > operator() (int a, int b) {
StrassenMatrix < atom, n / 2 > result;
int offs_i = a * n / 2;
int offs_j = b * n / 2;
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 02:32
---
Actually the orginal problem was fixed on the mainline. I will file a new problem for
the bug I found
which only effects some targets.
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 02:26
---
*** Bug 17567 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17312
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 02:26
---
*** This bug has been marked as a duplicate of 17312 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 02:19
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--
What|Removed |Added
Keywords||accepts-invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17320
--
What|Removed |Added
Keywords||accepts-invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17321
--
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17318
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 02:05
---
Does this work with i686-pc-linux-gnu as the target if so this is an optimization
problem in the sense
-march=pentium3 causes the wrong code. Also does this happen on the mainline.
--
What
--- Additional Comments From bangerth at dealii dot org 2004-10-13 01:43 ---
This seems to have been broken by a patch for which Zack assumed
responsibility here:
http://gcc.gnu.org/ml/gcc/2004-10/msg00464.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17964
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 01:20
---
Confirmed.
--
What|Removed |Added
Severity|normal |enhancemen
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 01:18
---
Confirmed, this is a middle-end problem on the mainline:
#0 0x003f13ec in expand_call (exp=0x42901a00, target=0xf15798, ignore=0) at
/Users/pinskia/src/
local1/gcc/gcc/calls.c:2351
#1 0x004f3874 in expand
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 01:05
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--
What|Removed |Added
Keywords||rejects-valid
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 00:56
---
Confirmed, a regression.
--
What|Removed |Added
Status|UNCONFIRMED
The below testcase recently broke for C++.
char *p = "\q"; /* { dg-error "unknown escape" } */
int i;
The problem is the line numbers for cpp_error
come out as the last line number in the source file.
we currently see:
t.cc:2:1: warning: unknown escape sequence '\q'
instead of:
t.cc:1:11: war
--- Additional Comments From pcarlini at suse dot de 2004-10-13 00:12 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
Reso
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-13 00:11
---
Subject: Bug 17948
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-13 00:11:14
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/inclu
--- Additional Comments From ovidr at users dot sourceforge dot net 2004-10-12
23:52 ---
Created an attachment (id=7332)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7332&action=view)
The two jar files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17963
gcc version 4.0.0 20041009 (experimental)
try-noerror.jar and tryerror.jar have the *same files* contained within, just
in a different order.
gcj -c try-noerror.jar
(no error)
gcj -c try-error.jar
gnu/crypto/pki/provider/EncodedKeyFactory.java:0: fatal error: reading class
gnu.crypto.pki.provi
The following test case is compiled to use hardware vector support
for -msse, -msse2, or -mmmx even though the vector type is smaller
than what the hardware supports for float elements. The vector
variables are given an alignment of 4 bytes, causing a seg fault at
runtime.
This test case causes two different internal compiler errors in GCC when
compiled with "-m32 -maltivec", with VECSIZE either 2 or 8:
__attribute__ ((vector_size (VECSIZE))) unsigned char v1, v2, v3;
void vxor (void
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-12 23:35
---
Subject: Bug 17503
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2004-10-12 23:35:39
Modified files:
gcc: Change
The attached source code is almost directly pasted from the comments in
GNAT.Sockets, just added a loop. The behaviour is what one could call undefined,
it either crashes with a memory access volation, produces no output, or produces
a fragment of the correct output, depending on what you send. I u
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-12 23:07
---
Fixed with Mark's patch for PR 15786.
With mainline I now get:
err.cc:3: error: `size_t' has not been declared
err.cc:8: error: `size_t' has not been declared
--
What|Removed
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2004-10-
unsigned long long div16(unsigned long long n) { return n / 16; }
Without -mpowerpc64:
_div16:
slwi r0,r3,28
srwi r4,r4,4
or r4,r0,r4
srwi r3,r3,4
blr
With:
_div16:
li r0,0
rldimi r0,r3,32,0
rldimi r0,r4,0,32
srdi r4,r0,4
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 22:55
---
not all constants though (power of 2 are fine) for an example 16:
mr r12,r3
srawi r11,r3,31
srawi r9,r11,31
srawi r10,r11,31
srwi r10,r9,28
li r9,0
add
expand_divmod cannot optimize code such as
long long div10(long long n) { return n / 10; }
when BITS_PER_WORD is 32. A call to __divdi3 gets generated. By contrast, when
BITS_PER_WORD is 64, this is optimized to a multiply and a shift. I noticed
this problem on powerpc32, but it ought to affec
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 22:28
---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Keywords|
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 22:00
---
Confirmed on the mainline:
+===GNAT BUG
DETECTED==+
| 4.0.0 20041012 (experimental) (powerpc-apple-darwin7.4.1) GCC error: |
| in
--- Additional Comments From janis187 at us dot ibm dot com 2004-10-12 22:00
---
Created an attachment (id=7331)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7331&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17957
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 21:59
---
Confirmed on the mainline:
+===GNAT BUG
DETECTED==+
| 4.0.0 20041012 (experimental) (powerpc-apple-darwin7.4.1) GCC error: |
| in save_gnu_tree, at
... and by forcing garbage collection to happen frequently, like so.
laptop% /home/janis/tools/gcc-mline-20041012/bin/gcc -c --param ggc-min-expand=0
--param ggc-min-heapsize=0 bug1.c
bug1.c: In function 'vsub&#
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 21:59
---
Confirmed on the mainline:
+===GNAT BUG
DETECTED==+
| 4.0.0 20041012 (experimental) (powerpc-apple-darwin7.4.1) GCC error: |
| in gnat_to_gnu_entity
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17956
This causes an Ada bootstrap, ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg
s-fore.adb -o s-fore.o
The trees look like:
natural___XDLU_0__2147483647 r;
long_long_float t;
:
t = MAX_EXPR , ABS_EXPR >;
if (t >= 1.0e+1 == 0) goto ; else goto ;
:;
r = 2;
goto ();
:;
r = 2;
:;
t =
--- Additional Comments From tobi at gcc dot gnu dot org 2004-10-12 21:37 ---
No, that's not sufficient. mpfr_set_str apparently doesn't like spaces in constants.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17941
--- Additional Comments From tobi at gcc dot gnu dot org 2004-10-12 21:26 ---
(In reply to comment #4)
> I tried this same program with g95 before I submitted a bug and got what
> I thought was the correct results without needing the additional _8 .
> Do the standards specify that defaul
--- Additional Comments From rth at gcc dot gnu dot org 2004-10-12 21:26 ---
This is essentially a duplicate of pr17503. I'm backporting the patch from
that PR from mainline to the 3.4 branch. With that, compilation time for
the testcase is 1 minute instead of 30.
--
What
--- Additional Comments From fjahanian at apple dot com 2004-10-12 20:57 ---
tree-outof-ssa.c is not part of this patch. I accidentally checked it in. I have since
backed it out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17892
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-12 20:50
---
Subject: Bug 17892
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-12 20:50:08
Modified files:
gcc: ChangeLog tree-outof-ssa.c tree-ssa-d
PR/17892 was filed because gcc-4.0 performs an unsafe optimization of (X*C)*C into
X*(C*C).
Fix to this PR prevents certain safe transformation; such as X*2.0*2.0->X*4.0 from
taking place.
This PR is to track this enhancement.
--
Summary: Perform associative optimization when it is
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 20:31
---
I cannot reproduce this on powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17527
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-10-12 19:56
---
patch for powerpc64-linux-gnu:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01037.html
Index: gcc/config/host-linux.c
===
RCS file: /home/jgri
--- Additional Comments From hjl at lucon dot org 2004-10-12 19:52 ---
You are right. The second patch isn't needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 19:45
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 19:20
---
Note this is not a really a regression, the main issue I see here is that we are ifcvt
if(a) 1 else 0; to a and
then we copy the return part (the movzbl and ret) on the other branch but we don't
combine t
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-12 19:07
---
Subject: Bug 17952
CVSROOT:/cvs/gcc
Module name:gcc
Branch: java-gui-branch
Changes by: [EMAIL PROTECTED] 2004-10-12 19:07:48
Modified files:
libjava: Chang
Debian Bug #276227:
-- interestingly, the error message is different depending on
-- the number of enumeration elements in T1 and T2.
package Test_124 is
type T1 is (b01,b02,b03,b04,b05,b06,b07,b08,b09,b10,
b11,b12,b13,b14,b15,b16,b17,b18,b19,b20,
b21,b22,b23,b24,b
--- Additional Comments From trt at acm dot org 2004-10-12 18:52 ---
Given the problem pointed out in
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01013.html I do not see how this
patch can be readily made to work. To avoid redundant truthvalue conversion it
might be necessary e.g. to ch
--- Additional Comments From gdr at cs dot tamu dot edu 2004-10-12 18:51 ---
Subject: Re: [3.4/4.0 regression] local classes as template argument
"mmitchel at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
[...]
| Consider:
|
| template
| void f(T *);
|
| void g() {
| s
Debian Bug #276224:
-- If the expected type for an expression or name is some specific
-- tagged type, then the expression or name shall not be dynamically
-- tagged unless it is a controlling operand in a call on a
-- dispatching operation.
procedure Test_121 is
package pak1 is
type
--- Additional Comments From dalej at apple dot com 2004-10-12 18:30 ---
OK, thanks. From this it appears that the only effect of 'asm volatile' that users
can safely rely on is that such an instruction will not be deleted. If this is
agreeable to everybody, I will revise the documentat
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2004-10-
With window managers that support _NET_REQUEST_FRAME_EXTENTS no AWT (or Swing)
windows ever show. There is only the following error message.
(:6725): Gdk-WARNING **: /home/mark/sources/gtk+/gdk/x11/gdkdrawable-x11.c:912
drawable is not a pixmap or window
This was caused by the patch that delayed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 17:57
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 17:53
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
Component|target
The dominance info is incorrect for entry and exit blocks.
According to dominated_by_p, nothing dominates the exit block (which is wrong),
and nothing post-dominates the entry block (which is also wrong).
A simple example:
(gdb) p dominated_by_p (CDI_POST_DOMINATORS, ENTRY_BLOCK_PTR, EXIT_BLOCK_P
The following test case illustrates an example where dcbtst instructions are
being inserted too aggressively during FDO.
Test Case:
typedef struct {
union {
short arr[64];
short arr2[8][8];
}un;
} str, *strPtr;
str blah;
int main (int argc, char *argv[])
{
int i, x, y;
strPt
--- Additional Comments From rth at gcc dot gnu dot org 2004-10-12 17:39 ---
Ah, I see some amount of confusion here.
Yes, in the referenced message I do argue for "asm volatile" to be a scheduling
barrier. You'll note that what I'm most concerned about there is that the asm
remain in t
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 17:25
---
Confirmed, this is caused by IV-OPTS.
--
What|Removed |Added
CC|
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-12 17:21
---
Subject: Bug 17931
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-12 17:14:43
Modified files:
gcc: ChangeLog
gcc/config/i386: i
--- Additional Comments From pcarlini at suse dot de 2004-10-12 17:17 ---
Everything considered, if we have to use an additional iterator next, probably is
better just reverting my stupid change and return to:
while (__first != __last)
erase(__first++);
--
http://gcc.gnu.org
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 17:16
---
I send out the email for the patch but it looks like the web archiver is not working.
--
What|Removed |Added
-
IA64 sets STRICT_ALIGNMENT to 1 but the tree loop optimizer is converting byte
loads into a unaligned word load (and thus creating an unaligned access).
The attached program compiles and runs with no optimization, fails with -O1 and
works with -O1 -fno-tree-loop-optimize. With -O1 running the exe
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 17:04
---
Note for the C++ front-end at this point we don't warn for the last for statement but
we do for C, I
have a fix for the problem (I fixed while fixing another problem).
--
http://gcc.gnu.org/bugzilla/sh
--- Additional Comments From pcarlini at suse dot de 2004-10-12 16:57 ---
I'm guilty of this, sorry, your patch looks correct. Will deal with this later
today.
--
What|Removed |Added
--
What|Removed |Added
Version|0.0 |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17948
I expect the following program to produce the following output:
a 2
b 1 1
i.e, two elements go into the set, we delete one, and one remains.
However, when i compile this with the current cvs head, the program
actually does the following:
$ g++ -g -o x x.cc
$ ./x
a 2
b 0 1
$
i.e., two element
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 16:23
---
This patch fixes it, I will submit it soon:
Index: semantics.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/semantics.c,v
retrieving revision 1.446
diff
--- Additional Comments From bangerth at dealii dot org 2004-10-12 16:14 ---
Yes, me too. What a funny message :-)
BTW, this is how the bug evolved over time:
g/x> /home/bangerth/bin/gcc-4.0-pre/bin/c++ -c x.cc
x.cc: In function `int main()':
x.cc:9: warning: 'operator 1' is depre
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-12 16:13
---
As in the discussion of DR 415, it's not feasible to postpone all error messages
until overload resolution has succeeded. The example in DR 415 is that you
might need to instantiate a class type to do type
--- Additional Comments From pluto at pld-linux dot org 2004-10-12 16:09 ---
I found the second bug and I think it's related to the first report.
/ -O0 on all tests /
With -march={i[3456]86,athlon} gcc works fine.
With -march=pentium[34] gcc fails:
In file included from /usr/inc
--- Additional Comments From bangerth at dealii dot org 2004-10-12 16:07 ---
If this is put under a flag of its own, it may actually be useful. I
see no reason why we should dismiss it that quickly.
W.
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 16:07
---
Confirmed, I thought I saw a bug like this before.
--
What|Removed |Added
Status
--- Additional Comments From micis at gmx dot de 2004-10-12 16:07 ---
I will check this tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17944
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 16:06
---
Actually here is the reduced testcase:
struct C
{
C (const C &x);
};
C &f();
void breakme (C j, bool k)
{
for (;; k ? j : f()) ;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17661
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 16:04
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pluto at pld-linux dot org 2004-10-12 16:03 ---
Created an attachment (id=7330)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7330&action=view)
testcase #2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17942
1 - 100 of 141 matches
Mail list logo
