cc -O -pipe -funroll-loops -DIN_GCC -DHAVE_CONFIG_H
-DPREFIX=\/usr/obj/usr/src/tmp/usr\
-I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc
--- Comment #2 from ajrobb at bigfoot dot com 2006-05-10 09:45 ---
Created an attachment (id=11428)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11428action=view)
multi-word bit shift
This is my loop - using a single index that decrements to zero
I have seen simpler loops
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-10 08:06 ---
Fixed in 4.0.3:
/tmp /space/rguenther/install/gcc-4.0.3/bin/g++ -Wall -S t.C
t.C:11: error: declaration of '~TPoligon' as member of 'TPoints'
--
rguenth at gcc dot gnu dot org changed:
What
Fold does not fold two comparisons in a row if the intermediate type differs
in being a pointer vs. an integer variable. This also is the reason for not
folding (Foo *)(char *)foo with foo being of Foo type (we can fold that to
(Foo *)foo).
There's code to do that I think, but it's just missing
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-10 09:07
---
I can reproduce this ICE with mainline on i686-linux. I propose the following
patch:
Index: parse.c
===
--- parse.c (revision 113603)
+++
--- Comment #2 from christophe dot gengembre at paris dot ensam dot fr
2006-05-10 08:28 ---
Created an attachment (id=11427)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11427action=view)
source that triggered the error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27521
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-10 10:22 ---
Subject: Bug 27302
Author: rguenth
Date: Wed May 10 10:22:39 2006
New Revision: 113670
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113670
Log:
2006-05-10 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-05-10 11:03 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Hello.
We have Client/server socket application (multiple clients and servers).
Servers are multiplatform can be compiled for Windows (MSVC) and for Linux
(GCC).
Recently we detected memory leak in one of kinde of our servers. At the start
it uses only 15m (that is normally). Then it slowly grows
--- Comment #1 from chris at bubblescope dot net 2006-05-10 11:31 ---
Can you provide a complete program which demonstrates this link? I've tried
looking at the code in question myself, and cannot observe a memory leak
myself.
--
chris at bubblescope dot net changed:
--- Comment #1 from P dot Schaffnit at access dot rwth-aachen dot de
2006-05-10 11:34 ---
Sorry, I missed it before, but this could definitly be a dupplicate of 19777.
Philippe
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27524
--- Comment #2 from pcarlini at suse dot de 2006-05-10 12:10 ---
Chris is right. Certainly we are not aware of any problem in that code, in
particular the 3.4.5 version, very close to the original HP/SGI code and very
well tested from that point of view (at least). Please provide a
--- Comment #3 from sebastian dot pop at cri dot ensmp dot fr 2006-05-10
12:26 ---
Created an attachment (id=11429)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11429action=view)
fix
proposed fix. I didn't tested it other than making sure it fixed the bug.
--
--- Comment #5 from sebastian dot pop at cri dot ensmp dot fr 2006-05-10
12:32 ---
Created an attachment (id=11430)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11430action=view)
first shot at fixing this
didn't tested the patch, other than with RUNTESTFLAGS=tree-ssa.exp
and the
--- Comment #3 from ksharenkov at ya dot ru 2006-05-10 12:48 ---
Ok, i will try to create a short program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-10
12:59 ---
I think that it is not correct to emit an ICE on this one. The patch below
emits an error and bails out.
I will submit in the next 24hours.
Paul
Index: gcc/fortran/symbol.c
--- Comment #3 from christophe dot gengembre at paris dot ensam dot fr
2006-05-10 13:49 ---
the bug is trigged in Subroutine RecupValLuesDsCmdLC.
A .f source file with only Subroutine RecupValLuesDsCmdLC code trigger the
error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27521
I get a undefined reference to `.LL226' error when compiling RCS with -O2 on
sparc using gcc 4.2. This problem goes away when I use -O2. The assembler
output shows that .LL226 is referenced but not defined anywhere. I'll attach
the .i file and the .s file with -O1 (works) and -O2 (fails).
--- Comment #1 from tbm at cyrius dot com 2006-05-10 13:51 ---
Created an attachment (id=11431)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11431action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
--- Comment #2 from tbm at cyrius dot com 2006-05-10 13:52 ---
Created an attachment (id=11432)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11432action=view)
assembler with -O1 (works)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
--- Comment #7 from patchapp at dberlin dot org 2006-05-10 13:52 ---
Subject: Bug number PR25514
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00958.html
--
--- Comment #3 from tbm at cyrius dot com 2006-05-10 13:52 ---
Created an attachment (id=11433)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11433action=view)
assembler with -O2 (fails) - .LL226 is not defined
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
--- Comment #3 from jjcogliati-r1 at yahoo dot com 2006-05-10 13:54 ---
(In reply to comment #1)
Confirmed. Though sometimes I wonder if this is an over use of printf style
debugging.
rantWell, I have a fortran program. It ran fine for the first 10 and a half
hours. Then it
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #5 from kazu at gcc dot gnu dot org 2006-05-10 14:21 ---
Reduced down to:
extern void bar (int);
int
foo (int a, int b)
{
int c = a == b;
if (c)
bar (c);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27477
Reduced testcase from gcc.dg/builtin-object-size-1.c:
void abort(void);
int main (void)
{
void *b = Labcd;
if (__builtin_object_size (b + 2, 0) != sizeof (Labcd) - 2)
abort ();
return 0;
}
now, CCP propagates the constant Labcd[0] to the addition stmt:
b_1 = a[0];
D.1526_2 = a[0]
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:37
---
This is a duplicate of PR24549 (it's fixed by the same one-line patch).
*** This bug has been marked as a duplicate of 24549 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:37
---
*** Bug 27487 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-10 14:37 ---
CCP produces this tree since forever.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from malitzke at metronets dot com 2006-05-10 14:43 ---
To A Pinski
While I am _not_ a C lawyer, the following seems pertinent:
1 __FUNCTION__ is _not_ a predefined macro. However __func__ a predefined
identifier and I will take this up with the kernel people. However,
The code
inline int almost_equal(float a, float b, int maxUlps = 16) {
int intDiff = *(reinterpret_castint*(a)) -
*(reinterpret_castint*(b));
printf(intDiff %d\n,intDiff);
return intDiff;
}
gives different results when compiled with and without -O2
(yes, floats are
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-10 14:48 ---
Looks more like a typo in tree-object-size.c:plus_expr_object_size
Index: tree-object-size.c
===
*** tree-object-size.c (revision 113669)
---
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:51
---
Subject: Bug 24549
Author: fxcoudert
Date: Wed May 10 14:51:26 2006
New Revision: 113671
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113671
Log:
PR fortran/24549
* parse.c
--- Comment #1 from pluto at agmk dot net 2006-05-10 14:51 ---
you're violating the aliasing rules, so use -fno-strict-aliasing option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27533
--- Comment #2 from ulrich dot lauther at siemens dot com 2006-05-10 14:53
---
Created an attachment (id=11434)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11434action=view)
Complete tiny example exposing the problem
I submit this version that includes stdio.h for readability,
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-05-10 14:56
---
I have a patch that needs PR27529 fixed first, that needs PR27532 fixed first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
--- Comment #6 from dje at gcc dot gnu dot org 2006-05-10 14:56 ---
The section anchors feature does not like __FUNCTION__ or __func__ as an
inlined asm argument.
Also, some rs6000 work is not very informative or useful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
--- Comment #3 from ulrich dot lauther at siemens dot com 2006-05-10 14:55
---
Created an attachment (id=11435)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11435action=view)
same as before, but stdio.h expanded
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27533
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-10
14:58 ---
(In reply to comment #2)
Very odd; I do nightly builds of mainline on two different systems. On one of
them this failure stopped on 20060430 and on the other it stopped on 20060503,
but failed on
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:58
---
Subject: Bug 20460
Author: fxcoudert
Date: Wed May 10 14:58:48 2006
New Revision: 113672
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113672
Log:
PR fortran/20460
* resolve.c
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-10 14:59
---
As Pawel already pointed out:
Your code is brokan as you are violating the aliasing rules.
Please read about this in the non-bug section of http://gcc.gnu.org/bugs.html :
Casting does not work as expected when
--- Comment #96 from reichelt at gcc dot gnu dot org 2006-05-10 14:59
---
*** Bug 27533 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from kazu at gcc dot gnu dot org 2006-05-10 15:00 ---
The combiner seems to be doing something strange:
(insn 13 12 16 2 (set (reg:HI 21)
(eq:HI (cc0)
(const_int 0 [0x0]))) 237 {*bstzhireg} (nil)
(nil))
(insn 16 13 17 2 (set (cc0)
(reg:HI
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-10 15:06 ---
(In reply to comment #5)
To A Pinski
While I am _not_ a C lawyer, the following seems pertinent:
Why do you think this is related to the C standard?
1 __FUNCTION__ is _not_ a predefined macro. However
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-10 15:10 ---
Just to explain why a[0] + 2B is valid gimple:
a[0] is a gimple invariant and likewise for 2b. Therefor the two sides of
the Plus expression are going to valid for it. Therefor valid gimple.
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||link-failure
Target Milestone|--- |4.2.0
--- Comment #5 from pluto at agmk dot net 2006-05-10 15:26 ---
(In reply to comment #0)
The code
inline int almost_equal(float a, float b, int maxUlps = 16) {
int intDiff = *(reinterpret_castint*(a)) -
*(reinterpret_castint*(b));
if you really need such
Attempting to pass a pointer to a va_list variable to a function expecting such
a pointer causes a warning about passing a pointer of incompatible type.
[EMAIL PROTECTED] ~/work/ffdev $ gcc -v -save-temps -ansi -pedantic -Wall -W -O
-c t.c
Reading specs from
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 15:46 ---
It is an object type. An array is an object type.
*** This bug has been marked as a duplicate of 14557 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-05-10 15:46
---
*** Bug 27534 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 15:47 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from ksharenkov at ya dot ru 2006-05-10 15:58 ---
I have tried to create simple test case (about 200 rows) where I tried to
reproduce key code fragments. In simple test case leak not reproduced. But I
have easy reproduced it with very small application based on main
--- Comment #4 from janis at gcc dot gnu dot org 2006-05-10 16:03 ---
The test passes on both of my nightly builds now, so I'm closing this.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-10 16:49 ---
Assigning to Volker as he posted a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-10 16:52
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-10 16:55
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kazu at gcc dot gnu dot org 2006-05-10 17:00 ---
Could you submit a preprocessed testcase?
Many of us do not have m68k hardware that can be used for bootstrap.
Thanks,
--
kazu at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from kazu at gcc dot gnu dot org 2006-05-10 17:35 ---
Subject: Bug 24949
Author: kazu
Date: Wed May 10 17:35:24 2006
New Revision: 113675
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113675
Log:
PR target/24949
* config/m68k/m68k.md
--- Comment #2 from kazu at gcc dot gnu dot org 2006-05-10 17:35 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from aph at gcc dot gnu dot org 2006-05-10 17:41 ---
Xref: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191211
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12257
--- Comment #29 from pinskia at gcc dot gnu dot org 2006-05-10 17:48
---
Since Honza's patch to emit static and inline functions at -O0, this now fails
with BOOTCFLAGS as -O0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-05-10 18:27 ---
Subject: Bug 27470
Author: tkoenig
Date: Wed May 10 18:26:51 2006
New Revision: 113680
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113680
Log:
2005-05-10 Thomas Koenig [EMAIL PROTECTED]
PR
/*
ICE using gcc-4.2-20060506 on x86_64-unknown-linux-gnu
Regression from gcc-4.1.0
Source cut down from gmp-4.2.1/tests/refmpf.c
% gcc-4.2-20060506 -O3 -c foo.c
foo.c: In function âfooâ:
foo.c:27: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 19:06 ---
Oh, this is no longer a regression as -fsee is not enabled by default in newer
versions of 4.2 (a day after it was enabled by default for -O3, it was turned
off to fix some regressions at -O3).
--
pinskia at gcc
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-05-10 19:41 ---
Subject: Bug 27532
Author: rguenth
Date: Wed May 10 19:41:46 2006
New Revision: 113682
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113682
Log:
2006-05-10 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-10 19:42 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
$ /tmp/cvs/gcc-test-r113398/Build/./gcc/xgcc
-B/tmp/cvs/gcc-test-r113398/Build/./gcc/
-B/tmp/cvs/gcc-test-r113398/Build/root/powerpc64-suse-linux/bin/
-B/tmp/cvs/gcc-test-r113398/Build/root/powerpc64-suse-linux/lib/ -isystem
/tmp/cvs/gcc-test-r113398/Build/root/powerpc64-suse-linux/include
The g++ compiler for i386 target assumes that the stack is aligned by 16 when
storing xmm registers to the stack. However, the stack is not aligned when
compiling with option -Os (or with the Intel compiler). A misaligned memory
operand to an XMM instruction causes a general protection exception.
FAIL: gcc.c-torture/execute/20030128-1.c execution, -O1
FAIL: gcc.c-torture/execute/20030128-1.c execution, -O2
FAIL: gcc.c-torture/execute/20030128-1.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/20030128-1.c execution, -O3 -g
FAIL: gcc.c-torture/execute/20030128-1.c
FAIL: gcc.c-torture/execute/941014-2.c execution, -O1
FAIL: gcc.c-torture/execute/941014-2.c execution, -O2
FAIL: gcc.c-torture/execute/941014-2.c execution, -Os
--
Summary: gcc.c-torture/execute/941014-2.c FAILs
Product: gcc
Version: unknown
--- Comment #10 from flash at pobox dot com 2006-05-10 20:08 ---
PalmSource bug #126750.
--
flash at pobox dot com changed:
What|Removed |Added
CC|
--- Comment #8 from malitzke at metronets dot com 2006-05-10 20:17 ---
Well Fellas: Either have the Steering Committee revise the
Invitation to participate in testing; quoted iselectively below.
Or,have a member from the Steering Committe ask me to refrain
from further participation. I,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 20:39 ---
First so what darwin aligns the stack by default to 16bytes (that is demanded
by their ABI since their ABI is newer than GNU/Linux's). GNU/Linux follows the
SYSV x86 ABI which is documented, maybe you cannot find
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-10 20:41 ---
This has nothing to do with the C standard or even standard code. This is
inline-asm constraint which is failing and the inline-asm in the code is wrong.
This is a bug in the code so report it to Linux instead of
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-10 20:44 ---
The SYSV x86 ABI says the stack is aligned 4 byte aligned. Remember the SYSV
x86 ABI was done before MMX or SSE was around or even thought about back in the
486 days (and maybe even before then).
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-10 20:49 ---
This is confirmed, this is an interaction between stack slots and
-mpreferred-stack-boundary= which is what -Os sets. This is not a regression.
Maybe the real question is why are you using -Os for code with SSE in
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Current mainline fails to bootstrap on IRIX 5.3:
configure: error: Pthreads are required to build libgomp
make[1]: *** [configure-target-libgomp] Error 1
Environment:
System: IRIX lyra 5.3 11091812 IP22 mips
host: mips-sgi-irix5.3
build: mips-sgi-irix5.3
target: mips-sgi-irix5.3
configured
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2006-05-10
21:28 ---
Subject: Re: [4.2 Regression] libgomp bootstrap failure on Tru64 UNIX V4.0F
pinskia at gcc dot gnu dot org writes:
PR 26161 might had fixed this.
No, the problem persists as of 20060503.
--- Comment #6 from patchapp at dberlin dot org 2006-05-10 21:31 ---
Subject: Bug number PR c++/27315
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00361.html
--
--- Comment #1 from dje at gcc dot gnu dot org 2006-05-10 21:33 ---
I can disable section anchors for Ada, similar to Objective C and Objective
C++, but this failure likely means that there is a bug in the Trees generated
by GNU Ada.
--
dje at gcc dot gnu dot org changed:
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-10 21:36
---
Below is a patch for this ICE. I suspect that there a lots more ICEs lurking in
dump-parse-tree.c, which looks like it's not really written to be fed with
incomplete structures (as might happen during error
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-05-10 21:43
---
Now, this is fixed at the moment (but still invalid code), but I have a fix
that will break it again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from anlauf at gmx dot de 2006-05-10 21:53 ---
(In reply to comment #5)
*** Bug 27487 has been marked as a duplicate of this bug. ***
Well, first of all I have to admit that I am only a Fortran user.
But PR 27487 is only a duplicate because Tobias changed the
subject of
Currently, GCC only supports OpenMP on shared-memory systems.
It would be nice if it could be extended to support OpenMP via the ethernet,
infiniband etc. (distributed-memory systems).
There exists (at least) one implementation of distributed-memory OpenMP: The
Intel Compilers 9.1's Cluster
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 22:09 ---
Is there really a standard for this or just an extension of OpenMP?
Though this is useful a little bit for the Cell where you don't really have a
distrubuted machine but the memory will be distributed though.
--
--- Comment #12 from pluto at agmk dot net 2006-05-10 22:36 ---
following reduced testcase works with libstdc++ and segv with stlport.
#include list
#include vector
struct A { };
int main()
{
std::list A* l;
std::vector A* v( l.end(), l.end() );
return 0;
}
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-05-10 22:46 ---
Is there really a standard for this or just an extension of OpenMP?
I'm not sure whether I understand the question.
Directive wise it is OpenMP augmented by a single directive: shareable.
This
--- Comment #12 from sje at cup dot hp dot com 2006-05-10 22:54 ---
I believe the patch checked in for this defect is causing
g++.old-deja/g++.other/static14.C and
g++.old-deja/g++.other/static20.C to fail.
--
sje at cup dot hp dot com changed:
What|Removed
When the ms_struct pragma was implemented, Documention was not added for it.
--
Summary: [4.2 Regression] the ms_struct pragma is not documented
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: documentation
Severity:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27542
According to:
http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#Type-Attributes
ms_struct is now support for also for the RS6000 back-end.
--
Summary: [4.2 Regression] attribute ms_struct is now also for
rs6000 but not documented
Product: gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
It was added by:
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg0.html
But it was not documented. Zem no longer works at Apple now either.
--
Summary: [4.0/4.1/4.2 Regression] attribute altivec is not
documented
Product: gcc
Version:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27544
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-11 02:16 ---
PR 27544 is about a missing docs for an attribute for RS6000, altivec.
PR 27543 is about ms_struct attribute on rs6000/PowerPC as it just says x86
supports it which is no longer true.
--
pinskia at gcc dot gnu
I'm working on a shared library, and would like to build it with
-fprofile-generate information generated from tests that are built with the
library, so I can apply it with -fprofile-use. However, when I build the
library with CFLAGS='-O2 -g -fprofile-generate', it fails to link the tests
with the
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-11 02:43 ---
Can you make sure that the library is still building with -fPIC, if it is not,
then this is not a bug.
And can you make sure that the library is linking with -fprofile-generate, if
it is not, then this is not a bug.
--- Comment #2 from hpj at copyleft dot no 2006-05-11 02:52 ---
Yes, it's building with -fPIC and building/linking with -fprofile-generate.
Without -fprofile-generate, it all builds fine. I'm using libtool. I'm
attaching logs of builds with and without -fprofile-generate so you have all
--- Comment #3 from hpj at copyleft dot no 2006-05-11 02:53 ---
Created an attachment (id=11436)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11436action=view)
Build without -fprofile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27545
1 - 100 of 103 matches
Mail list logo
