Hey Eyal,
I see two kinds of warnings:
warning: logical '||' with non-zero constant will always evaluate as
true
warning: logical '' with non-zero constant will always evaluate as
true
The first statement is true, the second false.
You're right. Can you please file a PR
Hi All,
I am getting out of memory strings error log of our product. It
seems that error message out of memory doesn't have our common error
format.
We suspect that GCC library libstdc++.a is giving this error code.
#strings libstdc++.a | egrep out of memory
out of memory
Can you please
I am getting out of memory strings error log of our product. It
seems that error message out of memory doesn't have our common error
format.
This is most probably coming from:
include/backward/defalloc.h
where:
template class _Tp
inline _Tp* allocate(ptrdiff_t __size, _Tp*) {
Hello,
$ g++ -c err.cc
err.cc:7: error: prototype for 'void Cint::foo(const int)' does not match
any in class 'Cint'
err.cc:3: error: candidate is: void CT::foo(const T) [with T = int]
err.cc:7: error: template definition of non-template 'void Cint::foo(const
int)'
$
Note that substituting
Bernd Schmidt wrote:
insn 5301: (set (reg/f:SI 4082) (reg/f:SI 3275))
insn 5291 (set (reg:DF 4078])
(mem/s:DF (plus:SI (reg/f:SI 3275) (reg:SI 3812
REG_DEAD 3275
insn 5314 (set (reg:DF 4096)
(mem/s:DF (plus:SI (reg/f:SI 4082) (reg:SI 4084
After reload we end up
Bootstrapping today's trunk (rev. 125180) on i386-mingw32 (native)
leads me to the following error at the end of stage3:
make[3]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/
libiberty/testsuite'
make[3]: Entering directory `/home/coudert/ibin/i386-pc-mingw32/
libiberty'
make[3]:
Eyal Lebedinsky wrote:
I see two kinds of warnings:
warning: logical '||' with non-zero constant will always evaluate as true
warning: logical '' with non-zero constant will always evaluate as true
The first statement is true, the second false. It can say (if the case is
such) warning:
FX Coudert [EMAIL PROTECTED] writes:
Bootstrapping today's trunk (rev. 125180) on i386-mingw32 (native)
leads me to the following error at the end of stage3:
make[3]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/
libiberty/testsuite'
make[3]: Entering directory
Dave Korn [EMAIL PROTECTED] writes:
On 30 May 2007 18:05, Andreas Schwab wrote:
Lothar Werzinger writes:
Eyal Lebedinsky wrote:
I see two kinds of warnings:
warning: logical '||' with non-zero constant will always evaluate as true
warning: logical '' with non-zero constant will always
On 30 May 2007 18:12, Andreas Schwab wrote:
Dave Korn [EMAIL PROTECTED] writes:
On 30 May 2007 18:05, Andreas Schwab wrote:
Lothar Werzinger writes:
Eyal Lebedinsky wrote:
I see two kinds of warnings:
warning: logical '||' with non-zero constant will always evaluate as
true
Andreas Schwab wrote:
1 0 is still 0.
Andreas.
Oops my bad. Didn't think (long enough) before posting ;-)
Lothar
Hi,
We are pleased to announce the release of AspeCt-oriented C (ACC) V 0.6.
The ACC 0.6 release includes some experimental features and a new script
tacc for automatically integrating aspect-compilation in building
large C-based software projects.
For more details and download, please
On May 29, 2007, at 6:11 PM, Jack Howarth wrote:
I am wondering if it is possible that our problem with these long
double calls in gfortran on Darwin PPC could be as simple as
gfortran not using this fixed math header on Darwin PPC.
No.
Snapshot gcc-4.2-20070530 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070530/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
http://gcc.gnu.org/PR32102 is about the fact that -Wall
-Wstrict-overflow is not the same as -Wstrict-overflow -Wall (i.e.,
the order of the options matter). The reason is that -Wall sets
warn_strict_overflow to 1 and -Wstrict-overflow sets
warn_strict_overflow to 2.
It is normal and expected
On Wed, May 30, 2007 at 03:48:05PM -0700, Ian Lance Taylor wrote:
http://gcc.gnu.org/PR32102 is about the fact that -Wall
-Wstrict-overflow is not the same as -Wstrict-overflow -Wall (i.e.,
the order of the options matter). The reason is that -Wall sets
warn_strict_overflow to 1 and
Joe Buck [EMAIL PROTECTED] writes:
How about: have -Wall still set warn_strict_overflow
to 1, but to have -Wall -Wstrict-overflow *or* -Wstrict-overflow -Wall
*or* just -Wstrict-overflow set it to 2? The only change would be
to prevent -Wall from *decreasing* the value.
Sure, makes sense.
On Tue, 2007-05-29 at 16:13 -0700, Andrew Pinski wrote:
On 5/29/07, Jeffrey Law [EMAIL PROTECTED] wrote:
I haven't followed PTR_PLUS development at all -- what specifically
spurred you to hack on this Andrew?
Since we lose a
lot of alignment in 4.0 after
On 5/30/07, Jeffrey Law [EMAIL PROTECTED] wrote:
On Tue, 2007-05-29 at 16:13 -0700, Andrew Pinski wrote:
The next step is to see if that patch is no longer needed for hppa
(well and fixing the hppa back-end).
I would expect you can kill that patch; I don't think you can fix
the PA backend
On 30 May 2007 16:12:12 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Joe Buck [EMAIL PROTECTED] writes:
How about: have -Wall still set warn_strict_overflow
to 1, but to have -Wall -Wstrict-overflow *or* -Wstrict-overflow -Wall
*or* just -Wstrict-overflow set it to 2? The only change
On 5/30/07 7:07 PM, Joe Buck wrote:
How about: have -Wall still set warn_strict_overflow
to 1, but to have -Wall -Wstrict-overflow *or* -Wstrict-overflow -Wall
*or* just -Wstrict-overflow set it to 2? The only change would be
to prevent -Wall from *decreasing* the value.
Yes. My idea was
--- Comment #7 from burnus at gcc dot gnu dot org 2007-05-30 06:13 ---
I attach a test file and a Makefile that returns something like `Found 34
differences', but should just find ~2 differences due to differing time stamp
and MD5 sum.
PS: The same probem occurred with g95, but is
I have a MODULE containing an INTERFACE . I then USE this interface name in
another file, but accidently specifies the namd twice after the ONLY clause.
This generates strange error messages. It's hard to say exactly what triggers
the error - it seems that it only happens for INTERFACE names.
--- Comment #1 from enok at lysator dot liu dot se 2007-05-30 08:30 ---
... I forgot to state the error message:
gfortran412 -c tst.f90
In file tst.f90:12
USE MOD, ONLY : FOO,FOO
1
Error: Symbol 'foo' referenced at (1) not found in module 'mod'
--
--- Comment #1 from joerg dot richter at pdv-fs dot de 2007-05-30 08:47
---
AIX/sed doesn't allow sed -e ''.
Can't currently attach patches. Here is it inline:
--- libstdc++-v3/include/Makefile.in.old2007-05-30 10:03:19.0
+0200
+++ libstdc++-v3/include/Makefile.in
--- Comment #9 from andrew dot stubbs at st dot com 2007-05-30 08:51
---
OK, I see what you are getting at now. The delete is defined (by the code), but
the warning concerns the destructor also.
Anyway, as you say, the warning can be silenced by casting to char*.
--
andrew dot
--- Comment #6 from jv244 at cam dot ac dot uk 2007-05-30 09:22 ---
(In reply to comment #5)
I wonder if my patch at:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01769.html
Fixes the issue.
both testcases still fail for me at -O2 with this morning's compiler (which
should include
/Philippe/Tools/Gmp --with-htmldir
Thread model: posix
gcc version 4.3.0 20070530 (experimental)
--
Summary: Misleading compilation diagnostic
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
--- Comment #2 from razya at il dot ibm dot com 2007-05-30 09:38 ---
(In reply to comment #1)
I get the same failure on powerpc64-linux-gnu.
I recreated it too, working on it. Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32146
For gcc.dg/gomp/atomic-6.c we create (x86_64)
D.2052 = (unsigned int) D.2043;
D.2056 = (unsigned int) D.2044;
D.2057 = (unsigned int) D.2043;
D.2058 = __sync_val_compare_and_swap_4 (D.2051, D.2057, D.2056);
D.2043 = (int) D.2058;
if (D.2043 != D.2052)
which compares a signed integer
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-30 10:09 ---
It looks like the following will fix it
Index: gimplify.c
===
--- gimplify.c (revision 125161)
+++ gimplify.c (working copy)
@@ -5308,7 +5308,7 @@
When compiling my code with the -ftrapv option, I would have expected the
program to detect integer overflows. However, this only seems to happen for the
8-byte integer type, and not for the other integer types.
Maybe I have a wrong expectation here, and it should only check 8-byte
integers? If
--- Comment #2 from jakub at gcc dot gnu dot org 2007-05-30 10:28 ---
Looks obvious to me (and from what I eyeballed in that routine this is
the only place that needs it). Just a minor nit, after your patch the
line is certainly over 80 characters long.
--
Hi
I am the new user to MinGW. In our company we want to use Eclipse with
MinGW. So I installed MinGW.
While building programs I encountered an error.
ERROR:
C:\gcc -c hello.c
hello.c:6: error: stray '\26' in program
hello.c:6:3: warning: no newline at end of file
my
--- Comment #6 from patchapp at dberlin dot org 2007-05-30 13:15 ---
Subject: Bug number PR32103
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/2007-05/msg02053.html
--
I configured GCC like this:
/n/08/rask/src/gcc/configure --target=powerpc-unknown-eabisim --disable-nls
--with-newlib --enable-sim --disable-shared --enable-languages=c,c++,objc
When make runs configure in the target subdirectories, sim-crt0.o from libgloss
isn't found:
configure:2362: checking
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-30 13:23 ---
This seems to have fixed itself - all three testcases run fine on 4.3.0
20070525. I'll check it out tonight on x86_ia64 and, if all is well, I'll
clear the PR.
Paul
--
--- Comment #8 from jakub at gcc dot gnu dot org 2007-05-30 13:32 ---
Subject: Bug 29382
Author: jakub
Date: Wed May 30 13:32:34 2007
New Revision: 125182
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125182
Log:
PR bootstrap/29382
* configure.in: Don't use
--- Comment #10 from aph at gcc dot gnu dot org 2007-05-30 13:36 ---
*** This bug has been marked as a duplicate of 10632 ***
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from aph at gcc dot gnu dot org 2007-05-30 13:36 ---
*** Bug 24454 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10632
In the following code, __gfortran_os_error is thrown as unresolved at link
time. The trouble goes away if
//'=0'
is removed.
$ cat silly.f
character(16) :: str,namx
len=4
namx='abcdefg'
str=' '
str(7:)=namx(1:len)//'=0'
write (6,*) str
end
$ gfortran
--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk 2007-05-30 13:42
---
Created an attachment (id=13633)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13633action=view)
Failing program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32155
--- Comment #3 from jakub at gcc dot gnu dot org 2007-05-30 13:46 ---
Subject: Bug 31769
Author: jakub
Date: Wed May 30 13:46:25 2007
New Revision: 125183
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125183
Log:
PR tree-optimization/31769
* except.c
--- Comment #9 from jakub at gcc dot gnu dot org 2007-05-30 13:48 ---
Subject: Bug 29382
Author: jakub
Date: Wed May 30 13:48:07 2007
New Revision: 125184
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125184
Log:
PR bootstrap/29382
* configure.in: Don't use
--- Comment #4 from jakub at gcc dot gnu dot org 2007-05-30 13:49 ---
Subject: Bug 31769
Author: jakub
Date: Wed May 30 13:49:06 2007
New Revision: 125185
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125185
Log:
PR tree-optimization/31769
* except.c
--- Comment #2 from jv244 at cam dot ac dot uk 2007-05-30 13:54 ---
this one seems to work now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31221
--- Comment #5 from jakub at gcc dot gnu dot org 2007-05-30 14:00 ---
Fixed on the trunk, gcc-4_2-branch and redhat/gcc-4_1-branch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2007-05-30 14:01 ---
this still fails with current gfortran, so isn't a duplicate
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
generates an ICE, I think it is a regression
write (*,'(2A3)') 'X'//(/1,2/)//'Y'
END
--
Summary: ICE with characters
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
--- Comment #10 from jakub at gcc dot gnu dot org 2007-05-30 14:03 ---
Worked around in 4.2.1+ and on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jv244 at cam dot ac dot uk 2007-05-30 14:04 ---
the original testcase fails (again/still?)
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-30 14:11 ---
Subject: Bug 32152
Author: rguenth
Date: Wed May 30 14:11:06 2007
New Revision: 125187
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125187
Log:
2007-05-30 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2007-05-30 14:30
---
This is an aliasing issue.
true_dependence () returns '0' on mems from insns 15 and 58. This is due to
MEM_READONLY_P () flag set on them.
(insn:HI 15 13 16 3 (set (mem/u/f/c/i:DI (symbol_ref:DI
--- Comment #7 from kazu at gcc dot gnu dot org 2007-05-30 15:02 ---
Doh, I'll post a patch to move the testcase to an appropriate directory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27387
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2007-05-30 15:06
---
Created an attachment (id=13634)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13634action=view)
Patch
This patch fixes the issue but wasn't yet bootstrapped or tested in any other
way.
--
When I compile the program listed below I get the message Error: Global name
'len' at (1) is already being used as a FUNCTION at (2)
For what it's worth, Compaq, Lahey, and g95 do not consider it an error.
PROGRAM VAL
i = len( )
END
SUBROUTINE len(i)
END
--
Summary: Can a
--- Comment #1 from ubizjak at gmail dot com 2007-05-30 15:08 ---
gfortran -ffast-math -funroll-loops -O3 -msse3 -mfpmath=387 rnflow.f90
time ./a.out
user0m37.982s
profiled run:
user0m43.147s
each sample counts as 0.01 seconds.
% cumulative self self
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-30 15:12 ---
I don't think MEM_READONLY_P should be set. I think this is related to PR
31809.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2007-05-30 15:22
---
Created an attachment (id=13635)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13635action=view)
Patch
Updated patch.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2007-05-30 15:27
---
(In reply to comment #3)
I don't think MEM_READONLY_P should be set. I think this is related to PR
31809.
Memory location in question is a constant static variable in a function. When
the function is run
Here is a test program:
// Call uninitialized_fill on a type with a default copy constructor
// but no default assignment operator.
#include memory
#include utility
typedef std::pairconst int, int MyPair;
void Alpha(MyPair* start, MyPair* end) {
MyPair my_pair(1, 2);
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-30 15:46 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-30 15:56 ---
Here is the comment from rtl.h about MEM_READONLY_P:
/* 1 if RTX is a mem that is statically allocated in read-only memory. */
And not:
/* 1 in a REG, MEM, or CONCAT if the value is set at most once, anywhere.
--- Comment #5 from bonzini at gnu dot org 2007-05-30 15:57 ---
A bug with the same symptom resurfaced. David, did I understand right that
this time the problem is the huge environment passed from the toplevel
makefile?
--
bonzini at gnu dot org changed:
What
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-30 16:36 ---
Yes, it is indeed a regression, which was introduced between
2007-05-25-r125057 and 2007-05-29-r125159.
==26453==at 0x474E05: gfc_add_loop_ss_code (trans-array.c:1638)
==26453==by 0x475495:
--- Comment #8 from wdobler at ucalgary dot ca 2007-05-30 16:37 ---
PS: The same probem occurred with g95, but is fixed now.
I can reproduce this with gfortran, however, also g95 fails whereas NAG f95
has as only change the filename.
The current version (as of 30 May 2007) of g95
For following program a warning should be printed. NAG f95 prints:
Warning: yy.f90, line 9: Type declaration for generic intrinsic LEN ignored
If one changes real :: len into integer :: len, NAG f95 shows:
Warning: yy.f90, line 9: Intrinsic function LEN explicitly typed
I think it makes sense to
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-30 16:58 ---
When I compile the program listed below I get the message Error: Global name
'len' at (1) is already being used as a FUNCTION at (2)
(add NAG f95 to the list of compilers)
This is a bug in gfortran; an extended
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to
I just tried to compile Fortran package LAPACK with the
GNU Fortran compiler version 4.3 snapshot 20070525
The compiler said
/home/dcb/gcc/20070525/results/bin/gfortran -g -O3 -Wall -c clanht.f -o
clanht.o
clanht.f: In function 'clanht':
clanht.f:1: error: found a virtual definition for a GIMPLE
--- Comment #1 from dcb314 at hotmail dot com 2007-05-30 17:03 ---
Created an attachment (id=13636)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13636action=view)
fortran source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32160
--- Comment #5 from hjl at gcc dot gnu dot org 2007-05-30 17:48 ---
Subject: Bug 32098
Author: hjl
Date: Wed May 30 17:48:10 2007
New Revision: 125193
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125193
Log:
2007-05-30 H.J. Lu [EMAIL PROTECTED]
PR libjava/32098
--- Comment #6 from hjl at gcc dot gnu dot org 2007-05-30 17:52 ---
Subject: Bug 32098
Author: hjl
Date: Wed May 30 17:52:05 2007
New Revision: 125194
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125194
Log:
2007-05-30 H.J. Lu [EMAIL PROTECTED]
PR libjava/32098
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-30 17:54 ---
-ftrapv only traps floating-point overflow - no integer overflows.
(This is not completely correct, as some systems seem to offer to send FPE also
for integer overflows, see e.g.
--- Comment #7 from hjl at gcc dot gnu dot org 2007-05-30 17:54 ---
Subject: Bug 32098
Author: hjl
Date: Wed May 30 17:54:48 2007
New Revision: 125195
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125195
Log:
2007-05-30 H.J. Lu [EMAIL PROTECTED]
PR libjava/32098
--- Comment #27 from manu at gcc dot gnu dot org 2007-05-30 17:23 ---
Reminder: this will need an entry in http://gcc.gnu.org/gcc-4.3/changes.html
before closing as FIXED.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #8 from hjl at lucon dot org 2007-05-30 17:58 ---
Libjava should build again.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from fang at csl dot cornell dot edu 2007-05-30 18:00
---
test case fails with 4.2.0 (release)
test case works with 3.3.3 (x86 SuSE linux)
test case fails with 3.3 (powerpc Apple's blds. 1760/1819)
Yet 3.3.3 is currently listed under known to fail.
The mixed results on
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-30 18:02 ---
Fails with: 2007-05-25-r125057
Works with: 2007-05-24-r125013
Zdenek, I think it is one of your patches which either caused this regression
or which revealed it. Could you have a look or suggest someone to do so?
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-05-30 18:02
---
-ftrapv only traps floating-point overflow - no integer overflows.
It's the other way around, -ftrapv is meant to trap on integer operations only.
But it's well-known for being broken...
--
ebotcazou at
--- Comment #1 from patchapp at dberlin dot org 2007-05-30 18:05 ---
Subject: Bug number PR target/32130
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/2007-05/msg02078.html
--
--- Comment #2 from eweddington at cso dot atmel dot com 2007-05-30 18:09
---
Fails with 4.3-20070525, and with 4.2.0, with same error, but line 54 in
rtlhooks.c.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #19 from eweddington at cso dot atmel dot com 2007-05-30 18:59
---
Testcase succeeds with 4.3-20070525, with all -O settings. Changing target
milestone to 4.3.0, lowering priority.
--
eweddington at cso dot atmel dot com changed:
What|Removed
--- Comment #5 from eweddington at cso dot atmel dot com 2007-05-30 19:23
---
Bug still present in 4.2.0, and 4.3-20070525.
To test bug (fixed from last comment):
avr-gcc -Os shifty3.i -o shifty3.o
avr-objdump -d shifty3.o shifty3.dis
Compare output.
--
eweddington at cso dot
--- Comment #3 from eweddington at cso dot atmel dot com 2007-05-30 19:34
---
Testcase fails for 4.2.0 and 4.3-20070525.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #5 from ian at airs dot com 2007-05-30 19:41 ---
I think this is fixed by this patch:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01079.html
I am currently testing that patch.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-30 19:59 ---
Reopen...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-30 19:59 ---
...to mark as dup of PR19020.
*** This bug has been marked as a duplicate of 19020 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-05-30 19:59 ---
*** Bug 32153 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dgregor at gcc dot gnu dot org 2007-05-30 19:59 ---
The rvalue references patch (PR 29939) also implements reference collapsing as
described in core issue 106.
Unfortunately, however, Wolfgang's test case does not work even with reference
collapsing due to an
--- Comment #10 from eweddington at cso dot atmel dot com 2007-05-30 20:09
---
Test case fails for 4.3-20070525.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #4 from eweddington at cso dot atmel dot com 2007-05-30 20:29
---
Marking this bug as duplicate of bug #27386 because that bug has reduced test
case and more analysis.
*** This bug has been marked as a duplicate of 27386 ***
--
eweddington at cso dot atmel dot com
--- Comment #11 from eweddington at cso dot atmel dot com 2007-05-30 20:29
---
*** Bug 21834 has been marked as a duplicate of this bug. ***
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #10 from eweddington at cso dot atmel dot com 2007-05-30 20:40
---
Fails for 4.3-20070525
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #12 from andreast at gcc dot gnu dot org 2007-05-30 20:44
---
No negative feedback, so closing. Please reopen if not fixed.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #37 from eweddington at cso dot atmel dot com 2007-05-30 20:54
---
test.c fails in 4.2.0 for -Os only, -O[0123] works.
test.c succeeds for 4.3-20070525 for all -O[0123s].
--
eweddington at cso dot atmel dot com changed:
What|Removed
--- Comment #38 from eweddington at cso dot atmel dot com 2007-05-30 20:59
---
termios.c successful for 4.2.0, 4.3-20070525, for all -Ox.
arpcache.i successful for 4.2.0, 4.3-20070525, for all -Ox.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
--- Comment #1 from pcarlini at suse dot de 2007-05-30 21:00 ---
Curious, this is actually a C++ front-end issue, a bug in my implementation of
__is_pod: currently it just forwards to pod_type_p, in cp/tree.c, and
apparently I was wrong to assume it exactly implements the Standard
--- Comment #6 from martin dot audet at imi dot cnrc-nrc dot gc dot ca
2007-05-30 21:02 ---
I'm the original submiter of this bug and I'am not sure now if it's a bug in
g++ template instantiation mechanism (e.g. problem with the two phase name
lookup) or if the code example itself is
1 - 100 of 132 matches
Mail list logo
