--- Comment #3 from paolo dot bonzini at lu dot unisi dot ch 2006-09-21
08:21 ---
Subject: Re: [ecj] update build instructions to account for
changes
> This is found using the normal gcc specs approach. In a distribution
> I'd expect ecj1 to end up in the gcc-lib dir. In my case I
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-21 08:51 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #13 from bkoz at gcc dot gnu dot org 2006-09-21 09:00 ---
I like this solution a lot. NICE!
It seems as if everything is now consistent except for std::string. Any
thoughts on that one?
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-21 09:12 ---
Confirmed. Gimplification get's this wrong. Testcase:
extern void abort (void);
void foo(int **p, int *q)
{
*(*p++)++ = *q++;
}
int main()
{
int i = 42, j = 0;
int *p = &i;
foo(&p, &j);
if (p - 1 != &i
--- Comment #14 from pcarlini at suse dot de 2006-09-21 09:13 ---
(In reply to comment #13)
> I like this solution a lot. NICE!
>
> It seems as if everything is now consistent except for std::string. Any
> thoughts on that one?
basic_string is delicate, from many different points of vi
--- Comment #15 from bkoz at gcc dot gnu dot org 2006-09-21 10:21 ---
Ok, seems sane enough. Just curious about the omission.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
--- Comment #16 from pcarlini at suse dot de 2006-09-21 10:22 ---
(In reply to comment #15)
> Ok, seems sane enough. Just curious about the omission.
I'm going to adjust vstring first. Hopefully we can back port something to
basic_string, but really seems tricky (_S_max_size is static,
--- Comment #17 from paolo at gcc dot gnu dot org 2006-09-21 10:34 ---
Subject: Bug 29134
Author: paolo
Date: Thu Sep 21 10:34:48 2006
New Revision: 117109
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117109
Log:
2006-09-21 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
Hi,
recently I wrote the tiny program attached below to test overloading of new and
delete. Unfortunately, the overloaded delete[] operator does not get called.
:-(
System: Linux HOSTNAME 2.6.17-1.2187_FC5 #1 SMP Mon Sep 11 01:16:59 EDT 2006
x86_64 x86_64 x86_64 GNU/Linux
g++: g++ (GCC) 4.1.1 200
Hi,
recently I wrote the tiny program attached below to test overloading of new and
delete. Unfortunately, the overloaded delete[] operator does not get called.
:-(
System: Linux HOSTNAME 2.6.17-1.2187_FC5 #1 SMP Mon Sep 11 01:16:59 EDT 2006
x86_64 x86_64 x86_64 GNU/Linux
g++: g++ (GCC) 4.1.1 200
--- Comment #1 from Andreas dot Kowarz at tu-dresden dot de 2006-09-21
10:47 ---
*** This bug has been marked as a duplicate of 29164 ***
--
Andreas dot Kowarz at tu-dresden dot de changed:
What|Removed |Added
---
--- Comment #1 from Andreas dot Kowarz at tu-dresden dot de 2006-09-21
10:47 ---
*** Bug 29163 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29164
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-21 11:25 ---
EDG ends up not even calling the overloaded delete. Looking at the std I can
see no reason why your program should not use the overloaded deletes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29164
--- Comment #3 from Andreas dot Kowarz at tu-dresden dot de 2006-09-21
11:59 ---
(In reply to comment #2)
> EDG ends up not even calling the overloaded delete. Looking at the std I can
> see no reason why your program should not use the overloaded deletes.
>
For the moment, I can wor
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-09-21 12:15 ---
Subject: Re: [4.2 Regression] Misscompilation with structs due to new struct
alias
On 21 Sep 2006 04:23:24 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #4 from pinskia at g
--- Comment #11 from WILLIAMPAUL dot PHILIBERT at telus dot com 2006-09-21
12:18 ---
Subject: RE: Found a problem with the JNI methods declared and implemented
It is the only solution I found. The problem does not exist with Solaris 10 !
William Paul Philibert
Administrateur UNIX
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-09-21 12:22 ---
Subject: Re: [4.2 Regression] Misscompilation with structs due to new struct
alias
> > > Why do they get different SMT's?
> > Because of this:
> > /* To avoid creating unnecessary memory ta
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-09-21 12:30 ---
Suspending pending DR. Neil's interpretation would be a more useful sense of
the
standard, but there is a deliberate decision to err on the side of rejecting
code
rather than of accidentally creating an extension.
If
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2006-09-21
13:03 ---
Proposed patches are posted at...
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00906.html
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00908.html
...which together should allow this PR to be finally clos
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-09-21 13:07 ---
We have a flag (TREE_THIS_NOTRAP) to annotate ARRAY_REFs and INDIRECT_REFs. It
could be used to guide tree-ifcvt to do the transformation. Can we have
if-converted stores at the tree level at all?
--
rguenth at
Under the current standard, the following program should not compile:
static void f(int) {}
template void t(T t) { f(t); }
void g() { t(1); }
EDG 3.0 rejects it.
The C++ standard clause 14.6.4.2 states that function calls depending on
template parameters may only consider function declarations
Attached is a testcase which shows that some registers are clobbered
over throwing/catching an exception:
bash>c++ unwind_test.cpp
bash>./a.out
Checksum not OK ( 42895 != 58377 ).
Register corruption in stack unwinding.
In the debugger you can see,
--- Comment #1 from matz at gcc dot gnu dot org 2006-09-21 13:35 ---
Created an attachment (id=12303)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12303&action=view)
Breaking testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29166
--- Comment #2 from matz at gcc dot gnu dot org 2006-09-21 13:39 ---
Some more analysis of the original bugreport (
https://bugzilla.novell.com/show_bug.cgi?id=201157 ) :
For gcc version 4.1.2 20060731 (prerelease) (SUSE Linux),
r4-r7 contain before the call:
86, 87, 88, 89
and after
--- Comment #3 from matz at gcc dot gnu dot org 2006-09-21 13:40 ---
Hmpf. I wonder if there's any tool to really inspect the unwind info, like
it is possible for dwarf. But readelf doesn't help very much:
% readelf -wf a.out
% readelf -u a.out
...
<_Z4doItv>: [0x4b00-0x4
--- Comment #30 from krebbel at gcc dot gnu dot org 2006-09-21 13:56
---
All three (c974001, c974013 and cb20001) do not fail on s390x anymore since my
patch removing the CLOBBERs for eh registers has been applied:
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00498.html
If the analysi
--- Comment #31 from rguenth at gcc dot gnu dot org 2006-09-21 13:59
---
Note that Ada requires a patch to enable struct-aliasing, as it does
bool
gnat_post_options (const char **pfilename ATTRIBUTE_UNUSED)
{
flag_inline_trees = 1;
if (!flag_no_inline)
flag_no_inline = 1;
if
Hi!
This example will demonstrate 2 problems in mt_allocator.cc:
typedef __gnu_cxx::__mt_alloc allocator_type;
typedef __gnu_cxx::__pool_base::_Tune tune_type;
allocator_type mt_char;
tune_type t(8, 4, 8, (5 - 4 * sizeof(void*)), 4096, 10,
false);
--- Comment #32 from ebotcazou at gcc dot gnu dot org 2006-09-21 14:05
---
> Note that Ada requires a patch to enable struct-aliasing, as it does
Right, there is some confusion in this PR. The problem does *not* exist with
the pristine mainline sources so I'm reclassifying.
--
ebo
--- Comment #12 from jblaine at mitre dot org 2006-09-21 14:09 ---
FWIW, this fails for me in the exact same way under Red Hat
Enterprise Linux v3.
Both of my 4.1.1 builds are complete failures at this point
(the other being Solaris 9 mentioned above, and yeah I used
CONFIG_SHELL=/bin/k
--- Comment #13 from WILLIAMPAUL dot PHILIBERT at telus dot com 2006-09-21
14:20 ---
Subject: RE: Found a problem with the JNI methods declared and implemented
Just in case, are you building outside the source directory!?
setenv CONFIG_SHELL /bin/ksh
mkdir /usr/local/build-gcc-4.1.1
--- Comment #14 from jblaine at mitre dot org 2006-09-21 14:22 ---
I'm building in a 'foo' directory I made at the top of the unpackaged source
tree.
mkdir foo
cd foo
../configure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-09-21 14:31
---
> mkdir foo
> cd foo
> ../configure
Beginner error I'm afraid. :-) See http://gcc.gnu.org/install/configure.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 14:37 ---
*** This bug has been marked as a duplicate of 19092 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-21 14:37 ---
*** Bug 29165 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-21 14:37 ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#561
Suspending since that Defect Report is still open.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #16 from lucier at math dot purdue dot edu 2006-09-21 14:38
---
Subject: Re: Found a problem with the JNI methods declared and implemented
On Sep 21, 2006, at 10:31 AM, ebotcazou at gcc dot gnu dot org wrote:
>> mkdir foo
>> cd foo
>> ../configure
>
> Beginner error I'm
The following code triggers an ICE in gcc 4.1.0 and 4.1.1
===
struct MyClass
{
MyClass( const MyClass& );
MyClass& operator=( const MyClass& );
void volatile_member_func() volatile;
static void static_func() {};
};
void
MyClass::volatile_member_func
--- Comment #33 from krebbel at gcc dot gnu dot org 2006-09-21 14:49
---
Ok. I wasn't aware of this. On s390 these testcases failed even without the
struct-aliasing patch. So obviously it was just a coincidence that the same
testcases failed on s390 (plus one more).
Sorry if I made the
--- Comment #17 from WILLIAMPAUL dot PHILIBERT at telus dot com 2006-09-21
14:49 ---
Subject: RE: Found a problem with the JNI methods declared and implemented
Well the only way I had to compile GCC 4.1.1 under Solaris 9 and get rid of the
JNI methods error was to disable the test rig
--- Comment #34 from dberlin at gcc dot gnu dot org 2006-09-21 14:53
---
Subject: Re: ACATS c974001 c974013 hang with struct aliasing
On 21 Sep 2006 14:49:14 -, krebbel at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #33 from krebbel at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 14:54 ---
*** This bug has been marked as a duplicate of 26577 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-09-21 14:54
---
*** Bug 29168 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #26 from eweddington at cso dot atmel dot com 2006-09-21 15:18
---
(From update of attachment 12162)
The gcc-4.1.1-dwarf32-note.patch file is obsolete and no longer needed. Torleif
was able to build a parser to work with both size DWARF addresses.
--
eweddington at cso d
--- Comment #18 from jblaine at mitre dot org 2006-09-21 16:04 ---
Not beginner error. I just tried with my objdir completely outside the
srcdir and the error is the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2006-09-21 16:09
---
> Eric, it is not forbidden to put objdir into srcdir. It is not
> unsupported to do so.
Simply amazing... Quoting http://gcc.gnu.org/install/configure.html:
"First, we highly recommend that GCC be built in
--- Comment #20 from lucier at math dot purdue dot edu 2006-09-21 16:22
---
Subject: Re: Found a problem with the JNI methods declared and implemented
On Sep 21, 2006, at 12:09 PM, ebotcazou at gcc dot gnu dot org wrote:
> building where objdir is a subdirectory of
> srcdir is unsup
sse3-not-fisttp.c scan-assembler-not fisttp FAILs on i386-pc-solaris2.10
I get the following when bootstrapping mainline on i386-pc-solaris2.10:
Executing on host: /u01/var/tmp/gcc_trunk_svn/gcc_20060921/gcc/xgcc
-B/u01/var/tmp/gcc_trunk_svn/gcc_20060921/gcc/
/u01/var/tmp/gcc_trunk_svn/gcc/gcc/te
--- Comment #35 from ebotcazou at gcc dot gnu dot org 2006-09-21 16:53
---
> I suspect the reality is there is some fundamental misunderstanding of
> how aliasing or addressability works on the part of the Ada folks (no
> offense to them, it's just the arguments they keep offering are,
--- Comment #21 from tromey at gcc dot gnu dot org 2006-09-21 17:02 ---
I think the best solution is to disable the check.
We don't need it and making it always be correct seems like a pain.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
I have a simple reduction test. (attachment to follow)
I'm compiling it with:
../ppc_build/gcc/cc1 -mcpu=G4 -maltivec -O3 -ftree-vectorize reductest.c
If the types are all unsigned, the loop is vectorized.
If the types are all signed, the vectorizer bails because it doesn't know some
pattern and
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Component|c |tree-opti
--- Comment #1 from eplondke at gmail dot com 2006-09-21 17:05 ---
Created an attachment (id=12304)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12304&action=view)
Test to try signed/unsigned reductions
A simple reduction test.
Change WHATSIGN between "signed" and "unsigned" to
--- Comment #4 from tromey at gcc dot gnu dot org 2006-09-21 17:07 ---
Maybe a --with-installed-ecj-jar=/path option would be good.
Then a distro like fedora could build gcj by pointing it at
an already-installed ecj; we could install a little sh script
in the right place that would run
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-21 17:09 ---
This is a known issue as C standard requires the short to be promoted to an
int.
This has nothing to do with the autovect except it cannot handle this case yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-21 17:11 ---
This is a dup of bug 26128.
*** This bug has been marked as a duplicate of 26128 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-21 17:11 ---
*** Bug 29170 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from sayle at gcc dot gnu dot org 2006-09-21 17:13 ---
Subject: Bug 29132
Author: sayle
Date: Thu Sep 21 17:13:33 2006
New Revision: 117114
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117114
Log:
2006-09-21 Roger Sayle <[EMAIL PROTECTED]>
PR debug/29
--- Comment #1 from echristo at apple dot com 2006-09-21 17:52 ---
Yes, this should pass.
--
echristo at apple dot com changed:
What|Removed |Added
CC|ec
Unlike Bug #29159 and Bug #17402, this one involves -ffreestanding. The results
are not really different. Basically, gcc is unable to correctly compile
anything significant with -fwhole-program. With or without the -ffreestanding
option, gcc will leave undefined references to various string.h thing
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 17:57 ---
externally_visible should have fixed the undefined symbol.
Do you really have a simple testcase instead of just describing what your code
does?
--
pinskia at gcc dot gnu dot org changed:
What|Remo
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2006-09-21 17:57
---
> I've followed the mail lists for years while this was debated; I
> don't think it's settled. ("./configure; make" definitely isn't
> supported.)
Tempus fugit. :-)
Index: ChangeLog
===
The --combine option fails to forget the "once" property of a header file when
gcc moves on to dealing with the next *.c file. The pragma should function just
the same as the usual "#ifndef _SOME_ARBITRARY_CRAP" hack.
k 0 $ cat once.h
#pragma once
#define D
k 0 $ cat a.c
#include "once.h"
#ifndef
--- Comment #9 from bergner at vnet dot ibm dot com 2006-09-21 18:14
---
Created an attachment (id=12305)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12305&action=view)
Patch to rs6000_legitimize_address to force base pointers into rA position of
indexed load/store instructions.
--- Comment #2 from acahalan at gmail dot com 2006-09-21 18:15 ---
A simple test case would involve the code I gave plus whatever it takes to make
gcc decide to call memcpy. What is the most simple thing which triggers that?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29171
--- Comment #10 from bergner at vnet dot ibm dot com 2006-09-21 18:16
---
(From update of attachment 12190)
Forgot to obsolete this patch by the updated patch.
--
bergner at vnet dot ibm dot com changed:
What|Removed |Added
---
--- Comment #11 from bergner at vnet dot ibm dot com 2006-09-21 18:19
---
Created an attachment (id=12306)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12306&action=view)
Alternate patch to rs6000_legitimize_address to force base pointers into rA
position of indexed load/store in
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-09-21 18:22
---
Subject: Bug 28861
Author: lmillward
Date: Thu Sep 21 18:22:11 2006
New Revision: 117117
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117117
Log:
PR c++/28861
* decl.c (shadow_tag): Retu
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-09-21 18:26
---
Fixed in 4.2.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-09-21 18:33
---
Subject: Bug 28303
Author: lmillward
Date: Thu Sep 21 18:33:49 2006
New Revision: 117118
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117118
Log:
PR c++/28303
* decl.c (grokdeclarator):
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 18:34 ---
I bet the C front-end forgot to tell the preprocessor to rest the "pragma once"
table.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-09-21 18:34
---
Fixed in 4.2.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #3 from acahalan at gmail dot com 2006-09-21 18:49 ---
foo 0 $ cat foo.c
void *memcpy(void *restrict, const void *restrict, unsigned long);
void *memcpy(void *restrict dst, const void *restrict src, unsigned long n)
{
const char *p = src;
char *q = dst;
--- Comment #4 from dorit at il dot ibm dot com 2006-09-21 19:30 ---
By the way, the testcase gets vectorized if you compile with -fwrapv.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29170
Right now, bug 29171 has status WAITING. I clicked the "Status" link next to
that to see if there is anything I ought to do about it, and I get this page:
http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#status
The WAITING status does not exist. My bug is in a non-existant status.
Well gee. I
In the code below, gcc fails to optimize a hand-crafted memcpy as a call to the
memcpy function. (or perhaps as "rep;movsb" when compiling with "-Os") I've
tried "-O2", "-O3", and "-Os". There are probably a great number of similar
optimizations that could be done.
This optimization is not unheard
--- Comment #8 from bkoz at gcc dot gnu dot org 2006-09-21 20:24 ---
> I applied r116954 to 116942.
Well, then it's still my patch or patches then. Sorry.
> It's still using linuxthreads. Also because of the limitations
> of the ldcw semaphore instruction in PA 1.1, the atomic lock
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
--- Comment #7 from steven at gcc dot gnu dot org 2006-09-21 20:24 ---
No working test case, no feedback for two months -> no reason to keep this
open.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-09-21 20:26 ---
Also:
Does hpux use the hppa atomics config, or the generic layer? If it uses the
hppa atomics config, why isn't this a problem on hpux?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
--- Comment #10 from steven at gcc dot gnu dot org 2006-09-21 20:27 ---
Subject: Bug 29087
Author: steven
Date: Thu Sep 21 20:27:36 2006
New Revision: 117120
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117120
Log:
2006-09-21 Steven Bosscher <[EMAIL PROTECTED]>
PR c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 20:36 ---
Actually it is there, just in a different place:
http://gcc.gnu.org/bugs/management.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-21 20:36 ---
Confirmed, note waiting means waiting for the reporter to get back to us about
a question, it should have been obvious anyways.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 20:37 ---
Yes this is known issue.
http://www.gccsummit.org/2006/view_abstract.php?content_key=27
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from dwmw2 at infradead dot org 2006-09-21 20:38 ---
Apologies -- GCC bugzilla mail was going missing due to being sent with a bogus
sender address. Will dig out a current test case if it's still an issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-21 20:39 ---
Also mentioned in with results also:
http://www.gccsummit.org/2006/2006-GCC-Summit-Proceedings.pdf
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pvanvugt at axys dot com 2006-09-21 20:49 ---
(In reply to comment #1)
> This is not a bug as char pointers are special by the C standard. char is a
> different type from either unsigned char or signed char. Also you should not
> use -funsigned-char/-fsigned-char un
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-21 21:03 ---
(In reply to comment #2)
> (In reply to comment #1)
> > This is not a bug as char pointers are special by the C standard. char is a
> > different type from either unsigned char or signed char. Also you should
> >
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-09-21 21:10 ---
Whoops, Janis, you are right. Sorry for the false alarm. The fancy dejagnu line
I spit out at you does nothing.
I also tried to hack up this as you suggested:
Index: testsuite/lib/libstdc++.exp
==
--- Comment #4 from gcc at brainhub dot org 2006-09-21 21:19 ---
I accepts Andrew's point, but note that you will get errors, not warnings, for
identical C++ code.
The problem is exacerbate by libc prototypes such as size_t strlen(const char
*s). If you want to use libc functions, perha
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-21 21:24 ---
(In reply to comment #4)
> I accepts Andrew's point, but note that you will get errors, not warnings, for
> identical C++ code.
Right, this is still invalid code in both C and C++, just in the C front-end we
decided
--- Comment #11 from steven at gcc dot gnu dot org 2006-09-21 21:31 ---
Fixed.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from steven at gcc dot gnu dot org 2006-09-21 21:32 ---
Denis, this should be fixed in the next release of GCC 4.1 (which will be GCC
4.1.2) and in GCC 4.2. Thanks for reporting the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29087
Compiling this invalid C++ code with current mainline:
void foo() { static int c = 2; static const char *a[][c] = { { "1", "2" } }; }
gives me:
foo.cc: In function void foo():
foo.cc:1: internal compiler error: in tree_low_cst, at tree.c:4519
Please submit a full bug report,
with preprocessed
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-09-21 22:19
---
Subject: Bug 29016
Author: mmitchel
Date: Thu Sep 21 22:18:54 2006
New Revision: 117123
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117123
Log:
PR c++/29016
* typeck.c (build_unary_op):
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-09-21 22:25
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #15 from sayle at gcc dot gnu dot org 2006-09-21 23:38 ---
Subject: Bug 26983
Author: sayle
Date: Thu Sep 21 23:38:21 2006
New Revision: 117125
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117125
Log:
2006-09-21 Steven Bosscher <[EMAIL PROTECTED]>
PR mid
--- Comment #5 from acahalan at gmail dot com 2006-09-22 02:24 ---
(In reply to comment #4)
> I still don't see why my code should not compile even for register starved
> x86.
> Including the -fomit-frame-pointer optimization should allow using the ebp
> register at least for leaf funct
--- Comment #14 from rsandifo at gcc dot gnu dot org 2006-09-22 04:36
---
FWIW, this appears to be the same problem as the
compile/20050112-1.c failure on the -mips32 multilibs
of mipsisa64-elf-gcc.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from jespdj at hotmail dot com 2006-09-22 06:51 ---
I've been looking at my code some more time, and I noticed that there are bugs
in it. For example, I'm not using the '&' early clobber modifier in the
embedded asm, which is necessary if the output operand is modified bef
1 - 100 of 101 matches
Mail list logo
