--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2005-10-11
07:30 ---
*** This bug has been marked as a duplicate of 20003 ***
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
---
--- Comment #4 from belyshev at depni dot sinp dot msu dot ru 2005-10-11
07:30 ---
*** Bug 23069 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003
--- Comment #29 from dannysmith at users dot sourceforge dot net
2005-10-11 08:01 ---
Updated patch here.
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00565.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21766
--- Comment #5 from uros at kss-loka dot si 2005-10-11 08:55 ---
(In reply to comment #4)
>
> gcse-sm blindly converted valid insn pattern into unrecognized insn pattern.
The problem is in gcse.c, function replace_store_insn(), line 6294:
6293 mem = smexpr->pattern;
6294 insn = gen
--- Comment #3 from mick at nag dot co dot uk 2005-10-11 09:26 ---
Thanks - the problem is now fixed in 64-bit compilations. However, if I compile
try.f and sub.c with the -m32 flag, I still get memory allocated on 8-byte
boundaries rather than 16-byte. As Andrew said, this is down to th
--- Comment #4 from pcarlini at suse dot de 2005-10-11 09:55 ---
The problem is confirmed, should be fixable.
--
pcarlini at suse dot de changed:
What|Removed |Added
La
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2005-10-11 10:42
---
Really interesting: it's a combination of TARGET_PTRMEMFUNC_VBIT_LOCATION,
inlining, efficient stack slot allocation and delay slot scheduling!
SPARC doesn't define TARGET_PTRMEMFUNC_VBIT_LOCATION so the compiler
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2005-10-11 10:54
---
> The only approach to fixing this I can think of is to modify the selection
> logic of TARGET_PTRMEMFUNC_VBIT_LOCATION: if the target has strict alignment
> and delay slots, the macro should be set to ptrmemfunc_
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-11 11:19 ---
This is really a glibc bug and needs to be fixed. The C standard says that
malloc allocates that the right alignment so this is a glibc bug.
--
pinskia at gcc dot gnu dot org changed:
What|Remove
Hi,
compiling linux-2.6.13.4 (vanilla) on my PC (linux-2.6.13.1, gcc-3.3.6,
glibc-2.3.5).
Problem (make):
...
LD drivers/scsi/qla2xxx/built-in.o
CC drivers/serial/serial_core.o
*** glibc detected *** double free or corruption (!prev): 0x084dd188 ***
drivers/serial/serial_core.c: In
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 11:25 ---
*** This bug has been marked as a duplicate of 16676 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #22 from pinskia at gcc dot gnu dot org 2005-10-11 11:25
---
*** Bug 24304 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-11 11:26 ---
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from bonzini at gcc dot gnu dot org 2005-10-11 11:38
---
This is as small as I could make it. Any other attempt to hoist something
causes it not to fail anymore (at -maltivec -O2). Interesting, given that GCSE
*does* the hoisting...
It's a reload problem.
typedef _
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-11 11:48 ---
This is now fixed by preventing to build with the HP's as.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
va_arg seems to mess up the va_list when variadic variables have size 0, but
when have large alignment requirements. When the alignment is small, this
seems to work by chance.
$ gcc foo.c -o foo && ./foo
3 0
#include
#include
typedef int __attribute__ ((vector_size (16))) foo_t;
struct s
{
--- Comment #2 from dvilleneuve at kronos dot com 2005-10-11 12:28 ---
Indeed, in gcc-4.0.1, the previous code chunk does not elicit a warning.
However, a slightly modified version still gets a warning (tested
on RHEL-4, with ).
#include
extern int f(void);
extern int g(int);
extern
--- Comment #2 from mconstant at hancocklumber dot com 2005-10-11 12:33
---
I actually solved the problem. I had to just reinstall the kernel-headers and
kernel-modules off of the slackware discs again and it works now. The files
that were giving errors were corrupted somehow. I tried t
--- Comment #3 from tobi at gcc dot gnu dot org 2005-10-11 13:25 ---
(In reply to comment #2)
> In case anybody wants to work on this, I have an old unfinished patch lying
> around that adds builtins and RTL codes for byteswap operation. This allows
> to use platform specific tricks that
/space/rguenther/obj/gcc-libgfortran/gcc/f951
/space/rguenther/src/gcc-libgfortran/gcc/testsuite/gfortran.fortran-torture/execute/character_select_1.f90
-quiet -dumpbase character_select_1.f90 -mtune=pentiumpro -auxbase
character_select_1 -O0 -w -version -fprofile-generate -o character_select_1.s
/
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-11 13:28 ---
Closing as invalid for now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
u --host=i686-pc-linux-gnu --enable-__cxa_atexit
--enable-languages=c++,objc,java,f95 --prefix=/home/gates/pinskia/linux
--enable-threads=posix --enable-shared
Thread model: posix
gcc version 4.1.0 20051011 (experimental)
/home/gates/pinskia/linux/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -quiet -v
t.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #7 from giovannibajo at libero dot it 2005-10-11 13:43 ---
Yes, I think the problem is in delay slot scheduling too. COND_EXPR means that
either branch must not be evaluated because it could be illegal; if you hoist a
mem from a branch into the delay slot of the condition, yo
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-11 13:44 ---
Confirmed, here is a C testcase:
struct a
{
void *l;
char *k;
};
void *f(struct a*, int len, char*);
void fgg(void)
{
void * gotovar;
struct a jmp[] = {{&&L1, ""}, {&&L2, "EEE"}, {&&L3, "T"}};
gotovar = f
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-10-11 13:51
---
> Yes, I think the problem is in delay slot scheduling too. COND_EXPR means that
> either branch must not be evaluated because it could be illegal; if you hoist
> a
> mem from a branch into the delay slot of the
On Oct 11, 2005, at 9:51 AM, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-10-11
13:51 ---
Yes, I think the problem is in delay slot scheduling too. COND_EXPR
means that
either branch must not be evaluated because it could be ille
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-11 13:55 ---
Subject: Re: [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
On Oct 11, 2005, at 9:51 AM, ebotcazou at gcc dot gnu dot org wrote:
>
>
> --- Comment #8 from ebotcazou at gcc dot gnu dot org 2
../../obj34/gcc/cc1plus -w -quiet -o /dev/null pr24278.min1.ii
Killed
Program received signal SIGINT, Interrupt.
0x006cd5c7 in classify_argument (mode=QImode, type=0x2a95a058f0,
classes=0x7fbfffe050, bit_offset=0) at i386.c:2054
2054 if (TREE_CODE (field) == FIELD_DECL)
(g
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-11 13:58 ---
Created an attachment (id=9964)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9964&action=view)
testcase
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24308
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-10-11 13:59
---
> may_trap_p is the correct thing as it should detect this instruction as
> trapping:
>
> /* Memory ref can trap unless it's a static var or a stack slot. */
> case MEM:
>if (MEM_NOTRAP_P (x))
>
--- Comment #2 from bje at gcc dot gnu dot org 2005-10-11 14:02 ---
gcc version 4.1.0 20051010 (experimental)
I managed to work out that you need to add -msse to trigger the bug.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-11 14:06
---
I am changing the target milestone back to 4.1 as this is most likely fortran
specific, just nobody has found a C/C++ testcase for this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-11 14:07
---
(In reply to comment #10)
> I am changing the target milestone back to 4.1 as this is most likely fortran
> specific, just nobody has found a C/C++ testcase for this bug.
I mean this is most likely ___NOT___ fortr
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-11 14:09 ---
Confirmed, a regression from 3.3.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 14:10 ---
Works for me with 3.4.0, 4.0.0, and 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
The example (attached below), when compiled by following gcc
---
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../../gcc-CVS-20051011/gcc-CVS-20051011/configure
--host=i686-pc-linux-gnu --prefix=/usr/local/opt/gcc-4.1
--exec-prefix=/usr/local/opt/gcc
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-11 14:11 ---
(In reply to comment #2)
> Works for me with 3.4.0, 4.0.0, and 4.1.0.
Except that was 32bit.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from drab at kepler dot fjfi dot cvut dot cz 2005-10-11
14:11 ---
Created an attachment (id=9965)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9965&action=view)
Triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #11 from mark at codesourcery dot com 2005-10-11 14:22 ---
Subject: Re: [4.0 regression] mem_fun* code fine
with -O1, bus error with -O2
ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-10-11 13:59
> ---
>
>>ma
--- Comment #4 from dberlin at gcc dot gnu dot org 2005-10-11 14:25 ---
Subject: Bug 4
Author: dberlin
Date: Tue Oct 11 14:15:11 2005
New Revision: 83801
URL: http://gcc.gnu.org/viewcvs?root=gccrepo&view=rev&rev=83801
Log:
Fixing bug 4
Modified:
branches/improved-aliasing-branch/g
--- Comment #17 from h dot m dot brand at xs4all dot nl 2005-10-11 14:37
---
Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04
On 6 Oct 2005 17:24:10 -, "dje at gcc dot gnu dot org"
<[EMAIL PROTECTED]> wrote:
Now that all seems to be in more or less working order, and gcc-4
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-10-11 14:41
---
> This certainly is a bug in the back-end, not a bug in the default
> location of the v-bit. You shouldn't need to break the C++ ABI on SPARC
> to fix this bug.
Right, I was confused, I thought __pfn was derefe
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-10-11 14:41 ---
It looks like only checking-enabled 3.4.5 allocates memory until it get's
killed
by the kernel. A checking-disabled 3.4.5 build just endlessly loops (in the
same place).
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-10-11 14:45 ---
Also fails with 3.3.3 (SuSE Linux) - which is really hammer-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24308
--- Comment #13 from mark at codesourcery dot com 2005-10-11 14:47 ---
Subject: Re: [4.0 regression] mem_fun* code fine
with -O1, bus error with -O2
ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-10-11 14:41
> ---
>
>>Th
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 14:48 ---
Confirmed, reduced testcase:
float weight[10];
void lsp_weight_quant(float *x, char *cdbk)
{
int i,j;
float dist;
int best_id=0;
for (i=0;i<16;i++)
{
for (j=0;j<10;j++)
dist=dist+weight[
--- Comment #18 from h dot m dot brand at xs4all dot nl 2005-10-11 14:52
---
Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04
On 11 Oct 2005 14:37:31 -, "h dot m dot brand at xs4all dot nl"
<[EMAIL PROTECTED]> wrote:
Ignore the AIX 4.3 question: I've raised the limits to u
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-10-11 14:55 ---
Oh, and make it hang-on-valid by adding a closing brace at EOF. Also fails
with
unpatched FSF 3.3.6, so not a regression. So WONTFIX probably, unless latent
somehow.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #3 from drab at kepler dot fjfi dot cvut dot cz 2005-10-11
14:56 ---
(In reply to comment #2)
> --
> but this is just a latent bug as the above also ICEs in 4.0.0.
> Related to PR 23820.
No! Both the reduced and my original testcase work for me on 4.0.x.
At least on th
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-11 14:58 ---
(In reply to comment #3)
> No! Both the reduced and my original testcase work for me on 4.0.x.
> At least on this one:
That is with checking disabled so ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-11 15:03 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from cvs-commit at gcc dot gnu dot org 2005-10-11 15:11
---
Subject: Bug 23946
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-11 15:11:02
Modified files:
gcc: ChangeLog tree-ssa-ccp.c
gcc/testsuit
--- Comment #5 from drab at kepler dot fjfi dot cvut dot cz 2005-10-11
15:24 ---
(In reply to comment #4)
> That is with checking disabled so ...
Yes. That's right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
--- Comment #6 from dberlin at gcc dot gnu dot org 2005-10-11 15:27 ---
Subject: Re: [4.1 Regression] ICE with -O3
-ftree-loop-linear
On Tue, 2005-10-11 at 15:24 +, drab at kepler dot fjfi dot cvut dot
cz wrote:
>
> --- Comment #5 from drab at kepler dot fjfi dot cvut
Due to a design-mistake in the cxx_printable_name print ring buffer, we print
out freed strings at ipa-inline.c:cgraph_decide_inlining_of_small_functions
fprintf (dump_file,
"\nConsidering %s with %i insns to be inlined into %s\n"
" Estimated growth
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-11 15:38 ---
Patch was posted. Problem is latent since at least old-gcc.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-10-11 15:40 ---
Created an attachment (id=9966)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9966&action=view)
testcase (unincluded)
Testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24310
--- Comment #11 from bonzini at gcc dot gnu dot org 2005-10-11 15:41
---
Created an attachment (id=9967)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9967&action=view)
reduced testcase
reduced testcase, but with uninitialized variables. top of tree:
2005-09-29 Paolo Bonzini
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-10-11 15:42 ---
The patch causes diffs like the following in the ipa-inline-dump:
-Considering int GuardLayers::lower(int) const [with int Dim = 2] with 0
in
sns to be inlined into int UniformGridPartition::partition(const D&,
std:
--- Comment #6 from janis at gcc dot gnu dot org 2005-10-11 16:22 ---
I forgot to add the PR information to the ChangeLog entry at first, but this
is fixed in 3.4.5 by http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00274.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18583
>From the Meissner example Window (Ising model), this line
print '(" ", I6, 64 A1)', L**3, Merge ("+", "-", Ising(: 4, : 4, : 4) == 1)
causes
meissner10.f90: In function MAIN__:
meissner10.f90:18: internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:3815
The ICE is
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2005-10-11 16:24
---
> Ah. I think that would best be fixed in the front-end, then. If the
> class doesn't have a virtual pointer, then there's no need to generate
> the conditional expression; avoiding that will not only fix this b
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org
--- Comment #6 from bonzini at gcc dot gnu dot org 2005-10-11 16:30 ---
Can somebody with a failing system remove all @'s from the toplevel Makefile
and send me the log that results?
That is,
sed -i 's/^\t@/\t' Makefile
make
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #3 from janis at gcc dot gnu dot org 2005-10-11 16:32 ---
This is from Steve Ellcey's change on 2005-10-07, which I approved. I'll
take a look.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-11 16:38
---
Subject: Bug 21369
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-11 16:38:00
Modified files:
gcc/cp : parser.c ChangeLo
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-11 16:38
---
Subject: Bug 21369
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]2005-10-11 16:38:52
Modified files:
gcc/cp : parser.c ChangeLog
gcc/testsuite : Cha
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-11 16:41
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-11 16:45 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #18 from mmitchel at gcc dot gnu dot org 2005-10-11 16:49
---
The optimization question in Comment #11 was answered incorrectly.
The C++ standard in fact requires that Y be initialized before the constructor
is run; see [basic.start.init].
--
http://gcc.gnu.org/bugzill
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org
|dot org
--- Comment #19 from sabre at nondot dot org 2005-10-11 16:58 ---
To clarify: you are saying that the response in comment #12 is wrong?
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
--- Comment #20 from mark at codesourcery dot com 2005-10-11 17:00 ---
Subject: Re: [4.0/4.1 Regression] C++ front-end does not "inline"
the static const double
sabre at nondot dot org wrote:
> --- Comment #19 from sabre at nondot dot org 2005-10-11 16:58 ---
> To clarify: yo
--- Comment #21 from sabre at nondot dot org 2005-10-11 17:03 ---
"required optimization" doesn't make sense to me. To put it more clearly, do
you agree that this:
"In particular, I think the C++ standard specifies that memory is zero
initialized and then ctors (within a translation un
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-11 17:04
---
Subject: Bug 24281
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-11 17:04:45
Modified files:
gcc/testsuite : ChangeLog
gcc/testsuite/gcc.dg/compa
--- Comment #22 from mark at codesourcery dot com 2005-10-11 17:05 ---
Subject: Re: [4.0/4.1 Regression] C++ front-end does not "inline"
the static const double
sabre at nondot dot org wrote:
> --- Comment #21 from sabre at nondot dot org 2005-10-11 17:03 ---
> "required opti
--- Comment #23 from sabre at nondot dot org 2005-10-11 17:10 ---
Ah, very interesting. Thanks for the clarification. Should I file another PR
about cases where this is mishandled?
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
The following testcase is miscompiled:
#include
double foo() { return 1.0; }
static struct S { S(); } s;
static const double Y = foo()+2.0;
S::S() {
printf("%f\n", Y);
}
int main() {
printf("%f\n", Y);
}
Both printfs should print 3 based on Mark's insight in Comment #22 of bug
21089.
-Chri
--- Comment #24 from sabre at nondot dot org 2005-10-11 17:15 ---
At pinskia's request, I filed Bug 24312 to show the miscompilation due to
mishandling this. I thought it would be better to keep this PR focused on the
missed-optimization aspect.
-Chris
--
http://gcc.gnu.org/bugzil
--- Comment #1 from sabre at nondot dot org 2005-10-11 17:15 ---
Note that this could be handled in a straight-forward way with init priorities.
--
sabre at nondot dot org changed:
What|Removed |Added
---
--- Comment #15 from giovannibajo at libero dot it 2005-10-11 17:16 ---
Probably. But what if the problem with dereferencing p was that it is NULL,
instead of a misalignment? Would that case be caught in reorg by something
else?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 17:18 ---
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
This program demonstrates a bug in the complex sqrt function
in gfortran. When complex number x = (0.0,-1.0), the result comes
back as the negative of the expected result. Of course, the negative
of the expected result is still a square root of the original
number, but the f95 standard says that th
--- Comment #16 from mark at codesourcery dot com 2005-10-11 17:31 ---
Subject: Re: [4.0 regression] mem_fun* code fine
with -O1, bus error with -O2
giovannibajo at libero dot it wrote:
> --- Comment #15 from giovannibajo at libero dot it 2005-10-11 17:16
> ---
> Probably. B
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-11 17:31 ---
Hmm, I think this is a bug in glibc's csqrt. as I get the following on
powerpc-darwin:
( 0.00, -1.00) ( 0.7071068,-0.7071068)
( 9.994E-39, -1.00) ( 0.7071068,-0.7071068)
--- Comment #2 from jconner at apple dot com 2005-10-11 17:31 ---
Patch submitted here:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01274.html
Awaiting review...
--
jconner at apple dot com changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 17:33 ---
This is a bug in glibc's csqrt as gfortran just calls it. Please report it to
them.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-11 17:36 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org
|dot org
--- Comment #3 from erik dot edelmann at iki dot fi 2005-10-11 18:11
---
Testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24245
--- Comment #15 from cvs-commit at gcc dot gnu dot org 2005-10-11 18:15
---
Subject: Bug 24263
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-11 18:14:57
Modified files:
gcc: ChangeLog convert.c
Log message:
PR mi
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2005-10-11 18:16
---
See http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00578.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
This is the offending code, which gets compiled successfully.
--
// The base template.
template
struct A
{
int select() { return 0; }
};
//Extra "template<>"
template <>
template <>
template <>
template <>
template <>
template <>
template <>
template <>
template <>
tem
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-11 18:25 ---
Fixed in 3.4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #4 from tkoenig at gcc dot gnu dot org 2005-10-11 18:40 ---
I'm trying to work on this.
I would prefer a syntax "open(...,convert="little_endian") or something like
that.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
-
1 - 100 of 211 matches
Mail list logo
