--- Comment #6 from uros at kss-loka dot si 2005-10-12 06:49 ---
This is IMO middle-end problem, store motion should check if new insn pattern
is valid, before old insn is replaced.
--
uros at kss-loka dot si changed:
What|Removed |Added
--
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2005-10-12 06:39
---
Mark, do you have an opinion on the following implementation detail? We don't
want to duplicate the code of may_trap_p and rtx_addr_can_trap_p, so the new
predicate will essentially piggyback on it, simply bypas
--- Comment #8 from ppluzhnikov at charter dot net 2005-10-12 06:16 ---
The patch above suppresses the '#0 ', but not if one does:
/usr/local/gcc-4.1-20050813/bin/gcc -v -E -dD - < /dev/null
in which case it *still* produces (now arguably plain wrong):
# 1 ""
#define __STDC_HOSTED
--- Comment #43 from ian at airs dot com 2005-10-12 05:44 ---
I see that Giovanni checked in a significant patch here:
2005-07-20 Giovanni Bajo <[EMAIL PROTECTED]>
Make CONSTRUCTOR use VEC to store initializers.
Is this PR still a significant regression from an earlier relea
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-12 05:43
---
Subject: Bug 20901
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-12 05:43:08
Modified files:
gcc/fortran: ChangeLog gfor
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-12 05:43
---
Subject: Bug 20902
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-12 05:43:08
Modified files:
gcc/fortran: ChangeLog gfor
--- Comment #2 from cvs-commit at gcc dot gnu dot org 2005-10-12 05:43
---
Subject: Bug 24207
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-12 05:43:08
Modified files:
gcc/fortran: ChangeLog gfor
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-12 05:43
---
Subject: Bug 20900
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-12 05:43:08
Modified files:
gcc/fortran: ChangeLog gfor
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-12 05:43
---
Subject: Bug 20899
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-12 05:43:08
Modified files:
gcc/fortran: ChangeLog gfor
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-12 05:43
---
Subject: Bug 20890
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-12 05:43:08
Modified files:
gcc/fortran: ChangeLog gfor
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-12 05:43
---
Subject: Bug 20835
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-12 05:43:08
Modified files:
gcc/fortran: ChangeLog gfor
--- Comment #21 from cvs-commit at gcc dot gnu dot org 2005-10-12 05:43
---
Subject: Bug 16404
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-12 05:43:08
Modified files:
gcc/fortran: ChangeLog gfo
--- Comment #56 from ian at airs dot com 2005-10-12 05:26 ---
Is this PR really a 4.0 regression? The timings which I see in the comments
suggest that 4.0 is just as fast as earlier releases.
That is, the PR may have become a 4.1 regression, but I don't see that it is a
4.0 regression.
--- Comment #7 from per at bothner dot com 2005-10-12 05:13 ---
Subject: Re: [4.1 Regression] line number 0 for
causes GAS to complain
pinskia at gcc dot gnu dot org wrote:
> --- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-12 00:15
> ---
> Per,
> Are you going to
I'm trying to build gcc 4.0.2 and I got an error when building the support for
the fortran language (c, c++, java, etc builds just fine). Since the problems
looks specific to fortran, I build gcc with the following configuration:
../gcc-4.0.2/configure --enable-languages=f95
The error I got is:
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-12 03:23 ---
This patch has been approved for 4.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
_MM_TRANSPOSE4_PS could be improved so that it is faster.
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00324.html
--
Summary: _MM_TRANSPOSE4_PS could be improved
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: patch
--- Comment #12 from wilson at gcc dot gnu dot org 2005-10-12 03:07 ---
Created an attachment (id=9975)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9975&action=view)
Untested patch to fix problems with dependency serialization.
This adds an UNCOND argument to add_dependence_list
--- Comment #11 from wilson at gcc dot gnu dot org 2005-10-12 02:52 ---
My earlier guess was correct. It is a problem with the
sched_insn_condition_mutex_p code. Also, there is the problem that the code
for handling serialization points for dependencies is confused.
sched-deps creates
--- Comment #3 from flash at pobox dot com 2005-10-12 01:59 ---
See bug 24322 against gcc-3.4.4-glibc-2.3.5/arm-softfloat-linux-gnu.
--
flash at pobox dot com changed:
What|Removed |Added
--- Comment #1 from flash at pobox dot com 2005-10-12 01:57 ---
Created an attachment (id=9974)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9974&action=view)
110517_snow_min.i
PalmSource bug 110517.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24322
Compiling the file snow.c from the ffmpeg project
(http://ffmpeg.sourceforge.net), or a Delta-reduced pre-processed version of it
(which I'll attach) causes either a segmentation fault or out of memory
condition. This was originally noticed by Eric Moon with
arm-softfloat-linux-gnu/gcc-3.4.1-glibc
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-12 01:23 ---
As mentioned, this is a VRP bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-12 01:22 ---
As mentioned, this is a VRP bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-12 01:18 ---
Fixed. Thanks for your report.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from cvs-commit at gcc dot gnu dot org 2005-10-12 01:18
---
Subject: Bug 23926
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-12 01:18:07
Modified files:
libstdc++-v3 : ChangeLog acinclude.m4 configure
Log message:
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-12 01:02 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from dannysmith at users dot sourceforge dot net 2005-10-12
01:01 ---
(In reply to comment #6)
> Is this still broken?
No.
It was fixed by this:
2005-07-13 H.J. Lu <[EMAIL PROTECTED]>
* config/alpha/linux.h (TARGET_HAS_F_SETLKW): Renamed to ...
(TAR
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-12 00:58 ---
This happens still, correct?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24093
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-12 00:56 ---
Hmm, the 4.0 patch was approved, I wonder if I could get away with applying
this as obvious as it just gets us the same code as the 4.0 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-12 00:55 ---
I am going to apply the patch as obvious once testing has finished.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-12 00:53 ---
(In reply to comment #4)
> I'll make the sinker sink loads.
Since that will not happen until 4.2 at the earliest because it needs some
cleanup as mentioned on
http://gcc.gnu.org/wiki/Improved%20Aliasing%20Todo%20Lis
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-12 00:46 ---
double hmm, I think this is more of a RA/scheduling issue as the RTL level
changes the code to what DOM changes it to.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-12 00:37 ---
Here is a simple testcase:
int g(int);
int f(int i, int j)
{
i +=1;
if (j)
i+=100;
i+=1;
g(i);
return i;
}
Notice how there are two branch in !j case while there should be only one.
--
pinskia at g
--- Comment #6 from kargl at gcc dot gnu dot org 2005-10-12 00:32 ---
Fixed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-12 00:32 ---
Hmm, we also have a missed optimization on the tree level too.
For the following code:
__complex__ double t1;
void f() {
__complex__ double t;
__imag__ t = 0;
__real__ t = 0;
t1 = t;
}
we get:
t1
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-12 00:31
---
Subject: Bug 20786
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-12 00:31:35
Modified files:
gcc/fortran: ChangeLog ires
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-12 00:21 ---
I think this is a dup of bug 18501.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22456
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-12 00:17 ---
Any news on this one?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Last reconf
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-12 00:15 ---
Is this still broken?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21597
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-12 00:15 ---
Per,
Are you going to fix this soon, if not please say you have no time and I will
look into it.
Thanks,
Andrew Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-11 23:58
---
Subject: Bug 20786
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-11 23:58:17
Modified files:
gcc/fortran: ChangeLog iresolve.c
gcc/testsuite
--- Comment #37 from ian at airs dot com 2005-10-11 23:47 ---
Fixed on mainline. This is a minor compilation time speedup, and I don't think
there is much benefit to porting back to the release branches.
--
ian at airs dot com changed:
What|Removed
--- Comment #36 from cvs-commit at gcc dot gnu dot org 2005-10-11 23:46
---
Subject: Bug 13931
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-11 23:45:57
Modified files:
gcc: ChangeLog combine.c
Log message:
PR rtl-
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-11 23:43 ---
(In reply to comment #4)
> Confirmed, broken by this patch:
> http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02147.html
This patch just exposes a latent bug in the RA, not be able to handle stuf like
this.
--
pins
--- Comment #6 from rth at gcc dot gnu dot org 2005-10-11 23:38 ---
Fixed.
--
rth 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 23:35
---
Subject: Bug 24313
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-11 23:35:27
Modified files:
libgfortran: ChangeLog
libgfortran/intrinsics: c
--- Comment #17 from ian at airs dot com 2005-10-11 23:33 ---
Fixed on mainline. I don't think there is any compelling need to backport this
minor warning patch to the 4.0 or 3.4 branches.
--
ian at airs dot com changed:
What|Removed |Added
--
--- Comment #16 from cvs-commit at gcc dot gnu dot org 2005-10-11 23:31
---
Subject: Bug 8057
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-11 23:30:57
Modified files:
gcc/cp : ChangeLog cvt.c
gcc/testsuite : ChangeLog
--- Comment #15 from mark at codesourcery dot com 2005-10-11 23:27 ---
Subject: Re: [3.4/4.0/4.1 regression] Templates/non-templates
and warnings about statements without effects
This patch is OK, thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8057
--- Comment #4 from belyshev at depni dot sinp dot msu dot ru 2005-10-11
23:18 ---
Confirmed, broken by this patch:
http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02147.html
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
-
--- Comment #19 from giovannibajo at libero dot it 2005-10-11 22:57 ---
(In reply to comment #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?
> Well, then the co
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-11 22:52
---
Subject: Bug 24255
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-11 22:52:04
Modified files:
gcc: ChangeLog c-typeck.c
Added files:
gcc/test
--- Comment #14 from mark at codesourcery dot com 2005-10-11 22:46 ---
Subject: Re: [3.4/4.0/4.1 regression] Templates/non-templates
and warnings about statements without effects
ian at airs dot com wrote:
> --- Comment #13 from ian at airs dot com 2005-10-11 22:37 ---
> With
--- Comment #13 from ian at airs dot com 2005-10-11 22:37 ---
With your suggested test case, and my suggested patch, you will get the warning
foo.cc: In function void f():
foo.cc:3: warning: value computed is not used
It's easy to emit the warning only for template instantiations and
--- Comment #12 from mark at codesourcery dot com 2005-10-11 22:33 ---
Subject: Re: [3.4/4.0/4.1 regression] Templates/non-templates
and warnings about statements without effects
With the proposed patch, what happens with something like:
template
void f() {
T(); /* Has side-effect
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2005-10-11 22:21
---
> Sorry -- my idea about fixing this in the front end is bogus. It's OK to
> dereference a pointer-to-member to a virtual function member even if the base
> class doesn't have any virtual functions;
Too bad. :-
--- Comment #17 from mmitchel at gcc dot gnu dot org 2005-10-11 22:05
---
Eric --
Sorry -- my idea about fixing this in the front end is bogus. It's OK to
dereference a pointer-to-member to a virtual function member even if the base
class doesn't have any virtual functions; c.f., g++.
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 22:05 ---
Hmm, when compiled to native it works but not when using gij.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24321
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-11 22:03 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-11 22:00 ---
Close as invalid per comment #1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 22:00 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
Consider this program:
public class iof {
static class Z {
static {
System.out.println("init");
}
}
public static Object x () { return new Object(); }
public static void main(String[] args)
{
System.out.println(x() instanceof Z);
}
}
With gcj this prints "init".
W
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-11 21:40 ---
To close as invalid per comment #2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-11 21:39 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from rakdver at gcc dot gnu dot org 2005-10-11 21:34 ---
Freeing estimates should definitely be safe. I would also recommend
adding scev_reset to tree_ssa_dce_loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24300
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-11 21:31 ---
Close as invalid per comment #1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-11 21:31 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-11 21:30 ---
To close as invalid per comment #2 and #3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-11 21:29 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-11 21:28 ---
*** Bug 24320 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 21:28 ---
(In reply to comment #0)
> Both Suse 9.3 (gcc 3.3.5/x86_64) and 10.0 (gcc 4.0.2/x86_64) exhibit this same
> problem -- open an fstream with out|in will not actually create the file.
> Strace shows that O_CREAT is no
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-11 21:26 ---
To close as invalid based on comment #4.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-11 21:25 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2005-10-11 21:22
---
The patch has fixed the 32-bit mode but broken the 64-bit mode. :-(
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Both Suse 9.3 (gcc 3.3.5/x86_64) and 10.0 (gcc 4.0.2/x86_64) exhibit this same
problem -- open an fstream with out|in will not actually create the file.
Strace shows that O_CREAT is not passed to open() when out|in is used, but is
if just 'out' is used. This is a rehash of bug #5629 which is clai
--- Comment #3 from belyshev at depni dot sinp dot msu dot ru 2005-10-11
21:07 ---
// reduced testcase
int bar (char *s)
{
return foo (strlen(s));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-11 21:07
---
I believe the patch attached will fix the problem.
Diego, will this allow you to reactivate your optimization? And, if so, what
kind of code will be improved?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-11 21:06
---
Created an attachment (id=9973)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9973&action=view)
Proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912
--- Comment #27 from mmitchel at gcc dot gnu dot org 2005-10-11 21:05
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #26 from cvs-commit at gcc dot gnu dot org 2005-10-11 20:59
---
Subject: Bug 21089
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-11 20:59:53
Modified files:
gcc/cp : call.c init.c ty
--- Comment #25 from cvs-commit at gcc dot gnu dot org 2005-10-11 20:58
---
Subject: Bug 21089
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]2005-10-11 20:58:46
Modified files:
gcc/cp : call.c init.c typeck.c ChangeLog
gcc/t
--- Comment #8 from cvs-commit at gcc dot gnu dot org 2005-10-11 20:53
---
Subject: Bug 21369
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]2005-10-11 20:53:55
Modified files:
gcc/testsuite : ChangeLog
gcc/testsuite/g++.dg/init: me
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 20:51 ---
We have another report of this before. Basicially the ra in gcc needs a lot of
help to fix this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from erg at trifocus dot net 2005-10-11 20:49 ---
Created an attachment (id=9972)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9972&action=view)
string functions for Factor
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319
[EMAIL PROTECTED]:~/Factor/Factor$ gcc -O -fschedule-insns native/string.c
native/string.c: In function from_c_string:
native/string.c:103: error: unable to find a register to spill in class DIREG
native/string.c:103: error: this is the insn:
(insn 13 39 14 0 (parallel [
(set (reg:D
--- Comment #9 from kargl at gcc dot gnu dot org 2005-10-11 20:46 ---
Patch for libgfortran
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00626.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24313
--- Comment #8 from kargl at gcc dot gnu dot org 2005-10-11 20:21 ---
Yes, I agree glibc has the bug. But, libgfortran also has the bug
and will be present on every OS that does not have a libm with csqrt
and csqrtf. I have a patch for libgfortran.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-11 20:18 ---
(In reply to comment #6)
> FreeBSD *does not* have a csqrt or csqrtf in libm! The problem is
> in intrinsics/c99_functions.c. I'm testing a patch.
But if csqrtf in c99_functions.c was pulled from glibc, then there
--- Comment #6 from kargl at gcc dot gnu dot org 2005-10-11 20:11 ---
FreeBSD *does not* have a csqrt or csqrtf in libm! The problem is
in intrinsics/c99_functions.c. I'm testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24313
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-11 19:58 ---
(In reply to comment #4)
> Note the use of __builtin_csqrtf().
But that just calls into csqrt which is part of libm. Look at the asm output.
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #4 from kargl at gcc dot gnu dot org 2005-10-11 19:56 ---
This is definitely a gcc bug.
gfortran -fdump-tree-original csqrt.f
yields (with removal of IO crap and shorting of long constants)
MAIN__ ()
{
complex4 y;
complex4 x;
x = __complex__ (0.0, -1.0e+0);
y = _
--- Comment #7 from tkoenig at gcc dot gnu dot org 2005-10-11 19:37 ---
(In reply to comment #6)
> Many compilers, like the Intel and PGI ones for instance, simply have a
> -byteswap flag that is set at compile time.
ifort actually uses -convert big_endian or -convert little_endian to
s
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-11 19:30 ---
(In reply to comment #2)
> Wow, that was fast!
> What about this code?
> I am using g++ 4.0.1, and it compiles without any error.
Yes that should fail to compile. Confirmed, not a regression.
--
pinskia at gcc
--- Comment #26 from ian at airs dot com 2005-10-11 19:30 ---
Regression bugs should have target milestones.
--
ian at airs dot com changed:
What|Removed |Added
Target
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-11 19:28 ---
Reduced testcase for 4.0.x and above:
void s48_double_to_bignum(int exponent){
long length = exponent) + sizeof (long)) * 8) - 2) - 1)) /
(((sizeof (long)) * 8) - 2)));
}
This really should be filed
--- Comment #25 from rth at gcc dot gnu dot org 2005-10-11 19:24 ---
I don't think we can reasonably attack this for 4.1. This is something
that should be done during a stage 1.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from rth at gcc dot gnu dot org 2005-10-11 19:21 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
1 - 100 of 211 matches
Mail list logo
