On Sun, Nov 14, 2010 at 07:21:50PM -0800, Linus Torvalds wrote:
So when Richard Gunther says a memory clobber doesn't cover automatic
storage, to me that very clearly spells gcc is buggy as hell.
Because automatic storage with its address taken _very_ much gets
clobbered by things like memset
That said, changing the inline asm to just clobber one less register
would be completely sufficient to make it work well with all gccs out there,
just push/pop one of the register around the whole body. I doubt calling
out SMM BIOS is actually so performance critical that one push and one pop
On Mon, Nov 15, 2010 at 09:56:05AM +0100, Jakub Jelinek wrote:
Yes, reload should figure out it has address of regs already tied to %eax,
unfortunately starting with IRA it doesn't (I'll file a GCC bug about that;
http://gcc.gnu.org/PR46479
Jakub
With 638 macros documented by @defmac, and 475 files that include tm.h ,
our current approach to hookization is too slow to get the tree optimizers
and front ends independent of target macros in any useful timeframe.
Therefore, I propose the following approach:
The target macros currently
On Mon, Nov 15, 2010 at 09:56:05AM +0100, Jakub Jelinek wrote:
On Sun, Nov 14, 2010 at 07:21:50PM -0800, Linus Torvalds wrote:
So when Richard Gunther says a memory clobber doesn't cover automatic
storage, to me that very clearly spells gcc is buggy as hell.
Because automatic storage with
On Mon, Nov 15, 2010 at 9:56 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sun, Nov 14, 2010 at 07:21:50PM -0800, Linus Torvalds wrote:
So when Richard Gunther says a memory clobber doesn't cover automatic
storage, to me that very clearly spells gcc is buggy as hell.
Because automatic storage
And for this the starting point should be what has been requested,
i.e. preprocessed source + gcc options + gcc version and some hints what
actually misbehaves (with the , +m (*regs) change reverted)
in gcc bugzilla. Only with that we can actually look at what has been
happening, see whether
On Mon, Nov 15, 2010 at 11:54:46AM +0100, Andi Kleen wrote:
And for this the starting point should be what has been requested,
i.e. preprocessed source + gcc options + gcc version and some hints what
actually misbehaves (with the , +m (*regs) change reverted)
in gcc bugzilla. Only with
Guess we need somebody who actually reported the problem, state what
gcc was actually used and post preprocessed source, gcc options
from his case.
Jim Bos,
Can you please supply that?
Please use
rm drivers/char/i8k.o
make V=1 drivers/char/i8k.o
make drivers/char/i8k.i
and supply the .i
On 11/13/2010 08:40 PM, Peter Bergner wrote:
On Sat, 2010-11-13 at 11:27 +0100, Paolo Bonzini wrote:
On 11/12/2010 03:25 PM, H.J. Lu wrote:
IRA may move instructions across an unspec_volatile,
Do you have a testcase?
Are you sure it's IRA and not our old friend update_equiv_regs()
which
Hello,
On 14.11.2010 0:08, Xinliang David Li wrote:
I re-measured the performance difference using trunk gcc and trunk
clang/llvm on a core-2 box. -fno-strict-aliasing is added to gcc
because clang/llvm's type based aliasing is not incomplete and not
enabled by default. I also added
Is there any another way to give attributes to inline assembly insns?
2010/10/26 Ian Lance Taylor i...@google.com:
roy rosen roy.1ro...@gmail.com writes:
If I want the compiler to understand the inline assembly is it
possible to write define_insn which would match the pattern that GCC
Quoting roy rosen roy.1ro...@gmail.com:
Is there any another way to give attributes to inline assembly insns?
See define_asm_attributes.
It appears that reload_combine does not take exceptions into account.
When it encounters a BARRIER it forgets all register uses after this
point. But an exception can transfer control to any of the CODE_LABELs
and jump back to after the BARRIER, with the registers still in use.
There should
On Mon, 15 Nov 2010, Joern Rennecke wrote:
With 638 macros documented by @defmac, and 475 files that include tm.h ,
our current approach to hookization is too slow to get the tree optimizers
and front ends independent of target macros in any useful timeframe.
I think it's perfectly feasible;
But this lets you just set default attributes.
I want to set real attributes so that the compiler would be able to
know which insn can be parallelized with another.
Is there a different way?
Are you saying that an inline assembly statement would stay as is, and
would not be touched by the compiler
On Mon, Nov 15, 2010 at 3:16 AM, Jakub Jelinek ja...@redhat.com wrote:
I don't see any problems on the assembly level. i8k_smm is
not inlined in this case and checks all 3 conditions.
If it really is related to gcc not understanding that *regs has
changed due to the memory being an automatic
Eric Botcazou ebotca...@adacore.com writes:
It appears that reload_combine does not take exceptions into account.
When it encounters a BARRIER it forgets all register uses after this
point. But an exception can transfer control to any of the CODE_LABELs
and jump back to after the BARRIER,
JUMP_INSNs already invalidate the register use information. The problem
is that CALL_INSNs that can throw don't.
Sure, that's precisely what I was suggesting to change, like in rev 162301.
--
Eric Botcazou
For peak, FDO is the most effective option. It can boost performance
by 7-10% depending on the program. The options you suggested probably
won't make too big a dent. -funroll-loops can hurt performance
without profiling. More aggressive inlining, ipa-cp, unswitching etc
enabled by O3 may help a
Quoting Joseph S. Myers jos...@codesourcery.com:
On Mon, 15 Nov 2010, Joern Rennecke wrote:
With 638 macros documented by @defmac, and 475 files that include tm.h ,
our current approach to hookization is too slow to get the tree optimizers
and front ends independent of target macros in any
Eric Botcazou ebotca...@adacore.com writes:
JUMP_INSNs already invalidate the register use information. The problem
is that CALL_INSNs that can throw don't.
Sure, that's precisely what I was suggesting to change, like in rev 162301.
Ahh, you mean something like this? (Fixes the testcase,
On 11/15/2010 05:04 PM, Linus Torvalds wrote:
On Mon, Nov 15, 2010 at 3:16 AM, Jakub Jelinek ja...@redhat.com wrote:
I don't see any problems on the assembly level. i8k_smm is
not inlined in this case and checks all 3 conditions.
If it really is related to gcc not understanding that *regs
On Mon, Nov 15, 2010 at 06:36:06PM +0100, Jim Bos wrote:
On 11/15/2010 12:37 PM, Andi Kleen wrote:
See attached, note this is the vanilla 2.6.36 i8k.c (without any patch).
And to be 100% sure, if I build this (make drivers/char/i8k.ko) it won't
work.
[ The i8k.i is rather big, even gzipped
For peak, FDO is the most effective option. It can boost performance
by 7-10% depending on the program. The options you suggested probably
won't make too big a dent. -funroll-loops can hurt performance
without profiling. More aggressive inlining, ipa-cp, unswitching etc
-funroll-loops
On Mon, Nov 15, 2010 at 9:40 AM, Jim Bos jim...@xs4all.nl wrote:
Hmm, that doesn't work.
[ Not sure if you read to whole thread but initial workaround was to
change the asm(..) to asm volatile(..) which did work. ]
Since I have a different gcc than yours (and I'm not going to compile
my
On 11/15/2010 06:44 PM, Jakub Jelinek wrote:
On Mon, Nov 15, 2010 at 06:36:06PM +0100, Jim Bos wrote:
On 11/15/2010 12:37 PM, Andi Kleen wrote:
See attached, note this is the vanilla 2.6.36 i8k.c (without any patch).
And to be 100% sure, if I build this (make drivers/char/i8k.ko) it won't
On Mon, Nov 15, 2010 at 07:17:31PM +0100, Jim Bos wrote:
# gcc -v
Reading specs from /usr/lib/gcc/i486-slackware-linux/4.5.1/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i486-slackware-linux/4.5.1/lto-wrapper
Target: i486-slackware-linux
Configured with: ../gcc-4.5.1/configure
On 11/15/2010 07:08 PM, Linus Torvalds wrote:
On Mon, Nov 15, 2010 at 9:40 AM, Jim Bos jim...@xs4all.nl wrote:
Hmm, that doesn't work.
[ Not sure if you read to whole thread but initial workaround was to
change the asm(..) to asm volatile(..) which did work. ]
Since I have a different gcc
On 11/15/2010 07:30 PM, Jim Bos wrote:
On 11/15/2010 07:08 PM, Linus Torvalds wrote:
On Mon, Nov 15, 2010 at 9:40 AM, Jim Bos jim...@xs4all.nl wrote:
Hmm, that doesn't work.
[ Not sure if you read to whole thread but initial workaround was to
change the asm(..) to asm volatile(..) which did
On 11/07/10 15:41, Andreas Schwab wrote:
Andi Kleena...@firstfloor.org writes:
Jimjim...@xs4all.nl writes:
After upgrading my Dell laptop, both OS+kernel the i8k interface was giving
nonsensical output. As it turned out it's not the kernel but compiler
upgrade which broke this.
Guys at
On Mon, 15 Nov 2010, Joern Rennecke wrote:
Quoting Joseph S. Myers jos...@codesourcery.com:
On Mon, 15 Nov 2010, Joern Rennecke wrote:
With 638 macros documented by @defmac, and 475 files that include tm.h ,
our current approach to hookization is too slow to get the tree optimizers
On 11/08/10 03:49, Richard Guenther wrote:
On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleena...@firstfloor.org wrote:
Andreas Schwabsch...@linux-m68k.org writes:
The asm fails to mention that it modifies *regs.
It has a memory clobber, that should be enough, no?
No. A memory clobber does not
roy rosen roy.1ro...@gmail.com writes:
Is there any another way to give attributes to inline assembly insns?
Not that I know of. It would be a useful feature in some cases, though
difficult to document.
For specific cases a backend can normally do better by providing builtin
functions.
Ian
On Mon, Nov 15, 2010 at 10:30 AM, Jim Bos jim...@xs4all.nl wrote:
Attached version with plain 2.6.36 source and version with the committed
patch, i.e with the '+m (*regs)'
Looks 100% identical in i8k_smm() itself, and I'm not seeing anything
bad. The asm has certainly not been optimized away
On Mon, Nov 15, 2010 at 07:30:35PM +0100, Jim Bos wrote:
On 11/15/2010 07:08 PM, Linus Torvalds wrote:
On Mon, Nov 15, 2010 at 9:40 AM, Jim Bos jim...@xs4all.nl wrote:
Hmm, that doesn't work.
[ Not sure if you read to whole thread but initial workaround was to
change the asm(..) to
On Mon, Nov 15, 2010 at 10:45 AM, Jeff Law l...@redhat.com wrote:
A memory clobber should clobber anything in memory, including autos in
memory; if it doesn't, then that seems like a major problem. I'd like to
see the rationale behind not clobbering autos in memory.
Yes. It turns out that
On 11/15/2010 07:26 PM, Jakub Jelinek wrote:
On Mon, Nov 15, 2010 at 07:17:31PM +0100, Jim Bos wrote:
# gcc -v
Reading specs from /usr/lib/gcc/i486-slackware-linux/4.5.1/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i486-slackware-linux/4.5.1/lto-wrapper
Target:
On Mon, Nov 15, 2010 at 07:58:48PM +0100, Jakub Jelinek wrote:
Now, not sure why this happens, as there is
case GIMPLE_ASM:
for (i = 0; i gimple_asm_nclobbers (stmt); i++)
{
tree op = gimple_asm_clobber_op (stmt, i);
if (simple_cst_equal(TREE_VALUE
On Mon, Nov 15, 2010 at 11:12 AM, Jakub Jelinek ja...@redhat.com wrote:
Ah, the problem is that memory_identifier_string is only initialized in
ipa-reference.c's initialization, so it can be (and is in this case) NULL in
ipa-pure-const.c.
Ok. And I guess you can verify that all versions of
On Mon, Nov 15, 2010 at 11:21:30AM -0800, Linus Torvalds wrote:
On Mon, Nov 15, 2010 at 11:12 AM, Jakub Jelinek ja...@redhat.com wrote:
Ah, the problem is that memory_identifier_string is only initialized in
ipa-reference.c's initialization, so it can be (and is in this case) NULL in
On 11/15/2010 11:12 AM, Jakub Jelinek wrote:
- if (simple_cst_equal(TREE_VALUE (op), memory_identifier_string) == 1)
+ if (strcmp (TREE_STRING_POINTER (TREE_VALUE (link)), memory) == 0)
I prefer this solution. I think memory_identifier_string is over-engineering.
Patch to remove it
On Mon, Nov 15, 2010 at 11:53:05AM -0800, Richard Henderson wrote:
On 11/15/2010 11:12 AM, Jakub Jelinek wrote:
- if (simple_cst_equal(TREE_VALUE (op), memory_identifier_string) == 1)
+ if (strcmp (TREE_STRING_POINTER (TREE_VALUE (link)), memory) == 0)
I prefer this solution. I
On 11/15/2010 08:51 PM, Jakub Jelinek wrote:
On Mon, Nov 15, 2010 at 11:21:30AM -0800, Linus Torvalds wrote:
On Mon, Nov 15, 2010 at 11:12 AM, Jakub Jelinek ja...@redhat.com wrote:
Ah, the problem is that memory_identifier_string is only initialized in
ipa-reference.c's initialization, so it
The only targets that are using textual prologues and epilogues are now
arc, cris, pdp11 and vax. ARC should probably have been deprecated long
ago, any plans to convert the others or (for cris) to flip the default?
Paolo
Ahh, you mean something like this? (Fixes the testcase, but not
properly tested yet.)
Yes, but I think you still need the regular treatment for these CALL_INSNs:
Index: postreload.c
===
--- postreload.c(revision 166701)
We currently have 3 non-algorithmic maintainers:
loop optimizer Zdenek Dvorak o...@ucw.cz
loop optimizer Daniel Berlin dber...@dberlin.org
libcpp Tom Tromey tro...@redhat.com
Especially for the loop optimizer, the situation is
On 11/15/2010 04:48 PM, Joseph S. Myers wrote:
* The macro is tested with #if/#ifdef/#ifndef/#elif in a source file
outside of config/ (but including front-end subdirectories). Care is
needed in identifying such macros through grep because of
backslash-newline line continuations and because
On Nov 15, 2010, at 3:50 PM, Paolo Bonzini wrote:
The only targets that are using textual prologues and epilogues are now arc,
cris, pdp11 and vax. ARC should probably have been deprecated long ago, any
plans to convert the others or (for cris) to flip the default?
Learning how to do this
Quoting Paolo Bonzini bonz...@gnu.org:
Augmenting libcpp with a new kind of poisoning that only affect
preprocessor conditionals would probably make this a lot simpler.
If we don't have a wrapper macro, we can just poison the macro.
I still have to find out how practical that is, but for now
2010/11/15 Jan Hubicka hubi...@ucw.cz:
For peak, FDO is the most effective option. It can boost performance
by 7-10% depending on the program. The options you suggested probably
won't make too big a dent. -funroll-loops can hurt performance
without profiling. More aggressive inlining,
On Mon, Nov 15, 2010 at 7:45 PM, Jeff Law l...@redhat.com wrote:
On 11/08/10 03:49, Richard Guenther wrote:
On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleena...@firstfloor.org wrote:
Andreas Schwabsch...@linux-m68k.org writes:
The asm fails to mention that it modifies *regs.
It has a memory
On Mon, 15 Nov 2010, Paolo Bonzini wrote:
The only targets that are using textual prologues and epilogues are now arc,
cris, pdp11 and vax. ARC should probably have been deprecated long ago, any
plans to convert the others or (for cris) to flip the default?
What code are you loking at; where
On Mon, Nov 15, 2010 at 10:00 PM, Paolo Bonzini bonz...@gnu.org wrote:
We currently have 3 non-algorithmic maintainers:
loop optimizer Zdenek Dvorak o...@ucw.cz
loop optimizer Daniel Berlin dber...@dberlin.org
libcpp Tom Tromey
I did some measurement (64bit).
Experiment 1:
-O2 -funroll-loops vs -O2
It improves performance (geomean) by 0.56%, not too much:
O2 O2 unroll-loops
164.gzip13241331 0.56%
On Mon, Nov 15, 2010 at 10:00 PM, Paolo Bonzini bonz...@gnu.org wrote:
We currently have 3 non-algorithmic maintainers:
loop optimizer Zdenek Dvorak o...@ucw.cz
loop optimizer Daniel Berlin dber...@dberlin.org
libcpp Tom Tromey
I did some measurement (64bit).
Experiment 1:
-O2 -funroll-loops vs -O2
It improves performance (geomean) by 0.56%, not too much:
O2 O2 unroll-loops
164.gzip13241331 0.56%
testcase shows that in 4.1/4.2/4.3/4.4 this is miscompiled only when using
-fno-ipa-reference, in 4.5 it is miscompiled always when optimizing
unless -fno-ipa-pure-const (as 4.5 added local-pure-const pass which is run
before ipa-reference) and in 4.6 this has been fixed by Honza when
doing
On Mon, Nov 15, 2010 at 11:43:22PM +0100, Andi Kleen wrote:
testcase shows that in 4.1/4.2/4.3/4.4 this is miscompiled only when using
-fno-ipa-reference, in 4.5 it is miscompiled always when optimizing
unless -fno-ipa-pure-const (as 4.5 added local-pure-const pass which is run
before
On 11/15/10 15:07, Richard Guenther wrote:
On Mon, Nov 15, 2010 at 7:45 PM, Jeff Lawl...@redhat.com wrote:
On 11/08/10 03:49, Richard Guenther wrote:
On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleena...@firstfloor.orgwrote:
Andreas Schwabsch...@linux-m68k.orgwrites:
The asm fails to
On 11/15/2010 11:10 PM, Hans-Peter Nilsson wrote:
There *is* an option to omit the prologue and epologue
controlling the TARGET_PROLOGUE_EPILOGUE; I'm guessing that
could cause confusion.
That's what confused me.
Is that getting in the way of something?
Yes, there is code conditionalized
On Mon, Nov 15, 2010 at 11:58 PM, Jeff Law l...@redhat.com wrote:
On 11/15/10 15:07, Richard Guenther wrote:
On Mon, Nov 15, 2010 at 7:45 PM, Jeff Lawl...@redhat.com wrote:
On 11/08/10 03:49, Richard Guenther wrote:
On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleena...@firstfloor.org
wrote:
Just measured: lto +O3 improves over O2 by a decent 4.8% geomean. More
data come later.
164.gzip13241322 -0.10%
175.vpr16941703 0.51%
176.gcc22932347
This means O3 level inlining should be turned on also for lto build by
default -- as -O2 lto performance is too unimpressive.
David
On Mon, Nov 15, 2010 at 3:36 PM, Xinliang David Li davi...@google.com wrote:
Just measured: lto +O3 improves over O2 by a decent 4.8% geomean. More
data come
This means O3 level inlining should be turned on also for lto build by
default -- as -O2 lto performance is too unimpressive.
I am just re-tunning the inliner and hope to get more speedups for smaller
costs than we get right now. I however don't think we can resonably enable it
as it is at LTO
This means O3 level inlining should be turned on also for lto build by
default -- as -O2 lto performance is too unimpressive.
I am just re-tunning the inliner and hope to get more speedups for smaller
costs than we get right now. I however don't think we can resonably enable it
as it is
On Mon, Nov 15, 2010 at 4:25 PM, Jan Hubicka hubi...@ucw.cz wrote:
This means O3 level inlining should be turned on also for lto build by
default -- as -O2 lto performance is too unimpressive.
I am just re-tunning the inliner and hope to get more speedups for smaller
costs than we get right
On Mon, Nov 15, 2010 at 4:25 PM, Jan Hubicka hubi...@ucw.cz wrote:
This means O3 level inlining should be turned on also for lto build by
default -- as -O2 lto performance is too unimpressive.
I am just re-tunning the inliner and hope to get more speedups for smaller
costs than we get
Fortunately linker plugin solves the problem here and this is why I want to
have it by default. GCC then can do effectively -fwhole-program for binaries
(since linker knows what will be bound elsewhere) and take advantage of
visibility((hidden)) hints for shared libraries same way. Most of
I know it is debatable and I could be convinced otherwise, but I would suggest:
#ifdef __cplusplus
extern C {
#endif
...
#ifdef __cplusplus
} /* extern C */
#endif
be applied liberally in gcc.
Not around #includes, it is the job of each .h file, and mindful of #ifdefs
(ie:
Jay K jay.kr...@cornell.edu writes:
Any folks that get to see the mangled names, debugging, working on
binutils, whatever, are saved from them.
Demangling is easy and readily available.
I don't see any reason to add extern C indiscriminately at this time.
If there are concrete problems,
Fortunately linker plugin solves the problem here and this is why I want to
have it by default. GCC then can do effectively -fwhole-program for
binaries
(since linker knows what will be bound elsewhere) and take advantage of
visibility((hidden)) hints for shared libraries same way.
On Mon, Nov 15, 2010 at 5:39 PM, Jan Hubicka hubi...@ucw.cz wrote:
Fortunately linker plugin solves the problem here and this is why I want
to
have it by default. GCC then can do effectively -fwhole-program for
binaries
(since linker knows what will be bound elsewhere) and take
More performance data:
-O2 -funroll-all-loops vs O2: +1.1% geomean
O2 O2 unroll-all-loops
164.gzip13241336 0.94%
175.vpr16941670 -1.44%
On 11/15/10 16:07, Richard Guenther wrote:
If the address of the auto isn't taken, then why is the object in memory to
begin with (with the obvious exception for aggregates).
Exactly sort of my point. If people pass the address ofx to an asm
and modifyx + 8 expecting the adjacent stack
target.h and function.h include tm.h, and they got data structure dependencies
that are painful to untangle. function.h requires x_rtl to be split into
a target-type tainted part and one that can be used in tree optimizers
/ frontends
(via the inline functions in emit-rtl.c). To get rid of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46478
Summary: Missing diagnosis for combining SUBROUTINE and
FUNCTION in a GENERIC interface
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: accepts-invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
--- Comment #26 from Johannes Singler singler at kit dot edu 2010-11-15
08:53:12 UTC ---
(In reply to comment #25)
You might have misread what I wrote. I did not mention 35 tests; I
mentioned
that a test became slower by 35%. The total
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
--- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-15
09:12:19 UTC ---
(In reply to comment #9)
Last patch:
Now: http://gcc.gnu.org/ml/fortran/2010-11/msg00243.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46479
Summary: [4.4/4.5/4.6 Regression] +m (*regs) : a (regs)
doesn't use (%eax) for the MEM
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46479
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||law at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
--- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-15
09:43:09 UTC ---
Author: rguenth
Date: Mon Nov 15 09:43:01 2010
New Revision: 166744
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166744
Log:
2010-11-15 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46427
--- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org
2010-11-15 09:58:47 UTC ---
Author: amylaar
Date: Mon Nov 15 09:58:42 2010
New Revision: 166747
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166747
Log:
Add PR number
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46427
Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46474
--- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2010-11-15
10:14:00 UTC ---
(In reply to comment #2)
If it's due to the reported difference using fma and not using fma then
probably the tree fma code lacks checks for debug stmts.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46101
--- Comment #3 from Dodji Seketeli dodji at gcc dot gnu.org 2010-11-15
10:17:41 UTC ---
Patch posted to http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01489.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339
--- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr
2010-11-15 10:14:16 UTC ---
The patch in comment #9 fixes this PR along with pr34640 (and its duplicates),
pr39304, pr40737, and pr41627 (probably also duplicates of pr34640)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46474
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46474
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-15
10:37:15 UTC ---
(In reply to comment #3)
(In reply to comment #2)
If it's due to the reported difference using fma and not using fma then
probably the tree fma code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46480
Summary: [trans-mem] Uninstrumented code path is missing
Product: gcc
Version: trans-mem
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46461
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-15
10:45:18 UTC ---
Created attachment 22396
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22396
gcc46-pr46461.patch
Untested patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46474
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36659
Dan Horak dan at danny dot cz changed:
What|Removed |Added
CC||dan at danny dot cz
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46366
--- Comment #3 from Andrey Belevantsev abel at gcc dot gnu.org 2010-11-15
11:10:56 UTC ---
It is no problem to make this function return 0; and explicitly declare its
return type, I just need to check that the test case will still ICE without a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46481
Summary: long double should default to 64bit even for aix6.1
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46276
--- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2010-11-15
11:20:13 UTC ---
Created attachment 22397
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22397
preliminary fix for problematic assert
Simply splitting the components of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45962
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45892
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45965
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
---
1 - 100 of 248 matches
Mail list logo
