--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-14 09:16 ---
The testcase comes from gcc testsuite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2005-11-14 09:27 ---
Subject: Re: IVs with the same evolution not eliminated
> They can happen due to macro expansion or C++ template inlining.
And do they?
> I wonder if PRE for scalar-evolutions would be usefu
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||fche at redhat dot com
Status|UNCONFIRMED
--- Comment #7 from steven at gcc dot gnu dot org 2005-11-14 10:32 ---
It would be more interesting to measure than think ;-)
My experience is that when it is in Briggs' test suite, it usually also happens
in actually useful code. But, only the numbers will tell :-)
Zdenek is right, it
--- Comment #22 from steven at gcc dot gnu dot org 2005-11-14 10:36 ---
Yes, mesa is down. But is that related to this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18048
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-11-14 09:45 ---
> > They can happen due to macro expansion or C++ template inlining.
> And do they?
If they can, they will do. Will this regularly happen? I think no.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
seen with trunk 20051112
mkdir testsuite/treelang
rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../src/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite; \
EXPECT=expect ; export EXPECT ; \
TRANSFORM=s,$,-4.1,;; export TRANSFORM; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_
--- Comment #18 from charlet at gcc dot gnu dot org 2005-11-14 13:06
---
Subject: Bug 18434
Author: charlet
Date: Mon Nov 14 13:05:58 2005
New Revision: 106886
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106886
Log:
2005-11-14 Robert Dewar <[EMAIL PROTECTED]>
PR a
When linking an OpenMP program it is necessary to explicitly supply
the flag "-lgomp" on the command line; using "-fopenmp" is not sufficient.
Would it be possible to make "-fopenmp" imply "-lgomp" when linking is
performed, as most other compilers do? Or does this lead to problems?
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 13:16 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 13:17 ---
Confirmed, I thought I saw this somewhere else.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24832
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 13:18 ---
Do you have a testcase for this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24834
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 13:19 ---
Confirmed, since this was a split off.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet|i686-pc-linux-gnu |i?86-*-*, x86_64-*-*
Target Milestone|--- |
--- Comment #13 from reichelt at gcc dot gnu dot org 2005-11-14 13:24
---
Fixed on mainline by Mark's patch for PR20293:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00942.html
We now get:
PR12272.cc:10: error: reference to 'NS2' is ambiguous
PR12272.cc:5: error: candidates are: names
--- Comment #1 from aoliva at gcc dot gnu dot org 2005-11-14 13:55 ---
So is pthread_key_delete not declared in HP-UX's DCE headers? Is it actually
the correct spelling, or have we always had a harmless typo in gthr-dce.h? It
looks suspicious because pthread_keycreate doesn't have the
--- Comment #16 from reichelt at gcc dot gnu dot org 2005-11-14 13:56
---
For the record:
I contacted the maintainer of the Linux man pages about the inaccurate
description of frexp (see comment #6). A corrected version will be in
man-pages-2.14.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-14 13:57 ---
There is a problem - -static. If -fopenmp automatically adds -lgomp,
then -static -fopenmp should add -lgomp -lrt -lpthread on some platforms,
-lgomp -lpthread on others, maybe something different elsewhere.
But specs
--- Comment #3 from aoliva at gcc dot gnu dot org 2005-11-14 13:58 ---
Mine
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
enum A{b,c};
template
struct foo {
explicitfoo(T& t);
explicitfoo(foo);
};
int main() {
int i;
foo v(i);
}
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In instantiation of `foo':
foo.cc:10: instantiated from here
foo.cc:5: error: invalid constructor; you probably mean
--- Comment #4 from aoliva at gcc dot gnu dot org 2005-11-14 14:19 ---
Does this target actually support weak declarations? It appears to me that it
only does when the assembler supports .weak, but even then, the linker will
object to undefined weak symbols, which is something this test
--- Comment #5 from aoliva at gcc dot gnu dot org 2005-11-14 14:25 ---
Hmm, this is tricky. I hadn't considered the case of having one of these
functions defined with a symbol that does not have external linkage. I suppose
we may have to take care of this case :-( even though it probab
--- Comment #6 from aoliva at gcc dot gnu dot org 2005-11-14 14:30 ---
Another idea that's just occurred to me is to use a preprocessor macro to
*refer* to the symbols throughout the source files. Say, __gthrw_(x) would
expand to __gthrw_x when weakrefs are available, and to just x othe
The following code generates a parse error:
struct Foo
{
template Foo();
};
template <> Foo::Foo()
{
}
--
Summary: g++ issues parse error on constructor template
specialization.
Product: gcc
Version: unknown
Status: UNCONFIRME
--- Comment #4 from debian-gcc at lists dot debian dot org 2005-11-14
14:57 ---
with the patch proposed in PR24348 down to 12.
Matthias
Running target unix
FAIL: comment compilation from source
FAIL: PR12416 -O3 compilation from bytecode
FAIL: PR6729 -O3 compilation from source
FAIL
The head of the gomp branch reports an ICE when trying to compile the snippet
below:
template struct Healpix_Map {
T *map;
int npix_;
void Import_nograde (const Healpix_Map &orig) {
#pragma omp parallel
{
int m;
#pragma omp for schedule (dynamic)
for (m=0; m &a, Healpix_Map &b) {
--- Comment #6 from amacleod at redhat dot com 2005-11-14 15:18 ---
Subject: Bug 24709
Author: amacleod
Revision: 106865
Modified property: svn:log
Modified: svn:log at Mon Nov 14 15:18:46 2005
--
--- svn:log (
--- Comment #1 from martin at mpa-garching dot mpg dot de 2005-11-14 15:14
---
> gcc version 4.1.0-gomp-20050608-branch 20051109 (experimental) (merged
20051109)
BTW, it appears as if the compiler datestamp is not correctly updated on
the gomp branch (it says 20051109, but there have b
trunk 20051112 fails to bootstrap on m68k-linux, maybe related to 22049
Matthias
stage1/xgcc -Bstage1/ -B/usr/lib/gcc-snapshot/m68k-linux-gnu/bin/ -c -O2
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-defi
We miscompile yyparse of f2c to just
yyparse ()
{
...
:
save1 = yylval;
save2 = yyval;
save3 = yynerrs;
save4 = yyerrflag;
yynerrs = 0;
yyerrflag = 0;
yyerror (&"yacc stack overflow"[0]);
ret:;
yylval = save1;
yyval = save2;
yynerrs = save3;
yyerrflag = save4;
return 1;
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-14 15:27 ---
Created an attachment (id=10233)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10233&action=view)
testcase
self-contained (but complete) yyparse function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-14 15:29 ---
The problem is that with 31.ccp we introduce:
:
save1 = yylval;
save2 = yyval;
save3_92 = yynerrs;
save4_94 = yyerrflag;
yystate_95 = 0;
yychar_96 = -1;
yynerrs = 0;
yyerrflag = 0;
yyp_99 = &yys[53
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||bonzini at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 15:38 ---
*** This bug has been marked as a duplicate of 6259 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-14 15:38 ---
*** Bug 24848 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-14 15:40 ---
Reduced testcase:
void abort(void);
int main()
{
int a[10], *p;
p = &a[-1];
if (p >= &a[9])
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
--- Comment #1 from aoliva at gcc dot gnu dot org 2005-11-14 15:41 ---
Yeah, weakref support in the compiler is independent of .weakref support in the
assembler. If .weakref is not available, the compiler will emulate that by
always using the target symbol name, and deciding at the last
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-11-14 15:42 ---
C++ frontend is fine. With C out of
(.03.gimple)
p = &a + -4B;
D.1282 = &a + 36B;
we (fold?) get
(.10.cleanup_cfg)
p = &a[1073741823];
D.1282 = &a[9];
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-14 15:42 ---
Confirmed, short testcase:
int f(void)
{
int i = -1;
int a[10];
int *b = &a[2];
return &a[i]>=b;
}
int main(void)
{
if (f())
abort();
}
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #17 from sje at cup dot hp dot com 2005-11-14 15:44 ---
Eric, can you be more specific about what won't work? The regression testing
with Zack's patch seemed to go fine and hand testing some cases looks OK too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2005-11-14 15:52
---
> Eric, can you be more specific about what won't work? The regression testing
> with Zack's patch seemed to go fine and hand testing some cases looks OK too.
Do you have a eh_dummy.o file for both -milp32 and
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-14 15:56 ---
The problem here is that we are comparing in unsigned when we shoud be
comparing in a signed type.
This was introduced by:
2005-01-29 Richard Guenther <[EMAIL PROTECTED]>
PR tree-optimization/15791
--- Comment #19 from sje at cup dot hp dot com 2005-11-14 16:01 ---
Yes, I checked the installed libgcc_eh.a
(lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and
lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain
eh_dummy.o. I do not getting any warnings messages from ld wh
--- Comment #7 from amacleod at redhat dot com 2005-11-14 16:01 ---
Subject: Bug 24709
Author: amacleod
Date: Sun Nov 13 16:09:14 2005
New Revision: 106865
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106865
Log:
PR tree-optimization/24709
* tree-ssa-operands.
// compile this with -O3 to get segfault on 4.0.3,
// note the "warning: inline function 'A::~A()' used but never defined".
// 3.3 and 4.1 accept this code without warning.
// This bug was originally reported by Alexey Maximov <[EMAIL PROTECTED]>
struct A;
template
struct P
{
P() : p(0) { }
~
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 16:04 ---
This is a dup of bug 24248 which in turn is a dup of bug 22252.
*** This bug has been marked as a duplicate of 22252 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-14 16:04 ---
*** Bug 24852 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #20 from bugzilla-gcc at thewrittenword dot com 2005-11-14
16:07 ---
(In reply to comment #19)
> Yes, I checked the installed libgcc_eh.a
> (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and
> lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain
> eh_dummy.o. I
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2005-11-14 16:09
---
> Yes, I checked the installed libgcc_eh.a
> (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and
> lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain
> eh_dummy.o. I do not getting any warnings mes
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build, ice-on-valid-code
Target Milestone|---
For current mainline and Apple 3.3/4.0, the top pass in the profile is
scheduling: 14.99 (42%) usr 4.32 (75%) sys 19.32 (46%) wall
Note that at -O0, instead, it is
global alloc : 1.06 (30%) usr 0.03 ( 5%) sys 1.09 (26%) wall
but I doubt we can do much about it.
--- Comment #1 from bonzini at gcc dot gnu dot org 2005-11-14 16:22 ---
Created an attachment (id=10234)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10234&action=view)
file used for benchmarking
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-14 16:27 ---
Valid testcase (?):
void abort(void);
int main()
{
int a[10], *p, *q;
q = &a[1];
p = &q[-1];
if (p >= &a[9])
abort ();
return 0;
}
fold_stmt is doing the &a[0] + -4B to &a[1073741823] transformation.
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2005-11-14 16:28
---
> Odd. We have the latest linker patch installed on our system (PHSS_33349) and
> applying Eric's patch added eh_dummy.o to libgcc_eh.a but the linker still
> gave
> a warning. I guess 'struct eh_dummy;' didn't
--- Comment #23 from sje at cup dot hp dot com 2005-11-14 16:33 ---
I build binutils 2.16 as part of my GCC build/test so I used that ar and ranlib
when building GCC:
ar --version
GNU ar 2.16.91 20051103
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you ma
--- Comment #24 from bugzilla-gcc at thewrittenword dot com 2005-11-14
16:59 ---
(In reply to comment #23)
> I build binutils 2.16 as part of my GCC build/test so I used that ar and
> ranlib
> when building GCC:
We're using the system ar/ranlib. I built binutils-2.16 with _no_ patches
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-14 17:03 ---
Patch to avoid the situation posted.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-14 17:04 ---
(In reply to comment #8)
> Patch to avoid the situation posted.
So this patch makes the real bug latent.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #25 from sje at cup dot hp dot com 2005-11-14 17:05 ---
I build binutils with --disable-shared and using flex/bison instead of
lex/yacc, that is probably why my ar works. I experimented with the use of the
system ar/ranlib by just building eh_dummy.o and .a by hand and they
--- Comment #26 from bugzilla-gcc at thewrittenword dot com 2005-11-14
17:18 ---
(In reply to comment #25)
> I build binutils with --disable-shared and using flex/bison instead of
> lex/yacc, that is probably why my ar works. I experimented with the use of
> the
> system ar/ranlib by
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-14 17:25 ---
Gfortran is doing the right thing with respect to
a BOZ-literal-constant (other than a BOZ can only
be used in a DATA statement per the F95 standard,
so the code is invalid).
If you look at the definition of BOZ in th
--- Comment #27 from sje at cup dot hp dot com 2005-11-14 17:26 ---
In your last comment you mention the binutils ar, but later the binutils as. I
cannot reproduce the problem by just using the binutils ar command but I can
reproduce it using the binutils as (assembler) command. Which
--- Comment #3 from kargl at gcc dot gnu dot org 2005-11-14 17:29 ---
Remove "wrong-code" keyword because gfortran is doing
the correct thing with a BOZ-literal-constant with the
exception of permitting BOZ-literal-constant in non-DATA
statements.
--
kargl at gcc dot gnu dot org chan
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-14 17:29
---
Actually I was wrong on which patch caused/exposed this,
This was caused by:
2005-05-14 Richard Guenther <[EMAIL PROTECTED]>
* fold-const.c (div_if_zero_remainder): New function.
(try_move_mult_t
--- Comment #28 from bugzilla-gcc at thewrittenword dot com 2005-11-14
17:29 ---
(In reply to comment #27)
> In your last comment you mention the binutils ar, but later the binutils as.
> I
> cannot reproduce the problem by just using the binutils ar command but I can
> reproduce it u
--- Comment #29 from sje at cup dot hp dot com 2005-11-14 17:31 ---
In my comment I meant to say I could reproduce the problem with the HP
assembler, but not with the GNU assembler (even if I use the GNU ar). I will
test some more combinations.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-14 17:31
---
div_if_zero_remainder assumes that the type of the agruments comming in are the
same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
--- Comment #30 from sje at cup dot hp dot com 2005-11-14 17:35 ---
OK, I have reproduced it with GNU as (assembler) and HP ar. Should we bypass
the whole issue by putting 'int __libgcc_eh_dummy;' in eh_dummy.o and use that
as the 3.4 patch? I am willing to test and submit such a patch
--- Comment #9 from janis at gcc dot gnu dot org 2005-11-14 17:39 ---
A regression hunt on powerpc-linux shows that the testcase from comment #8
starts failing with this large merge from the autovect branch, within the
date range that the submitter identified:
http://gcc.gnu.org/viewcvs
--- Comment #31 from bugzilla-gcc at thewrittenword dot com 2005-11-14
17:41 ---
Sure. I don't understand how Zack's patch works but as long as we have a
solution that works, fine by me. Eric might be interested in reviewing the
patch too.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #32 from sje at cup dot hp dot com 2005-11-14 17:46 ---
Do you see this problem on the Top-of-tree and/or 4.0 sources? That seems to
use the same eh_dummy.c file (struct eh_dummy;) as 3.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
--- Comment #33 from bugzilla-gcc at thewrittenword dot com 2005-11-14
17:51 ---
(In reply to comment #32)
> Do you see this problem on the Top-of-tree and/or 4.0 sources? That seems to
> use the same eh_dummy.c file (struct eh_dummy;) as 3.4.
4.0.2 had the same problem.
--
http:
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2005-11-14 17:51
---
> Sure. I don't understand how Zack's patch works but as long as we have a
> solution that works, fine by me. Eric might be interested in reviewing the
> patch too.
The misunderstanding has been cleared with Ste
--- Comment #10 from mark at codesourcery dot com 2005-11-14 17:59 ---
Subject: Re: [4.1 Regression] ICE on pointer initialization
with C99 initializer
giovannibajo at libero dot it wrote:
> --- Comment #9 from giovannibajo at libero dot it 2005-11-14 00:30
> ---
> Mark, do
--- Comment #2 from bonzini at gcc dot gnu dot org 2005-11-14 18:12 ---
Top of the profile:
1051747.2325 cc1 cc1sched_analyze_insn
98121 6.7475 cc1 cc1free_deps
89078 6.1256 cc1 cc1bitmap_set_bit
63000 4.3323 cc1
--- Comment #11 from dberlin at gcc dot gnu dot org 2005-11-14 18:14
---
Mark, the frontend is producing the address of a constructor, and nothing in
the middle end used to be really analyzing static iniatlizers which is why it
didn't break before (those that do try to look at them woul
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #10 from dberlin at gcc dot gnu dot org 2005-11-14 18:18
---
It probably did *nothing at all* before the merge. The ICE is not too hard to
fix, i just haven't gotten to it yet
I will hopefully soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2005-11-14 18:21
---
> For current mainline and Apple 3.3/4.0, the top pass in the profile is
>
> scheduling: 14.99 (42%) usr 4.32 (75%) sys 19.32 (46%) wall
Is it the first scheduling pass? If so, we have a patch
--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2005-11-14
18:26 ---
Subject: Re: scheduling takes 40% or more time
>Is it the first scheduling pass? If so, we have a patch at AdaCore to limit
>its explosion.
>
>
Yes, it is. schedule_insns2 takes nothing.
Paolo
--
--- Comment #12 from mark at codesourcery dot com 2005-11-14 18:27 ---
Subject: Re: [4.1 Regression] ICE on pointer initialization
with C99 initializer
dberlin at gcc dot gnu dot org wrote:
> --- Comment #11 from dberlin at gcc dot gnu dot org 2005-11-14 18:14
> ---
> Mark,
--- Comment #2 from hp at gcc dot gnu dot org 2005-11-14 18:35 ---
In response to comment #1 regarding "excess errors", see the original
description: I don't get any, I just get a call to abort when the
test-program is executed (as you know, the "*** EXIT code 4242" is
the status-wrapper
--- Comment #2 from m4341 at abc dot se 2005-11-14 18:42 ---
This was detected by opening the whole set of Java files in Eclipse (and not
having any standard Java library at all selected). The close method stood out
as an error. since it was declared to throw an exception in the classes
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-14 18:47
---
Note we haveyyp = &yys[-1]; (where yys is an array) in
the orginal testcase so that is undefined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2005-11-14 18:50
---
Created an attachment (id=10236)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10236&action=view)
Patch (against 3.4.x) for controlling the explosion of the 1st scheduling pass.
* params.def (PARAM_
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-14 19:08
---
I have a fix for the only valid testcase (comment #7) here.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-14 19:09
---
(In reply to comment #13)
> I have a fix for the only valid testcase (comment #7) here.
s/valid/defined/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-14
19:15 ---
Subject: Re: [4.1 regression] gthr-dce.h:77: error: expected expression before
'{' token
> So is pthread_key_delete not declared in HP-UX's DCE headers? Is it actually
> the correct spelling, or have we a
--- Comment #2 from m4341 at abc dot se 2005-11-14 19:18 ---
Created an attachment (id=10237)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10237&action=view)
Proposal for the initial split.
This is the initial split I did, and I must admit that it isn't thoroughly
tested.
There a
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 19:32 ---
Comeau also rejects this. I don't understand why we are trying to instantiate
foo::foo(foo) except to try to match the constructor, so
maybe this is invalid after all. Some one else really needs to look at this.
A
>From Joel Sherril
arm-rtems4.7 - C, C++ OK. Ada fails with this:
../../xgcc -B../../ -c -DCROSS_COMPILE -DIN_GCC `echo -g -O2
-Dinhibit_libc -fno-inline -fexceptions -DIN_RTS |sed -e
's/-pedantic//g' -e 's/-Wtraditional//g'` \
-I. -I.. -I../..
-I/home/joel/gcc-work/head/gcc-
--- Comment #8 from janis at gcc dot gnu dot org 2005-11-14 19:40 ---
A regression hunt on powerpc-linux using -O2 with the testcase in comment #7
identified the following large patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=100478
r100478 | dnovillo | 2005-06-02 02:57:15 + (Thu, 0
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-14
19:40 ---
Subject: Re: FAIL: gcc.dg/attr-weakref-1.c
> Does this target actually support weak declarations? It appears to me that it
> only does when the assembler supports .weak, but even then, the linker will
> o
--
Summary: call to setlocale doesn't return expected value
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
Reported
>From Joel Sherrill:
Gcc on the head fails to compile arm-rtems4.7 at the following point
when Ada is enabled.
../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg s-auxdec.adb -o
s-auxdec.o
s-auxdec.ads:286:13: alignment for "Aligned_Word" must be at least 4
The code is:
type Aligned_Wor
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 19:48 ---
Why do you think this is a GCC bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
--- Comment #1 from joel at gcc dot gnu dot org 2005-11-14 19:48 ---
Created an attachment (id=10238)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10238&action=view)
Simple fix
This is the simplest way to fix this bug. I just added an include of stdarg.h
but I don't know if this
--- Comment #7 from jb at gcc dot gnu dot org 2005-11-14 19:48 ---
Subject: Bug 21468
Author: jb
Date: Mon Nov 14 19:48:31 2005
New Revision: 106898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106898
Log:
2005-11-14 Janne Blomqvist <[EMAIL PROTECTED]>
PR fortran/21
1 - 100 of 180 matches
Mail list logo
