--- Comment #10 from rguenth at gcc dot gnu dot org 2006-07-13 07:39
---
Reopening then...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-07-13 07:40
---
...to assign myself.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assi
--- Comment #18 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-07-13 07:58 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> > > I-cache.
> > this only matters if this increase in code size will make the code go
>
--- Comment #19 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-07-13 08:01 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> > > I-cache.
> > this only matters if this increase in code size will make the code go
>
--- Comment #20 from zackw at panix dot com 2006-07-13 08:25 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> > However, ch isn't just copying the loop header; it is also
> > copying the *entire body of the loop*, which nothing
--- Comment #21 from zackw at panix dot com 2006-07-13 08:28 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> on your real program, how much performance do you gain by hand-rewriting
> the assembler to look the way you like? Ju
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-07-13 08:28
---
For practical purposes (determining the loop runs at least once) it needs to
duplicate the exit condition. Which happens to be difficult here, as there are
multiple loop exits.
--
http://gcc.gnu.org/bugzilla/
--- Comment #23 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-07-13 09:00 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> > on your real program, how much performance do you gain by hand-rewriting
> > the assem
--- Comment #24 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-07-13 09:03 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> > > However, ch isn't just copying the loop header; it is also
> > > copying the *entire
../unxlngi6.pro/slo/uuid.o: In function `create':
../../inc/rtl/instance.hxx:292: undefined reference to `(anonymous
namespace)::rtl_Instance<(anonymous namespace)::Pool, rtl::Static<(anonymous
namespace)::Pool, (anonymous namespace)::PoolHolder>::StaticInstance,
osl::Guard, osl::GetGlobalMutex, in
--- Comment #1 from caolanm at redhat dot com 2006-07-13 09:42 ---
Created an attachment (id=11877)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11877&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28370
--- Comment #2 from caolanm at redhat dot com 2006-07-13 09:43 ---
Created an attachment (id=11878)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11878&action=view)
original -6 nm output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28370
--- Comment #3 from caolanm at redhat dot com 2006-07-13 09:43 ---
Created an attachment (id=11879)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11879&action=view)
new nm -7 output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28370
--- Comment #2 from pfister at reith-pfister dot de 2006-07-13 10:08
---
Subject: Re: Pointer arithmetic failure
Hello,
thanks for your immediate response, but i can't repeat the bug today.
Yesterday, i spent one day in evaluating the bug in my application and now it
seems to be vani
--- Comment #4 from caolanm at redhat dot com 2006-07-13 11:06 ---
Created an attachment (id=11880)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11880&action=view)
diff against testme.ii which will make it work for me
This attachment is a diff against the testme.ii and makes the
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-13 11:53 ---
This is invalid code with no diagnostic required.
See the full explaination in PR 28360 which is exactly the same case. In fact
with a real testcase :).
*** This bug has been marked as a duplicate of 28360 ***
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-13 11:53 ---
*** Bug 28370 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-13 11:55 ---
Basicially the code was violating ODR rules before because of the anonymous
namespace.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28370
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-13 12:06 ---
So closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-07-13 12:19 ---
Note I think you should have first checked FSF 4.1.2 which will have not this
issue. 4.2.0 might have it, I might had been wrong at closing as a dup, that
might be because I am tried and had a long day and it is 9:2
--- Comment #12 from reichelt at gcc dot gnu dot org 2006-07-13 13:02
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-07-13 13:14
---
The bug is not fixed on the 4.0 branch.
The ICE only happens in a different position:
bug.cc: In instantiation of 'B<0>':
bug.cc:8: instantiated from here
bug.cc:5: error: no type named 'X' in 'struct A<0>'
bug.
--- Comment #16 from reichelt at gcc dot gnu dot org 2006-07-13 13:21
---
Jason, would you mind adding a testcase? Thanks!
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-07-13 14:08 ---
Here is a full reduced self contained testcase:
namespace
{
template< typename Inst>
struct rtl_Instance
{
static int * m_pInstance;
};
template< typename Inst> int * rtl_Instance< Inst>::m_pInstance =
--- Comment #5 from anemo at mba dot ocn dot ne dot jp 2006-07-13 14:42
---
Created an attachment (id=11881)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11881&action=view)
do not put rdhwr instruction on delay slot
With this patch, gcc 4.2 (with -O1, -O2) and gcc 4.1.1 with -O1
--- Comment #6 from anemo at mba dot ocn dot ne dot jp 2006-07-13 14:58
---
(In reply to comment #2)
> Although I don't know much about the instruction scheduling, I had
> a similar problem on SH and it was workarounded with emitting blockage
> insns. The patch below might work for you
http://earth.google.com/download-earth.html
On 7/13/06, DebianTux23 <[EMAIL PROTECTED]> wrote:
http://earth.google.com/download-earth.html
On 12 Jul 2006 21:18:46 -, eric dot lemings at roguewave dot com
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] tests]$ gcc --version
> gcc (GCC) 4.1.0
--- Comment #1 from wieseltux23 at gmail dot com 2006-07-13 15:08 ---
Subject: Re: New: Default template parameter causes compiler segfault
http://earth.google.com/download-earth.html
On 7/13/06, DebianTux23 <[EMAIL PROTECTED]> wrote:
> http://earth.google.com/download-earth.html
>
>
http://earth.google.com/download-earth.html
https://www.google.com/accounts/ServiceLogin?service=pages&continue=http%3A%2F%2Fpages.google.com%3A80%2F
On 7/13/06, DebianTux23 <[EMAIL PROTECTED]> wrote:
http://earth.google.com/download-earth.html
On 12 Jul 2006 21:18:46 -, eric dot lemings a
--- Comment #2 from wieseltux23 at gmail dot com 2006-07-13 15:09 ---
Subject: Re: New: Default template parameter causes compiler segfault
http://earth.google.com/download-earth.html
https://www.google.com/accounts/ServiceLogin?service=pages&continue=http%3A%2F%2Fpages.google.com%3A80
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-07-13 15:31
---
Reduced testcase that crashes when compiled with
"g++ --param ggc-min-expand=0 --param ggc-min-heapsize=0 -O":
=
extern "C" int verbose;
struct A
{
char const* foo()
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-07-13 15:44
---
Shorter testcase that ICE's without issuing an error message first:
==
int foo;
void foo() {}
==
The problem appeared with GCC 3.0.
--
reichelt at gcc dot gnu dot org c
The following snippet:
#include
void foo(){}
templatevoid bar(){}
template
void test(const T&)
{
std::cout<);
}
produces this oputput on gcc version 3.2 20020927
(prerelease) under Cygwin:
PFvvE
FvvE
But the two lines should be identical --in both
cases, the deduced T should be void(*)().
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-07-13 15:51 ---
Fixed (at least) in 3.3.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from edmar at freescale dot com 2006-07-13 16:08 ---
I tried the patch on comment 7 on gcc main line from yesterday. It did not work
for me:
foo.c: In function 'foo':
foo.c:1: error: unrecognizable insn:
(insn 11 10 12 3 (set (subreg:DF (reg:DI 121) 0)
(mem/u/c/i:
--- Comment #9 from jakub at gcc dot gnu dot org 2006-07-13 16:25 ---
The reason why the var is not emitted seems to be that
note_vague_linkage_var is not called on it in finish_static_data_member_decl.
If I replace
if (! processing_template_decl && TREE_PUBLIC (decl))
note_vague_l
--- Comment #10 from dje at watson dot ibm dot com 2006-07-13 16:31 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
> edmar at freescale dot com writes:
edmar> I tried the patch on comment 7 on gcc main line from yesterday. It did
not work
edmar> for me:
--- Comment #1 from patchapp at dberlin dot org 2006-07-13 16:50 ---
Subject: Bug number PR c++/28343
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-07/msg00584.html
--
http://gcc.gnu.org/bugzil
--- Comment #10 from jakub at gcc dot gnu dot org 2006-07-13 16:50 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #1 from patchapp at dberlin dot org 2006-07-13 17:00 ---
Subject: Bug number PR c++/28294
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-07/msg00586.html
--
http://gcc.gnu.org/bugzil
--- Comment #10 from lmillward at gcc dot gnu dot org 2006-07-13 17:33
---
Weird, I bootstrapped and tested this patch on the 4.0 branch not long before
applying. I'll take a look and see if I can see why the new testcase is
ICE'ing.
--
lmillward at gcc dot gnu dot org changed:
With the actual snapshot gcc-4.2-20060708 I get a segfault when I use the
option -fipa-pta
Michael Cieslinski
g++ -fipa-pta -S get.ii -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.2-20060708/configure --prefix=/usr/local/gcc42s
--program-suffix=42s --with-ar
--- Comment #1 from micis at gmx dot de 2006-07-13 17:54 ---
Created an attachment (id=11882)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11882&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28372
--- Comment #4 from sje at cup dot hp dot com 2006-07-13 17:57 ---
Eric, do you have any new information on this problem? I cannot reproduce it.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #11 from edmar at freescale dot com 2006-07-13 18:01 ---
I tested with both examples. Both fails with the same ICE.
I am sure I am using the right compiler, because I invoked it explictitly with:
./install_area/gcc-trunk-20060712-e500v2/bin/powerpc-unknown-linux-gnuspe-gcc
w
--- Comment #18 from janis at gcc dot gnu dot org 2006-07-13 18:18 ---
A regression hunt on powerpc-linux using the C testcase from comment #6
identified the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=100793
r100793 | rth | 2005-06-09 07:43:40 + (Thu, 09 Jun 2
--- Comment #2 from sebor at roguewave dot com 2006-07-13 19:07 ---
If it is in our (Rogue Wave) current code, could you please let us know where
so we can look into fixing it? (It's doesn't matter whther gcc does the right
thing here or not, our code should be portable either way.) Than
--- Comment #12 from dje at watson dot ibm dot com 2006-07-13 19:58 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
> edmar at freescale dot com writes:
edmar> And to kill the last shread of doubt, here I am using the xgcc present
on the
edmar> very same build dir
--- Comment #13 from edmar at freescale dot com 2006-07-13 20:09 ---
What about now:
/local/gnu_toolchain/build_area/obj_gcc-trunk_e500v2/gcc/xgcc
-B/local/gnu_toolchain/build_area/obj_gcc-trunk_e500v2/gcc/ -O2 -c foo.c
foo.c: In function 'f':
foo.c:1: error: unrecognizable insn:
(insn
/* gcc-4.1.1 gives "unaligned access" on alphaev68-dec-osf5.1b
regression from gcc-3.4.4
% gcc -v
Using built-in specs.
Target: alphaev68-dec-osf5.1b
Configured with: /usr/local/gcc-4.1.1/src/gcc-4.1.1/configure
--enable-languages=c --prefix=/usr/local/gcc-4.1.1/alpha-OSF1-V5
Thread model: po
foo.c
$ ./xgcc -B./ -v
Reading specs from ./specs
Target: powerpc-unknown-linux-gnuspe
Configured with: /farm/dje/src/src/configure
--target=powerpc-unknown-linux-gnuspe --enable-e500_double --enable-languages=c
Thread model: posix
gcc version 4.2.0 20060713 (experimental)
$ cat foo.s
.file
--- Comment #15 from edmar at freescale dot com 2006-07-13 20:48 ---
Ahhha, I found the problem. My patch is wrong:
This line
+ (match_operand:DF 1 "register_operand" "r,m"))]
should read
+ (match_operand:DF 1 "input_operand" "r,m"))]
I don't know how I made this mess, I wi
--- Comment #1 from falk at debian dot org 2006-07-13 20:58 ---
The conversion from int* to aa* is only defined if the pointer is correctly
aligned. Even if it was correctly aligned, dereferencing this pointer is
undefined behavior (see -Wstrict-aliasing documentation). So this is not a
--- Comment #17 from langton at gcc dot gnu dot org 2006-07-13 21:00
---
(In reply to comment #16)
>
> Thanks but it doesn't work...
Did you re-run 'configure' after rebuilding GMP and MPFR? What happens if you
try to configure and bootstrap from a clean object directory?
-
--- Comment #8 from langton at gcc dot gnu dot org 2006-07-13 21:11 ---
(In reply to comment #0)
> 3. Run ./configure --enable-threads --x-includes=/usr/X11R6
> --x-libraries=/usr/X11R6 --with-cpu=powerpc --with-mpfr=/usr/local/lib
> --with-gmp=/usr/local/lib.
Are you building in the s
--- Comment #18 from steven at gcc dot gnu dot org 2006-07-13 21:47 ---
Re. comment #16: That looks like you get an internal compiler error (ICE )while
building g++ which has nothing to do with libgfortran. If that ICE is
reproducible, it deserves its own bug report.
--
http://gcc.
--- Comment #3 from kk at microfocus dot com 2006-07-13 21:49 ---
(In reply to comment #2)
> If it is in our (Rogue Wave) current code, could you please let us know where
> so we can look into fixing it? (It's doesn't matter whther gcc does the right
> thing here or not, our code should
--- Comment #4 from fang at csl dot cornell dot edu 2006-07-13 22:06
---
Subject: Re: error: ' error: 'MyClass::MyClass(const MyClass&)'
is private error: within this context
> --- Comment #3 from kk at microfocus dot com 2006-07-13 21:49 ---
> (In reply to comment #2)
> >
If an Objective-C call with variable arguments, such as [NSString
stringWithFormat:@"foo %d", 3], is wrapped in a macro call, the combined call
will fail to compile. It seems like gcc is overlooking the square brackets
entirely, and sees the comma in the method call as belonging to the macro
itself
--- Comment #1 from mike at ambrosiasw dot com 2006-07-13 22:25 ---
Created an attachment (id=11885)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11885&action=view)
Minimal test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28375
--- Comment #2 from mike at ambrosiasw dot com 2006-07-13 22:28 ---
Created an attachment (id=11886)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11886&action=view)
Minimal test case
Oops, wrong version.
--
mike at ambrosiasw dot com changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-13 22:44 ---
More than that:
int cc[1];
foo(cc); /* says "unaligned access" */
int foo(v)
aa *v;
You are also violating C aliasing rules and also violating an even more
fundental problem in that the struct aa will not f
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-13 22:47 ---
You want to wrap the message "call" in "()":
FIRST(([NSString stringWithFormat:@"We're number %d!", 1]),
@"ignored");
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-13 22:52 ---
This is most likely the same as PR 26963.
-fipa-pta does nothing useful for users (except compiler developers).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-13 23:46 ---
Confirmed, we should not ICE on undefined code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from janis at gcc dot gnu dot org 2006-07-14 00:20 ---
A regression hunt on powerpc-linux using an i686-linux cross compiler
identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=102570
r102570 | hubicka | 2005-07-29 22:22:41 + (Fri, 29 Jul 2005)
Th
--- Comment #9 from craigwd2000 at gmail dot com 2006-07-14 00:22 ---
I just now tried that. Now I'm getting this error:
make: *** No rule to make target `bootstrap'. Stop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28297
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-14 00:40 ---
This fixes it for me (but I don't have time to test it):
Index: typeck.c
===
--- typeck.c(revision 115413)
+++ typeck.c(working copy)
@@ -3984,7
when building opensp with gcc-4.1.1 and -O3 on alpha, gcc ICEs:
ice.ii: In function 'void __static_initialization_and_destruction_0(int, int)':
ice.ii:13: error: unrecognizable insn:
(insn 23 22 24 2 (set (reg:DI 84)
(leu:DI (const_int 0 [0x0])
(const_int 4 [0x4]))) -1 (nil)
--- Comment #1 from vapier at gentoo dot org 2006-07-14 02:42 ---
Created an attachment (id=11887)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11887&action=view)
PR28376.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28376
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-14 03:45 ---
(In reply to comment #0)
> ice.ii:13: error: unrecognizable insn:
> (insn 23 22 24 2 (set (reg:DI 84)
> (leu:DI (const_int 0 [0x0])
> (const_int 4 [0x4]))) -1 (nil)
> (nil))
This should never
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-07-14 05:07
---
F95
9.2.2.2 (1)
"Reading and writing records shall be accomplished only by sequential access
formatted input/output statements that do not specify namelist formatting."
F2003
9.3 (9)
"Reading and writing reco
-Original Message-
From: Deng Shi
Sent: 2006年7月13日 10:37
To: '[EMAIL PROTECTED]'
Subject: Inconsistent floating point result when using G++ 3.3.6 with option
-O0 or -O1 separately
hi expert,
I found our application tool gave the inconsistent floating point result when
using different
73 matches
Mail list logo
