Somehow this got stuck in the spam filter.
- Forwarded message from [EMAIL PROTECTED] -
Date: Sat, 01 Mar 2008 09:21:21 -0500
From: Joern Rennecke [EMAIL PROTECTED]
Reply-To: Joern Rennecke [EMAIL PROTECTED]
Subject: Re: [PATCH][4.3] Deprecate -ftrapv
To: gcc@gcc.gnu.org
2008/2/29, J.C. Pizarro [EMAIL PROTECTED]:
Here are the results of benchmarks of 3 compressors: 7z, bzip2 and gzip, and
GCCs 3.4.6, 4.1.3-20080225, 4.2.4-20080227, 4.3.0-20080228 4.4.0-20080222.
Thanks, that's very interesting. I had noticed 4.2 producing 10%
larger and 10% slower code for a
On Mon, 3 Mar 2008, H.J. Lu wrote:
Hi,
I'd like to fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35453
for gcc 4.3. Defines SIDD_XXX in SSE4 header file is a bad idea. SSE 4
header file
in icc will also be fixed.
Works for me.
Richard.
Hi,
Sure hope I've come to the right place...
I need to somehow persuade GCC (on x86) to always treat vtables as if
they were dllimport'ed. For linking to work on my target platform (a
custom X86 OS) it's important that constructors reference vtables
indirectly (i.e. through pointers in idata).
Segher Boessenkool wrote:
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single
Hello all,
I am encountering a strange problem. I have a code
Snippet that contains a while loop.
The snippet is as follows:
While( (expr1) (expr2) );
Initially the value of both expr1 and expr2 are
Set to 1.
Next, only the value of expr1 is set to 0 within a
SIGINT handler.
I
Raghukrishna Hegde wrote:
Hello all,
I am encountering a strange problem. I have a code
Snippet that contains a while loop.
The snippet is as follows:
While( (expr1) (expr2) );
Initially the value of both expr1 and expr2 are
Set to 1.
Next, only the value of expr1 is set to 0
But the remaining question is: can we
support type introperability from Fortran array to C vector?
I think this is more a middle-end issue that a Fortran issue, so I'm
following there: can the middle-end VIEW_CONVERT_EXPR between and
ARRAY_REF of, say, INTEGER_TYPE (which is what the
On Mon, 3 Mar 2008, [EMAIL PROTECTED] wrote:
I have a stand-alone, non-Web-based app. that I'd like to
distribute as a .exe with some database files, to a layman
audience, and I'd like to avoid issues of JRE distribution and
compatibility, etc. So I'm hoping someone, somewhere, has
written a
On Mon, Mar 03, 2008 at 11:08:24PM -0500, Robert Dewar wrote:
Segher Boessenkool wrote:
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
any access to a naturally aligned scalar object in memory
BIT_FIELD_REF is currently only generated by the middle-end (fold, SRA
and parts of the vectorizer). At the moment the bit position and size
of the extract can be non-constant and the type of the result is
unspecified.
I suggest to make sure that bit position and size are constants, the
object
Well if they do require more than one instruction, the rule has
no effect (whenever possible). If they can be done in one
instruction (as on the x86), then why not require this, why
make a special case?
We don't even guarantee consistent behavior for volatile bitfields, so I
really doubt we
I'm really wondering why this is being considered.
A documented property of the form GCC will use a single instruction
to do X when possible means exactly nothing. In particular, to call
such a statement a guarantee is seriously misleading.
If Linux needs the single-instruction property for
On 3/4/08 10:55 AM, Richard Guenther wrote:
I suggest to make sure that bit position and size are constants, the
object referenced is of integral type (BIT_FIELD_REF should not be
used as a way to circumvent aliasing) and the result type is of the
same type as the operand zero type (and not a
Paul Koning wrote:
I'm really wondering why this is being considered.
A documented property of the form GCC will use a single instruction
to do X when possible means exactly nothing. In particular, to call
such a statement a guarantee is seriously misleading.
I agree.
If Linux needs the
On Tue, Mar 04, 2008 at 11:15:00AM -0500, Diego Novillo wrote:
fold currently optimizes a.b.c == 0 to BIT_FIELD_REF a, 8, big-num 1
for bit field field-decls c. IMHO this is bad because it pessimizes
TBAA (needs to use a's alias set, not the underlying integral type
alias set) and it breaks
On Tue, 4 Mar 2008, Jakub Jelinek wrote:
On Tue, Mar 04, 2008 at 11:15:00AM -0500, Diego Novillo wrote:
fold currently optimizes a.b.c == 0 to BIT_FIELD_REF a, 8, big-num 1
for bit field field-decls c. IMHO this is bad because it pessimizes
TBAA (needs to use a's alias set, not the
On Tue, Mar 04, 2008 at 04:37:29PM +, Andrew Haley wrote:
Typically those would be found in asm statements.
I suspect it would be valuable to have standardized primitives for
atomic actions (semaphores, spinlocks, test-and-set primitives,
circular buffers, pick one).
We already have
On 3/4/08, Richard Guenther [EMAIL PROTECTED] wrote:
I suggest to make sure that bit position and size are constants, the
object referenced is of integral type (BIT_FIELD_REF should not be
used as a way to circumvent aliasing) and the result type is of the
same type as the operand zero
Jakub Jelinek wrote:
On Tue, Mar 04, 2008 at 04:37:29PM +, Andrew Haley wrote:
Typically those would be found in asm statements.
I suspect it would be valuable to have standardized primitives for
atomic actions (semaphores, spinlocks, test-and-set primitives,
circular buffers, pick one).
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
We don't have atomic read or atomic write builtins (ok, you could
abuse __sync_fetch_and_add (x, 0) for atomic read and a loop with
__sync_compare_and_swap_val for atomic store, but that's a
horrible overkill. Being able to assume that
On Tue, 4 Mar 2008, Andrew Pinski wrote:
On 3/4/08, Richard Guenther [EMAIL PROTECTED] wrote:
I suggest to make sure that bit position and size are constants, the
object referenced is of integral type (BIT_FIELD_REF should not be
used as a way to circumvent aliasing) and the result type
On Tue, Mar 04, 2008 at 09:02:34AM +, Martin Guy wrote:
Is there a clause in regressions for takes longer to compile and
produces worse code?
Worse code is a regression, so is slower compile time. Both are
judgement calls; some of them are not going to be changed, but safe
patches changing
Richard Guenther wrote:
On Tue, Mar 4, 2008 at 7:31 PM, David Daney [EMAIL PROTECTED] wrote:
Perhaps anything declared volatile should have these semantics.
Although mentioning 'volatile' on the lkml is probably not a good idea.
Certainly not. volatile has nothing to do with atomic
On Sat, Mar 1, 2008 at 2:46 PM, Paolo Bonzini [EMAIL PROTECTED] wrote:
By the way, I still don't understand how birth points would work. Can
someone give an example of what the insn stream would look like with
birth points, and what the DU/UD chains would look like?
With a big IIUC,
On 3/4/08 1:53 PM, Steven Bosscher wrote:
So, from an implementation, would we make PHI-like UD-chains to nop
insns that represent the birth points, or would we actually add PHI
functions and let the normal UD-chains point to the PHI function
arguments?
Why put them in the IL stream at all?
On Sat, Mar 1, 2008 at 11:13 AM, Jan Hubicka [EMAIL PROTECTED] wrote:
Diego,
I am leaning to just adding noop moves at the birthpoints (dominance
frontiers) as real noop move insns in the streams in the passes that use
ud or du chains. The back end is tolerant of noop moves and
On Tue, Mar 4, 2008 at 7:58 PM, Diego Novillo [EMAIL PROTECTED] wrote:
Both PHIs and birthpoints are merely factoring devices that let you cut
down the number of UD links. They don't need to be part of the IL, much
like none of the DF objects are part of the RTL IL.
Maybe they don't need
On 3/4/08 2:12 PM, Steven Bosscher wrote:
That code is IMHO just awfully ugly. And slow too, last I checked.
Yeah, there's quite a bit of bookkeeping needed to do incremental SSA
updates.
should not want that on RTL. I don't think we should allow
transformations on RTL that are too hard
J.C. Pizarro wrote:
p7zip-4.57
[...]
1. 1m50s compile, 1630164 file, 1618639 text, 6120 data, 27168 bss, 5m50s run.
2. 1m53s compile, 1665952 file, 1649829 text, 4668 data, 29160 bss, 6m04s run.
3. 2m08s compile, 1629088 file, 1613313 text, 4672 data, 29160
Steven Bosscher wrote:
On Tue, Mar 4, 2008 at 7:58 PM, Diego Novillo [EMAIL PROTECTED] wrote:
Both PHIs and birthpoints are merely factoring devices that let you cut
down the number of UD links. They don't need to be part of the IL, much
like none of the DF objects are part of the RTL
Steven Bosscher [EMAIL PROTECTED] writes:
For the location of the extra instructions, I would *not* keep them on
the side. If you have something special going on, my motto is: Make
it explicit.
Going back to something discussed upthread: would you expect to use this
for hard regs as well as
On 3/4/08 2:38 PM, Kenneth Zadeck wrote:
Steven Bosscher wrote:
On Tue, Mar 4, 2008 at 7:58 PM, Diego Novillo [EMAIL PROTECTED] wrote:
Both PHIs and birthpoints are merely factoring devices that let you cut
down the number of UD links. They don't need to be part of the IL, much
like
Hi,
1) In ssa, the operands of the phis and the renaming contain
information. The operands are paired with the cfg edges that the
values come in on. In fud/birthpoints there is no such pairing or
renaming. For some problems, like conditional constant, this pairing
and renaming is what
On Tue, Mar 4, 2008 at 8:47 PM, Richard Sandiford
[EMAIL PROTECTED] wrote:
Steven Bosscher [EMAIL PROTECTED] writes:
Going back to something discussed upthread: would you expect to use this
for hard regs as well as pseudos? No-op moves aren't necessarily supported
for all hard registers.
Jan Hubicka wrote:
Hi,
1) In ssa, the operands of the phis and the renaming contain
information. The operands are paired with the cfg edges that the
values come in on. In fud/birthpoints there is no such pairing or
renaming. For some problems, like conditional constant, this pairing
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction
Steven Bosscher [EMAIL PROTECTED] writes:
On Tue, Mar 4, 2008 at 8:47 PM, Richard Sandiford
[EMAIL PROTECTED] wrote:
Steven Bosscher [EMAIL PROTECTED] writes:
Going back to something discussed upthread: would you expect to use this
for hard regs as well as pseudos? No-op moves aren't
* Basile STARYNKEVITCH wrote on Thu, Feb 28, 2008 at 06:56:35PM CET:
Ralf Wildenhues wrote:
* Basile STARYNKEVITCH wrote on Thu, Feb 28, 2008 at 05:39:47PM CET:
run-basilys.d: run-basilys.h \
$(CONFIG_H) $(SYSTEM_H) $(TIMEVAR_H) $(TM_H) $(TREE_H) $(GGC_H) \
tree-pass.h basilys.h
Segher == Segher Boessenkool [EMAIL PROTECTED] writes:
Segher Good point. Suggestions for better wording? How does
Segher any access to a naturally aligned scalar object in memory
Segher that is not a bit-field and fits in a general purpose integer
Segher machine register, will be
On Tue, Mar 4, 2008 at 9:46 PM, Richard Sandiford
[EMAIL PROTECTED] wrote:
I don't see why hard registers are special as far as FUD chains go.
We have DU chains for hard regs, so why not FUDs too?
We have them, but does anyone use them? Does anyone actually even
compute them? (Apparently
I think that at this point, i have been convinced to:
1) use fud's rather than birthpoints because these do keep a slot for
the value along each in edge.
2) keep the info on the side (see rsandifors diverging thread).
I am not there on keeping extra names on the side. The advantage of
I think that at this point, i have been convinced to:
1) use fud's rather than birthpoints because these do keep a slot for
the value along each in edge.
2) keep the info on the side (see rsandifors diverging thread).
I am not there on keeping extra names on the side. The
On 3/4/08 4:06 PM, Jan Hubicka wrote:
The names are equivalent to UD pointers: Either you can have version
names or just coinsider the destination of UD pointer to be the
destination. Or am I still missing a point?
Nope, that's exactly right. Versioned names are useful for some things
As I said before, I think any words of this form SHOULD NOT be added.
All it does is add words to the documentation that provide NO
guarantee of anything -- but in a way that will confuse those who
don't read it carefully enough into thinking that they DID get some
sort of guarantee.
The idea
Segher Boessenkool wrote:
As I said before, I think any words of this form SHOULD NOT be added.
All it does is add words to the documentation that provide NO
guarantee of anything -- but in a way that will confuse those who
don't read it carefully enough into thinking that they DID get some
sort
Segher == Segher Boessenkool [EMAIL PROTECTED] writes:
As I said before, I think any words of this form SHOULD NOT be
added. All it does is add words to the documentation that provide
NO guarantee of anything -- but in a way that will confuse those
who don't read it carefully enough
AFAIK the only reason we don't break this rule is that doing so would
be grossly inefficient; there's nothing to stop any gcc back-end with
(say) seriously slow DImode writes from using two SImode writes instead.
I'm fairly sure ARM already breaks this rule.
Currently it probably only effects
Segher Boessenkool writes:
... People are relying on this undocumented GCC behaviour already,
and when things break, chaos ensues.
GCC has introduced many changes over the years that have broken many
programs that have relied on undocumented or unspecified behaviour.
You won't find much sympathy
Manuel López-Ibáñez [EMAIL PROTECTED] writes:
Here is a patch that give us caret diagnostics in C/C++. There a lot
of things that can be improved but because I wanted to get some
feedback with my current approach.
Basically, I store a pointer linebuf in the line_map structure to a
Doug Gregor [EMAIL PROTECTED] writes:
I see that it is time to submit applications to be a mentor
organization for the Google Summer of Code. I've updated the GSoC wiki
page at:
http://gcc.gnu.org/wiki/SummerOfCode
with a class of projects I'm interested in; others should do the same.
H.J. Lu [EMAIL PROTECTED] writes:
Here is the patch for both gcc 4.3 and 4.4. OK for 4.3/4.4? Tested on
Linux/ia32
and Linux/ia64 with gcc 4.3/4.4.
gcc/
2008-03-03 H.J. Lu [EMAIL PROTECTED]
PR target/35453
* config/i386/smmintrin.h (SIDD_XXX): Renamed to ...
Ian Lance Taylor [EMAIL PROTECTED] writes:
This is OK for mainline. I will defer to an RM for 4.3, though my
recommendation is that it should go into 4.3 if possible.
Sorry, the thread broke, and I didn't see that this had already been
approved.
Ian
Hello Everyone,
I am trying to do some development on the C Compiler in Cygwin and I
am doing the following to build it:
$ ../gcc-4.0.2/gcc/configure
--prefix=/home/Balaji/Software_Tools/install --enable-languages=c
The problem i am getting is this:
$ make all install
TARGET_CPU_DEFAULT=
Balaji V. Iyer [EMAIL PROTECTED] writes:
I am trying to do some development on the C Compiler in Cygwin and I
am doing the following to build it:
gcc@gcc.gnu.org is the wrong mailing list. Please send any further
e-mail to [EMAIL PROTECTED] Thanks.
$ ../gcc-4.0.2/gcc/configure
Run
I'm trying to compile the following piece of code:
static const int ln = 10;
static int ar[ln];
I'm getting:
storage size of 'ar' isn't constant
size of variable 'ar' is too large
Is the code legal? Can you provide me with references to its legality
or a discussion about it? it seems to be
Thank you Ian. I did the modification you mentioned...now I am running
into more problems.
Now it is failing somewhere in libiberty.. here is the exact message (I
just simply typed make all install) (I get same messae when I just do
make)
Configuring in fixincludes
configure: loading cache
On 3/4/08, Elazar Leibovich [EMAIL PROTECTED] wrote:
I'm trying to compile the following piece of code:
static const int ln = 10;
static int ar[ln];
I'm getting:
storage size of 'ar' isn't constant
size of variable 'ar' is too large
Is the code legal? Can you provide me with
The testcase:
--cut here--
#include stdio.h
double
__attribute__ ((noinline))
test (double x)
{
return x = 0.0 ? x : -x;
}
double
__attribute__ ((always_inline))
test_inlined (double x)
{
return x = 0.0 ? x : -x;
}
int main()
{
double x = -0.0;
printf (%f %f %f\n, x, test(x),
--- Comment #1 from ubizjak at gmail dot com 2008-03-04 08:40 ---
Hm, -0.0 = 0.0 is folded to TRUE, as confirmed by:
printf (%i\n, -0.0 = 0.0);
This produces 1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35456
Sent from my iPhone
On Mar 4, 2008, at 0:40, ubizjak at gmail dot com [EMAIL PROTECTED]
wrote:
--- Comment #1 from ubizjak at gmail dot com 2008-03-04 08:40
---
Hm, -0.0 = 0.0 is folded to TRUE, as confirmed by:
printf (%i\n, -0.0 = 0.0);
This produces 1.
That is
--- Comment #2 from pinskia at gmail dot com 2008-03-04 08:49 ---
Subject: Re: Different results for inlined vs. non-inlined function
Sent from my iPhone
On Mar 4, 2008, at 0:40, ubizjak at gmail dot com [EMAIL PROTECTED]
wrote:
--- Comment #1 from ubizjak at gmail dot
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-03-04 09:14
---
The original motivation for this report was that I was trying to reproduce the
occasional problem of error being called (a this should never happen sanity
check) at this place in the code. I thought I had
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-04 09:31 ---
Patch welcome.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35449
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35454
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|other |target
Target Milestone|--- |4.2.4
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #3 from ubizjak at gmail dot com 2008-03-04 10:01 ---
Working on a fix.
--
ubizjak at gmail dot com changed:
What|Removed |Added
I get the following error message trying to build trunk r132854 on CELL
SPU:
-O2 ' 'CPPFLAGS=' 'LDFLAGS=' 'build_alias=powerpc64-unknown-linux-gnu'
'host_alias=spu' 'target_alias=spu' --cache-file=.././config.cache
--srcdir=../../../../gcc/newlib/libc
configure: loading cache .././config.cache
--- Comment #17 from pcarlini at suse dot de 2008-03-04 11:04 ---
(In reply to comment #16)
Sorry, I had two versions of patch and managed to commit the wrong copy.
Sent correct one to ML. It should be fixed now.
Indeed, it's fixed! Many, many thanks!
The point I wanted to make is
--- Comment #4 from ubizjak at gmail dot com 2008-03-04 12:41 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00207.html.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from irar at il dot ibm dot com 2008-03-04 13:30 ---
It fails in initialize_matrix_A() when called with chrec {0, +, {0, +, 4}_1}_2:
int_cst_value (CHREC_RIGHT (chrec)) ICEs, since CHREC_RIGHT (chrec) here is {0,
+, 4}_1.
Ira
--
irar at il dot ibm dot com changed:
Dependency generation (-M) does not quote '#' in filenames.
--
Summary: Dependency generation (-M) does not quote '#' in
filenames
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #1 from markus dot milleder at generali dot at 2008-03-04
13:37 ---
Created an attachment (id=15259)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15259action=view)
Patch for mkdeps.c + testcase
This trivial patch cures the problem. I do not have a copyright
--- Comment #2 from rwild at gcc dot gnu dot org 2008-03-04 13:53 ---
Please note that quoting # in makefiles is not portable, but only supported
by some make implementations. For example, with
foo: a\#b
bar: c#d
AIX make will assume 'foo' depends on 'a\', and 'bar' on 'c'.
--- Comment #5 from uros at gcc dot gnu dot org 2008-03-04 13:58 ---
Subject: Bug 35456
Author: uros
Date: Tue Mar 4 13:57:27 2008
New Revision: 132863
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132863
Log:
PR middle-end/35456
* fold-const.c
--- Comment #3 from markus dot milleder at generali dot at 2008-03-04
14:10 ---
(In reply to comment #2)
Please note that quoting # in makefiles is not portable, but only supported
by some make implementations. For example, with
foo: a\#b
bar: c#d
AIX make will assume
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2008-03-04 14:21
---
A bit of experimentation reveals that we can use the asymptotic expression at
http://en.wikipedia.org/wiki/Error_function#Asymptotic_expansion for arguments
larger than 7, and it does converge with less than 100
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2008-03-04 14:26
---
On ppc longdouble, convergence requires argument = 8.6 and, again, less than
100 terms. Why does convergence radius depend on the format of the
floating-point type, I wonder... For the record, here's the small C
--- Comment #16 from uweigand at gcc dot gnu dot org 2008-03-04 14:51
---
Hi Jakub,
we need the same changes in both .eh_frame and .dwarf_frame;
does the gas .cfi_ support both sections?
I'm wondering how save restore should work across two
different FDEs -- in the new FDE, we'd
--- Comment #17 from jakub at gcc dot gnu dot org 2008-03-04 15:10 ---
.cfi_* doesn't create .dwarf_frame, but perhaps it could be taught to do that
optionally (some flag on .cfi_startproc that would switch on additional
creation of .dwarf_frame).
The plan with save/restore was that you
ICE segmentaion fault when compiling. Apologies for the source included but I
had to reduce it down from proprietary code...
Command used: gfortran -v -save-temps -c ice_bug.f90
Output:
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr
--- Comment #1 from s dot binnie at ucl dot ac dot uk 2008-03-04 15:15
---
Created an attachment (id=15260)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15260action=view)
testcase for above bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35459
--- Comment #4 from irar at il dot ibm dot com 2008-03-04 15:44 ---
Isn't the same problem as in pr34635?
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
--- Comment #1 from ismail at namtrac dot org 2008-03-04 17:14 ---
Confirming on i686-apple-darwin9 with m64.
--
ismail at namtrac dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2008-03-04 17:15 ---
This compiles with 4.2.3 and 4.3.0 (aka trunk). In that you are using
4.1.2, I doubt anyone with fix this bug in that branch. I'll suggest
that an upgrade to a newer version of gfortran is in order.
This bug should
--- Comment #23 from wilson at tuliptree dot org 2008-03-04 17:56 ---
Subject: Re: [4.2/4.3/4.4 regression] undefined reference
to `_Unwind_GetIPInfo'
ubizjak at gmail dot com wrote:
--- Comment #22 from ubizjak at gmail dot com 2008-02-20 18:39 ---
Critical P2 bug and the
When I attempt to compile the snapshot of 2/29/08 on OpenBSD 4.2 I get the
following message:
libcpp.a(errors.o)(.text+0x258): In function `cpp_error':
/home/mrichmon/gcc-4.4-20080229/libcpp/errors.c:141: undefined reference to
`__builtin_stdarg_start'
libcpp.a(errors.o)(.text+0x3a0): In function
--- Comment #11 from hp at gcc dot gnu dot org 2008-03-04 18:12 ---
Patches at http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00225.html and
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00226.html.
--
hp at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-04 18:22 ---
Support for __builtin_stdarg has been removed. I guess this is still
referenced
in OpenBSD headers?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35460
--- Comment #1 from hjl at gcc dot gnu dot org 2008-03-04 19:18 ---
Subject: Bug 35453
Author: hjl
Date: Tue Mar 4 19:17:35 2008
New Revision: 132867
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132867
Log:
gcc/
2008-03-04 H.J. Lu [EMAIL PROTECTED]
PR target/35453
--- Comment #3 from hjl dot tools at gmail dot com 2008-03-04 19:24 ---
Fixed for both gcc 4.3/4.4.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl at gcc dot gnu dot org 2008-03-04 19:24 ---
Subject: Bug 35453
Author: hjl
Date: Tue Mar 4 19:23:22 2008
New Revision: 132868
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132868
Log:
gcc/
2008-03-04 H.J. Lu [EMAIL PROTECTED]
Backport from
the following is accepted by at least xlf, pgf and ifort, but not by
gcc version 4.3.0 20080213 (experimental) [trunk revision 132283] (GCC)
!$OMP PARALLEL DO DEFAULT(PRIVATE) SHARED(I,
!$J)
DO K=1,10
IF (I-J-K==0) I=K
ENDDO
END
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-04 19:59 ---
I happen to have a fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
typedef struct {
int x;
} mystruct;
mystruct m;
should either have no name or a name of mystruct in C++. I see:
.ascii anonymous struct\0 ; DW_AT_name
and
.ascii $_0\0 ; external name
This works as expected in C.
Still fails in 20080308. I think this is target
typedef struct {
int x;
} mystruct;
mystruct m;
is missing any debug information for mystruct. If one compiles as C, mystruct
is present.
Still broken in 20080308 compiler. Should be target independent.
--
Summary: typedef missing in debug information with -gdwarf-2 for
--- Comment #1 from mrs at apple dot com 2008-03-04 20:14 ---
radr://5070293
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35462
--- Comment #1 from mrs at apple dot com 2008-03-04 20:15 ---
radr://5070293
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35463
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-04 20:26 ---
I think this is invalid if I read 2.1.2 Free Source Form Directives in
http://www.openmp.org/mp-documents/spec25.pdf correctly.
I think it should be:
!$OMP PARALLEL DO DEFAULT(PRIVATE) SHARED(I,
!$OMP
1 - 100 of 134 matches
Mail list logo
