--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-29 07:04 ---
Function declaration
function LoadLibrary(lpFileName) bind(C,name='LoadLibraryA')
!gcc$ ATTRIBUTES STDCALL :: LoadLibrary
use ISO_C_BINDING
... and use
hmodule = LoadLibrary('fun.dll'//achar(0))
..
--- Comment #5 from uros at gcc dot gnu dot org 2009-07-29 07:11 ---
Subject: Bug 40577
Author: uros
Date: Wed Jul 29 07:11:09 2009
New Revision: 150198
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150198
Log:
PR target/40577
* config/alpha/alpha.c (alpha_expan
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-29 07:27 ---
>From the thread at c.l.f:
"A little testing revealed that the assembly code is correct, only the mangled
name is wrong when there is a character argument. Perhaps the mangled name
takes into account a spurious h
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-07-29 07:32
---
By using my cross-compiler and setting a breakpoint in
i386_pe_mangle_decl_assembler_name(), I can confirm the analysis (that it's a
question of hidden length parameter).
--
http://gcc.gnu.org/bugzilla/show_b
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/756be3846916a4b0
- not yet debugged/confirmed.
--
Summary: Leakage with derived types with ALLOCATABLE components
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-07-29 08:06
---
I'll take this for now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
A
--- Comment #9 from rguenther at suse dot de 2009-07-29 08:05 ---
Subject: Re: Function object abstraction penalty
with inline functions.
On Tue, 28 Jul 2009, paolo dot carlini at oracle dot com wrote:
> --- Comment #7 from paolo dot carlini at oracle dot com 2009-07-28 19:38
>
--- Comment #11 from hubicka at ucw dot cz 2009-07-29 08:08 ---
Subject: Re: Function object abstraction penalty with inline functions.
> I'll take this for now.
My preferred way of fixing this would be to include FRE pass.
Unfortunately my last benchmarks adding FRE early wasn't showi
--- Comment #8 from rguenther at suse dot de 2009-07-29 08:09 ---
Subject: Re: [4.5 Regression] ICE with recursion
at -O3
On Tue, 28 Jul 2009, jamborm at gcc dot gnu dot org wrote:
> --- Comment #7 from jamborm at gcc dot gnu dot org 2009-07-28 20:59
> ---
> Ha, please disr
--- Comment #12 from rguenther at suse dot de 2009-07-29 08:12 ---
Subject: Re: Function object abstraction penalty
with inline functions.
On Tue, 28 Jul 2009, jamborm at gcc dot gnu dot org wrote:
> --- Comment #8 from jamborm at gcc dot gnu dot org 2009-07-28 21:33
> ---
--- Comment #11 from ro at techfak dot uni-bielefeld dot de 2009-07-29
08:20 ---
Subject: Re: [4.4/4.5 Regression] tools.zip doesn't build on systems with
short command lines
htl10 at users dot sourceforge dot net writes:
> I have a slightly different message on alphaev68-dec-osf5.1a
Compile the following code with options -Os -mthumb -march=armv5te
extern short shortv2();
short shortv1()
{
return shortv2();
}
Gcc generates
push{r3, lr}
bl shortv2
lsl r0, r0, #16// A
asr r0, r0, #16// B
pop {r3, pc}
The
--- Comment #1 from carrot at google dot com 2009-07-29 08:57 ---
Created an attachment (id=18266)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18266&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40900
--- Comment #4 from davek at gcc dot gnu dot org 2009-07-29 09:23 ---
Reopening against 4.3.4 RC 20090727.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-07-29 09:27 ---
Can you please try this with -fno-tree-sra? If you have a revision
earlier than 147980 (new SRA) at hand, can you try that with
-fno-tree-sra? Thanks.
I'll try to reproduce this on gcc61 at the compile farm but it
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org
|dot org
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-29 09:33 ---
You don't see it on ARM for this case because of tail-calling. But for Thumb or
without sibcall optimizations you do see this problem.
--
ramana at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-29 09:35 ---
Subject: Bug 40851
Author: burnus
Date: Wed Jul 29 09:35:15 2009
New Revision: 150203
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150203
Log:
2009-07-29 Tobias Burnus
PR fortran/40851
*
Consider the following code fragment:
BEGIN CODE ==
#include
using namespace std;
class A {
private: //protected:
template
struct s {
enum {value = y };
};
public:
A() {}
};
int main() {
A();
cout << A::s<10>::value << endl;
return 0;
}
END CODE ==
Both
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-07-29 09:51 ---
(In reply to comment #8)
> > --- Comment #7 from jamborm at gcc dot gnu dot org 2009-07-28 20:59
> > ---
> > So, I belive the patch below fixes this issue and I am going to
> > bootstrap it overnight. Hon
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-07-29 10:16
---
(In reply to comment #12)
> ... at least scheduling FRE is still on the list of possible things
> todo (can you check if that fixes 3713 as well?)
>
No, it doesn't (unlike the testcase above, for which FRE is eno
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-29 10:20 ---
FX: As you seemingly have a working cross compiler: Can you check the patch
below?
(One does not need to consider the return value as gfc_return_by_reference
deals with that. Only the last change is relevant, the oth
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2009-07-29 10:28
---
The patch seems to work:
$ cat a.f90
subroutine foo
use ISO_C_BINDING
implicit none
interface
function LoadLibrary(lpFileName) bind(C,name='LoadLibraryA')
use ISO_C_BINDING
--- Comment #3 from ramana at gcc dot gnu dot org 2009-07-29 10:33 ---
I don't think this is a backend specific problem but more an rtl-optimization
problem where combine with its sign extension detection machinery should be
extended to detect such cases.
--
ramana at gcc dot gnu do
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-07-29 10:33
---
Bootstrap and testing finished fine, I submitted the patch:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01642.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
--- Comment #14 from rguenther at suse dot de 2009-07-29 10:57 ---
Subject: Re: Function object abstraction penalty
with inline functions.
On Wed, 29 Jul 2009, jamborm at gcc dot gnu dot org wrote:
> --- Comment #13 from jamborm at gcc dot gnu dot org 2009-07-29 10:16
> ---
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-07-29 11:01
---
looks similar to bug 40843 but I'm not sure if it's the same
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40901
--- Comment #2 from janus at gcc dot gnu dot org 2009-07-29 11:41 ---
(In reply to comment #1)
> In a similar vain: One could introduct an option to disable warning for the
> deleted features
Good point. In particular these are:
(1) Real and double precision DO variables.
(2) Branchi
--- Comment #5 from davek at gcc dot gnu dot org 2009-07-29 11:45 ---
Subject: Bug 38903
Author: davek
Date: Wed Jul 29 11:45:30 2009
New Revision: 150209
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150209
Log:
PR bootstrap/38903: Backport fix from HEAD.
* con
--- Comment #6 from davek at gcc dot gnu dot org 2009-07-29 12:08 ---
Fixed on gcc-4_3-branch.
Not present on gcc-4_4-branch, fix was applied to HEAD before branching.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from dodji at gcc dot gnu dot org 2009-07-29 12:40 ---
Subject: Re: New: enum constants don't appear in debug_pubnames
Le 10/04/2009 01:42, tromey at gcc dot gnu dot org a écrit :
> enum constants don't appear in .debug_pubnames.
> It seems like perhaps they should, bec
--- Comment #4 from jb at gcc dot gnu dot org 2009-07-29 12:46 ---
(In reply to comment #3)
> Is there a particular reason why we can not change this to off_t with 4.5.?
>
Yes, it would break the ABI. As it's such a minor issue, IMHO it can be
postponed until we need to break the ABI f
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
13:08 ---
Subject: Re: [4.5 Regression] FAIL:
g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and
above
> Can you please try this with -fno-tree-sra? If you have a revision
> earlier
>From 464.h264ref we can see that for
t1.c
const int i[10] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
t2.c
extern int i[10];
int main () { return i[0]; }
we should merge both decls, retaining the const qualification (the middle-end
considers both types compatible, lto_symtab_compatible doesn't).
--
t1.c
double i;
t2.c
int i;
int main () { return i; }
should be accepted with -fcommon.
What needs to be done is that we have to keep a list of decls per symtab
entry that we might end up merging to and we need to return the proper
decl when looking up the canonical decl.
A warning is still appr
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-29 13:39 ---
I'm working on this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assign
--- Comment #11 from jamborm at gcc dot gnu dot org 2009-07-29 13:40
---
(In reply to comment #8)
> That only detects direct loops, does it?
Actually, now I may understand but no, it is exactly the other way
round. The patch above only detects indirect loops, when there are at
le
http://gcc.gnu.org/onlinedocs/gfortran/COUNT.html
"COUNT(MASK [, DIM [, KIND]]) counts the number of .TRUE. elements of MASK
along the dimension of DIM. If DIM is omitted it is taken to be 1. DIM is a
scalar of type INTEGER in the range of 1 /leq DIM /leq n) where n is the rank
of MASK."
The desc
--- Comment #5 from matz at gcc dot gnu dot org 2009-07-29 14:42 ---
Subject: Bug 40830
Author: matz
Date: Wed Jul 29 14:41:38 2009
New Revision: 150215
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150215
Log:
PR middle-end/40830
* gcc.dg/vect/vect-pre-interact.c: XFAIL for no
--- Comment #6 from matz at gcc dot gnu dot org 2009-07-29 14:43 ---
Marvelous, ia64 doesn't support alignment compensation. So, xfailing the
test on such targets seems the right way. Fixed again.
--
matz at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from burnus at gcc dot gnu dot org 2009-07-29 14:45 ---
Subject: Bug 40898
Author: burnus
Date: Wed Jul 29 14:44:51 2009
New Revision: 150216
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150216
Log:
2009-07-29 Tobias Burnus
PR fortran/40898
*
--- Comment #7 from burnus at gcc dot gnu dot org 2009-07-29 14:47 ---
FIXED on the trunk (4.5) - does not affect any branch.
(In reply to comment #5)
> The patch seems to work:
It caused a regression when I tried to regtest it as I missed another
(follow-up) place, cf. http://gcc.gnu.
--- Comment #1 from kretz at kde dot org 2009-07-29 14:51 ---
I just tested with 4.4.1 and I can still confirm the problem.
--
kretz at kde dot org changed:
What|Removed |Added
---
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
16:02 ---
Subject: Re: [4.5 Regression] FAIL:
g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and
above
Attached tree dump.
Dave
--- Comment #6 from dave at hiauly1 dot hia dot
GCC creates invalid executable when an array from one DLL is accessed from
another DLL in a function with __attribute__((cold)).
--
$ cat dll1.c
int foo[2] = {0, 1};
$ cat dll2.c
extern int foo[2];
__attribute__((cold))
int bar(void)
{
return foo[1];
}
$ cat main.c
int bar(void);
int
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-29 16:10 ---
IIRC the cold attribute does a couple of things. The only thing I think that
might cause this is putting it into a .text.cold section.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Hi. Try this program:
#include
void f(long double a)
{
if (a != 1.0) abort();
}
int g(long double b)
{
f(b);
return 0;
}
int main(void)
{
g(1.0);
return 0;
}
Compile it with "-O2 -mpush-args -mno-accumulate-outgoing-args
-fomit-frame-pointer -fno-inline
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-29 17:07 ---
Created an attachment (id=18270)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18270&action=view)
A patch for the bug
A patch for the problem.
1. reverse the direction of "change_address
--- Comment #7 from danglin at gcc dot gnu dot org 2009-07-29 17:09 ---
In the 'ch' pass, we have:
:
a.85 = a;
SR.155_25 = b._M_value;
...
This gets transformed in the 'cplxlower' pass to
:
a.85 = a;
SR.155$real_7 = REALPART_EXPR ;
SR.155$imag_1 = IMAGPART_EXPR ;
However,
When compiling Scheme 48 with -O2, an overflow check in the internal arithmetic
gets elided. This bug showed up sometime after gcc 4.0.1. It's in 4.4.1, and
in the 4.5-20090723 snapshot. It's been seen on 32-bit Linux and 32-bit
FreeBSD.
The code snippet in question in c/scheme48vm-32.c is this:
--- Comment #1 from sperber at deinprogramm dot de 2009-07-29 17:37 ---
Created an attachment (id=18271)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18271&action=view)
preprocessed source file
gcc -v output:
kramer[420] gcc -v -save-temps -c -DHAVE_CONFIG_H
-D__COMPILING_SCHEM
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-29 17:40 ---
../s48/c/scheme48vm-32.c: In function 'current_code_vector':
../s48/c/scheme48vm-32.c:1426:8: warning: 'v_231X' may be used uninitialized in
this function
../s48/c/scheme48vm-32.c: In function 'HtopD12136':
../s48/c/
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-29 17:41 ---
>an overflow check in the internal arithmetic gets elided.
Does -Wno-strict-overflow fix the issue? Does -fwrapv fix the issue?
If so you are depending on overflow being defined as wrapping and the code is
undefin
--- Comment #4 from sperber at deinprogramm dot de 2009-07-29 17:42 ---
(From update of attachment 18271)
In the preprocessed file, the test that gets elided is in line 20307.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40907
1 incompatible symbols
0
_ZNSt5mutexC1Evstd::mutex::mutex()
version status: incompatible
GLIBCXX_3.4
type: functionstatus: added
=== libstdc++-v3 check-abi Summary ===
# of added symbols: 119
# of missing symbols:0
# of incompatible symbols: 1
usin
--- Comment #2 from rth at gcc dot gnu dot org 2009-07-29 17:55 ---
I believe a "proper" way to handle this, preserving the semantics that
the linker provides, is to transform this into
union {
double _1;
int _2;
} i;
and replace occurrences with i._1, i._2, etc.
Perhaps a more in
--- Comment #3 from rguenther at suse dot de 2009-07-29 18:01 ---
Subject: Re: LTO doesn't merge common sections properly
On Wed, 29 Jul 2009, rth at gcc dot gnu dot org wrote:
> --- Comment #2 from rth at gcc dot gnu dot org 2009-07-29 17:55 ---
> I believe a "proper" way to
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-29 18:03
---
If I'm not wrong, please double check, nothing happened in the library proper
between those versions, thus it looks like by chance a function is not inlined
anymore and now is matched by old loose bits of the l
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-29 18:07
---
By "a function", I meant of course _ZNSt5mutexC1Evstd::mutex::mutex(). In the
meanwhile I checked that indeed that symbol normally is *not* exported at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #4 from rth at gcc dot gnu dot org 2009-07-29 18:10 ---
So LTO still produces N output object files for N input files?
Cause you can't just output
.comm i,4,4
.comm i,8,8
in one object file, and I didn't see any changes to varasm.c...
--
http://gcc.gnu.org/bugzill
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-29 18:12 ---
long lo_b_2268X;
long lo_a_2267X;
long lo_c_2271X;
...
lo_a_2267X = 65535 & a_1962X;
lo_b_2268X = 65535 & b_2266X;
...
lo_c_2271X = ((lo_a_2267X) * (lo_b_2268X));
...
if ((536870911 < lo_c_2271X)) {
...
--- Comment #5 from rguenther at suse dot de 2009-07-29 18:18 ---
Subject: Re: LTO doesn't merge common sections properly
On Wed, 29 Jul 2009, rth at gcc dot gnu dot org wrote:
> --- Comment #4 from rth at gcc dot gnu dot org 2009-07-29 18:10 ---
> So LTO still produces N out
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-29 18:15 ---
patches should be sent to gcc-patches with a proper changelog entry and a note
on how you tested the patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
18:27 ---
Subject: Re: FAIL: abi_check
> If I'm not wrong, please double check, nothing happened in the library proper
> between those versions, thus it looks like by chance a function is not inlined
> anymore and n
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-29 19:20 ---
Ah, it's because I don't push to lto_global_var_decls. We can at
write-global-declarations time walk over all global vars and exchange the
written decl for
the largest in the chain.
--
http://gcc.gnu.org/bugzil
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
19:31 ---
Subject: Re: FAIL: abi_check
> By "a function", I meant of course _ZNSt5mutexC1Evstd::mutex::mutex(). In the
> meanwhile I checked that indeed that symbol normally is *not* exported at all.
I see a weak d
--- Comment #5 from paolo dot carlini at oracle dot com 2009-07-29 19:42
---
Yes, that is not supposed to be exported. Indeed, it isn't, on x86_64, for
example. For some reason, a 3_4 linker script pattern matches it, probably
matches std::m* things...
--
http://gcc.gnu.org/bugzill
--- Comment #6 from paolo dot carlini at oracle dot com 2009-07-29 19:46
---
Try something like this:
Index: config/abi/pre/gnu.ver
===
--- config/abi/pre/gnu.ver (revision 150220)
+++ config/abi/pre/gnu.ver (wor
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
20:13 ---
Subject: Re: FAIL: abi_check
> Try something like this:
Works for me.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40908
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-07-29 20:16
---
Subject: Bug 40834
Author: rguenth
Date: Wed Jul 29 20:16:32 2009
New Revision: 150222
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150222
Log:
2009-07-29 Richard Guenther
PR c++/40834
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-07-29 20:16
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #53 from jason at gcc dot gnu dot org 2009-07-29 20:36 ---
Subject: Bug 14912
Author: jason
Date: Wed Jul 29 20:35:40 2009
New Revision: 150223
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150223
Log:
PR c++/14912
* cp-tree.h (enum tsubst_flags): Ad
--- Comment #8 from paolo at gcc dot gnu dot org 2009-07-29 21:00 ---
Subject: Bug 40908
Author: paolo
Date: Wed Jul 29 21:00:10 2009
New Revision: 150228
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150228
Log:
2009-07-29 Paolo Carlini
PR libstdc++/40908
*
--- Comment #9 from paolo dot carlini at oracle dot com 2009-07-29 21:02
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #4 from jonathan dot sd24 at yahoo dot de 2009-07-29 21:05
---
Template-Parameters can be results of long calculations or typedefs with
several layers of indirection.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793
--- Comment #54 from jason at gcc dot gnu dot org 2009-07-29 21:09 ---
Thanks for the testcase, the patch I just checked in should fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
--- Comment #2 from bennett dot schneider at yahoo dot com 2009-07-29
22:11 ---
I've seen the same behaviour and was able to fix two separate issues. First,
the @ symbol on the leaq instruction is not necessary. This code is being
inserted because NO_PROFILE_COUNTERS is not defined (
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
--- Comment #7 from jsm28 at gcc dot gnu dot org 2009-07-29 22:33 ---
x86_64-pc-mingw32 is not a primary or secondary platform, moving to P4.
Please restore to P3 if this also appears on i686-mingw32 or another
primary or secondary platform.
--
jsm28 at gcc dot gnu dot org changed:
--- Comment #8 from jsm28 at gcc dot gnu dot org 2009-07-29 22:37 ---
Is comment #5 meant to be a claim that the patch does not fully fix the bug?
If so, please state with what revision on what target the problem is still
observed.
In any case, the targets mentioned are not primary or s
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
--- Comment #9 from jsm28 at gcc dot gnu dot org 2009-07-29 22:47 ---
Darwin not using (a non-ancient version of) the GNU assembler is sufficient
explanation for any assembler syntax issue appearing there but not on other
targets. Closing as fixed.
--
jsm28 at gcc dot gnu dot org ch
--- Comment #7 from jsm28 at gcc dot gnu dot org 2009-07-29 22:48 ---
As I understand it this is fixed by the patch shown (r149235),
please reopen if not.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-07-29 22:51 ---
Setting to P4 on the basis that the described bug circumstances involve
a RUNTESTFLAGS setting to use a single .exp file, please restore to P3
if it appears without using any RUNTESTFLAGS setting.
--
jsm28 at gcc d
--- Comment #8 from ppluzhnikov at google dot com 2009-07-29 22:51 ---
Confirm: r149235 fixes the problem here :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40596
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-07-29 22:52 ---
Setting to P4, but restore to P3 if a C or C++ test for this bug is found.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40671
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-07-29 22:54 ---
Solaris x86 is not a primary or secondary target so setting to P4.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-07-29 22:55 ---
Tru64 is not a primary or secondary target so setting to P4.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40861
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40866
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.5.0
http://gcc.g
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.5.0
http://gcc.g
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40797
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.4.2
http://gcc.g
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.4.2
http://gcc.g
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.5.0
http://gcc.g
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-07-29 23:08 ---
There is no indication in this bug report of whether the issue also
appears for 4.5. If it does, please update the regression marker to
"4.4/4.5 Regression".
--
jsm28 at gcc dot gnu dot org changed:
Wh
1 - 100 of 110 matches
Mail list logo
