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 s
--- 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 y
--- 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 w
--- 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=gcc&view=rev&rev=140411
Log:
2008-09-17 Pascal Rigaux <[EMAIL PROTECTED]>
gcc/ada/
--- 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 o
--- 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.
--
http://gcc.gnu.org/bug
--- 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 middle-
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-17 10:28 ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=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 == new_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=gcc&view=rev&rev=140412
Log:
2008-09-17 Richard Guenther <[EMAIL PROTECTED]>
--- 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=gcc&view=rev&rev=140412
Log:
2008-09-17 Richard Guenther <[EMAIL PROTECTED]>
--- 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
Status|ASSIGNE
--- 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=gcc&view=rev&rev=140413
Log:
2008-09-13 Daniel Kraft <[EMAIL PROTECTED]>
PR fortran
--- 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
Status|UNCONFIRM
--- 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=gcc&view=rev&rev=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 of
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 A
--- 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 resul
--
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
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.
S
--- 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|Rem
--- 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=16343&action=view)
potential patch 1
This is the first option which simply doesn't add the result of a PHI with no
uses to the partit
--
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=16344&action=view)
patch disabling TBAA pruning
This is the patch we use for openSUSE to fix this bug.
--
http://gcc.gnu.org/
--- 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=16345&action=view)
Potential patch #2
This is the other option, eliminate dead PHIs. compiling all of GCC .c files
at -O3, it finds
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
--- 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 i
--- 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=gcc&view=rev&rev=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 value),
--- 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% respec
--- 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
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- 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 b
--- 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
lin
The following valid code snippet is rejected since GCC 4.3.0:
==
struct A {};
template struct Traits
{
typedef void X;
};
template<> struct Traits<0>
{
typedef A X;
};
template struct B
{
typedef typename Traits::X Y;
void foo(Y y)
{
y.Y::A
--
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
.libs/in_unpack_generic.o(.t
--- 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=16346&action=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=gcc&view=rev&rev=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=gcc&view=rev&rev=140422
Log:
PR c++/37552
* typeck.c (build_array_ref): Use pr
--- 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 "" }, w
--- 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;
> ty
--- 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 fo
--- 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 i
--- 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 requi
--- 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=gcc&view=rev&rev=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
Status|UNCONFIRM
--- 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 Docume
--- 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 PPC
--- 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.
--
http://gcc.gnu.org/bugzilla/sh
--- 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
bu
--- 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
../gcc-4.3.1/con
--- 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=gcc&view=rev&rev=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
http://gcc
--- Comment #6 from brian at dessent dot net 2008-09-17 19:38 ---
Subject: Re: collect2: ld returned 1 exit status make[3]:
*** [libgfortran.la] Error 1
Even worse, you may have to start over with a clean source tree. See
pr32272 for an example of where a previous attempt at configu
Many backends need to override optimization options after
we have processed all optimization options. It is done
in OVERRIDE_OPTIONS. But it is only called once for a given
input. We do have OPTIMIZATION_OPTIONS, which is executed
when the optimization options are changed via "pragma GCC optimize"
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-17 20:07 ---
This is a target bug as the warning happens in the back-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2008-09-17 20:07 ---
Here is one approach to add OVERRIDE_OPTIMIZATION_OPTIONS so
that a backend can have a chance to override optimization
options.
--- gcc/config/i386/i386.h.override 2008-09-11 16:48:39.0 -0700
+++ gcc/con
--- Comment #3 from hjl dot tools at gmail dot com 2008-09-17 20:13 ---
(In reply to comment #1)
> This is a target bug as the warning happens in the back-end.
>
But there is no chance for a backend to do anything about it.
It can happen to any backends which check flag_XXX in
OVERRIDE
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-17 20:16 ---
(In reply to comment #3)
> (In reply to comment #1)
> > This is a target bug as the warning happens in the back-end.
> >
>
> But there is no chance for a backend to do anything about it.
> It can happen to any back
--- Comment #5 from hjl dot tools at gmail dot com 2008-09-17 20:24 ---
If the __optimize__ attribute is handled properly, we
may be able to fold the __target__ attribute into the
__optimize__ attribute and all backends can support
function specific -mXXX options like
void foo (void) _
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-17 20:26 ---
Then lets say it is a middle-end issue. Still nowhere has you touched the C
front-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
while trying to build gcc-4.3.2-3.srpm for sparc gfortran segfaults when
building for sparcv9
sparc64 builds ok
if i try and build the conf test manually that fails i get
[EMAIL PROTECTED] obj-sparc64-redhat-linux]$ cat conftest.f
program foo
real, parameter :: bar = sin (12.34 /
1 - 100 of 132 matches
Mail list logo
