--- Comment #6 from krebbel1 at de dot ibm dot com 2005-11-04 07:56 ---
My patch introduced the s390_regs_ever_clobbered function
which is used instead of regs_ever_live for determining
which registers need saving in function prologue.
This function is called during reload when the elimi
--- Comment #1 from fang at csl dot cornell dot edu 2005-11-04 07:47
---
also known to work: 3.4.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24667
--- Comment #13 from olh at suse dot de 2005-11-04 07:45 ---
Why does gcc make copies of r13 anyway, when it could just use it where needed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
--- Comment #12 from olh at suse dot de 2005-11-04 07:18 ---
Yes, adding the volatile fixes it for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24668
In addition to the current ability to put visibility attributes on file and
class scope, the ability to put visibility attributes on namespace scope is
desired.
The syntax is straight forward extension of existing visibility attribute
options.
namespace test __attribute__ ((visibility("hidden")))
--- Comment #9 from membar at gcc dot gnu dot org 2005-11-04 06:41 ---
I was able to "fix" this issue with an explicit --with-as= and --with-ld=. The
crossed native compiler passes the testcase that Rutger sent me.
Note that the correct term for the compiler we're referring to is "x-hos
--- Comment #2 from bkoz at gcc dot gnu dot org 2005-11-04 06:11 ---
Yes! I so want this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24645
g++ -Wcast-qual doesn't seem to reject the following code, it just accepts
quitely without warning.
//=== "foo.cc" ==
int main(int, char**) {
const int foo[2] = {1,1};
((int*)foo)[0] = 0;
}
//=
command: g++ -Wcast-qual foo.cc
program output: (none)
--- Comment #11 from bergner at vnet dot ibm dot com 2005-11-04 05:52
---
I've determined why we're dying, but not sure who is at fault yet. While
scanning through Olaf's assembly diff's, I noticed some code that normally
wouldn't be a problem in user code, but is problamatic in PPC64
--- Comment #10 from ian at airs dot com 2005-11-04 05:48 ---
>From IRC, the problem seems to be that gcc is copying the value out of a global
register variable, which it was not doing before. This is not acceptable, as
the global register may be changed on any context switch, and it is
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 05:06 ---
Confirmed, reduced testcase as far as I can get it (and is willing to try at
this point):
typedef unsigned long uint32_t;
typedef volatile uint32_t* const hwreg_t;
struct RegisterLayout
{
uint32_t intmask;
};
str
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC host triplet|CYGWIN_NT-5.0 |
GCC target triplet|powerpc-603e-eabi |*-*-*
Key
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-04 04:53 ---
Note you are most likely right that GCC is applying pointers to array too
early, see the meta-bug (PR 24666) which I just filed after you filed these two
bugs, there were two other bugs about arrays decaying too earl
--- Comment #3 from tom_gall at vnet dot ibm dot com 2005-11-04 04:52
---
fresh subversion code + right param seems to fix it ... least for the pure 64
bit case. I'll get to the multilib from 64 bit case in a few days.
--
tom_gall at vnet dot ibm dot com changed:
What
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-04 04:51
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-04 04:50
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 04:49 ---
4 bugs that I could find now (two were filed today).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
There are a many of these problems that have been filed, I think we should have
a meta-bug for it.
--
Summary: [meta-bug] arrays decay to pointers too early
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: rejects-valid, accepts-inv
I get an internal compiler error when compiling the code below. The compiler
error goes away if the "-fno-tree-ccp" is added to the command line. The exact
error message is:
gccbug.cpp: In constructor 'Controller_t::Controller_t()':
gccbug.cpp:41: internal compiler error: in get_indirect_ref_ope
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 04:44 ---
Confirmed, I think this is another case of the arrays decaying too early.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-04 04:42
---
Fixed on the mainline and the 4.0 branch for 4.0.3 but is waiting for a back
port for 3.4.x.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 04:41 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #19 from wilson at gcc dot gnu dot org 2005-11-04 04:32 ---
Giovanni's patch substitutes DECL_INLINE for DECL_DECLARED_INLINE_P. This
breaks -finline-functions, since now we get warnings for functions that weren't
originally declared inline. See for instance PR 10929 which
--- Comment #2 from tom_gall at vnet dot ibm dot com 2005-11-04 02:51
---
I'll give that whirl... I think I was mistakenly using --disable-biarch! :-/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24662
The following code, pulled from an example in section 14.8.2.2 of ISO C++,
should fail to compile, but doesn't:
template int f(T[5]);
int j=f(0);
A function template instantiation should fail if it would create an array with
void elements.
--
Summary: Template instantiation gene
--- Comment #15 from wilson at gcc dot gnu dot org 2005-11-04 02:12 ---
Subject: Bug 24202
Author: wilson
Date: Fri Nov 4 02:12:48 2005
New Revision: 106473
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106473
Log:
Fix pragma once bug where buffer is NULL and buffer_valid is t
--- Comment #14 from wilson at gcc dot gnu dot org 2005-11-04 02:10 ---
Subject: Bug 24202
Author: wilson
Date: Fri Nov 4 02:10:19 2005
New Revision: 106472
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106472
Log:
Fix failure with pragma once where buffer is NULL and buffer_v
The following compliant code fails to compile:
template int f1 (char[I]);
template int f1 (char p1 = I);
int i = f1<0>(0);
.. instead it generates an error, e.g.:
test.C:3: error: call of overloaded 'f1(int)' is ambiguous
test.C:1: note: candidates are: int f1(char*) [with int I = 0]
--- Comment #8 from vapier at gentoo dot org 2005-11-04 02:09 ---
yes, debian 3.3.6-10 (3.3.6) and 3.4.4-9 (3.4.5 20051015) both fail in the same
way ... debian's 4.0.3 (4.0.3 20051023) however fails in a different way:
sym.c: In function 'vtoa':
sym.c:28: internal compiler error: in fi
--- Comment #10 from jconner at gcc dot gnu dot org 2005-11-04 01:55
---
Subject: Bug 19989
Author: jconner
Date: Fri Nov 4 01:55:36 2005
New Revision: 106471
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106471
Log:
PR c++/19989
cp/pt.c (tsubst): Accept zero-length array if
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 01:49 ---
HUH
For a pure 64bit PPC GNU/Linux, you need --disable-multilib (and maybe
--with-cpu=default64) as you don't have a 32bit glibc.
Unless I am misunderstanding what you mean by a pure 64bit PPC GNU/Linux
distro.
--- Comment #7 from vapier at gentoo dot org 2005-11-04 01:46 ---
if that's the case, since this doesnt seem to be a regression (unless it worked
in like 3.2.x or older), does that mean i'm sol with 3.4.x/4.0.x ? :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
In the past with 3.3 and 3.4 gcc could be build as a 64 bit binary on ppc64.
gentoo-ppc64 as a distro is a full 64 bit environment.
I've been doing some early explorations on gcc 4.x for our next release of
gentoo-ppc64 and found that gcc no longer is able to bootstrap or even build in
a pure 64
--- Comment #14 from jsm28 at gcc dot gnu dot org 2005-11-04 01:23 ---
Subject: Bug 17964
Author: jsm28
Date: Fri Nov 4 01:23:54 2005
New Revision: 106469
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106469
Log:
gcc:
PR c++/17964
* diagnostic.c (diagnostic_set
--- Comment #9 from jconner at gcc dot gnu dot org 2005-11-04 01:23 ---
Subject: Bug 19989
Author: jconner
Date: Fri Nov 4 01:23:22 2005
New Revision: 106468
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106468
Log:
PR c++/19989
cp/pt.c (tsubst): Accept zero-length array if tf
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-04 01:19 ---
Hmm, I might take a look at this bug as I found it independently while
compiling some other fortran code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-04 01:13
---
*** Bug 19962 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-04 01:13 ---
This is a dup of bug 5291.
*** This bug has been marked as a duplicate of 5291 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-04 01:06 ---
Then maybe this has been fixed in 4.1.0 already.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
--- Comment #5 from vapier at gentoo dot org 2005-11-04 00:55 ---
ok, gcc-4.0.2 on Gentoo with no Gentoo patches fails same way
i'll see about creating a Debian chroot to doubly verify
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-04 00:28
---
Subject: Bug 22042
Author: pinskia
Date: Fri Nov 4 00:28:39 2005
New Revision: 106465
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106465
Log:
2005-11-03 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-11-04 00:28
---
Fixed in 4.0.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-04 00:23
---
Subject: Bug 22042
Author: pinskia
Date: Fri Nov 4 00:23:01 2005
New Revision: 106463
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106463
Log:
2005-11-03 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #4 from vapier at gentoo dot org 2005-11-04 00:12 ---
i had a SuSE guy report the samething, but i'll go ahead and rebuild a vanilla
4.0.2 to be sure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-04 00:07 ---
I cannot reproduce this on the mainline. Are you sure that this is not due to
a modification that gentoo has done?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #16 from joseph at codesourcery dot com 2005-11-04 00:05
---
Subject: Re: [3.4/4.0/4.1 Regression] stringification
BUG
On Thu, 3 Nov 2005, mmitchel at gcc dot gnu dot org wrote:
> Joseph, you're probably the person who best understands the behavior required
> by the stan
--- Comment #2 from vapier at gentoo dot org 2005-11-03 23:52 ---
Created an attachment (id=10139)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10139&action=view)
full test case from quake3 source quake3-register-spill-insn.tar.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #1 from vapier at gentoo dot org 2005-11-03 23:51 ---
Created an attachment (id=10138)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10138&action=view)
reduced test case, sym.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
trying to build quake3 on ia64 ... reduced test case looks like this:
$ gcc -O2 -c sym.c
sym.c: In function `vtoa':
sym.c:28: error: unable to find a register to spill in class `FR_REGS'
sym.c:28: error: this is the insn:
(insn 12 3 13 0 (set (reg:DF 134 f6 [343])
(float_truncate:DF (subre
--- Comment #15 from mmitchel at gcc dot gnu dot org 2005-11-03 23:49
---
Joseph, you're probably the person who best understands the behavior required
by the standard.
Since Per writes:
"I don't know enough about fine points of the standard to say what is
right. If you and Andrew
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-11-03 23:19
---
> Would you like me to try and get the same backtrace and assembler information
> for the configuration that works.
I think I have enough info and I'll try harder to reproduce the problem.
Thanks.
--
ebotca
--- Comment #4 from andreast at gcc dot gnu dot org 2005-11-03 23:18
---
First off, qt-peers are experimental, even in classpath (cp).
The componentevent.cpp part is covered already in the next cp release. Which we
will import soon.
The build process we have to adjust. We can not modi
--- Comment #9 from steve at telxio dot com 2005-11-03 23:15 ---
The problem lies in the file:
/opt/utsi/test/R500/opt/utsi/lib/libstdc++.so.6.0.3
If I compile the program with gcc-3.4.3 --without-gnu-as, the executable fails.
I then install the libstdc++ library from the config --with
--- Comment #13 from jsm28 at gcc dot gnu dot org 2005-11-03 23:08 ---
Subject: Bug 17964
Author: jsm28
Date: Thu Nov 3 23:08:18 2005
New Revision: 106454
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106454
Log:
gcc:
PR c++/17964
* diagnostic.c (diagnostic_set
--- Comment #8 from steve at telxio dot com 2005-11-03 23:08 ---
I forgot to mention, the assembler used was the code generated by gcc-3.4.4
--without-gnu-as, i.e. the configuration that fails.
Would you like me to try and get the same backtrace and assembler information
for the configu
--- Comment #7 from steve at telxio dot com 2005-11-03 23:05 ---
If I install gcc-3.4.4 --without-gnu-as and using the Solaris tools directly I
assemble and link the code, the resultant executable fails.
If I install gcc-3.4.4 --with-gnu-as and again using the solaris tools directly
and
--- Comment #8 from hubicka at gcc dot gnu dot org 2005-11-03 22:54 ---
Actually the code 4.1 in comment #5 should execute faster on true i686. It is
longer and will trigger partial memory stalls on later chips.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22563
--- Comment #18 from hubicka at gcc dot gnu dot org 2005-11-03 22:32
---
insn size is currently completely unused. It was used for producing loop
instructions.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23524
--- Comment #6 from laurent at guerby dot net 2005-11-03 22:14 ---
Fixed
--
laurent at guerby dot net changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from guerby at gcc dot gnu dot org 2005-11-03 22:13 ---
Subject: Bug 23427
Author: guerby
Date: Thu Nov 3 22:13:03 2005
New Revision: 106452
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106452
Log:
2005-11-03 James E Wilson <[EMAIL PROTECTED]>
PR ada
--- Comment #13 from janis at gcc dot gnu dot org 2005-11-03 22:12 ---
A regression hunt showed that "warning: inline function `void f1()' used
but never defined" disappeared with this patch to make the C++ front end
always work in unit-at-a-time mode:
r85309 | mmitchel | 2004-07-29 17:
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2005-11-03 22:11
---
> R500.ramses.240> diff tt.s.gnu-as tt.s.sol-as
> 322,323c322,323
> < .uleb128 0x1
> < .sleb128 -4
> ---
> > .byte 0x1
> > .byte 0x7c
Probably not significant. Could you link the obje
--- Comment #5 from steve at telxio dot com 2005-11-03 22:06 ---
Created an attachment (id=10137)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10137&action=view)
gcc assembler output for both Solaris as and GNU as
Contains two files that untar into the current directory:
tt.s.gnu
--- Comment #9 from olh at suse dot de 2005-11-03 22:05 ---
Created an attachment (id=10136)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10136&action=view)
PR24644-4.tar.bz2
object files and extracted asm functions for easier comparsion
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #4 from steve at telxio dot com 2005-11-03 21:58 ---
I have created assembler files for both g++-3.4.4 --with-gnu-as and g++3.4.4
--without-gnu-as.
I ran a diff on the two assembler files and their is only one significant
difference:
R500.ramses.240> diff tt.s.gnu-as tt.s.s
--- Comment #8 from bergner at vnet dot ibm dot com 2005-11-03 21:48
---
Adding myself to the CC list.
--
bergner at vnet dot ibm dot com changed:
What|Removed |Added
--- Comment #7 from olh at suse dot de 2005-11-03 21:30 ---
Created an attachment (id=10135)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10135&action=view)
PR24644-3.tar.bz2
revision 102096 works, revision 102098 doesnt.
copying the sched.o from the 102098 tree into the 102096 t
--- Comment #11 from hubicka at ucw dot cz 2005-11-03 21:23 ---
Subject: Re: [3.4/4.0/4.1 Regression] Long compile time for array initializer
with inlined constructor
Hmm, OK, this adds the neccesary knobs so you can trottle the parameters
even further. Sadly this brings quite dificul
On Thu, Nov 03, 2005 at 02:15:27PM -0700, Shaun Jackman wrote:
> When an object file is compiled by arm-elf-gcc 4.0.2, nm -S 2.16.*
> isn't printing the size of static variables. I'd very much appreciate
> a fix or workaround, if one is out there.
Check what the file really says, using readelf. I
o
0004 0004 C foo
b static_foo
$ nm -S foo.o
0004 0004 C foo
b static_foo
$ gcc -c foo.c
$ nm -S foo.o
0004 0004 C foo
0004 b static_foo
$ arm-elf-gcc --version | head -1
arm-elf-gcc (GCC) 4.0.2
$ arm-elf-nm --version | head -1
GNU nm 2.16.91 2005
--- Comment #3 from steve at telxio dot com 2005-11-03 21:09 ---
=
Backtace from gdb:
=
R500.ramses.185> g++ -g tt.cc
R500.ramses.186> gdb a.out
GNU gdb 6.3
Copyright 2004 Free Software Fo
--- Comment #7 from steven at gcc dot gnu dot org 2005-11-03 21:00 ---
Jakub, ping!
What's up with this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23567
--- Comment #9 from steven at gcc dot gnu dot org 2005-11-03 21:00 ---
Jakub, ping!
What's up with this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
--- Comment #6 from hubicka at ucw dot cz 2005-11-03 20:52 ---
Subject: Re: [4.1 Regression] WRITE(6,*) causes an ICE with -mcmodel=medium
OK, I think what is going on.
For some reason the code deciding whether data should be small or big
considers everything zero sized as unfinished p
Well, 4.0.2 works fine also. The problem is with g77 3.4 only.
C.S.
- Forwarded message from Cezary Sliwa <[EMAIL PROTECTED]> -
When compiled with g77/gfortran, the double precision arpack examples hang
before executing the first line of code. gcc 3.3 works fine.
gcc 3.4.4, 4.0.2
x86
--- Comment #3 from andreast at gcc dot gnu dot org 2005-11-03 20:35
---
Forgot to add where it bombs w/o gdb involved:
antlr/Parser.java: In class 'antlr.Parser':
antlr/Parser.java: In method 'antlr.Parser.consumeUntil(int)':
antlr/Parser.java:0: internal compiler error: Bus error
Ple
--- Comment #2 from steve at telxio dot com 2005-11-03 20:31 ---
Sorry, I forgot to post the version of the Solaris tools:
R500.ramses.129> /usr/ccs/bin/as -V
/usr/ccs/bin/as: Sun Compiler Common 10 s10_73 11/23/2004
R500.ramses.130> /usr/ccs/bin/ld -V
ld: Software Generation Utilities
--- Comment #10 from falk at debian dot org 2005-11-03 20:20 ---
Created an attachment (id=10134)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10134&action=view)
Preprocessed test case
This is not a designed test case, it's distilled from a real-world application
(libqd). I've at
--- Comment #12 from hubicka at gcc dot gnu dot org 2005-11-03 20:19
---
It seems to me that really only solution is working load PRE on TREEs. Since
this is out of 4.1
reach we can either revert my patch or retarget this for 4.2. I must say I am
inclined
to the second - the patch has
strip antlr.so -g -O2 -version
-fclasspath= -fassume-compiled -o /var/tmp//cchNKeYh.s
Reading symbols for shared libraries . done
GNU Java version 4.0.3 20051103 (prerelease) (powerpc-apple-darwin8.3.0)
compiled by GNU C version 4.0.3 20051103 (prerelease).
GGC heuristics: --param ggc-min-expan
--- Comment #59 from sebastian dot pop at cri dot ensmp dot fr 2005-11-03
20:10 ---
Subject: Re: [4.0/4.1 Regression] IV-OPTS is O(N^3)
Here is a first patch that uses PARAM_SCEV_MAX_EXPR_SIZE for limiting
the size of expressions that we want to handle. I will send it to
gcc-patches
--- Comment #9 from hubicka at gcc dot gnu dot org 2005-11-03 20:06 ---
For reload CSE there is --param max-cselib-memory-locations=10
that cuts it's time to 1%, overall.
Since this testcase is sort of designed to excercise the worst case behaviour,
I think it is not too bad...
alias a
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-03 20:01 ---
With x86_64_elf_select_section inbetween.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24188
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-03 19:58 ---
We have a STRING_CST in named_section.
The call to named_section comes from output_constant_def_contents.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24188
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-11-03 19:51
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-03 19:50 ---
Still fails for me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-11-03 19:49
---
Subject: Bug 21627
Author: mmitchel
Date: Thu Nov 3 19:49:19 2005
New Revision: 106443
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106443
Log:
PR c++/21627
* pt.c (register_specializati
--- Comment #2 from hubicka at gcc dot gnu dot org 2005-11-03 19:46 ---
SUBROUTINE FOO
WRITE(6,*) ''
END
balli:/usr/src/gcctest/install/gcc-base/bin # ./gfortran a.F90 -mcmodel=medium
-O1 -S
balli:/usr/src/gcctest/install/gcc-base/bin #
--
hubicka at gcc dot gnu dot org changed:
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-11-03 19:45
---
Subject: Bug 21627
Author: mmitchel
Date: Thu Nov 3 19:45:10 2005
New Revision: 106442
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106442
Log:
PR c++/21627
* pt.c (register_specializati
--- Comment #5 from hubicka at gcc dot gnu dot org 2005-11-03 19:38 ---
This is ineed move-loop-invariants bug. It assumes that destination of memory
store can be changed to register without validating
that is not the case on i386 - you can write arbitrary floating point value to
memory
--- Comment #6 from toon at moene dot indiv dot nluug dot nl 2005-11-03
19:34 ---
Mine ! All Mine !
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--
--- Comment #58 from sebastian dot pop at cri dot ensmp dot fr 2005-11-03
19:31 ---
Subject: Re: [4.0/4.1 Regression] IV-OPTS is O(N^3)
Here are again the numbers for mainline with no other patch:
time ./gcc/cc1 -O2 ~/ex/pr18595_10.c
real0m0.164s
user0m0.116s
sys 0m0.018
--- Comment #6 from bkoz at gcc dot gnu dot org 2005-11-03 19:28 ---
namespace association is the correct name for "strong using."
Indeed, you'll find that this is what I am using.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-03 19:25 ---
Isn't in a way strong using what you want here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
--- Comment #4 from bkoz at gcc dot gnu dot org 2005-11-03 19:10 ---
Created an attachment (id=10133)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10133&action=view)
mainline output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
--- Comment #3 from bkoz at gcc dot gnu dot org 2005-11-03 19:09 ---
Created an attachment (id=10132)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10132&action=view)
mainline chokes on this
Will attach the compiler output as a separate piece. It looks recent, as
gcc-3.4.x, gcc-4
--- Comment #2 from bkoz at gcc dot gnu dot org 2005-11-03 19:08 ---
Created an attachment (id=10131)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10131&action=view)
mainline chokes on this
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
--- Comment #1 from bkoz at gcc dot gnu dot org 2005-11-03 19:07 ---
Created an attachment (id=10130)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10130&action=view)
libstdc++ patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
This is an experiment in versioning the vague parts of libstdc++. It is
apparent that some kind of control over weak symbols is necessary for accurate
versioning of C++ constructs WRT shared libraries.
To that end, the obvious point of influence is the namespace name itself, since
it is part of th
1 - 100 of 184 matches
Mail list logo
