--- Comment #8 from hubicka at gcc dot gnu dot org 2005-11-03 08:22 ---
no longer 4.1 regression.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from olh at suse dot de 2005-11-03 08:24 ---
copying the schedule.o from gcc41 tree to gcc40 tree doesnt help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
--- Comment #16 from laurent at guerby dot net 2005-11-03 08:47 ---
Started passing on x86-linux but still failing on x86_64 as of:
LAST_UPDATED: Wed Nov 2 22:35:36 UTC 2005 (revision 106403)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548
--- Comment #4 from steven at gcc dot gnu dot org 2005-11-03 08:50 ---
We have the following two options:
- Make loop.c preserve the profile. We all know that's not doable.
- Backport the loop-invariant.c changes from the killloop-branch
and enable -fmove-loop-invariants when doing FDO
First known broken version: 4.1 SVN revision 106387
Last known working version: 4.0.1
Trying to byte-compile ecj results in a segmentation fault.
In the attached testcase (it's still relatively huge - sorry, my knowledge of
Java is limited to "it's similar to C++ without MI"), run
cd testcase
fo
--- Comment #1 from bero at arklinux dot org 2005-11-03 09:23 ---
Created an attachment (id=10119)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10119&action=view)
relatively large test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24652
--- Comment #2 from bero at arklinux dot org 2005-11-03 09:29 ---
After hacking the makefiles to get it to build anyway, trying to run an AWT
application aborts on startup because gcj renames libqtpeer.so to
lib-gnu-java-awt-peer-qt.so, while gnu/java/awt/peer/qt/QtToolkit.java still
tri
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-03 09:30 ---
Subject: Bug 24470
Author: rguenth
Date: Thu Nov 3 09:30:12 2005
New Revision: 106426
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106426
Log:
2005-11-03 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2005-11-03 09:31 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #86 from bero at arklinux dot org 2005-11-03 09:38 ---
Created an attachment (id=10120)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10120&action=view)
Updated version of the patch to apply on current SVN
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Comment #1 from mark at gcc dot gnu dot org 2005-11-03 09:41 ---
Confirmed, this prevents gjdoc from building, which used the build just fine
with earlier gcj 4.0.x releases.
--
mark at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from bonzini at gcc dot gnu dot org 2005-11-03 10:05
---
Note that while PR23948 could be fixed by hacking the current recip pass so
that it inserts the division into another basic block, this is not true of this
bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #17 from uros at kss-loka dot si 2005-11-03 10:05 ---
> > FYI: This problem is addressed in patch at
> > http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00116.html.
>
> Do you know if your patch also fixes this PR?
Unfortunatelly no... I don't know if insn size is considered
--- Comment #10 from belyshev at depni dot sinp dot msu dot ru 2005-11-03
10:39 ---
Created an attachment (id=10121)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10121&action=view)
patch for gcc-4_0-branch (same as in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22442#c5)
(In rep
--- Comment #14 from reichelt at gcc dot gnu dot org 2005-11-03 11:25
---
Now also fixed on the 3.4 branch due to Mark's patch for PR 19253:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00141.html
I'd really like to get that one backported to the 3.4 branch
--
reichelt at gcc dot gn
Eon seems to be our largest regression on x86-64 relative to all previous GCCs
up to 3.3-hammer branch.
The slowdown is visible at -O2 for about 7%, at -O3 -ffast-math -march=k8
-funroll-all-loops and profile feedback it is already over 10%.
I've hacked sources so inline decisiosns of 4.0 and 4.1 m
--- Comment #15 from reichelt at gcc dot gnu dot org 2005-11-03 11:26
---
I meant the 4.0 branch of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
--- Comment #14 from reichelt at gcc dot gnu dot org 2005-11-03 11:29
---
Since Mark's patch for PR19253
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00141.html
this is an error again.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #24 from ebotcazou at gcc dot gnu dot org 2005-11-03 11:31
---
Subject: Bug 23585
Author: ebotcazou
Date: Thu Nov 3 11:31:46 2005
New Revision: 106427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106427
Log:
PR rtl-optimization/23585
* rtlanal.c (
--- Comment #25 from ebotcazou at gcc dot gnu dot org 2005-11-03 11:34
---
Subject: Bug 23585
Author: ebotcazou
Date: Thu Nov 3 11:34:55 2005
New Revision: 106428
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106428
Log:
PR rtl-optimization/23585
* rtlanal.c (
--- Comment #2 from mlynarik at decef dot elf dot stuba dot sk 2005-11-03
11:39 ---
Created an attachment (id=10122)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10122&action=view)
Example files describing the problem
Zipped archive contains a c-source, 2 object files and 2 dwar
--- Comment #1 from hubicka at gcc dot gnu dot org 2005-11-03 11:40 ---
Actually I cut&pasted wrong BB and the -fno-tree-sra on 4.0 makes the
difference go away, so ignore the huge dumps :)
Let me see if I can work out something better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #3 from mlynarik at decef dot elf dot stuba dot sk 2005-11-03
11:46 ---
We have attached a c-source file which was compiled once for 64bit abi and once
for 32bit abi with command: "mips64-linux-gnu-gcc -c -gdwarf-2 -mabi=XX
example1.c". The resulting object files are example
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2005-11-03 12:18
---
I cannot reproduce with:
as: Sun Compiler Common 10 s10_73 11/23/2004
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.477
Could you post the backtrace and an excerpt of the dissassembled code
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-03 12:43 ---
You are missing a 'typename'
void operator()(K k)
{
hm[k] = 999;
IntHashMap::iterator itr = hm.find(k);
^^^
here.
IntHashMap is a dependent type.
--
rguenth at gcc dot gnu dot org
--- Comment #2 from hubicka at gcc dot gnu dot org 2005-11-03 12:58 ---
OK, have new, 100% sure theory ;)
for 4.0 -fno-tree-sra makes important difference, for 4.1 it does not. One
difference is that 4.0 splits startingpoint:
Initial instantiation for startPoint
startPoint.e[2] -> sta
--- Comment #4 from olh at suse dot de 2005-11-03 12:58 ---
What I have found so far with even more debugging:
<4>Processor 1 found.
<7>schedule(2883) swapper(0):c1,j4294892318 c000142ae100
<6>Brought up 2 CPUs
<7>_spin_lock_irq(85) swapper(0):c1,j4294892318 l c000142ae100 c
c00
--- Comment #5 from olh at suse dot de 2005-11-03 13:05 ---
Created an attachment (id=10123)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10123&action=view)
PR24644-2.tar.bz2
rq does change between the context switch.
<7>schedule(3025) swapper(0):c1,j4294892318 p cffd704
--- Comment #56 from sebastian dot pop at cri dot ensmp dot fr 2005-11-03
13:24 ---
Subject: Re: [4.0/4.1 Regression] IV-OPTS is O(N^3)
>
> So, I'd suggest that we add a --param here for max-loop-nest-depth, and then
> just not do this stuff on deeper nests, or ignore all the outer l
--- Comment #6 from olh at suse dot de 2005-11-03 13:31 ---
c000142ae100 is for cpu1, while c000142a6100 is for cpu0.
cpu1 was never active before, so all task switches were ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
The following code must now use the plain scope resolution operator in order to
work with gcc4. Is it a regression or a conformance to the specs?
class Initializer ;
namespace NS {
class A {
// Now must use ::Initializer with gcc4 in order to compile
// If not, the following error occu
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-03 14:25 ---
*** This bug has been marked as a duplicate of 24441 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-03 14:25 ---
*** Bug 24652 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-03 14:32 ---
(In reply to comment #3)
Can you look instead into the .s file when compiled with -dA which adds
annotations and then see if DW_AT_high_pc and DW_AT_low_pc is really zero. I
really doubt it. What you are seeing is
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-03 14:37 ---
No this is the correct way that friend resoluves stuff. (Just we did not
implement it correctly before 4.0.2).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-03 14:40 ---
Confirmed (a patch was posted), the issue is that we need to run DCE before
may_alias before SRA.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
Code follows
program dumm
implicit none
integer :: n
double precision :: fi
double precision, parameter :: one=1d0
! Statement functions
fi(n)=n *one
write(6,*) fi(10)
stop
end
The compiler yields
t.f90:0: internal c
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-03 14:43
---
I think this is fixed now by:
PR rtl-optimization/23585
* rtlanal.c (rtx_addr_can_trap_p_1) : Return 0 for an address
that can't trap plus a constant integer, if the mode has zero size.
Can
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-03 14:44 ---
Fixed at least on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-03 14:47 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00195.html
The main reason why DCE is required is that the struct variable is marked as
non TREE_ADDRESSABLE in may_alias.
--
pinskia at gcc dot gnu dot o
--- Comment #18 from rakdver at gcc dot gnu dot org 2005-11-03 14:48
---
The problem first appears in .greg dump (store to a[1] is somehow moved across
a function call that needs its original value)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
--- Comment #9 from jsm28 at gcc dot gnu dot org 2005-11-03 14:49 ---
Subject: Bug 24329
Author: jsm28
Date: Thu Nov 3 14:49:23 2005
New Revision: 106433
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106433
Log:
PR c/24329
* c-pretty-print.c (pp_c_type_specifie
--- Comment #57 from sebastian dot pop at cri dot ensmp dot fr 2005-11-03
15:02 ---
Subject: Re: [4.0/4.1 Regression] IV-OPTS is O(N^3)
sebastian dot pop at cri dot ensmp dot fr wrote:
>
> So, I think that we can safely close this PR.
>
The previous numbers were with mainline + pat
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-03 15:06 ---
Subject: Bug 24582
Author: pinskia
Date: Thu Nov 3 15:06:42 2005
New Revision: 106434
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106434
Log:
2005-11-03 Andrew Pinski <[EMAIL PROTECTED]>
PR c+
--- Comment #19 from rakdver at gcc dot gnu dot org 2005-11-03 15:09
---
Bogus REG_EQUIV note that causes this behavior first appears in .lreg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-03 15:13
---
Subject: Bug 24582
Author: pinskia
Date: Thu Nov 3 15:13:01 2005
New Revision: 106435
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106435
Log:
2005-11-03 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-03 15:13
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-03 15:21
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-03 15:21 ---
Subject: Bug 24589
Author: pinskia
Date: Thu Nov 3 15:21:15 2005
New Revision: 106436
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106436
Log:
2005-11-03 Andrew Pinski <[EMAIL PROTECTED]>
PR mi
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-03 15:21 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
GCC accepts that a function is defined several times under the same
name, provided it is static inline. It seems to rely on the assembler
to check this kind of issues.
Environment:
System: Linux nostromo 2.4.27-2-686-smp #1 SMP Tue Aug 16 15:57:25 JST 2005
i686 GNU/Linux
Architecture: i686
ho
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-03 15:30 ---
Fixed already in 4.0.3. This is a dup of bug 22052.
*** This bug has been marked as a duplicate of 22052 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #25 from pinskia at gcc dot gnu dot org 2005-11-03 15:30
---
*** Bug 24656 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
The first error reported in the attached is:
/home/ivan/ootbc/common/include/bitRow.hh:752: error: argument of type `size_t
(
bitRow::)(bitReference) const' does
not match `size_t'
Subsequent diagnostics are an ignorable cascade. The constructor is declared
as:
template
bitRo
--- Comment #1 from igodard at pacbell dot net 2005-11-03 15:36 ---
Created an attachment (id=10127)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10127&action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24657
--- Comment #2 from igodard at pacbell dot net 2005-11-03 15:36 ---
Created an attachment (id=10128)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10128&action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24657
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-03 15:39 ---
Confirmed, backtrace:
#0 0x0042bc4a in recursive_stmt_fcn (e=0xc08160, sym=0xc07d40)
at /home/pinskia/src/newtest/trunk/gcc/fortran/match.c:2727
#1 0x0042bc25 in recursive_stmt_fcn (e=0xc08420,
--- Comment #18 from dberlin at gcc dot gnu dot org 2005-11-03 15:39
---
Subject: Bug 24351
Author: dberlin
Date: Thu Nov 3 15:39:48 2005
New Revision: 106437
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106437
Log:
2005-11-03 Daniel Berlin <[EMAIL PROTECTED]>
Fix
--- Comment #19 from dberlin at gcc dot gnu dot org 2005-11-03 15:42
---
Fixed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24351
--- Comment #5 from laurent at guerby dot net 2005-11-03 15:42 ---
Confirmed on 4.0.2 and trunk.
+===GNAT BUG DETECTED==+
| 4.0.2 (i686-pc-linux-gnu) in tree_low_cst, at tree.c:3850|
| Error detected at message_pool.adb
--- Comment #20 from dberlin at gcc dot gnu dot org 2005-11-03 15:44
---
Fixed
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from laurent at guerby dot net 2005-11-03 15:49 ---
I'm testing the patch aginst trunk, is it okay for 4.1 or should we wait after
the branch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23427
Compiler version details:
*
gcc -v
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.4/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --enable-languages=c,c++,f
--- Comment #4 from ron_hylton at hotmail dot com 2005-11-03 16:00 ---
The code compiles with Intel C++ for Windows.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24605
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-03 16:03 ---
This is not a bug, this is how C++ works. The f in D hides the one in C unless
you add "using C::f;".
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-03 16:16
---
Subject: Bug 23155
Author: pinskia
Date: Thu Nov 3 16:15:53 2005
New Revision: 106438
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106438
Log:
2005-11-03 Andrew Pinski <[EMAIL PROTECTED]>
PR
Following code should produce a cvtps2pd and cvtpi2pd instructions that operate
on vectors:
void test_fp (float *a, double *b)
{
int i;
for (i = 0; i < 4; i++)
b[i] = (double) a[i];
}
void test_int (int *a, double *b)
{
int i;
for (i = 0; i < 4; i++)
b[i] = (double) a[i];
}
Cur
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-03 16:21
---
Subject: Bug 23155
Author: pinskia
Date: Thu Nov 3 16:21:52 2005
New Revision: 106439
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106439
Log:
2005-11-03 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-03 16:22
---
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-03 16:24 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-03 16:28 ---
Subject: Bug 24483
Author: rakdver
Date: Thu Nov 3 16:28:09 2005
New Revision: 106440
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106440
Log:
PR tree-optimization/24483
* tree-ssa-loop-iv
--- Comment #16 from r dot emrich at de dot tecosim dot com 2005-11-03
16:38 ---
(In reply to comment #15)
I'm trying the patch!
Result will follow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
--- Comment #3 from igodard at pacbell dot net 2005-11-03 16:43 ---
Here's a reduced case:
template struct B {};
struct A {
template
A(const B& b) : j(i) {}
voidi() {}
int j;
};
int main() {
B<5> b;
A a(b);
}
which gets you:
~/ootbc/member
--- Comment #2 from thorsten dot gecks at uni-bayreuth dot de 2005-11-03
16:49 ---
Subject: Re: overloaded function lookup in base class fails
pinskia at gcc dot gnu dot org schrieb:
> --- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-03 16:03
> ---
> This is not a
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-03 17:04 ---
I tested a few different versions of gcc and added the results to known to
work/fail. 3.3.3 accepted this code. before in 3.2.3 (and below), the error
message was :
t.cc:6: declaration of `void A::i()'
t.cc:4: chan
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-03 17:08 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from dorit at il dot ibm dot com 2005-11-03 17:11 ---
vectorization of type conversions has recently been added to autovect-branch.
It requires modeling the respective unpack and pack optabs in the machine
description.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-03 18:12 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from dje at transmeta dot com 2005-11-03 18:18 ---
I'm not sure the root cause of this bug is fixed in 4.1. It looks to me like
it's still there and is only (currently) hidden. Am I mistaken?
Apply this patch to gcc-4.1-20051029 and recompile the testcase with -O3.
I'm
--- Comment #3 from bero at arklinux dot org 2005-11-03 18:24 ---
Created an attachment (id=10129)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10129&action=view)
Patch
Attaching a fix for both issues in 24403, as well as another compile time
problem with the Qt peers.
I'll admi
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-03 18:25 ---
(In reply to comment #2)
> I'm not sure the root cause of this bug is fixed in 4.1. It looks to me like
> it's still there and is only (currently) hidden. Am I mistaken?
> Apply this patch to gcc-4.1-20051029 and r
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-11-03 18:40
---
This looks like a reload problem related to the one I fixed here:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01133.html
I'm currently testing a fix ...
--
uweigand at gcc dot gnu dot org changed:
--- Comment #7 from janis at gcc dot gnu dot org 2005-11-03 18:42 ---
A regression hunt identified the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=60521
r60521 | nathan | 2002-12-26 18:20:14 + (Thu, 26 Dec 2002) | 13 lines
cp:
PR c++/4803
* decl2.c (
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
--- 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
--- 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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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
1 - 100 of 184 matches
Mail list logo
