Kaveh R. GHAZI wrote:
On Mon, 8 Oct 2007, Heikki Linnakangas wrote:
sprintf(dest, %d, arg1); - a new function that does the same thing,
but without the overhead of parsing the format string. Like itoa on some
platforms. We could inline it as well. That would allow further
optimizations, if
Joe Buck wrote:
If your program has one or two dominant sprintf calls (as in the example
that motivated this exercise), it pays off. But for a large program with
thousands of {,s,f}printf calls, this kind of code size expansion could
easily hurt instead of help. Without some data showing a
There is a conflict between the command line switches that turn off individual
optimization steps and their preconditions. Compiling a hello world with the
following options:
-O1 -fno-tree-salias
causes gcc to fail with an internal consistency check. Pass return_slot has
PROP_alias in its
On 10/10/07, Wolfgang Gellerich [EMAIL PROTECTED] wrote:
There is a conflict between the command line switches that turn off individual
optimization steps and their preconditions. Compiling a hello world with the
following options:
This one issue is know, it was reported as PR 33092.
Thanks,
Hi Gcc Webmaster,
I estabilished an http mirror via rsync, updated four times a day with a
cron job, located in Utah (US), available at the URL
http://gcc.bigsearcher.com/;, from my server bigsearcher.com;
Please add this mirror to the list of available mirror location.
Best regards,
Andrea
On 10/10/07, Wolfgang Gellerich [EMAIL PROTECTED] wrote:
There is a conflict between the command line switches that turn
off individual
optimization steps and their preconditions. Compiling a hello
world with the
following options:
This one issue is know, it was reported as PR 33092.
On Wed, Oct 10, 2007 at 12:12:25AM -0400, Kaveh R. GHAZI wrote:
One simplification I don't believe we do yet, that should always be a win,
is turning: sprintf (foo, %c, bar); into:*foo = bar;
You need the null terminator: foo[0] = bar; foo[1] = 0;
But these things are rarely going to be
Jason Merrill wrote:
fafa wrote:
I tried to build gcc from the latest snapshot (gcc-4.3-20071005),
but I undefined the symbol __GTHREAD_HAS_COND
which is desribed in libstdc++-v3\ChangeLog as follows:
...
[!__GTHREAD_HAS_COND] Fall back to the old code, which deadlocks.
...
But
FYI this was libstdc++/33682, and was fixed with:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00415.html
Which was checked in yesterday. Please update your sources and try again.
best,
-benjamin
Hello,
I am currently looking for a topic for graduation thesis. I would
like it to be in the area of GCC code generation enhancements, and my
current best choice is providing predication support in selective
scheduling. If you have anything to suggest, I will be very glad to
hear; or maybe
I am pleased that the current trunk is looking to be in very good shape
for the mipsel-linux target:
http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00397.html
The gcc.c-torture/execute/loop-2[fg].c FAILures are due to kernel bugs.
gcc.c-torture/execute/mayalias-[23].c FAIL on
David Daney [EMAIL PROTECTED] writes:
There are two GCC tests for which I cannot explain the failures:
FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times nasty_local 0
This is on my list of things to look at. It seems to fail on 32-bit
MIPS targets but not 64-bit ones.
FAIL:
$ ./config.guess
i686-pc-linux-gnu
$gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared --enable-threads
--enable-languages=c,c++,fortran,java,objc,obj-c++,treelang
--enable-__cxa_atexit
Thread model: posix
gcc version 4.2.2
Linux
On Wed, 10 Oct 2007, Joe Buck wrote:
On Wed, Oct 10, 2007 at 12:12:25AM -0400, Kaveh R. GHAZI wrote:
One simplification I don't believe we do yet, that should always be a win,
is turning: sprintf (foo, %c, bar); into:*foo = bar;
You need the null terminator: foo[0] = bar; foo[1] =
ÎâêØ wrote:
Well... Is there anything I miss or forget to do ?
Someone needs to step through code in a debugger and try to figure out
what is going wrong.
I made an initial attempt at that. I hacked gcc a little to try to
force a failure with a contrived testcase. The first thing I
On Wed, Oct 10, 2007 at 04:22:45PM -0400, Kaveh R. GHAZI wrote:
But these things are rarely going to be a huge win, and I get
the impression that competing compiler developers only do them
when they help with standard benchmarks.
Their loss. I agree with avoiding these micro opts when
2007/10/11, Jim Wilson [EMAIL PROTECTED]:
Thanks for you helpful hints ! And I am sorry for such a late reply.
I have figured out this problem yesterday :-).
Do we know for sure that the scheduler is failing here? Have you looked
at -da RTL dumps to verify which pass is performing the
--- Comment #10 from belyshev at depni dot sinp dot msu dot ru 2007-10-10
06:08 ---
This bug is not fixed by r129193
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
--- Comment #3 from bonzini at gnu dot org 2007-10-10 06:44 ---
forward_propagate_and_simplify only propagates into single-set insns. In
principle there's nothing to forbid working on other insns (it already does it
for forward_propagate_subreg), but it is made harder because df does
--- Comment #8 from pault at gcc dot gnu dot org 2007-10-10 06:50 ---
(In reply to comment #7)
Hmmm, that's not right, is it? It should be
PROGRAM TST
IMPLICIT NONE
INTEGER :: P(4),I
integer, allocatable :: Q(:)
P = (/2,4,1,3/)
allocate (Q(size(P)))
Q = P
FORALL(I=1:4)
--- Comment #5 from aoliva at gcc dot gnu dot org 2007-10-10 06:31 ---
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00538.html
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from pault at gcc dot gnu dot org 2007-10-10 07:05 ---
(In reply to comment #17)
char.3 = (*(char[0:][1:1] *) atmp.0.data)[S.2][1]{lb: 1 sz: 1};
(*(char[0:][1:1] *) atmp.1.data)[S.2] = char.3;
the first line is correct, the second is not.
For
--- Comment #8 from tbm at cyrius dot com 2007-10-10 07:35 ---
*** Bug 33138 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32370
--- Comment #11 from ubizjak at gmail dot com 2007-10-10 07:59 ---
(In reply to comment #9)
Revision 128957 causes this regression.
I can confirm that r128956 bootstraps OK when configured with
--build=i386-pc-linux-gnu. Also, r128956 compiles and runs testcase from
comment #8 without
--- Comment #1 from kostikbel at ukr dot net 2007-10-10 08:16 ---
Created an attachment (id=14335)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14335action=view)
Fix for free() after putenv() on FreeBSD 7.x
The patch allowed me to bootstrap gcc 4.2.2 on the FreeBSD 7.x with
gnat
Created an attachment (id=14335)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14335action=view)
Fix for free() after putenv() on FreeBSD 7.x
The patch allowed me to bootstrap gcc 4.2.2 on the FreeBSD 7.x with
gnat enabled.
Patch looks good to me. OK for 4.2 branch and trunk.
Arno
The putenv() in the FreeBSD 7.x is made posix-conforming, that means
that the function does not make the copy of the argument string for entering
it into the environment.
As consequence, gcc/ada/env.c, __gnat_setenv() function shall not call
free() on the malloc'ed string. Otherwise, memory of
--- Comment #2 from charlet at adacore dot com 2007-10-10 08:18 ---
Subject: Re: putenv() is made posix-conformant on FreeBSD 7.x
Created an attachment (id=14335)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14335action=view)
--
--- Comment #4 from steven at gcc dot gnu dot org 2007-10-10 09:06 ---
Maybe regstack needs to be taught how to swap stack register loads to avoid the
fxch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26902
--- Comment #4 from pcarlini at suse dot de 2007-10-10 09:19 ---
(In reply to comment #2)
Here's my plan for the legacy hash containers:
1) port debug mode to tr1 associative containers
2) move ext/hash containers to deprecated
Thoughts?
Certainly, I agree with the (mid term?)
--- Comment #33 from steven at gcc dot gnu dot org 2007-10-10 08:57 ---
What happened with the suggestion to only do this in reassoc2 (see comment
#27)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-10-10 09:24
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-10-10 09:24 ---
Subject: Bug 33381
Author: rguenth
Date: Wed Oct 10 09:24:43 2007
New Revision: 129197
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129197
Log:
2007-10-10 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-10-10 09:24 ---
Subject: Bug 33099
Author: rguenth
Date: Wed Oct 10 09:24:43 2007
New Revision: 129197
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129197
Log:
2007-10-10 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-10-10 09:25
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-10-10 09:29
---
Subject: Bug 31899
Author: rguenth
Date: Wed Oct 10 09:29:13 2007
New Revision: 129199
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129199
Log:
2007-10-10 Richard Guenther [EMAIL PROTECTED]
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-10-10 09:29
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dominiq at lps dot ens dot fr 2007-10-10 09:35 ---
Are the codes in #7 and #8 supposed to behave differently?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33686
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-10-10 09:57 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from uros at gcc dot gnu dot org 2007-10-10 10:02 ---
Subject: Bug 33369
Author: uros
Date: Wed Oct 10 10:01:53 2007
New Revision: 129201
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129201
Log:
Backport from mainline:
2007-09-14 Uros Bizjak
--- Comment #3 from uros at gcc dot gnu dot org 2007-10-10 10:02 ---
Subject: Bug 33438
Author: uros
Date: Wed Oct 10 10:01:53 2007
New Revision: 129201
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129201
Log:
Backport from mainline:
2007-09-14 Uros Bizjak
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
At -O2 we should IMNSHO generate the same code for all 3 functions:
typedef union
{
struct
{
int f1, f2, f3, f4, f5, f6, f7, f8;
long int f9, f10;
int f11;
} f;
char s[56];
long int a;
} T;
void
foo (void)
{
T t;
t = (T) { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } };
test
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-10 11:23
---
The problem is that we try simplification in find_array_section() because the
vector subscript is EXPR_ARRAY, which is not necessarily constant (in this
case, the values in the constructor depend on variable i).
struct xt_entry_target {
unsigned char name[1];
};
struct ipt_entry {
unsigned char elems[1];
};
void match_different(const unsigned char *);
int dump_entry(struct xt_entry_target *t)
{
return __builtin_strcmp (t-name, );
}
void is_same(const struct ipt_entry *a)
{
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-10 11:34 ---
The problem here is that some times we use build_pointer_type () and sometimes
we use build_pointer_type_for_mode (). If the latter is called with ref-all
true (as done from builtins.c for unsigned char) we get
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-10 11:37 ---
Another fix would be to exchange the fix for PR19382 by only doing the
folding of builtin_memcmp if the alias set of unsigned char is zero.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33724
--- Comment #12 from zadeck at naturalbridge dot com 2007-10-10 11:41
---
I will look at it today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-10 11:49 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
BugsThisDependsOn|33669 |
AssignedTo|unassigned at gcc dot gnu |zadeck at
This testcase:
--cut here--
extern const int foo (int a);
extern const int bar (int a);
int test (int a)
{
return foo (a) + bar (a);
}
--cut here--
compiles to:
test:
subl$12, %esp
movl%ebx, 4(%esp)
movl16(%esp), %ebx
movl%esi, 8(%esp)
--- Comment #11 from irar at il dot ibm dot com 2007-10-10 13:23 ---
I understand that those symbols have to be renamed, I am just saying that maybe
it should be done in the gimplifier and not in the vectorizer. But since
force_gimple_operand_bsi also goes through the statements list,
--- Comment #2 from tobi at gcc dot gnu dot org 2007-10-10 12:59 ---
I have a patch for this. Unfortunately, while playing around with testcases I
found a new segfault, so I'll have to look into this before submitting.
Failing testcase:
! { dg-do run }
! { dg-options -fbounds-check }
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-10-10 13:28 ---
Not fixed by r129192. I see
FAIL: gcc.c-torture/execute/pr33669.c execution, -O1
FAIL: gcc.c-torture/execute/pr33669.c execution, -O2
FAIL: gcc.c-torture/execute/pr33669.c execution, -Os
on
--- Comment #4 from zadeck at naturalbridge dot com 2007-10-10 13:33
---
Subject: Re: [4.3 Regression] Wrong register allocation
on SH
kkojima at gcc dot gnu dot org wrote:
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-10-10 13:28
---
Not fixed by r129192. I
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-10-10 13:38
---
Subject: Bug 33636
Author: fxcoudert
Date: Wed Oct 10 13:38:38 2007
New Revision: 129208
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129208
Log:
PR fortran/33636
* expr.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-10 13:39 ---
The C FE strips qualifier in building the ARRAY_REF. I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-10-10 13:41
---
Subject: Bug 33391
Author: fxcoudert
Date: Wed Oct 10 13:40:50 2007
New Revision: 129209
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129209
Log:
PR testsuite/33391
*
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-10 13:41
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-10-10 13:42
---
Testcase fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hjl at lucon dot org 2007-10-10 13:52 ---
There are
-- Macro: STACK_BOUNDARY
Define this macro to the minimum alignment enforced by hardware
for the stack pointer on this machine. The definition is a C
expression for the desired alignment (measured
pb-d-128-141-24-81:~/src/pr tobi$ cat t.f90
program array_char
implicit none
character (len=2) :: x, y
character (len=2) :: z(2)
x = a
y = cd
z = [y(1:len(trim(y))), x(1:1)] ! causes segfault
end program array_char
pb-d-128-141-24-81:~/src/pr tobi$ ../hggcc/build/gcc/f951 t.f90
MAIN__
t.f90:6:
--- Comment #3 from tobi at gcc dot gnu dot org 2007-10-10 14:23 ---
The failure from #2 is now PR 33727.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
--- Comment #2 from hjl at lucon dot org 2007-10-10 13:54 ---
(In reply to comment #1)
STACK_BOUNDARY = PREFERRED_STACK_BOUNDARY = INCOMING_STACK_BOUNDARY
But for backward compatibility, we can only do it with a command line
option.
--
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-10 14:38 ---
Note that the (IMHO) valid code:
program array_char
implicit none
character (len=2) :: x, y
character (len=2) :: z(2)
x = a
y = cd
z = (/y(1:len(trim(x))), x(1:len(trim(x)))/) ! causes segfault
print *, z
end
I have a block of code:
struct LatLon : public Coord
{
std::string lat;
std::string lon;
inline LatLon() : lat(), lon() {}
};
Coord* coord;
coord = new LatLon();
static_castconst LatLon*(coord)-lat = static_castconst
LatLon*(other.coord)-lat;
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-10 14:40 ---
OTOH this works:
program array_char
implicit none
character (len=2) :: x
character (len=1) :: z
x = a
z = x(1:len(trim(x)))
end program array_char
So the problem is with array constructors.
--
--- Comment #1 from tobi at gcc dot gnu dot org 2007-10-10 14:25 ---
There's a disabled check in bounds_check_10.f90 (to be submitted) which depends
on this bug, please enable it after fixing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33727
--- Comment #2 from tobi at gcc dot gnu dot org 2007-10-10 14:34 ---
(In reply to comment #1)
There's a disabled check in bounds_check_10.f90 (to be submitted) which
depends
on this bug, please enable it after fixing.
Scratch that, of course after the first runtime error the
--- Comment #5 from bkoz at gcc dot gnu dot org 2007-10-10 15:24 ---
Subject: Bug 33633
Author: bkoz
Date: Wed Oct 10 15:23:59 2007
New Revision: 129210
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129210
Log:
2007-10-10 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #28 from pault at gcc dot gnu dot org 2007-10-10 15:44 ---
The patch below fixes the lot. It was not necessary in the end to touch
trans-intrinsic.c. Once the appropriate, offending bit of trans-array.c was
fixed, all the casting occurred correctly. The fixes to
--- Comment #5 from bkoz at gcc dot gnu dot org 2007-10-10 15:45 ---
This should be fixed now. Please confirm and close.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from rguenther at suse dot de 2007-10-10 15:47 ---
Subject: Re: wrong types in character array/scalar binop
On Wed, 10 Oct 2007, pault at gcc dot gnu dot org wrote:
--- Comment #28 from pault at gcc dot gnu dot org 2007-10-10 15:44
---
The patch below
--- Comment #6 from bkoz at gcc dot gnu dot org 2007-10-10 15:49 ---
Fixed.
Current debug mode results (ie, with make CXXFLAGS=-D_GLIBCXX_DEBUG check)
FAIL: 20_util/pair/moveable.cc execution test
FAIL: 23_containers/deque/moveable.cc execution test
FAIL:
--- Comment #7 from pcarlini at suse dot de 2007-10-10 15:52 ---
Yes, time to fix the moveable.cc tests in debug-mode. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33633
--- Comment #6 from danglin at gcc dot gnu dot org 2007-10-10 17:08 ---
Hans,
Is the attached patch correct?
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pcarlini at suse dot de 2007-10-10 17:36 ---
The moveable.cc fails are now fixed. Otherwise, a couple of fails are also
trivial
23_containers/vector/bool/capacity/29134.cc
23_containers/vector/bool/modifiers/insert/31370.cc
_S_word_size in the wrong namespace.
On 10 Oct 2007 08:58:00 -, steven at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #33 from steven at gcc dot gnu dot org 2007-10-10 08:57
---
What happened with the suggestion to only do this in reassoc2 (see comment
#27)?
Yeah, i'm not sure why we just made both
--- Comment #34 from dberlin at gcc dot gnu dot org 2007-10-10 17:43
---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
On 10 Oct 2007 08:58:00 -, steven at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #33 from steven at gcc dot
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30801
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32086
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32590
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32653
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-10-10 17:52
---
The original submitter says the problem has disappeared.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-10-10 17:53
---
Dave --
Is this fixed with Jan's patch? If so, please close.
Thanks,
-- Mark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33318
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33368
--- Comment #9 from bkoz at gcc dot gnu dot org 2007-10-10 17:56 ---
Sweet, thanks. Any chance you could put in the
23_containers/vector/bool/capacity/29134.cc
23_containers/vector/bool/modifiers/insert/31370.cc
fix too? My sources are in pre-deprecate mode right now...
best,
--- Comment #11 from mmitchel at gcc dot gnu dot org 2007-10-10 17:57
---
I understand that we don't know whether this is a problem in GCC or in Perl.
However, until we know, I think this should be P1 -- having GCC releases that
don't work with SPEC, without an explanation, undermines
--- Comment #10 from pcarlini at suse dot de 2007-10-10 17:57 ---
I don't have a fix ;) Everything seems rather ugly and not worth the trouble...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33633
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-10-10 17:58
---
We really need to fix this class of problems. Every release of GCC over the
past couple of years has had serious aliasing issues that caused real-world
programs to fall over. We can fix this by making the
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33434
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33458
1 - 100 of 144 matches
Mail list logo
