Hi. I just built GCC-4.1.1 (successfully).
My System: uname -a
Linux opus 2.6.17-rc5-git4 #1 PREEMPT Sat May 27 22:55:47 MDT 2006 i686
GNU/Linux
The build line:
gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.1/configure --enable-shared --enable-threads
Hello. This is my first post to this list, so I apologise in advance if I
get any of the 'stupid newbie' things wrong in this post. I have spent a
while reading the last month's archive.
I'm looking at the need to build a very comprehensive code optimizer and
generator for a very strange
Is anything wrong with SVN, or did my authorization to commit somehow
fall through the cracks?
Thomas
$ svn commit fortran/ChangeLog fortran/trans-array.c testsuite/ChangeLog
testsuite/gfortran.dg/multiple_allocation_2.f90
Waiting for Emacs...Done
svn: Commit failed (details follow):
On Sun, May 28, 2006 at 08:38:34PM +0200, Thomas Koenig wrote:
Is anything wrong with SVN, or did my authorization to commit somehow
fall through the cracks?
Is it maybe an anonymous checkout? Check svn info.
--
Daniel Jacobowitz
CodeSourcery
On Sun, May 28, 2006 at 02:43:20PM -0400, Daniel Jacobowitz wrote:
On Sun, May 28, 2006 at 08:38:34PM +0200, Thomas Koenig wrote:
Is anything wrong with SVN, or did my authorization to commit somehow
fall through the cracks?
Is it maybe an anonymous checkout? Check svn info.
That was it.
The machine is very strange in modern terms. It doesn't have registers, it
executes code in reverse Polish, the integer data type is a degenerate form
of the floating point data type, pointers are magic, there are no page
tables, and the word size isn't a power of 2, just to start. Oh, and
I just tried to commit the fix for PR 27470, a gfortran 4.1 regression,
and I got the error message:
$ svn commit fortran/ChangeLog fortran/trans-array.c testsuite/ChangeLog
testsuite/gfortran.dg/multiple_allocation_2.f90
Waiting for Emacs...Done
svn: Commit failed (details follow):
svn:
Hello,
I am trying to port big C/C++ programs (see www.dslinux.org) to the
nintendo DS console.
The console has 4 Mbytes internal memory, and 32 MBytes external
memory which is *not* 8bit writable (only 16 and 32 bits). CPU is an ARM
946. Using the external memory for ROM(XIP) and the internal
Dear all,
Doesn't autotools support relative paths in configure? Or is this a
particular issue of GCC's build system?
Cheers,
Manuel.
On May 28, 2006, at 1:58 PM, Manuel López-Ibáñez wrote:
Dear all,
Doesn't autotools support relative paths in configure?
The reason why you cannot pass relative paths for --prefix is because
--prefix is passed
down to all of the makefiles and others which is going to have the
wrong
Thanks Andrew, that is exactly what I did, although I was expecting
configure to be smart enough to use that trick on my behalf.
On 28/05/06, Andrew Pinski [EMAIL PROTECTED] wrote:
On May 28, 2006, at 1:58 PM, Manuel López-Ibáñez wrote:
Dear all,
Doesn't autotools support relative paths in
Hello,
When fwprop gets approved, CSE path following will disappear. We lose
virtually no optimization opportunities. Still, it should not be very
hard to make CSE work on extended basic blocks (but without rescanning
like path following does). All that would be needed is infrastructure
in
Steven Bosscher wrote:
Hello,
When fwprop gets approved, CSE path following will disappear. We lose
virtually no optimization opportunities. Still, it should not be very
hard to make CSE work on extended basic blocks (but without rescanning
like path following does). All that would be
On May 28, 2006, at 12:19 AM, Loren Wilton wrote:
I'm looking at the need to build a very comprehensive code
optimizer and
generator for a very strange (antique but still used mainframe)
machine.
Which machine out of curiosity?
--- Comment #10 from aoliva at gcc dot gnu dot org 2006-05-28 06:47 ---
Mine
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #11 from aoliva at gcc dot gnu dot org 2006-05-28 06:49 ---
Created an attachment (id=11522)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11522action=view)
Patch that appears to fix the problem
This patch, that I'm testing now, appears to fix the bug. And it even
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-05-28 09:18
---
Confirmed, Gigi is not prepared for this kind of circularity.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
file-a.c:
-
void __attribute__((weak)) func(void)
{
/* no code */
}
main()
{
func();
}
file-b.c:
-
void func(void)
{
printf(func\n);
}
# gcc -c file-a.c file-b.c -O2
# gcc -o program file-a.o file-b.o
The program will not print func, because the call to func() was
There is a problem in data dependence analysis that breaks bootstrap with
-ftree-vectorize (or any other flag that causes find_data_references_in_loop to
be called):
stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -c -g -O2 -msse2
-ftree-vectorize -DIN_GCC -W -Wall -Wwrite-strings
--- Comment #1 from pault at gcc dot gnu dot org 2006-05-28 09:45 ---
Created an attachment (id=11523)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11523action=view)
Patch to fix bug
I will submit this tonight; regtests on FC5/Athlon1700
Paul
--
The following malformed program is not diagnosed:
#include stdio.h bar
-Chris
--
Summary: Garbage at end of #include line ignored
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-28 09:50 ---
It is sad that this is not release critical, and even worse that the
contributor of vrp apparently can't miss half an hour to document his work as
he is required to do.
--
steven at gcc dot gnu dot org changed:
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-28 09:53 ---
This looks like one that the mem-ssa folks may want to give a look.
Will it be easier in mem-ssa to attach alias info to INDIRECT_REF nodes?
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from familie dot glaser at web dot de 2006-05-28 10:12
---
Right, but this only shows that the value tracking based optimization works
very well. The volatile crap is used to point out an example for situations in
which the optimizer must loose the values track. This
$ cat string_null_compare_1.f
program main
character*3 str1, str2
call setval(str1, str2)
if (str1 == str2) print *,'Should be unqual'
end
subroutine setval(str1, str2)
character*3 str1, str2
str1 = 'a' // CHAR(0) // 'a'
str2 = 'a' // CHAR(0)
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-28 11:50 ---
Then provide a real testcase please. With this report nothing is going to be
done because in the testcase, the volatiles are just crap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27771
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-28 12:03 ---
ipa-pure-const thinks that func is const, which is wrong. Then DCE comes along
and deletes the function call.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-28 12:07
---
(In reply to comment #3)
FX, Are you comming to the GCC summit?
Well, my employer has nothing to do with gfortra, so I won't be coming. But if
you ever come to Paris, I'll offer you a beer!
--
--- Comment #3 from pault at gcc dot gnu dot org 2006-05-28 12:11 ---
Arjen,
I tried this with gfortran 4.20 too (the report file was indeed
created with 4.1, but the result with the newer version was quite the
same). It happens when I build version 5.6.1 of PLplot
--- Comment #11 from tkoenig at gcc dot gnu dot org 2006-05-28 12:33
---
(In reply to comment #10)
Not committing right now.
Downloading a fresh version via svn cured that problem.
I'd have commited the patch by now, but for some strange reason,
I get Authentication failed errors
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-28 13:23
---
I tried with the following reduced testcase:
implicit none
integer :: i
logical :: l
type dt
integer, pointer :: a = null()
end type dt
type(dt), pointer :: obj(:) = null()
allocate(obj(2))
This reduced testcase is originally from the testsuite
gfortran.dg/cray_pointers_2.f90. It generates an incorrect out-of-bounds error
message when run with bounds-checking enabled.
$ cat cray_pointers_2.f90
integer targ(2)
integer pte
pointer(ptr,pte(*))
ptr = loc(targ)
targ(2) = -1
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-28 14:00 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #2 from pault at gcc dot gnu dot org 2006-05-28 14:09 ---
Created an attachment (id=11524)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11524action=view)
Patch for the bug exposed by the fix to this and PR25098
The patch for pr25098 fixes this bug but exposes another.
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-28 14:10 ---
(In reply to comment #3)
Dunno if tree loop reversal is already there, but Zdenek probably likes to
know
what bugs he is fixing...
Loop reversal doesn't occur yet.
gcc version 4.2.0 20060521 (experimental)
--- Comment #12 from berndtrog at yahoo dot com 2006-05-28 14:10 ---
--- Comment #11 from laurent at guerby dot net 2006-05-27 18:41 ---
Bernd, could you contribute (attach here) your Makefile and ada RTS changes so
that Ada build with AVR target succeeds?
Since I don't
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-05-28 14:25 ---
Subject: Re: Reverse loop order for increased efficiency
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-28 14:10
---
(In reply to comment #3)
Dunno if tree loop
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-28 14:53 ---
It's even worse:
$ cat cmp.f
program main
external isgreater
logical isgreater
print *,a ä
print *,isgreater(a, ä)
end
logical function isgreater(s1, s2)
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-28 15:20 ---
volatile makes all the optimizations turn off for that variable which means
nothing is going to happen.
This is not a bug, if you can find a testcase without volatile, please file a
new bug.
--
pinskia at gcc
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-28 15:23 ---
Actually no, you have to use -fPIC to get this not to be optimized, otherwise
func will be bound locally which is not what you want.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from patchapp at dberlin dot org 2006-05-28 15:37 ---
Subject: Bug number PR25098
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01425.html
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-28 15:47 ---
*** This bug has been marked as a duplicate of 27331 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-28 15:47 ---
*** Bug 27782 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-28 15:49
---
What about simply doing:
Index: intrinsics/string_intrinsics.c
===
--- intrinsics/string_intrinsics.c (revision 113849)
+++
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-28 15:59
---
Created an attachment (id=11525)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11525action=view)
Proposed patch
I'm tempted to propose the attached patch. It makes the front-end ultimately
use unsigned
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-28 16:05 ---
(In reply to comment #1)
What about simply doing:
Index: intrinsics/string_intrinsics.c
===
--- intrinsics/string_intrinsics.c (revision
--- Comment #12 from kazu at gcc dot gnu dot org 2006-05-28 16:06 ---
Subject: Bug 26622
Author: kazu
Date: Sun May 28 16:06:36 2006
New Revision: 114167
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114167
Log:
gcc/
PR tree-optimization/26622.
* fold-const.c
--- Comment #13 from kazu at gcc dot gnu dot org 2006-05-28 16:07 ---
Now fixed on 4.1.2 and on.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-28 16:10 ---
(In reply to comment #3)
Created an attachment (id=11525)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11525action=view) [edit]
Proposed patch
I'm tempted to propose the attached patch. It makes the
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-28 16:28
---
(In reply to comment #2)
In the meantime, this patch is approved :-)
No, your patch is approved! Please go ahead and commit :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27784
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-28 16:32
---
(In reply to comment #4)
unsigned char *string;
Humpf, I don't know. I don't think it's the best course of action... too
invasive.
As far as the collating sequence goes... should we eventually
support
--- Comment #6 from kargl at gcc dot gnu dot org 2006-05-28 16:52 ---
Guys,
Have you read 4.3.2.1.1? This defines the requirements on the
collating of the default character type. It also defines the
requirements on LGT, LGE, LLE, and LLT, which is why we use the
ascii_table in
// The code has been tested with GCC 3.4.2, 4.1.1 and 4.2.0 (alpha) and fails.
// It compiles successfully with Comeau (= 4.2) and VisualC++ (=7.1).
templatetypename X
struct x
{
templatetypename Y
struct y
{
typedef Y type;
};
};
templatetypename A
struct a : xA
{
// supposed to
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-28 18:42 ---
There is a defect report about this if a is really a dependent name or not (or
maybe it is the one about inherite and template and name lookup I forget).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27787
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-28 18:43 ---
Replacing a with xA, makes this work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27787
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-28 18:51 ---
http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#213
And
http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#108
Both seems a way to better understand this but I am confused with what the
standard says
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-28 18:53 ---
[kudzu:trunk/objdir/gcc] pinskia% ./xgcc -B. t.c
t.c:1:20: warning: extra tokens at end of #include directive
h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27783
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-28 18:55 ---
This is a bug in Apple's GCC as I cannot reproduce it in the FSF released
3.4.0, 4.0.0, 4.1.0 or 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-28 18:56 ---
I should note I could reproduce it with Apple's GCC though.
It has warned since 3.0.4, while 2.95.3 did:
earth:~~/ia32_linux_gcc2_95//bin/gcc t.c
t.c:1: stdio.hbar: No such file or directory
--
--- Comment #2 from bangerth at dealii dot org 2006-05-28 18:58 ---
(In reply to comment #0)
I'm not quite sure whether writing class before AN::B::C is valid
or has to be replaced by typename.
This is the subject of DR 180.
W.
--
bangerth at dealii dot org changed:
--- Comment #13 from ray at ultramarine dot com 2006-05-28 19:06 ---
Subject: Re: [4.1/4.2 Regression] Problems with direct
access io
On Sat, 28 May 2006, jvdelisle at gcc dot gnu dot org wrote:
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-05-28 00:40
--- Comment #8 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 25746
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114173
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #21 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 27155
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114173
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 27411
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114173
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 19015
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114173
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 25082
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114173
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #12 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 27449
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114173
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #8 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 27613
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114173
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 27584
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114173
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #8 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 27709
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114173
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 27584
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114174
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 25082
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114174
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 25746
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114174
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 27411
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114174
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 27709
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114174
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #22 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 27155
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114174
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 27613
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114174
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 19015
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114174
Log:
2006-05-28 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #11 from pault at gcc dot gnu dot org 2006-05-28 19:52 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2006-05-28 19:53 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:54 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2006-05-28 19:54 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pault at gcc dot gnu dot org 2006-05-28 19:55 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:56 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-05-28 19:56
---
(In reply to comment #6)
Have you read 4.3.2.1.1? This defines the requirements on the
collating of the default character type. It also defines the
requirements on LGT, LGE, LLE, and LLT, which is why we use
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:57 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from pault at gcc dot gnu dot org 2006-05-28 19:58 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-28 20:03 ---
(In reply to comment #7)
(In reply to comment #6)
Have you read 4.3.2.1.1? This defines the requirements on the
collating of the default character type. It also defines the
requirements on LGT, LGE, LLE,
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-28 20:05 ---
(In reply to comment #7)
Yes, but C strings are char by default and not unsigned char, so I guess we'd
best avoid changing that. But, a less invasive fix could be:
And char can either default to unsigned or
--- Comment #12 from tkoenig at gcc dot gnu dot org 2006-05-28 20:36
---
Subject: Bug 27470
Author: tkoenig
Date: Sun May 28 20:35:53 2006
New Revision: 114176
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114176
Log:
2005-05-28 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #13 from tkoenig at gcc dot gnu dot org 2006-05-28 20:37
---
Fixed on trunk and 4.1.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-28 20:47 ---
Something is removing the store to _M_start.
this_252 = (struct _Vector_baseB*,std::allocatorB* *) b;
this_253 = this_252;
# VUSE SMT.84_402;
D.13530_256 = this_252-_M_impl._M_start;
I think the cast
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-28 20:50 ---
This is related to PR 19817, the C++ front-end is producing that construct
which causes us not to constant prop zero.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27768
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-28 20:52 ---
But even without fixing PR 19817, it seems like the cast should be valid, or
maybe not someone who knows if the cast is valid in C++ where the struct is not
an inheirtance.
--
pinskia at gcc dot gnu dot org
--- Comment #4 from tschwinger at neoscientists dot org 2006-05-28 21:47
---
It seems my report is missing some detail.
Here's my apology and an attempt to outline my standard interpretation that
makes me think it is a bug.
(In reply to comment #0)
templatetypename X
struct x
{
The well-formed program below fails to compile with gcc 4.1.0:
$ cat t.cpp gcc -c t.cpp
template class T void foo (T*) { }
typedef void F ();
F* f = (F*)fooint;
t.cpp:5: error: address of overloaded function with no contextual type
information
--
Summary: error casting address of
This revision to gcc/cp
2006-05-24 Mark Mitchell [EMAIL PROTECTED]
PR c++/20103
* decl.c (cp_make_fname_decl): Don't set DECL_INITIAL to
error_mark_node to indicate an initialization is OK.
(start_decl): Likewise. Adjust call to start_decl_1.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-29 00:12 ---
It is only valid after DR 115. This is a dup of bug 11407.
*** This bug has been marked as a duplicate of 11407 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
1 - 100 of 111 matches
Mail list logo
