The following invalid code snippet triggers an ICE on mainline:
extern struct A a[1];
void foo()
{
a[0];
}
bug.cc: In function 'void foo()':
bug.cc:5: error: invalid use of incomplete type 'struct A'
bug.cc:1: error: forward declaration of
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37552
This code triggers an ICE in gcc-4.3.1 on i686 when compiled with g++:
typedef unsigned int ui32;
__extension__ typedef unsigned long long int ui64;
typedef ui32 __attribute__ ((__may_alias__)) ui32a;
typedef ui64 __attribute__ ((__may_alias__)) ui64a;
union u_u32
{
ui32a v;
} __attribute__
The following invalid code snippet triggers an ICE since GCC 4.3.0:
struct A {};
class B : A {};
void foo(B b)
{
(A)b;
}
bug.cc: In function 'void foo(B)':
bug.cc:6: error: 'A' is an inaccessible base of 'B'
bug.cc:6: internal compiler error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37554
The following invalid code snippet triggers an ICE since GCC 3.4.0:
struct A {};
typedef void (A::T)();
void foo()
{
T t;
t;
}
bug.cc:3: error: typedef name may not be a nested-name-specifier
bug.cc: In function 'void foo()':
bug.cc:8:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37555
The following invalid code snippet triggers an ICE on mainline:
struct A
{
void foo();
};
typedef void (A::T)();
void bar(T);
void baz()
{
bar(A::foo);
}
bug.cc:6: error: typedef name may not be a nested-name-specifier
bug.cc:8: error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37556
hi, recetly i found out something that is possible/probably bug in g++. so far
i have tested on 4.1.0 and 4.2.3. on previous versions there were no such error
(tried with 3.3.5).
here is brief description: i use string and wstring (and appropriate cin/cout
and wcin/wcout) in same console app that
--- Comment #4 from francois dot jacq at irsn dot fr 2008-09-17 07:18
---
Subject: Re: impossible to link with -fopenmp
Le mardi 16 septembre 2008 20:26, pinskia at gcc dot gnu dot org a écrit :
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-16 18:26
--- Did
--- Comment #17 from pault at gcc dot gnu dot org 2008-09-17 07:31 ---
(In reply to comment #16)
Lest anybody is worrying about the patch that I posted, I cannot commit until
tonight or tomorrow morning.
Since my laptop was stolen, I have no means to update my tree nor commit
anything
--- Comment #5 from francois dot jacq at irsn dot fr 2008-09-17 07:34
---
Subject: Re: impossible to link with -fopenmp
Le mardi 16 septembre 2008 20:50, dfranke at gcc dot gnu dot org a écrit :
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-09-16 18:50
---
--- Comment #5 from sam at gcc dot gnu dot org 2008-09-17 07:59 ---
Subject: Bug 21327
Author: sam
Date: Wed Sep 17 07:58:12 2008
New Revision: 140411
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140411
Log:
2008-09-17 Pascal Rigaux [EMAIL PROTECTED]
gcc/ada/
PR
--- Comment #6 from sam at gcc dot gnu dot org 2008-09-17 08:00 ---
Pascal's fix committed as trivial documentation fix in SVN trunk.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from jorn dot amundsen at ntnu dot no 2008-09-17 08:02
---
(In reply to comment #33)
Thank you for the tip on libtool libpath. Looking into it with dump -H, I did
not know it was that ugly. Indeed, this should be cleaned up if when building
and installing software.
In
--- Comment #6 from ubizjak at gmail dot com 2008-09-17 08:14 ---
cprop_hardreg pass is propagating DImode ax register, wrongly bypassing DI-SI
conversion.
Before cprop_hardreg, we have:
(call_insn/u:HI 27 88 28 4 pr37544.c:9 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:SI
--- Comment #7 from ubizjak at gmail dot com 2008-09-17 08:35 ---
(In reply to comment #5)
Confirmed on i686-linux with -std=c99 -O -msse2 -mfpmath=387 -march=i386.
Does not fail for x86_64-linux target with -m32 on x86_64-linux _and_
i686-linux hosts.
--
--- Comment #5 from pault at gcc dot gnu dot org 2008-09-17 08:55 ---
(In reply to comment #4)
4.3.2 is released, changing milestones to 4.3.3.
Although this passes Lahey with only a warning that the return value is not
set, it manifestly is standard defying according to 7.1.6.2
A
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-09-17 10:10
---
The problem in PR37385 is that we do not look at the canonical type in
get_alias_set, so we end up with a different alias set for the typedef
(which makes the behavior of get_alias_set inconsistent with the
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-17 10:28 ---
Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=138843
Any reason why you look at CALL_EXPR_FN's type instead of just TREE_TYPE
(expr)?
In this case TREE_TYPE (expr) is int, but CALL_EXPR_FN is COMPONENT_REF
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #8 from ubizjak at gmail dot com 2008-09-17 10:39 ---
The problem is in regrename.c, function maybe_mode_change. We enter the
function with:
orig_mode = DImode
copy_mode = SImode
new_mode = DImode
At the beginning of maybe_mode_change() we have:
if (orig_mode ==
--- Comment #2 from sam at gcc dot gnu dot org 2008-09-17 11:06 ---
You should sent a patch against the latest SVN trunk, so that it can be
reviewed.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-09-17 11:43
---
Subject: Bug 37385
Author: rguenth
Date: Wed Sep 17 11:42:11 2008
New Revision: 140412
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140412
Log:
2008-09-17 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-09-17 11:43
---
Subject: Bug 37491
Author: rguenth
Date: Wed Sep 17 11:42:11 2008
New Revision: 140412
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140412
Log:
2008-09-17 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from brian at dessent dot net 2008-09-17 11:44 ---
Subject: Re: impossible to link with -fopenmp
If you can't change your glibc version then you need to build gfortran
yourself from source. The problem is that the person that is building
the gfortran binary packages on
--- Comment #9 from ubizjak at gmail dot com 2008-09-17 11:48 ---
4.2 and 4.3 work OK.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Known to work|
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-09-17 11:43
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-17 11:57 ---
Subject: Bug 35770
Author: domob
Date: Wed Sep 17 11:56:09 2008
New Revision: 140413
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140413
Log:
2008-09-13 Daniel Kraft [EMAIL PROTECTED]
PR
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-17 11:59 ---
Fixed for trunk (4.4) and 4.3.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from ubizjak at gmail dot com 2008-09-17 12:01 ---
I'm testing following patch:
Index: regrename.c
===
--- regrename.c (revision 140409)
+++ regrename.c (working copy)
@@ -1314,6 +1314,9 @@
--- Comment #35 from dje at gcc dot gnu dot org 2008-09-17 12:22 ---
User reports successful resolution.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ro at gcc dot gnu dot org 2008-09-17 12:28 ---
Fixed for 4.4.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ro at gcc dot gnu dot org 2008-09-17 12:28 ---
Subject: Bug 37441
Author: ro
Date: Wed Sep 17 12:26:43 2008
New Revision: 140417
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140417
Log:
PR bootstrap/37441
* dwarf2out.c (dwarf2out_do_cfi_asm)
Gcc 4.4 used to accept the program
---
class Foo {
friend class Bar;
friend void func(const class Bar*);
};
--
since 140120 it does not.
Simon found the following:
gcc 2.95.3, 3.4.5 and icc accept it. Previous versions
When I compile and run the following code in my debug build using GCC 4.0.1 on
an Intel Mac (OSX10.5) I find that the pow() function returns NaN whereas in
the release build it works as expected. When using the powf() function it works
as expected.
const float dBgain = -2.75750828f;
const double
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-09-17 14:25
---
Ok, so I think we should be fine if we ignore PHI nodes with zero-use results
during building the elimination graph - chained unused PHIs will have lifeness
computed for all but the PHI node with the zero-use
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37555
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37554
In the following program, the type of the assignment expression f.x = 1
should be int, according to the integer promotion rules.
However, gcc 4.xx (on all architectures I've tested) prints 1.
#include stdio.h
int main()
{
struct foo { int x:1; } f;
printf(%u\n, sizeof(f.x = 1));
--- Comment #13 from amacleod at redhat dot com 2008-09-17 14:34 ---
I was in the middle of updating this PR and taking possesion :-)
Upon further reflection, I don't think it is acceptable for out-of-ssa to
generate incorrect code simply because an optimization wasn't run before it.
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-17 14:34 ---
*** Bug 37310 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-09-17 14:34
---
I think this is a duplicate of PR36747 as I no longer can reporduce this with
4.3.2.
*** This bug has been marked as a duplicate of 36747 ***
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-09-17 14:38
---
Hm, it doesn't work - bootstrap fails as gengtype segfaults.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37102
--- Comment #15 from amacleod at redhat dot com 2008-09-17 14:39 ---
Created an attachment (id=16343)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16343action=view)
potential patch 1
This is the first option which simply doesn't add the result of a PHI with no
uses to the
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37260
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-09-17 14:46 ---
Created an attachment (id=16344)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16344action=view)
patch disabling TBAA pruning
This is the patch we use for openSUSE to fix this bug.
--
--- Comment #16 from amacleod at redhat dot com 2008-09-17 14:48 ---
Created an attachment (id=16345)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16345action=view)
Potential patch #2
This is the other option, eliminate dead PHIs. compiling all of GCC .c files
at -O3, it finds a
bash-3.2$ cat g++.old-deja/g++.mike/warn1.C
// { dg-do assemble }
// { dg-options -Wall }
typedef char * charptr;
typedef __SIZE_TYPE__ size_t;
char c[]={'A','B','C','D'};
int i=size_t(c);
int *pp=i;
void foo() { }
int main()
{
charptr(*pp)++;// { dg-warning }
return 0;
}
bash-3.2$
--- Comment #1 from joseph at codesourcery dot com 2008-09-17 14:50 ---
Subject: Re: New: bitfield not promoted to int
On Wed, 17 Sep 2008, clemens at ladisch dot de wrote:
In the following program, the type of the assignment expression f.x = 1
should be int, according to the
--- Comment #37 from hubicka at gcc dot gnu dot org 2008-09-17 15:02
---
Subject: Bug 18071
Author: hubicka
Date: Wed Sep 17 15:00:59 2008
New Revision: 140418
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140418
Log:
PR c++/18071
* tree.h (DECL_INLINE): remove.
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-09-17 15:07
---
This is the patch we use for openSUSE to fix this bug.
Any particular reason for not installing it at the FSF as well?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from rguenther at suse dot de 2008-09-17 15:10 ---
Subject: Re: [4.3 Regression] Wrong code due
to bad TBAA pruning of points-to-sets and use in call clobbering
On Wed, 17 Sep 2008, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #7 from ebotcazou at gcc dot
--- Comment #2 from clemens at ladisch dot de 2008-09-17 15:11 ---
According to the proposed TC in DR 315 (If an int can represent all values of
the original type (as restricted by the width, for a bit-field), the type is
converted to an int;),
--
clemens at ladisch dot de changed:
--- Comment #1 from jakub at gcc dot gnu dot org 2008-09-17 15:12 ---
I guess the problem might be that Fortran has signed size_type_node (and
unsigned
sizetype), so what the newly added code in int_fits_type_p does breaks Fortran
assumptions. Say for sizetype -25 (i.e. unsigned
--- Comment #7 from bonzini at gnu dot org 2008-09-17 15:17 ---
Do you have a missed optimization for optimizing the functions to return 1?
Or does your patch fix it too?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-17 15:19 ---
GCC 4.0.1 is no longer supported by the FSF. Please update to at least GCC
4.2.4
and re-check if the problem is fixed. You may also want to report to Apple
instead which is known to heavily modify their compilers.
--- Comment #9 from luisgpm at linux dot vnet dot ibm dot com 2008-09-17
15:22 ---
Gathered some PPC 32/64 performance numbers with the patch (based on 140409).
No noticeable performance regressions were found. 32-bit swin and 64-bit art
had a little boost on speed (7.8% and 3.4%
--- Comment #8 from rguenther at suse dot de 2008-09-17 15:24 ---
Subject: Re: [4.4 Regression] ICE in in
simplify_truth_ops_using_ranges, at tree-vrp.c:6334
On Wed, 17 Sep 2008, bonzini at gnu dot org wrote:
--- Comment #7 from bonzini at gnu dot org 2008-09-17 15:17 ---
typedef unsigned int UInt32;
typedef unsigned char UInt8;
struct Data
{
UInt8 data[16];
const UInt8* getData() const
{
return data + 4;
}
};
struct Value {
UInt32 value;
static void update (Value signal, const Data source, UInt32 startBit);
};
void Value::update(Value signal,
--- Comment #1 from rbuergel at web dot de 2008-09-17 15:44 ---
oops, i forgot to mention my command line to compile it:
powerpc-linux-g++ -O3 -funroll-loops -c -o GetBytes2.o GetBytes2.cpp
using -O3 is important for reproducing this error
--
--- Comment #3 from joseph at codesourcery dot com 2008-09-17 15:55 ---
Subject: Re: bitfield not promoted to int
On Wed, 17 Sep 2008, clemens at ladisch dot de wrote:
According to the proposed TC in DR 315 (If an int can represent all values of
the original type (as restricted by
--- Comment #1 from janis at gcc dot gnu dot org 2008-09-17 16:00 ---
I tested with -m32 on powerpc64-linux, not with both -m32/-m64 which would have
caught this; I'll test with both for related patches.
The test previously used { dg-warning }, which matched any message from that
The following valid code snippet is rejected since GCC 4.3.0:
==
struct A {};
templateint struct Traits
{
typedef void X;
};
template struct Traits0
{
typedef A X;
};
templateint N struct B
{
typedef typename TraitsN::X Y;
void foo(Y y)
{
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37563
Hello,
From the terminal, I many lines that look similar to:
.libs/in_unpack_generic.o(.text+0x820): In function `getline':
/usr/include/bits/stdio.h:103: multiple definition of `getline'
.libs/backtrace.o(.text+0xbc0):/usr/include/bits/stdio.h:103: first defined
here
--- Comment #1 from reuben dot kraft at gmail dot com 2008-09-17 16:04
---
Created an attachment (id=16346)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16346action=view)
x86_64-unknown-linux-gnu/libgfortran/config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37564
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-17 16:06 ---
Subject: Bug 37324
Author: jakub
Date: Wed Sep 17 16:05:11 2008
New Revision: 140421
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140421
Log:
PR preprocessor/37324
* lib/target-supports.exp
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-17 16:07 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from jakub at gcc dot gnu dot org 2008-09-17 16:08 ---
Subject: Bug 37552
Author: jakub
Date: Wed Sep 17 16:07:08 2008
New Revision: 140422
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140422
Log:
PR c++/37552
* typeck.c (build_array_ref): Use
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-17 16:10 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from hjl dot tools at gmail dot com 2008-09-17 16:11 ---
(In reply to comment #1)
I tested with -m32 on powerpc64-linux, not with both -m32/-m64 which would
have
caught this; I'll test with both for related patches.
The test previously used { dg-warning }, which
--- Comment #1 from jason at gcc dot gnu dot org 2008-09-17 16:12 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from jason at gcc dot gnu dot org 2008-09-17 16:13 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from ubizjak at gmail dot com 2008-09-17 16:13 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01221.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from jason at gcc dot gnu dot org 2008-09-17 16:14 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from jason at gcc dot gnu dot org 2008-09-17 16:19 ---
This doesn't have anything to do with accessibility, but it is a new bug.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Sent from my iPhone
On Sep 17, 2008, at 8:42 AM, rbuergel at web dot de [EMAIL PROTECTED]
wrote:
typedef unsigned int UInt32;
typedef unsigned char UInt8;
struct Data
{
UInt8 data[16];
const UInt8* getData() const
{
return data + 4;
}
};
struct Value {
UInt32 value;
static
--- Comment #2 from pinskia at gmail dot com 2008-09-17 16:52 ---
Subject: Re: New: [4.2] -funroll-loops destroys inline asm code von powerpc
Sent from my iPhone
On Sep 17, 2008, at 8:42 AM, rbuergel at web dot de [EMAIL PROTECTED]
wrote:
typedef unsigned int UInt32;
typedef
--- Comment #3 from janis at gcc dot gnu dot org 2008-09-17 17:02 ---
This is twisting my brain, but in this simplified testcase:
__PTRDIFF_TYPE__ p;
short q;
void foo () { ((char *)p)++; }
void bar () { ((char *)q)++; }
we get an error with both -m32 and-m64 for foo but not
--- Comment #2 from jason at gcc dot gnu dot org 2008-09-17 17:31 ---
Fixed
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from paolo dot carlini at oracle dot com 2008-09-17 17:35
---
Thanks for catching this early, apparently this is a fundamental issue with the
current proposal: having such overloads returning const refs to elements of the
initializer_list is a very bad idea, because the
--- Comment #4 from janis at gcc dot gnu dot org 2008-09-17 17:38 ---
The same thing happens in C for the simplified testcase; z.c is a copy of z.C
from comment #3:
elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -c -m32 z.c
z.c: In function foo:
z.c:3: error: lvalue
--- Comment #13 from lucier at math dot purdue dot edu 2008-09-17 17:49
---
In the attached statistics file you find where this allocation overflowed
Alloc-pool KindPools Allocated PeakLeak
-
df_scan_ref
--- Comment #3 from hjl at gcc dot gnu dot org 2008-09-17 17:58 ---
Subject: Bug 37450
Author: hjl
Date: Wed Sep 17 17:57:24 2008
New Revision: 140425
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140425
Log:
2008-09-17 H.J. Lu [EMAIL PROTECTED]
PR c++/37450
*
--- Comment #4 from hjl dot tools at gmail dot com 2008-09-17 17:59 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #8 from hjl dot tools at gmail dot com 2008-09-17 18:06 ---
It may also impact PR 37283.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37394
--- Comment #3 from rbuergel at web dot de 2008-09-17 18:46 ---
The second constraint should be using b instead of r as b says
don't use r0.
Is this documented anywhere? The gcc manual says r means any general purpose
register and b means Address base register. Any Documentation (for
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-17 18:50 ---
From:
http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Machine-Constraints.html#Machine-Constraints
b
Address base register
Address base register is the standard saying rN or 0 (if r0 is used). This is
just the way
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-17 18:53 ---
Did you compile in the source directory? If so, don't. It is not well
supported and it is currently known to be broken for this same reason, see PR
35619.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37564
--- Comment #5 from rbuergel at web dot de 2008-09-17 18:57 ---
Too bad for newbies to ppc asm. :)
But thank you for your explanations
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37562
--- Comment #3 from reuben dot kraft at gmail dot com 2008-09-17 19:04
---
Do you mean do not run make from gcc-4.3.1 ? Or do mean do not set prefix to
gcc-4.3.1 ?
Currently I run make from /home/rkraft/apps/gcc-4.3.1 and I set prefix to
/home/rkraft/apps/gcc4
Here is my configure:
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-17 19:06 ---
You can also use __builtin_bswap32 in GCC 4.3 and above which gives you the
best code generation as it understands loading from memory and if the value is
in a register already.
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-17 19:07 ---
Please read http://gcc.gnu.org/install/configure.html:
First, we highly recommend that GCC be built into a separate directory than the
sources which does not reside within the source tree. This is how we generally
--- Comment #23 from pinskia at gcc dot gnu dot org 2008-09-17 19:07
---
*** Bug 37564 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2008-09-17 19:08 ---
Currently I run make from /home/rkraft/apps/gcc-4.3.1
Here is my configure:
./configure --prefix=/home/rkraft/apps/gcc4
Try:
cd /home/rkraft/apps/
mkdir gcc-4.3.1-build
cd gcc-4.3.1-build
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-17 19:08 ---
Subject: Bug 22374
Author: rguenth
Date: Wed Sep 17 19:07:27 2008
New Revision: 140427
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140427
Log:
2008-09-17 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-17 19:08 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.3.3
1 - 100 of 141 matches
Mail list logo
