On Wed, Sep 23, 2009 at 2:38 AM, Janis Johnson janis...@us.ibm.com wrote:
I've been implementing ISO/IEC TR 24733, an extension for the
programming language C++ to support decimal floating-point arithmetic,
in GCC. It might be ready as an experimental feature for 4.5, but I
would particularly
Hi all,
This is my first post to the list so do not be too harsh)
I have expected all c-torture tests to be highly portable but I have
recently ran into test which relies on int being 32-bit
(execute/980526-2.c).
The test runs to_kdev_t(0x12345678) (see below) and verifies that
result equals
On 09/23/2009 10:44 AM, Yuri Gribov wrote:
Hi all,
This is my first post to the list so do not be too harsh)
I have expected all c-torture tests to be highly portable but I have
recently ran into test which relies on int being 32-bit
(execute/980526-2.c).
Yes, it's possible that 64-bit ints
Yes, it's possible that 64-bit ints are not supported by the testsuite.
Changes to fix that are welcome.
I am not a gcc developer. Could someone verify and commit this patch
for testsuite/gcc.c-torture/execute/980526-2.c?
Best regards,
Yuri
980526-2.patch
Description: Binary data
Done. But if you have more cases, please report them.
Not yet. Thx!
--
Best regards,
Yuri
On Tue, Sep 22, 2009 at 11:50 PM, Vladimir Makarov vmaka...@redhat.com wrote:
Ian Lance Taylor wrote:
Amker.Cheng amker.ch...@gmail.com writes:
In function new_ready, it calls to min_insn_conflict_delay with
min_insn_conflict_delay (curr_state, next, next).
But the function's comments
Hi,
snip
IVOpts cannot identify start_26, start_4 and ivtmp_32_7 to be copies.
The root cause is that expression 'i + start' is identified as a common
expression between the test in the header and the index operation in the
latch. This is unified by copy propagation or FRE prior to loop
Hi,
In the case that a compiler flag in common.opt would best be served
with different default values on different targets.
I.E. a target-dependent Init()
Where can this be effected in the machinery ?
I can see how to make an override - but not a default.
cheers,
Iain
Thank you. I fixed the error. it caused by macro:
#define ELIMINABLE_REGS \
{\
{ARG_POINTER_REGNUM,FRAME_POINTER_REGNUM}, \
{ARG_POINTER_REGNUM,STACK_POINTER_REGNUM}, \
{FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM} \
}
because everytime when gcc check the
Hi,
When I build gcc first time this which the configure parameter is like this:
../rice-gcc-4.3.0/configure --target=$TARGET --prefix=$PREFIX
--enable-languages=c --without-headers --with-newlib --with-gnu-as
--with-gnu-ld --disable-multilib --disable-libssp
Binutils is ok and install in the
Sorry, I just found and fixed the bug. the config.host file in /libgcc/.
Sorry.
Hi:
Do I have to write the DImode operations on my *.md target description file?
Now I build my gcc first, there is an error on libgcc2.c. which is
an __muldi3 function.
The error information is:
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function __muldi3:
Quoting IainS develo...@sandoe-acoustics.co.uk:
Hi,
In the case that a compiler flag in common.opt would best be served
with different default values on different targets.
I.E. a target-dependent Init()
Where can this be effected in the machinery ?
I can see how to make an override - but
daniel tian wrote:
Hi:
Do I have to write the DImode operations on my *.md target description
file?
Yes. movMM must be implemented for all types that you want the compiler to
be able to handle at all; it's the only way it knows to move them around.
(Technically, it's supposed to be
On Tue, 2009-09-22 at 09:40 -0400, Jason Merrill wrote:
On 09/22/2009 07:04 AM, Jerry Quinn wrote:
On Mon, 2009-09-21 at 13:06 -0400, Jason Merrill wrote:
On 09/14/2009 11:54 AM, Jason Merrill wrote:
I think the way to go with this is to revert the compiler bits of
r149964, not mess with
Iain,
I am currently bootstrapping on i686-apple-darwin9 with the current patch:
diff -uN /opt/gcc/_gcc_clean/config/mh-intel-darwin
/opt/gcc/gcc-4.5-work/config/mh-intel-darwin
--- /opt/gcc/_gcc_clean/config/mh-intel-darwin 1970-01-01 01:00:00.0
+0100
+++
Hi Dominique,
I would expect you to need -gstrict-dwarf in CFLAGS_FOR_TARGET also
but the point of my question is to find a way of having this on by
default on Darwin (which is what we currently seem to need).
(more research is need on the latter - to determine whether the
problem lies
With the previous patch, bootstrap failed when building libgomp: -gstrict-dwarf
was
not passed during the configure stage. So it is not sufficient to pass it to
BOOT_CFLAGS. Would repeating the trick for CFLAGS_FOR_TARGET have a chance to
work?
Dominique
Hello,
I am looking for some more information of the SSA Gimple syntax and
was wondering if there was BNF available?
I am interested in the IR of gcc and am just looking for some further
documentation/explanation of some of the syntax I am observing such
as:
On 09/23/2009 09:22 AM, Jerry Quinn wrote:
I'm not really sure how everything fits together here. Am I missing
something obvious?
I notice that you're missing the fix_string_type that tinfo_name does.
But I'd rather not duplicate the code that creates the STRING_CST;
better to delay the
On Wed, Sep 23, 2009 at 11:01, Rob Quigley robquig...@gmail.com wrote:
Does anyone know where I might find such information? Any help and/or
pointers in the direction of information would be most welcome. I
tried the gcc wiki but I couldn't find much on SSA Gimple/low-Gimple
There are
Rob Quigley robquig...@gmail.com writes:
I am looking for some more information of the SSA Gimple syntax and
was wondering if there was BNF available?
There is no BNF. Sorry.
I am interested in the IR of gcc and am just looking for some further
documentation/explanation of some of the
+#define PSEUDO_REG_P(X) ((X)=FIRST_PSEUDO_REGISTER)
There's already a HARD_REGISTER_NUM_P that's the exact inverse.
+#define G_REG_P(X) ((X)32)
I suppose you're planning to add floating point registers?
+#define CONST_OK_FOR_LETTER_P(VALUE, C) \
+( (C) == 'J' ?
Hello,
I have this scenario:
using dwarfdump --debug-frame in a very simple object generated
with current trunk.
I am trying to figure out (with the dwarf3 spec) wether the problem
is in the tool (dwarfdump), or what we're emitting.
Can anyone more knowledgeable comment?
Iain.
Dave Korn wrote:
Eric Botcazou wrote:
Your .diff contains this
+ EH_MECHANISM=-gcc
so it looks as though the base compiler was SJLJ.
Ah, bingo! Thanks Eric; yes, I have a recent build of an SJLJ Gnat from
HEAD lying around my PATH ahead of my old 4.3.2-with-ZCX. Getting that out of
On 09/23/2009 11:00 AM, IainS wrote:
DW_CFA_restore (5)
Assertion failed: (reg_state_pos != cie-initial_state.regs.end()),
function ParseInstructions, file
/SourceCache/dwarf_utilities/dwarf_utilities-49/source/DWARFDebugFrame.cpp,
line 353.
Abort trap
There could be some confusion in
Is it just a bug for me to generate LIBGNAT_TARGET_PAIRS in a way that
has superfluous spaces (whether leading, trailing or embedded), or shall I
send a patch to add a $(strip) to the right-hand side of the ifeq
comparison? Or perhaps we should do
LIBGNAT_TARGET_PAIRS:=$(strip
On Wed, 2009-09-23 at 10:29 +0200, Richard Guenther wrote:
On Wed, Sep 23, 2009 at 2:38 AM, Janis Johnson janis...@us.ibm.com wrote:
I've been implementing ISO/IEC TR 24733, an extension for the
programming language C++ to support decimal floating-point arithmetic,
in GCC. It might be
On 09/23/2009 02:11 PM, Janis Johnson wrote:
The class types for std::decimal::decimal32 and friends do have the
proper modes. I suppose I could special-case aggregates of those modes
but the plan was to pass these particular classes (and typedefs of
them) the same as scalars, rather than _any_
On Wed, Sep 23, 2009 at 4:11 PM, Janis Johnson janis...@us.ibm.com wrote:
On Wed, 2009-09-23 at 10:29 +0200, Richard Guenther wrote:
On Wed, Sep 23, 2009 at 2:38 AM, Janis Johnson janis...@us.ibm.com wrote:
I've been implementing ISO/IEC TR 24733, an extension for the
programming language
Eric Botcazou wrote:
Is it just a bug for me to generate LIBGNAT_TARGET_PAIRS in a way that
has superfluous spaces (whether leading, trailing or embedded), or shall I
send a patch to add a $(strip) to the right-hand side of the ifeq
comparison? Or perhaps we should do
Hi Richard,
I finally got around to getting the data you wanted. Thanks for
the response. Please
find my comments below.
On Sun, Aug 9, 2009 at 2:15 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sat, Aug 8, 2009 at 11:59 PM, Sriraman Tallamtmsri...@google.com wrote:
Hi,
On Sat, Aug 8, 2009 at 2:59 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi,
Here is a patch to eliminate redundant zero-extension instructions
on x86_64.
Tested: Ran the gcc regresssion testsuite on x86_64-linux and verified
that the results are the same with/without this patch.
GCC bootstrap :
Total number of zero-extension instructions before : 1456
Total number of zero-extension instructions after : 5814
No impact on boot-strap time.
You sure you have these numbers the right way around ? Shouldn't the
number of zero-extension instructions after the patch
Sorry, it is the other way around.
Total number of zero-extension instructions before : 5814
Total number of zero-extension instructions after : 1456
Thanks for pointing it.
On Wed, Sep 23, 2009 at 4:10 PM, Ramana Radhakrishnan
raman...@gmail.com wrote:
GCC bootstrap :
Total number of
On Wed, 2009-09-23 at 16:27 -0500, Gabriel Dos Reis wrote:
On Wed, Sep 23, 2009 at 4:11 PM, Janis Johnson janis...@us.ibm.com wrote:
On Wed, 2009-09-23 at 10:29 +0200, Richard Guenther wrote:
On Wed, Sep 23, 2009 at 2:38 AM, Janis Johnson janis...@us.ibm.com wrote:
I've been implementing
On Wed, Sep 23, 2009 at 3:57 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, Aug 8, 2009 at 2:59 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi,
Here is a patch to eliminate redundant zero-extension instructions
on x86_64.
Tested: Ran the gcc regresssion testsuite on x86_64-linux and
On Wed, Sep 23, 2009 at 6:23 PM, Janis Johnson janis...@us.ibm.com wrote:
On Wed, 2009-09-23 at 16:27 -0500, Gabriel Dos Reis wrote:
On Wed, Sep 23, 2009 at 4:11 PM, Janis Johnson janis...@us.ibm.com wrote:
On Wed, 2009-09-23 at 10:29 +0200, Richard Guenther wrote:
On Wed, Sep 23, 2009 at
--- Comment #12 from uros at gcc dot gnu dot org 2009-09-23 06:44 ---
Subject: Bug 39779
Author: uros
Date: Wed Sep 23 06:43:56 2009
New Revision: 152058
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152058
Log:
PR c/39779
* c-typeck.c (build_binary_op)
The boolean expression ((p1-next !p2-next) || p2-next) can be simplified
as (p1-next || p2-next), but gcc failed to detect this.
The attached source code is an example, compile it with options -Os
-march=armv5te -mthumb, I got
push{lr}
ldr r3, [r0]
cmp
--- Comment #1 from carrot at google dot com 2009-09-23 06:49 ---
Created an attachment (id=18634)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18634action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41442
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-23 07:02 ---
Subject: Bug 41411
Author: jakub
Date: Wed Sep 23 07:02:26 2009
New Revision: 152059
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152059
Log:
* dwarf2out.c (loc_list_plus_const): Only define if
--- Comment #7 from jakub at gcc dot gnu dot org 2009-09-23 07:05 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
seen on the trunk:
/home/doko/gcc/snap/x/gcc-snapshot-20090919/build/./gcc/xgcc
-B/home/doko/gcc/snap/x/gcc-snapshot-20090919/build/./gcc/
-B/usr/lib/gcc-snapshot/arm-linux-gnueabi/bin/
-B/usr/lib/gcc-snapshot/arm-linux-gnueabi/lib/ -isystem
/usr/lib/gcc-snapshot/arm-linux-gnueabi/include
--- Comment #4 from jsg at openbsd dot org 2009-09-23 08:43 ---
I have changed the header in OpenBSD to use __builtin_offsetof for gcc = 4.0,
though I don't agree with the warning or having code in GCC that makes it be
invoked if offsetof isn't using a builtin.
The OpenBSD targets in
--- Comment #1 from doko at ubuntu dot com 2009-09-23 08:49 ---
using binutils 2.19.91.20090910
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41443
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-23 08:50 ---
You wound need to enable PRE implement code hoisting to remove the redundant
load (or write the condition as p2-next || (p1-next !p2-next)).
PRE is run too late
to help generate optimal code though as ifcombine
--- Comment #1 from jakub at gcc dot gnu dot org 2009-09-23 08:51 ---
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01602.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-23 08:52 ---
We don't warn for uninitialized uses in PHIs early and the first CCP pass
already removes all of the loop.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #48 from developer at sandoe-acoustics dot co dot uk
2009-09-23 09:13 ---
(In reply to comment #43)
(In reply to comment #42)
Are you building with --enable-build-with-cxx or something similar?
confirmed.
building with:
out-of-tree gmp/mpfr and
--- Comment #2 from doko at ubuntu dot com 2009-09-23 09:24 ---
gcc configured with: --with-arch=armv6 --with-tune=cortex-a8
--with-float=softfp --with-fpu=vfp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41443
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-23 09:24 ---
Or fold could handle this...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41442
--- Comment #1 from jakub at gcc dot gnu dot org 2009-09-23 09:25 ---
Patches should be posted to gcc-patches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41444
--- Comment #29 from jamborm at gcc dot gnu dot org 2009-09-23 09:28
---
Thanks. With the patch fixing the problem described in #24, we get
further when compiling with release checking but run into syntax
errors when compiling stage3 libstc++. And the debug info is still
corrupted.
--- Comment #49 from dominiq at lps dot ens dot fr 2009-09-23 09:28 ---
With the patch in comment #45 I bootstrapped revision 152032 on
powerpc-apple-darwin9. I still have:
17913 - libtool: link: dsymutil .libs/libstdc++.6.dylib || :
17914 : Assertion failed: (orig_str), function
--- Comment #4 from xxcv07 at gmail dot com 2009-09-23 09:29 ---
http://en.wikipedia.org/wiki/Stack_overflow ?
This bug is worse then I thought it is still occurring after
-fno-optimize-sibling-calls and less frequent and like a race condition right
after seek is done to avi with
--- Comment #13 from uros at gcc dot gnu dot org 2009-09-23 09:37 ---
Subject: Bug 39779
Author: uros
Date: Wed Sep 23 09:37:25 2009
New Revision: 152064
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152064
Log:
PR c/39779
* c-typeck.c (build_binary_op)
--- Comment #5 from xxcv07 at gmail dot com 2009-09-23 09:44 ---
Still unreproducible inside gdb can someone tell me why?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41424
--
xxcv07 at gmail dot com changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41424
--- Comment #30 from ubizjak at gmail dot com 2009-09-23 09:48 ---
(In reply to comment #29)
Thanks. With the patch fixing the problem described in #24, we get
further when compiling with release checking but run into syntax
errors when compiling stage3 libstc++. And the debug info
--- Comment #6 from ubizjak at gmail dot com 2009-09-23 09:50 ---
(In reply to comment #5)
Still unreproducible inside gdb can someone tell me why?
You can try to run the executable under valgrind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41424
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-23 09:55 ---
It is gengtype-parse.c that matters, if all of gengtype except this file is
compiled with r152018 and this file with r152017, it works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41436
for example; with --enable-stage1-languages=c,c++ (required for in-tree
GMP/MPFR)
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
--- Comment #14 from uros at gcc dot gnu dot org 2009-09-23 10:19 ---
Subject: Bug 39779
Author: uros
Date: Wed Sep 23 10:18:46 2009
New Revision: 152066
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152066
Log:
PR c/39779
* c-typeck.c (build_binary_op)
--- Comment #15 from ubizjak at gmail dot com 2009-09-23 10:24 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-23 10:41 ---
r152018 seems to change generated code even on:
/* { dg-options -O2 -m32 -fno-inline -mtune=generic } */
struct S
{
const char *s1;
int s2;
char s3;
};
static struct S s;
static inline const char *
bar (void)
--- Comment #3 from joseph at codesourcery dot com 2009-09-23 11:11 ---
Subject: Re: New: libffi fails to build with -mfloat-abi=softfp
On Wed, 23 Sep 2009, doko at ubuntu dot com wrote:
../../../src/libffi/src/arm/sysv.S: Assembler messages:
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-23 11:26 ---
Ah, the problem is that targetm.calls.static_chain is called even on function
decls which have decl_function_context (fndecl) == NULL, and those have
undefined the DECL_NO_STATIC_CHAIN bit, as tree-nested.c only sets
--- Comment #4 from joseph at codesourcery dot com 2009-09-23 11:28 ---
Subject: Re: libffi fails to build with -mfloat-abi=softfp
The __ARM_ARCH__ settings in this file are also out of date (no handling
of __ARM_ARCH_6T2__, __ARM_ARCH_6M__, __ARM_ARCH_7__, __ARM_ARCH_7A__,
--- Comment #5 from jakub at gcc dot gnu dot org 2009-09-23 11:50 ---
Created an attachment (id=18635)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18635action=view)
gcc45-pr41436.patch
Patch I'm bootstrapping/regtesting ATM.
--
--- Comment #7 from xxcv07 at gmail dot com 2009-09-23 11:56 ---
I wish I can do that but I'm testing it under Vista x64 on Windows.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41424
--- Comment #1 from jakub at gcc dot gnu dot org 2009-09-23 12:32 ---
Confirmed. Can be reproduced even with just:
#define A(a,b)
A(1,
2) int i;
int j;
Here int i; is on the 3rd line, but -E generates
# 1 h.c
# 1 built-in
# 1 command-line
# 1 h.c
int i;
int j;
The extra line to
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #7 from ramana at gcc dot gnu dot org 2009-09-23 12:41 ---
*** Bug 41443 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ramana at gcc dot gnu dot org 2009-09-23 12:41 ---
A dup of PR40242.
*** This bug has been marked as a duplicate of 40242 ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-23 13:06 ---
Subject: Bug 41436
Author: jakub
Date: Wed Sep 23 13:06:20 2009
New Revision: 152067
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152067
Log:
PR bootstrap/41436
* cgraphunit.c
--- Comment #7 from jakub at gcc dot gnu dot org 2009-09-23 13:14 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from doko at ubuntu dot com 2009-09-23 13:19 ---
Created an attachment (id=18636)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18636action=view)
patch
testing the attached patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41443
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-09-23
13:20 ---
Fixed with r151594.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
As reported by Richard in
int a;
int foo()
{
int tmp = a;
int tmp2 = a;
int tmp3;
int res;
a = 0;
tmp3 = tmp2;
res = tmp - tmp2 + 1;
return res;
}
results in wrong-debug with -O2 -g. Having # DEBUG tmp3 = a
after a = 0 is wrong certainly already at gimple levels, while # DEBUG
--- Comment #50 from howarth at nitro dot med dot uc dot edu 2009-09-23
13:38 ---
(In reply to comment #42)
Are you building with --enable-build-with-cxx or something similar?
libstdc++-v3 isn't normally compared. The difference you are seeing is likely
related to different random
--- Comment #51 from howarth at nitro dot med dot uc dot edu 2009-09-23
13:49 ---
Is there anyway to redefine or adjust gno-strict-dwarf at a target specific
level so that for a given target that option could be set to Init(1)? Having to
pass this through BOOT_CFLAGS seems suboptimal
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-23 13:55 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #52 from developer at sandoe-acoustics dot co dot uk
2009-09-23 13:57 ---
(In reply to comment #51)
Is there anyway to redefine or adjust gno-strict-dwarf at a target specific
level so that for a given target that option could be set to Init(1)? Having
to
pass this
--- Comment #7 from doko at ubuntu dot com 2009-09-23 14:03 ---
Created an attachment (id=18637)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18637action=view)
fixed patch
fixed patch, no regressions when applied to libffi-3.0.7
--
--- Comment #8 from aph at gcc dot gnu dot org 2009-09-23 14:10 ---
This patch is fine. Post it to the gcc list and I'll approve it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41443
--- Comment #53 from howarth at nitro dot med dot uc dot edu 2009-09-23
14:25 ---
So then the most robust approach would be to add your patch to enable dwarf
debugging on darwin8 and then add...
gno-strict-dwarf
Common RejectNegative Var(dwarf_strict,0) Init(1)
Emit DWARF additions
--- Comment #54 from jakub at gcc dot gnu dot org 2009-09-23 14:30 ---
For target masks, the target override routine checks the *_explicit flag and
only changes it to the default if it wasn't explicit.
For other variables, usually the variable is initialized to some other value
(-1
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-23 14:33 ---
Fixed:
http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00815.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from doko at gcc dot gnu dot org 2009-09-23 14:50 ---
Subject: Bug 40242
Author: doko
Date: Wed Sep 23 14:50:35 2009
New Revision: 152075
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152075
Log:
2009-09-23 Matthias Klose d...@ubuntu.com
PR
--- Comment #55 from jakub at gcc dot gnu dot org 2009-09-23 14:52 ---
Subject: Bug 41405
Author: jakub
Date: Wed Sep 23 14:52:20 2009
New Revision: 152076
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152076
Log:
PR bootstrap/41405
* doc/invoke.texi: Document
--- Comment #3 from dodji at gcc dot gnu dot org 2009-09-23 14:59 ---
Subject: Bug 41065
Author: dodji
Date: Wed Sep 23 14:58:58 2009
New Revision: 152077
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152077
Log:
Fix PR debug/41065
gcc/ChangeLog:
PR debug/41065
--- Comment #10 from doko at gcc dot gnu dot org 2009-09-23 15:08 ---
Subject: Bug 41443
Author: doko
Date: Wed Sep 23 15:08:02 2009
New Revision: 152078
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152078
Log:
2009-09-23 Matthias Klose d...@ubuntu.com
PR
--- Comment #9 from doko at gcc dot gnu dot org 2009-09-23 15:08 ---
Subject: Bug 40242
Author: doko
Date: Wed Sep 23 15:08:02 2009
New Revision: 152078
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152078
Log:
2009-09-23 Matthias Klose d...@ubuntu.com
PR
--- Comment #11 from doko at gcc dot gnu dot org 2009-09-23 15:11 ---
Subject: Bug 41443
Author: doko
Date: Wed Sep 23 15:11:17 2009
New Revision: 152079
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152079
Log:
2009-09-23 Matthias Klose d...@ubuntu.com
PR
--- Comment #10 from doko at gcc dot gnu dot org 2009-09-23 15:11 ---
Subject: Bug 40242
Author: doko
Date: Wed Sep 23 15:11:17 2009
New Revision: 152079
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152079
Log:
2009-09-23 Matthias Klose d...@ubuntu.com
PR
--- Comment #56 from howarth at nitro dot med dot uc dot edu 2009-09-23
15:23 ---
(In reply to comment #54)
For target masks, the target override routine checks the *_explicit flag and
only changes it to the default if it wasn't explicit.
For other variables, usually the variable is
--- Comment #24 from rguenth at gcc dot gnu dot org 2009-09-23 15:23
---
A simple band-aid for DOM is IMHO ok here, sth like:
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c (revision 152059)
+++ tree-ssa-dom.c
--- Comment #57 from howarth at nitro dot med dot uc dot edu 2009-09-23
15:42 ---
Can we just add...
;; enable gstrict-dwarf as default
TargetSave
int gstrict_dwarf_explicit=1
in darwin.opt to achieve this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
1 - 100 of 162 matches
Mail list logo
