Здравствуйте!
Ваш знакомый Обухов Д.В dmitiy.obu...@gmail.com, предлагает вам ознакомиться с
идеей ответственности избираемых народом Президента и депутатов, смысл которой
в следующем: поскольку единственным источником власти в России является её
народ (ст.3 Конституции РФ), а ответственности
On 02/17/2010 04:50 AM, dib.cool...@gmail.com wrote:
hi...
I am a student of b.sc first yr in comp.science
can you tell me
which parsing technique is used in ANSI c language and in gcc?
A hand-written recursive descent parser. It's in gcc/c-parse.c.
and how the parse tree is
Quoting Ralf Wildenhues ralf.wildenh...@gmx.de:
sed alternation \| is not portable.
I've replaced it now with a pair of substitutions. I also fixed
the ',' substitution to give yield on opening bracket for the next cast,
and to apply for all commas.
+ $[]as_decl_type
What is this
On 02/17/2010 04:41 PM, Joern Rennecke wrote:
Quoting Ralf Wildenhues ralf.wildenh...@gmx.de:
sed alternation \| is not portable.
I've replaced it now with a pair of substitutions. I also fixed
the ',' substitution to give yield on opening bracket for the next cast,
and to apply for all
Quoting Paolo Bonzini bonz...@gnu.org:
Maybe we can use this in AC_CHECK_DECLS instead of having a new
separate macro. If there is a parenthesis in the name call the new
version, if there is none, call the old one.
You shouldn't need to keep the old version around, it's supposed to be
a
Hi,
Mark just made an ICE in the compiler with non-default options a P1
bug for GCC 4.5 (xf.
http://gcc.gnu.org/ml/gcc-bugs/2010-02/msg01695.html).
Can someone please explain why this kind of bug should be of
release-blocking priority?
Thanks,
Ciao!
Steven
Steven Bosscher wrote:
Mark just made an ICE in the compiler with non-default options a P1
bug for GCC 4.5 (xf.
http://gcc.gnu.org/ml/gcc-bugs/2010-02/msg01695.html).
Can someone please explain why this kind of bug should be of
release-blocking priority?
As I wrote in the PR, I want to
Hi I am working on calling the instrument function before every
function call automatically. I tried inserting this pass which would
add my function to every edge
//
static unsigned int spmm_insert(void){
struct cgraph_edge *e;
struct cgraph_node
On Wed, Feb 17, 2010 at 7:46 PM, Mark Mitchell m...@codesourcery.com wrote:
Steven Bosscher wrote:
Mark just made an ICE in the compiler with non-default options a P1
bug for GCC 4.5 (xf.
http://gcc.gnu.org/ml/gcc-bugs/2010-02/msg01695.html).
Can someone please explain why this kind of bug
Maybe we can use this in AC_CHECK_DECLS instead of having a new
separate macro. If there is a parenthesis in the name call the new
version, if there is none, call the old one.
You shouldn't need to keep the old version around, it's supposed to be
a drop-in replacement. The reason I used a
Quoting Paolo Bonzini bonz...@gnu.org:
Maybe we can use this in AC_CHECK_DECLS instead of having a new
separate macro. If there is a parenthesis in the name call the new
version, if there is none, call the old one.
You shouldn't need to keep the old version around, it's supposed to be
a
We are trying to add a 16bit integer division library function for
bfin port. I just found GCC didn't do integral promotions when calling
library function.
For example, in function foo, I can assume both arguments are zero
extended from unsigned short to unsigned int.
extern unsigned short foo
--- Comment #11 from burnus at gcc dot gnu dot org 2010-02-17 08:22 ---
Replying to myself (comment #10):
I think one should really send a interpretation request.
I have now created one and sent it to Van.
What about POINTERs?
Pointers seem to be treated similarly to allocatables.
--- Comment #5 from jakub at gcc dot gnu dot org 2010-02-17 08:55 ---
Subject: Bug 42918
Author: jakub
Date: Wed Feb 17 08:54:59 2010
New Revision: 156823
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156823
Log:
PR debug/42918
* caller-save.c
--- Comment #6 from jakub at gcc dot gnu dot org 2010-02-17 08:59 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #22 from paolo dot carlini at oracle dot com 2010-02-17 09:36
---
So... shall we close this as fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-02-17 09:39
---
Subject: Bug 41043
Author: rguenth
Date: Wed Feb 17 09:39:26 2010
New Revision: 156824
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156824
Log:
2010-02-16 Richard Guenther rguent...@suse.de
PR
--- Comment #1 from ubizjak at gmail dot com 2010-02-17 09:43 ---
--cut here--
Index: xop-check.h
===
--- xop-check.h (revision 156823)
+++ xop-check.h (working copy)
@@ -1,6 +1,7 @@
#include stdlib.h
#include cpuid.h
--- Comment #3 from nickc at gcc dot gnu dot org 2010-02-17 10:05 ---
Subject: Bug 11238
Author: nickc
Date: Wed Feb 17 10:05:27 2010
New Revision: 156826
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156826
Log:
PR 11238
* Makefile.tpl (local-distclean): Also
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43101
--- Comment #3 from ubizjak at gmail dot com 2010-02-17 10:59 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-17 11:00 ---
#0 0x00a6cb3a in build_ref_for_offset_1 (res=0x0,
type=0x75ade690, offset=0, exp_type=0x77ee4498)
at /space/rguenther/src/svn/trunk/gcc/tree-sra.c:1445
1445 offset = offset %
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ACATS c37105a wrong-code on |[4.5 Regression] ACATS
|arm-linux
--- Comment #5 from anitha dot boyapati at atmel dot com 2010-02-17 11:09
---
Fails with gcc 4.4.3 and gcc 4.5 with -O1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39223
--- Comment #6 from anitha dot boyapati at atmel dot com 2010-02-17 11:19
---
An observation - the same file when compiled with -O1 for i386 target also
appears to load g_54 using movl instruction.
_func_45:
...
L11:
testw %bx, %bx
je L7
movl
--- Comment #2 from laurent at guerby dot net 2010-02-17 11:57 ---
For reference c87b39a on powerpc-linux:
^M
,.,. C87B39A ACATS 2.5 10-02-17 00:06:47^M
C87B39A OVERLOADING RESOLUTION FOR ALLOCATORS.^M
^M
raised CONSTRAINT_ERROR : c87b39a.adb:93 discriminant check failed^M
Still
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-02-17 12:31 ---
Mine, I'll make type_internals_preclude_sra_p return true for arrays
with elements with zero-sized type.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-17 13:56 ---
I guess lambda-code.c needs to be taught about debug stmts.
This is actually more important than usual -fcompare-debug differences, here
debug stmt actually prevent the optimization altogether.
Without -g the loops
--- Comment #3 from josiejoppen at gmail dot com 2010-02-17 14:00 ---
the cortex m1 is a thumb2 only target. Also the command BLX #imm is not
supported under ARM V6 arch. Now as a case history, I can tell the following.
Initially i had trouble getting into interrupts. i found that the
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to
--- Comment #8 from 0xe2 dot 0x9a dot 0x9b at gmail dot com 2010-02-17
14:16 ---
(In reply to comment #7)
Where the compiler always chooses some particular implementation is
implementation defined behavior, not undefined behavior. Undefined behavior
is
always just that,
--- Comment #9 from paolo dot carlini at oracle dot com 2010-02-17 14:39
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2010-02-17 14:41 ---
Please stop reopening. 6.3.1.3 is about casts between integer types.
Signed integer overflow is even mentioned as an example of undefined behavior
in 3.4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43089
Source
volatile uint8_t mUsart0BufferReadPtr;
void Usart0AtModeSkipLine(void)
{
uint8_t rdptr = 0;
rdptr = mUsart0BufferReadPtr;
rdptr = mUsart0BufferReadPtr;
rdptr = mUsart0BufferReadPtr;
}
-
Generated asm
+0694: 93DFPUSH R29
--- Comment #2 from davek at gcc dot gnu dot org 2010-02-17 15:10 ---
(In reply to comment #1)
This sounds more like a cygwin problem, not a GCC one.
It's a problem with the cygwin target-dependent linker spec.
The -mno-cygwin option is deprecated and scheduled to be withdrawn, so I
--- Comment #2 from davek at gcc dot gnu dot org 2010-02-17 15:15 ---
I can confirm that 4.3 series builds working ecj1 when you use the configure
option, since that's how I build the distro release compiler.
--
davek at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from hjl dot tools at gmail dot com 2010-02-17 15:21 ---
I think it is caused by revision 144618:
http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00120.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #10 from davek at gcc dot gnu dot org 2010-02-17 15:24 ---
This bug was originally caused by the fact that libjava was disabled in
noconfigdirs for cygwin at the time the report was filed. This has long since
been fixed.
The last four comments are incorrect in assuming
http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/C_002b_002b-Dialect-Options.html#index-fno_002drtti-148
doesn't mention any restrictions on compiling programs with some translation
units compiled with -frtti, and others compiled with -fno-rtti. Yet there are
such restrictions. For example, programs
--- Comment #4 from davek at gcc dot gnu dot org 2010-02-17 15:33 ---
The ln invocation has long since been using -f, so i'm closing this old bug
fixed.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2010-02-17 15:34 ---
I can't reproduce this with 4.4 either, since
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01924.html
gcc output looks like what Jan pasted here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42233
--- Comment #3 from davek at gcc dot gnu dot org 2010-02-17 15:29 ---
Just reconfirmed with recent pre-4.5.0 HEAD:
$ /gnu/gcc/install-pr42811-3/opt/gcc-tools/bin/g++-4.exe -S vis.cpp -o vis.asm
vis.cpp:30:47: warning: visibility attribute not supported in this
configuration; ignored
--- Comment #8 from davek at gcc dot gnu dot org 2010-02-17 15:39 ---
Hello James, are you still experiencing this problem?
It looks to me like the xgcc driver program that you debugged was working ok,
but something failed when it launched the separate cc1 process. You might need
to
--- Comment #6 from gmorin1 at bloomberg dot net 2010-02-17 15:40 ---
Are you compiling with g++ and -O2? On the only 4.4 version I have access to
right now (gcc version 4.4.0 20090514 (Red Hat 4.4.0-6), I get:
$ g++44 -O2 -S test_expect.c
$ cat test_expect.s
(snip)
.globl
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-02-17 15:43 ---
This is the current patch under discussion:
http://gcc.gnu.org/ml/gcc/2010-02/msg00176.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42798
--- Comment #12 from kargl at gcc dot gnu dot org 2010-02-17 15:57 ---
(In reply to comment #10)
(NAG f95 v5.1 and g95 reject it unconditionally; ifort allows it by default
but
rejects it with -stand f95 or -stand f03.)
I think one should really send a interpretation request.
I
--- Comment #13 from kargl at gcc dot gnu dot org 2010-02-17 16:02 ---
(In reply to comment #11)
Replying to myself (comment #10):
I think one should really send a interpretation request.
I have now created one and sent it to Van.
Did you include the language from F2008 that
--- Comment #6 from amonakov at gcc dot gnu dot org 2010-02-17 16:32
---
Handle ADDR_EXPR in SCEV
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00666.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41998
--- Comment #31 from mmitchel at gcc dot gnu dot org 2010-02-17 16:49
---
I still have no idea what this PR is about. Someone needs to make a clear
statement of what they believe the ABI to be. There are some simple questions:
* Can we expect that the stack is 16-byte aligned, or
--- Comment #22 from mmitchel at gcc dot gnu dot org 2010-02-17 16:52
---
I don't think we really know enough yet to understand whether this is a bug, or
if it is a bug, where the bug might lie. So, we certainly can't make it P1,
ignoring even the fact that this test is in Fortran.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42648
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42729
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
--- Comment #7 from mmitchel at gcc dot gnu dot org 2010-02-17 16:56
---
I think this is a critical problem. If var-tracking is causing factor-of-N
increases in memory usage, then we need an algorithmic change that prevents
that, even if that means inferior debug information. We're
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43065
--- Comment #1 from mmitchel at gcc dot gnu dot org 2010-02-17 16:58
---
I take the P1 setting back; I failed to recognize the use of
-fgraphite-identity. As long as that's not a default setting, I don't think
problems there should be P1.
--
mmitchel at gcc dot gnu dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43070
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43096
The attached Ada program outputs RADPR RADSSR when compiled as:
gnatmake -Wall -O0 -v test_main -o ada_test
but generates raised CONSTRAINT_ERROR : radar_types.adb:11 range check failed
when compiled as:
gnatmake -Wall -O1 -v test_main -o ada_test
OS is OpenSuse 11.2.
gcc -v:
Using built-in
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43097
--- Comment #1 from neven at hitt dot nl 2010-02-17 17:07 ---
Created an attachment (id=19896)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19896action=view)
concatenated Ada source files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43106
--- Comment #32 from hjl dot tools at gmail dot com 2010-02-17 17:09
---
(In reply to comment #31)
I still have no idea what this PR is about. Someone needs to make a clear
statement of what they believe the ABI to be. There are some simple
questions:
* Can we expect that the
--- Comment #3 from uramakrishna at gmail dot com 2010-02-17 17:13 ---
Is this bug still around (r156830)? I have a 64 bit linux machine and it seems
to be fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43026
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27016
--- Comment #13 from mmitchel at gcc dot gnu dot org 2010-02-17 17:15
---
I reluctantly agree with Ian's comment in:
http://gcc.gnu.org/ml/gcc/2010-01/msg00332.html
that:
I think it would be troubling if a gcc release required a very new
binutils release on a popular platform like
--- Comment #44 from mmitchel at gcc dot gnu dot org 2010-02-17 17:20
---
As I understand it, this is an Alpha-specific problem. It may have an
Alpha-independent solution, but only users on Alpha will be affected. So, I've
downgraded this to P5.
--
mmitchel at gcc dot gnu dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42502
--- Comment #33 from joseph at codesourcery dot com 2010-02-17 17:24
---
Subject: Re: [4.4/4.5 Regression] zlib segfault in
inflate_table() compiled w/ -O -msse2 ftree-vectorize
I believe the ABI *is* that the stack must be 16-byte aligned at function
boundaries, although this is
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42505
--- Comment #5 from mmitchel at gcc dot gnu dot org 2010-02-17 17:27
---
Do we have any evidence that this is actually a regression? If this test has
never worked on IA64/HPPA, then this is not a regression. It should then be
XFAIL'd on those platforms, with this PR left open.
--
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42851
--- Comment #4 from zsojka at seznam dot cz 2010-02-17 17:33 ---
r156830 still crashes for me, both at x86 and x86_64 (with -m32)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43026
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43055
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43069
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43076
--- Comment #3 from mmitchel at gcc dot gnu dot org 2010-02-17 17:38
---
I think we need to understand Steven's comment that ipa-struct-reorg is
broken. This pass isn't on by default, AFAICT, so that decreases it's risk.
But, if it's broken-by-design, as opposed to has-a-few-bugs,
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43101
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
--- Comment #3 from mmitchel at gcc dot gnu dot org 2010-02-17 17:42
---
Richard, is this fixed now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43074
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43066
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43079
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43093
--- Comment #10 from mmitchel at gcc dot gnu dot org 2010-02-17 17:51
---
IIUC, this is not a regression.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143
--- Comment #11 from 0xe2 dot 0x9a dot 0x9b at gmail dot com 2010-02-17
17:52 ---
(In reply to comment #10)
Please stop reopening. 6.3.1.3 is about casts between integer types.
Signed integer overflow is even mentioned as an example of undefined behavior
in 3.4.3.
Well, look,
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431
--- Comment #11 from paolo dot carlini at oracle dot com 2010-02-17 17:57
---
Mark, with your permission, I'm restoring P3: indeed, strictly speaking the
failure of that specific testcase isn't a regression, because it didn't exist
in gcc4.4.x, but I understand it uncovered a rather
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-17 17:58
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from sje at cup dot hp dot com 2010-02-17 18:03 ---
I tried the test with GCC 4.4.0 and 4.3.3 on IA64, in those cases the test
failed because we didn't actually pack anything and then the if test failed and
we called abort.
$ /opt/hp-gcc-4.3.3/bin/g++ -Wpacked packed1.C
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-02-17 18:12
---
Use -fwrapv if you want signed integer overflow being defined the way you want
it being defined. That is the whole point of that flag. The reason why GCC
acts the way it acts by default is to allow more
--- Comment #34 from jakub at gcc dot gnu dot org 2010-02-17 19:31 ---
Yeah, I completely agree with that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-02-17 20:17
---
Tobias, reply to your RFC on fortran list. I think the negative check should
go away. Then I think we should consider an option of -fcheck-mem-alloc which
we can then make more elaborate and do numerouse useful
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
Command line:
gcc -O3 -mavx -c testcase.c
Tested revisions:
r156830 - crash
r156745 - crash
r156293 - crash
r155966 - OK (release checking)
r155609 - OK
r154830 - OK
r153685 - OK
4.4 r156256 - OK (with checking)
4.4 r153668 - OK
Valgrind output:
==1002== Command:
--- Comment #1 from zsojka at seznam dot cz 2010-02-17 20:51 ---
Created an attachment (id=19897)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19897action=view)
reduced testcase
gcc -O3 -mavx -c pr43107.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43107
50 | ./a.out
...
user0m8.825s
*** gcc 4.5.0 20100217 (revision 156834):
$ g++ -O2 test.cpp time echo 50 | ./a.out
...
user0m28.574s # Aaargh!!!
$ g++ -DUSE_MY_CMULT -O2 test.cpp time echo 50 | ./a.out
...
user0m8.817s
=== analysis ===
The libstdc
--- Comment #1 from jan at epgmod dot phys dot tue dot nl 2010-02-17 21:05
---
Created an attachment (id=19898)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19898action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
1 - 100 of 155 matches
Mail list logo
