This is a fallout from PR31198.
Using
a = MAX(1,2, a1, a2)
where a1 and a2 are optional arguments: If both a1 and a2 are not present,
gfortran gives a bogus run-time error message:
Fortran runtime error: Second argument of 'max' intrinsic should be present
Looking at the dump, gfortran
--- Comment #9 from bje at gcc dot gnu dot org 2007-08-17 06:49 ---
Fixed in r127578.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aldot at gcc dot gnu dot org
|dot org
Compile the following program with -O3 on FreeBSD or Linux, x86:
///
#include stdlib.h
#include string.h
register long foo asm(esi);
register long bar asm(edi);
char * crash_me_baby(char *str) {
char *path = malloc(1024 + strlen(str));
return path;
}
--- Comment #1 from slava at factorcode dot org 2007-08-17 07:56 ---
Created an attachment (id=14068)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14068action=view)
Test case
This is a test case for the bug. Compile with -O1, -O2 or -O3 to trigger it.
With -O0, it compiles fine.
--- Comment #10 from burnus at gcc dot gnu dot org 2007-08-17 08:14 ---
Rejecting operator(.procedure.) has been fixed by PR33072.
Accepting multiple renames/imports of an operator (operator(.op.),
operator(.myop.)=operator(.op.)) is fixed by the submitted patch
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 09:15 ---
Fixed by:
2007-08-14 Daniel Berlin [EMAIL PROTECTED]
* tree-pass.h (PROP_pta): Removed.
(TODO_rebuild_alias): New.
(pass_may_alias): Removed.
* tree-ssa-ccp.c
--- Comment #15 from manu at gcc dot gnu dot org 2007-08-17 09:17 ---
This seems to me a duplicate of PR179. I am going to add a dependency to
remember to check this PR when PR179 gets fixed.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pcarlini at suse dot de 2007-08-17 09:23 ---
Hi Volker. I will be away for some days on vacations... In the meanwhile, if
you could double check that we really want the fix for 27211 (not a regression)
on the branches and, in case, take care of the backport, it would
--- Comment #2 from paolo at gcc dot gnu dot org 2007-08-17 09:27 ---
Subject: Bug 33084
Author: paolo
Date: Fri Aug 17 09:27:06 2007
New Revision: 127579
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127579
Log:
2007-08-17 Johannes Willkomm [EMAIL PROTECTED]
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 09:27 ---
For one, I don't think __real__ X = R; __imag__ X = C; is really nice
looking. Now if the person did:
*(double*) X = R; ((double*) X)[1] = C;
it might be a different story but then again X is still defined
--- Comment #3 from paolo at gcc dot gnu dot org 2007-08-17 09:28 ---
Subject: Bug 33084
Author: paolo
Date: Fri Aug 17 09:28:09 2007
New Revision: 127580
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127580
Log:
2007-08-17 Johannes Willkomm [EMAIL PROTECTED]
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 09:29 ---
/* An in-class declaration of a static data member should be
external; it is only a declaration, and not a definition. */
if (init == NULL_TREE)
gcc_assert (DECL_EXTERNAL (decl));
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-17 09:03
---
*** Bug 33096 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 09:03 ---
*** This bug has been marked as a duplicate of 11001 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from paolo at gcc dot gnu dot org 2007-08-17 09:35 ---
Subject: Bug 32870
Author: paolo
Date: Fri Aug 17 09:35:23 2007
New Revision: 127581
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127581
Log:
/cp
2007-08-17 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from pcarlini at suse dot de 2007-08-17 09:36 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pcarlini at suse dot de 2007-08-17 09:30 ---
Fixed for 4.2.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from manu at gcc dot gnu dot org 2007-08-17 10:15 ---
(In reply to comment #3)
void use(const int *a)
{
int *b = (int*)a;
Andrew, you are right. I tend to forget how fragile is 'const', even in C++.
So, then this is invalid and thus it is PR10138.
--
--- Comment #5 from pcarlini at suse dot de 2007-08-17 10:22 ---
This is now fixed both in mainline and in 4_2-branch:
32190.C: In function 'int main()':
32190.C:5: error: template argument 1 is invalid
at this point, not being a regression, I think we can close it.
--
pcarlini at
--- Comment #6 from manu at gcc dot gnu dot org 2007-08-17 10:24 ---
(In reply to comment #5)
This is now fixed both in mainline and in 4_2-branch:
32190.C: In function 'int main()':
32190.C:5: error: template argument 1 is invalid
at this point, not being a regression, I think
--- Comment #7 from pcarlini at suse dot de 2007-08-17 10:26 ---
Sure, I'll take care of that...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
--- Comment #8 from manu at gcc dot gnu dot org 2007-08-17 10:28 ---
Ivan, would you like to write, test and post the testcase? Once it is approved
I can commit it for you (with your name of course!).
A starting point will be http://gcc.gnu.org/wiki/HowToPrepareATestcase, if you
need
--- Comment #9 from igodard at pacbell dot net 2007-08-17 10:37 ---
Subject: Re: wrong error recovery on parsing template arguments
Begging your pardon, but what's wrong with the one I put in already?
Ivan
manu at gcc dot gnu dot org wrote:
--- Comment #8 from manu at gcc dot
--- Comment #2 from joseph at codesourcery dot com 2007-08-17 10:37 ---
Subject: Re: [4.1/4.2/4.3 Regression] spurious exceptions
with -ffloat-store
On Fri, 17 Aug 2007, pinskia at gcc dot gnu dot org wrote:
For one, I don't think __real__ X = R; __imag__ X = C; is really nice
--- Comment #10 from manu at gcc dot gnu dot org 2007-08-17 10:50 ---
(In reply to comment #9)
Subject: Re: wrong error recovery on parsing template arguments
Begging your pardon, but what's wrong with the one I put in already?
Nothing is wrong, but to be useful for GCC
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-17 11:24
---
Oh, sh**, I didn't think about simplification. Well, I don't see an easy way to
have error messages at runtime, so we should simply skip those. We won't have
any diagnostic, but no compiler that I know of does
--- Comment #4 from raselmsh at hotmail dot com 2007-08-17 12:04 ---
I took a look at ccache again, and it is definitely not what I was thinking of.
ccache is more aimed at accelerating multiple full compile rounds of the same
package, whereas I was thinking of improving dependency
Recently I discovered, that gfortran FE creates invalid decl trees for exteranl
intrinsics: only return value is added to arg chain, and none of the actual
arguments. This can potentially break much stuff, because of inconsistency of
CALL_EXPR and corresponding fndecl.
This was due to the
--- Comment #1 from asl at math dot spbu dot ru 2007-08-17 12:42 ---
Created an attachment (id=14069)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14069action=view)
Quick and dirty patch
Attached is quick and dirty patch to populate symbol with arguments. It seems
to be
--- Comment #9 from wouter dot vermaelen at scarlet dot be 2007-08-17
12:44 ---
Here is a simpler testcase:
int f(int i) { return 100LL / (1 + i); }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
--- Comment #2 from asl at math dot spbu dot ru 2007-08-17 12:49 ---
Quick example of the problem:
function_decl 0x4bf6d00 _gfortran_matmul_r4
type function_type 0x52495a0
type void_type 0x4419840 void VOID
align 8 symtab 6 alias set -1
LLVM:
--- Comment #10 from zadeck at naturalbridge dot com 2007-08-17 12:48
---
Subject: Re: [4.3 Regression] ICE with -O2 -fsee
wouter dot vermaelen at scarlet dot be wrote:
--- Comment #9 from wouter dot vermaelen at scarlet dot be 2007-08-17
12:44 ---
Here is a simpler
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-08-17 13:09
---
Subject: Bug 33079
Author: fxcoudert
Date: Fri Aug 17 13:09:23 2007
New Revision: 127584
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127584
Log:
PR fortran/33079
*
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-17 13:10
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-17 13:21 ---
Oh, sh**, I didn't think about simplification.
Well, I don't see an easy way to
have error messages at runtime, so we should simply skip those.
Good idea. As long as the compiler does the right thing (TM) we
--- Comment #2 from ian at airs dot com 2007-08-17 14:31 ---
This patch fixes the problem and passes the g++ testsuite.
Index: cp/decl.c
===
--- cp/decl.c (revision 127491)
+++ cp/decl.c (working copy)
@@ -4963,7
--- Comment #11 from patchapp at dberlin dot org 2007-08-17 15:10 ---
Subject: Bug number PR31298
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01081.html
--
--- Comment #4 from patchapp at dberlin dot org 2007-08-17 15:10 ---
Subject: Bug number PR32875
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01077.html
--
--- Comment #6 from pcarlini at suse dot de 2007-08-17 15:30 ---
I guess we can indeed close this one as fixed in mainline...
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2007-08-17 15:37 ---
FWIW, Comeau gives very similar errors:
ComeauTest.c, line 3: error: incomplete type is not allowed
union B b;
^
ComeauTest.c, line 6: error: tag kind of class or struct is incompatible with
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure CC=gcc43 CXX=g++43 --program-suffix=43
--disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 20070816 (experimental)
The following code:
#include type_traits
int main() {
bool b =
--- Comment #1 from chris dot fairles at gmail dot com 2007-08-17 15:48
---
Created an attachment (id=14070)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14070action=view)
patch to fix compile error when using pointers with is_convertible
--
--- Comment #2 from chris dot fairles at gmail dot com 2007-08-17 15:48
---
Created an attachment (id=14071)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14071action=view)
test case that gives compile error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33098
--- Comment #5 from patchapp at dberlin dot org 2007-08-17 15:10 ---
Subject: Bug number PR32881
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01078.html
--
--- Comment #2 from pcarlini at suse dot de 2007-08-17 16:15 ---
This is fixed in the active branches. Now the diagnostic is:
18207.C: In constructor 's::s()':
18207.C:8: error: no matching function for call to 'm::m()'
18207.C:4: note: candidates are: m::m(const m)
18207.C: In
--- Comment #4 from paolo at gcc dot gnu dot org 2007-08-17 16:39 ---
Subject: Bug 33098
Author: paolo
Date: Fri Aug 17 16:39:10 2007
New Revision: 127588
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127588
Log:
2007-08-17 Chris Fairles [EMAIL PROTECTED]
PR
--- Comment #11 from igodard at pacbell dot net 2007-08-17 17:25 ---
Subject: Re: wrong error recovery on parsing template arguments
Seems impractical. I don't have access to the old versions or mainline,
and don't know what magic to put in the source for your system to use.
I'm
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pcarlini at suse dot de 2007-08-17 16:31 ---
Yes, let's patch-up this, but really I have to finish the builtin, this is only
temporary.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from pcarlini at suse dot de 2007-08-17 16:40 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from drow at gcc dot gnu dot org 2007-08-17 17:24 ---
Subject: Bug 31884
Author: drow
Date: Fri Aug 17 17:24:22 2007
New Revision: 127590
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127590
Log:
PR testsuite/31884
*
--- Comment #12 from pcarlini at suse dot de 2007-08-17 18:09 ---
Hi Giovanni, any update on this?
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from janis at gcc dot gnu dot org 2007-08-17 18:21 ---
Current mainline (revision 127590) still gets this ICE for i686-pc-linux-gnu
with either bid or dpd decimal float support. The current line number for the
ICE is reload1.c:2001.
--
The following test case is miscompiled with GCC 4.2:
extern void abort (void);
volatile int N = 5;
void foo (void)
{
int i;
char *p, value[10];
value[0] = 0x42;
for (i = 0; i N; i++)
if (i 0)
{
p = (char *)i - 1;
*(value + (int) p) = (char) i;
}
if
--- Comment #8 from patchapp at dberlin dot org 2007-08-17 20:15 ---
Subject: Bug number PR20441
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01151.html
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 20:18 ---
Confirmed (and yes this was fixed by PtrPlus).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 20:20 ---
Exposed by:
2006-02-07 Jeff Law [EMAIL PROTECTED]
Which added VRP after IV-OPTs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dnovillo at google dot com 2007-08-17 20:27 ---
Subject: Re: [4.2 Regression] Scalar evolutions
confusing VRP with pointer values that wrap around
On 8/17/07 4:20 PM, pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-17 20:34 ---
Oh you are correct but this still worked in 4.1.1 though, I have not looked
into what changed between 4.1.1 and 4.2.0 with respect of scev yet.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #5 from dnovillo at google dot com 2007-08-17 20:37 ---
Subject: Re: [4.2 Regression] Scalar evolutions
confusing VRP with pointer values that wrap around
On 8/17/07 4:34 PM, pinskia at gcc dot gnu dot org wrote:
--- Comment #4 from pinskia at gcc dot gnu dot org
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-17 20:42 ---
The IR is the same but scev did something different:
Visiting statement:
p_10 = i.0_9 - 1B;
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = p_10)
(get_scalar_evolution
(scalar = p_10)
(scalar_evolution
--- Comment #5 from janis at gcc dot gnu dot org 2007-08-17 20:44 ---
Why use %.9e, %.17e, and %.36Le to write the binary float values to a
string, instead of using lengths of FLT_DIG, DBL_DIG, and LDBL_DIG? For
i686-linux those are 6, 15, and 18.
--
--- Comment #3 from paolo at gcc dot gnu dot org 2007-08-17 20:47 ---
Subject: Bug 32112
Author: paolo
Date: Fri Aug 17 20:46:59 2007
New Revision: 127596
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127596
Log:
/cp
2007-08-17 Paolo Carlini [EMAIL PROTECTED]
PR
I now get this during bootstrap on Solaris x86 using the native linker
(/usr/ccs/bin/ld):
ld: fatal: unwind table: file
/u01/var/tmp/gcc_trunk_svn/gcc_20070817/./gcc/amd64/crtend.o: section
.eh_frame: bad cie version 0: offset 0x0
collect2: ld returned 1 exit status
gmake[5]: *** [libgcc_s.so]
--- Comment #12 from paolo at gcc dot gnu dot org 2007-08-17 21:31 ---
Subject: Bug 32190
Author: paolo
Date: Fri Aug 17 21:31:40 2007
New Revision: 127597
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127597
Log:
2007-08-17 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #1 from tromey at gcc dot gnu dot org 2007-08-17 21:32 ---
Looks like directives.c:parse_include is not handling the
dependency case correctly.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from paolo at gcc dot gnu dot org 2007-08-17 21:38 ---
Subject: Bug 32190
Author: paolo
Date: Fri Aug 17 21:38:19 2007
New Revision: 127598
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127598
Log:
2007-08-17 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #14 from paolo at gcc dot gnu dot org 2007-08-17 21:38 ---
Subject: Bug 32190
Author: paolo
Date: Fri Aug 17 21:38:40 2007
New Revision: 127599
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127599
Log:
2007-08-17 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #15 from pcarlini at suse dot de 2007-08-17 21:40 ---
Already fixed in 4_2-branch and mainline.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #8 from aaw at gcc dot gnu dot org 2007-08-17 21:42 ---
Subject: Bug 31749
Author: aaw
Date: Fri Aug 17 21:42:38 2007
New Revision: 127600
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127600
Log:
PR c++/31749
gcc/cp/
* name-lookup.c
--- Comment #2 from tromey at gcc dot gnu dot org 2007-08-17 22:08 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-17 22:15
---
Fixed on the trunk.
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-08-17 22:15
---
Subject: Bug 28989
Author: pinskia
Date: Fri Aug 17 22:14:47 2007
New Revision: 127603
URL:
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-17 22:15
---
Fixed on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known
This C++ test case works with gcc 4.1.1. With gcc 4.2 and with mainline it
gets an inexplicable error.
typedef void v;
typedef v (*pf)(v);
foo.cc:2: error: anonymous has incomplete type
foo.cc:2: error: invalid use of v
--
Summary: C++ error on valid code: anonymous has
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 23:33 ---
This is not valid code.
*** This bug has been marked as a duplicate of 9278 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from pinskia at gcc dot gnu dot org 2007-08-17 23:33
---
*** Bug 33101 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Source code:
--
volatile int i;
int j;
int testme(void)
{
return i = 1;
}
int testme2(void)
{
return j = 1;
}
--
Compiler command line: cc -S -O torvalds.c
--
Expected results: volatile accesses not moved past sequence points,
optimization
--- Comment #2 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
00:11 ---
Hmmm... I wasn't asking for volatile to be atomic, just for it to avoid
generating unnecessary code.
--
paulmck at linux dot vnet dot ibm dot com changed:
What|Removed
--- Comment #3 from segher at kernel dot crashing dot org 2007-08-18 00:12
---
(In reply to comment #1)
volatile != atomic.
And that is relevant why? Paul is perfectly aware of this, btw.
There might be other reasons why GCC doesn't want to do this
optimisation, but this isn't one
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-18 00:12 ---
It is still the same issue.
*** This bug has been marked as a duplicate of 3506 ***
*** This bug has been marked as a duplicate of 3506 ***
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-18 00:12
---
*** Bug 33102 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-18 00:21 ---
omewhat also related, (void)x; still accesses memory when x is volatile --
I suppose this might be desirable, however.
It is because you say to load from x.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-18 00:05 ---
volatile != atomic.
*** This bug has been marked as a duplicate of 3506 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-18 00:05
---
*** Bug 33102 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from segher at kernel dot crashing dot org 2007-08-18 00:31
---
It is still the same issue.
*** This bug has been marked as a duplicate of 3506 ***
It isn't the same issue. The submitter of #3506 claimed the code
that GCC currently generates is incorrect, which
--- Comment #6 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:04 ---
(In reply to comment #4)
It is still the same issue.
Perhaps I am missing something, but I don't know of any hardware that would
react differently to this two-instruction sequence:
movli,
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-18 01:10 ---
One should note this is actually hard to do without changing the code for 3506
also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-18 01:11 ---
PS you should have reported this first to debian since you are using their
modified version of GCC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-18 01:12 ---
s/debian/Ubuntu/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-18 01:13
---
Actually as I understand it, the expanded version is slightly faster under
newer x86's anyways as they don't have an extra decode stage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
--- Comment #11 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:21 ---
(In reply to comment #10)
Actually as I understand it, the expanded version is slightly faster under
newer x86's anyways as they don't have an extra decode stage.
The main concern on the recent LKML
--- Comment #12 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:23 ---
(In reply to comment #9)
s/debian/Ubuntu/
Please accept my apologies for skipping that step -- I wasn't aware of this.
Should I replicate this bug at Ubuntu, or is this strictly advice for future
bug
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-08-18 01:25
---
(In reply to comment #11)
The main concern on the recent LKML thread appeared to be code size rather
than
speed.
One should note this only helps CISC based processors, it will not help stuff
like PowerPC
--- Comment #2 from ian at airs dot com 2007-08-18 04:19 ---
Thanks for the explanation. That is new to me.
I am now going to reopen this bug because the error message is terrible. There
is no anonymous or incomplete type here. gcc should perhaps print something
like
error: invalid
This report was prompted by a mail on the lkml which was suggesting to
hand-craft memset: http://lkml.org/lkml/2007/8/17/309 . So I wondered if the
code generated for __builtin_memset was any good, and could be used instead of
hand-crafted code. I tested with (Debian) GCC 3.4.6, 4.1.3, 4.2.1, and
96 matches
Mail list logo
