[Bug target/32191] ICE with complex __float128

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-06-03 07:00 ---
Try compiling:

c128 foo (c128 x, c128 y)
{
  typedef _Complex float __attribute__((mode(TC))) c128;
  x *= y;
  return x;
}

This will most likely also crash at higher optimization levels.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32191

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

--- Comment #31 from pluto at agmk dot net  2007-06-03 07:21 ---
r125227 | dberlin | 2007-05-31 11:37:38 -0400 (Thu, 31 May 2007) | 11 lines

2007-05-27  Daniel Berlin <[EMAIL PROTECTED]>

Fix PR/30052
Backport PTA solver from mainline

* pointer-set.c: Copy from mainline
* pointer-set.h: Ditto.
* tree-ssa-structalias.c: Copy solver portions from mainline.
* Makefile.in (tree-ssa-structalias.o): Update dependencies


-- 

pluto at agmk dot net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052

[Bug fortran/32124] Execution stops with stat= in ALLOCATE

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2007-06-03 07:26 ---
Subject: Bug 32124

Author: burnus
Date: Sun Jun  3 07:25:54 2007
New Revision: 125293

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125293
Log:
2007-05-28  Tobias Burnus  <[EMAIL PROTECTED]>

   PR fortran/32124
   * gfortran.dg/allocate_stat_1.f90: Remove.


Removed:
trunk/gcc/testsuite/gfortran.dg/allocate_stat_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124

[Bug fortran/32124] Execution stops with stat= in ALLOCATE

[burnus at gcc dot gnu dot org]

--- Comment #11 from burnus at gcc dot gnu dot org  2007-06-03 07:26 ---
Backed out test case as no one seems to have an idea how to produce a test case
which works on all platforms.
-> FIXED.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124

Defining a double

[Levin, Andrew Michael]

When I try to compile this code:

class ScoreDistanceRestraints
{
double asdfasdsfa( 0);
};

int main ()
{
return 0;
}

I get three errors that say:

expected identifier before numeric constant
expected ',' or '...' before numeric constant
ISO C++ forbids declaration of 'parameter' with no type
---
Levin, Andrew Michael
Vanderbilt University
Email: [EMAIL PROTECTED]

[Bug middle-end/32140] [4.3 Regression] Miscompilation with -O1

[jv244 at cam dot ac dot uk]

--- Comment #7 from jv244 at cam dot ac dot uk  2007-06-03 09:02 ---
suspect that this is a front end issue, where something wrong is being
generated for s2a_3. It seems to trigger only if a is a function results, and
s1,s2,s3 are len=*. 


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 CC||paulthomas2 at wanadoo dot
   ||fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140

[Bug target/32191] ICE with complex __float128

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-06-03 09:22:57
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32191

[Bug fortran/32195] New: [regression] ICE in get_array_ctor_strlen

[dominiq at lps dot ens dot fr]

With 4.3.0 20070601 I have several ICE, e.g., array_constructor_13.f90:

(gdb) run array_constructor_13.f90
Starting program: /sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin7/4.3.0/f951
array_constructor_13.f90
Reading symbols for shared libraries +++. done
 MAIN__ to_string
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0007f4ac in get_array_ctor_strlen (block=0xbfffe9b8, c=0x43306b20,
len=0xbfffe918) at ../../gcc-4.3-20070602/gcc/fortran/trans-array.c:1379
1379../../gcc-4.3-20070602/gcc/fortran/trans-array.c: No such file or
directory.
in ../../gcc-4.3-20070602/gcc/fortran/trans-array.c
(gdb) backtrace
#0  0x0007f4ac in get_array_ctor_strlen (block=0xbfffe9b8, c=0x43306b20,
len=0xbfffe918) at ../../gcc-4.3-20070602/gcc/fortran/trans-array.c:1379
#1  0x0002 in ?? ()
#2  0x0007f450 in get_array_ctor_strlen (block=0xbfffe9b8, c=0x43306b20,
len=0xbfffe918) at ../../gcc-4.3-20070602/gcc/fortran/trans-array.c:1418
#3  0x00091ea0 in gfc_conv_function_call (se=0xbfffe868, sym=0x43306b90,
arg=0xbfffe874, append_args=0x0) at
../../gcc-4.3-20070602/gcc/fortran/trans-expr.c:2162
#4  0x0009d5e8 in gfc_conv_intrinsic_funcall (se=0xbfffeca8, expr=0x43306830)
at ../../gcc-4.3-20070602/gcc/fortran/trans-intrinsic.c:1514
#5  0x0009f50c in gfc_conv_intrinsic_function (se=0xbfffeca8, expr=0x43306830)
at ../../gcc-4.3-20070602/gcc/fortran/trans-intrinsic.c:4022
#6  0x00092f0c in gfc_conv_function_expr (se=0xbfffeca8, expr=0x7c1664) at
../../gcc-4.3-20070602/gcc/fortran/trans-expr.c:2713
#7  0x00095230 in gfc_trans_assignment (expr1=0x43306390, expr2=0x43306830,
init_flag=0 '\0') at ../../gcc-4.3-20070602/gcc/fortran/trans-expr.c:3557
#8  0x00077ba0 in gfc_trans_code (code=0x43306830) at
../../gcc-4.3-20070602/gcc/fortran/trans.c:558
#9  0x0008cde0 in gfc_generate_function_code (ns=0x43812c00) at
../../gcc-4.3-20070602/gcc/fortran/trans-decl.c:3183
#10 0x0004d950 in gfc_parse_file () at
../../gcc-4.3-20070602/gcc/fortran/parse.c:3264
#11 0x00071388 in gfc_be_parse_file (set_yydebug=1) at
../../gcc-4.3-20070602/gcc/fortran/f95-lang.c:303
#12 0x00112f68 in toplev_main (argc=8179940, argv=0x43305ab0) at
../../gcc-4.3-20070602/gcc/toplev.c:1051
#13 0x25c0 in _start (argc=2, argv=0xb0e0, envp=0xb0ec) at
/SourceCache/Csu/Csu-47/crt.c:267
#14 0x8fe1a31c in __dyld__dyld_start ()

or in

  character(len=1) :: tempn(1,2)
  character(len=1),allocatable :: foo(:,:), bar(:,:)
  tempn = 'a'
  x = 0
  allocate(foo(3,0),bar(-2:-4,7:9))
  print *, reshape(tempn(-7:-8,:),(/3,3/),pad=(/'a'/))
  print *, reshape(tempn(-7:-8,:),(/3,3,3/),pad=(/'a'/))
  print *, reshape(tempn(-7:-8,:),(/3,3,3,3,3,3,3/),pad=(/'a'/))
!  print *, reshape(tempn(:,9:8))
!  print *, reshape(foo)
!  print *, reshape(bar)
  end

(gdb) run zero_reshape.f90
Starting program: /sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin7/4.3.0/f951
zero_reshape.f90
Reading symbols for shared libraries +++. done
 MAIN__
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0007f608 in get_array_ctor_strlen (block=0xbfffe478, c=0x433073f0,
len=0xbfffe3d8) at ../../gcc-4.3-20070602/gcc/fortran/trans-array.c:1427
1427../../gcc-4.3-20070602/gcc/fortran/trans-array.c: No such file or
directory.
in ../../gcc-4.3-20070602/gcc/fortran/trans-array.c
(gdb) backtrace
#0  0x0007f608 in get_array_ctor_strlen (block=0xbfffe478, c=0x433073f0,
len=0xbfffe3d8) at ../../gcc-4.3-20070602/gcc/fortran/trans-array.c:1427
#1  0x0003 in ?? ()
#2  0x0007f450 in get_array_ctor_strlen (block=0xbfffe478, c=0x433073f0,
len=0xbfffe3d8) at ../../gcc-4.3-20070602/gcc/fortran/trans-array.c:1418
#3  0x00091ea0 in gfc_conv_function_call (se=0xbfffe328, sym=0x43308600,
arg=0xbfffe334, append_args=0x0) at
../../gcc-4.3-20070602/gcc/fortran/trans-expr.c:2162
#4  0x0009d5e8 in gfc_conv_intrinsic_funcall (se=0xbfffe88c, expr=0x43307010)
at ../../gcc-4.3-20070602/gcc/fortran/trans-intrinsic.c:1514
#5  0x0009f50c in gfc_conv_intrinsic_function (se=0xbfffe88c, expr=0x43307010)
at ../../gcc-4.3-20070602/gcc/fortran/trans-intrinsic.c:4022
#6  0x00092f0c in gfc_conv_function_expr (se=0xbfffe88c, expr=0x7c1664) at
../../gcc-4.3-20070602/gcc/fortran/trans-expr.c:2713
#7  0x00093624 in gfc_conv_expr (se=0xbfffe88c, expr=0x43307010) at
../../gcc-4.3-20070602/gcc/fortran/trans-expr.c:3153
#8  0x0007fa34 in gfc_add_loop_ss_code (loop=0xbfffeac0, ss=0x43308520,
subscript=216 'Ø') at ../../gcc-4.3-20070602/gcc/fortran/trans-array.c:1846
#9  0x000802fc in gfc_conv_loop_setup (loop=0xbfffeac0) at
../../gcc-4.3-20070602/gcc/fortran/trans-array.c:3299
#10 0x000a0bb0 in gfc_trans_transfer (code=0xbfffeac0) at
../../gcc-4.3-20070602/gcc/fortran/trans-io.c:1969
#11 0x000779e8 in gfc_trans_code (code=0x433076e0) at
../../gcc-4.3-20070602/gcc/fortran/trans.c:690
#12 0x000a3858 in build_dt (function=0x42763000, code=0x433077a0) at
../../gcc-4.3-20070602/gcc/fortran/trans-io.c:1626
#13 0x00077a08 in gfc_trans_code (code=0x433077a0) at
../../gcc-4.3-20070602/gcc/fortran/trans.c:666

[Bug target/32191] ICE with complex __float128

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-06-03 11:42 
---
(In reply to comment #4)
> c128 foo (c128 x, c128 y)
> {
>   typedef _Complex float __attribute__((mode(TC))) c128;
>   x *= y;
>   return x;
> }
> 
> This will most likely also crash at higher optimization levels.

Right. (but still only with -std=c99)

FWIW, I probably should have mentioned that I spotted this bug during the
testing of my little 4.3 project of reworking the way libgfortran handles
different types.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.3.0
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32191

[Bug fortran/31310] gfortran is missing -fcase-preserve option

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2007-06-03 11:47 ---
Re. comment #3:
Wow. Thanks for your encouraging comment.  Now people know not to waste time on
your bugs, because you're just another rude complaining troll.

Oh, wait...  Maybe not.

Fortunately, most people understand that their priorities don't always  match
with other people's priorities.  Developers of gfortran are all volunteers who
are free to work on what they give priority to.

The truth is that, even though you seem to have a different impression, people
do care about your problem.  But there are just so many other problems, and so
few people trying to fix any.  Telling these hard-working folks that they suck
because they ignore you, in your perception, is not constructive, and bad for
you in the long if you value the availability of a decent free Fortran
compiler.

I would encourage you to file any bugs you may know of.  Even if they're not
fixed tomorrow, the only way to ever have them fixed at all is by reporting
them, so people know these problems exist.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31310

[Bug libgomp/32193] Upgrading GNU/Linux to libc6_2.6~20070518-2 breaks libgomp make - FIX given

[rob1weld at aol dot com]

--- Comment #2 from rob1weld at aol dot com  2007-06-03 12:16 ---
>> Comment From Andrew Pinski
>> That is wrong and non portable.

Your answer seems simple enough but I'm not sure I understand it ...


I just did a "make -i check" and diff on my prior compile and this one.

The results of the check tests are _identical_. Is the testing incomplete?

=== libgomp tests ===
Running target unix
=== libgomp Summary ===
# of expected passes1566


All the tests passed. It gets no better than that.

I suggest that it is not "wrong" - as for "portable", I can't write code for
computers I know nothing about. Can you tell me how the description below is
not portable for YOU. It would not make any changes for you, would it?


It is correct and portable to the extent that it can be to:

1) Have the configure script check for the target "i686-pc-linux-gnu" and then
run the snippet of code I provided above (it is the standard way according to
the author of lib6).

2) If the library is NEW then have configure define something "similar" to:
#define HAVE_libc6_2_6_PTHREAD_AFFINITY_NP 1 the the file
gcc-4_3-trunk/libgomp/config.h .

3): In file gcc-4_3-trunk/libgomp/libgomp.h have something "similar" to this:

#ifdef HAVE_libc6_2_6_PTHREAD_AFFINITY_NP
#include 
#else
#include 
#endif

Whats wrong with that ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32193

[Bug libgomp/32193] Upgrading GNU/Linux to libc6_2.6~20070518-2 breaks libgomp make - FIX given

[rob1weld at aol dot com]

--- Comment #3 from rob1weld at aol dot com  2007-06-03 12:19 ---
Typo correction:

Change 
"#define HAVE_libc6_2_6_PTHREAD_AFFINITY_NP 1 the the file"
to
"#define HAVE_libc6_2_6_PTHREAD_AFFINITY_NP 1 in the file"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32193

[Bug tree-optimization/32194] [4.3 Regression] ice for legal code with -O3 with complex in loop

[rakdver at gcc dot gnu dot org]

-- 

rakdver at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rakdver at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-06-03 06:26:46 |2007-06-03 12:23:21
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32194

[Bug fortran/32196] New: Upgrading GNU/Linux to libc6_2.6~20070518-2 fails gfortran.dg/secnds.f

[rob1weld at aol dot com]

Please read first portion of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32193
to see the where and how of obtaining and installing new libc6, then come back
here.

After upgrading my library I did a diff of the "make -i check" test results of
the build before I upgraded and after I upgraded. It was identical except for
this:

# diff -Naur ../gcc-4_3-build-libc6_2.3.6/summary
../gcc-4_3-build-libc6_2.6/summary

--- ../gcc-4_3-build-libc6_2.3.6/summary2007-06-02 15:10:51.0 -0700
+++ ../gcc-4_3-build-libc6_2.6/summary2007-06-03 04:40:17.0 -0700
@@ -119,11 +119,12 @@
 FAIL: gfortran.dg/open_errors.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
 FAIL: gfortran.dg/open_errors.f90  -O3 -g  execution test
 FAIL: gfortran.dg/open_errors.f90  -Os  execution test
+FAIL: gfortran.dg/secnds.f  -O3 -fomit-frame-pointer  execution test

=== gfortran Summary ===

-# of expected passes   18236
-# of unexpected failures   16
+# of expected passes   18235
+# of unexpected failures   17
 # of expected failures 8
 # of unsupported tests 16
 /opt/gcc-4_3-build/gcc/testsuite/gfortran/../../gfortran  version 4.3.0
20070602 (experimental)


The "gfortran.dg/secnds.f" test did not fail prior to my upgrade.


-- 
   Summary: Upgrading GNU/Linux to libc6_2.6~20070518-2 fails
gfortran.dg/secnds.f
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32196

[Bug fortran/32196] Upgrading GNU/Linux to libc6_2.6~20070518-2 fails gfortran.dg/secnds.f

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2007-06-03 13:07 ---
> The "gfortran.dg/secnds.f" test did not fail prior to my upgrade.

You were a lucky guy!-) see PR32057 for more details


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32196

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

[rob1weld at aol dot com]

--- Comment #2 from rob1weld at aol dot com  2007-06-03 13:16 ---
Did GSL and Paranoia with -ffloat-store for gcc 4.3.0, same result.

Instead of "the normal x87 issue" it might be a "libm issue" since it works
with Cygwin's gcc but fails with all the Linux gcc's.


Here is something that gsl configure prints:

checking for inline... inline
checking for extern inline... yes
checking ieeefp.h usability... no
checking ieeefp.h presence... no
checking for ieeefp.h... no
checking for vprintf... yes
checking for _doprnt... no
...
checking for cos in -lm... yes
checking whether feenableexcept is declared... yes
checking whether fesettrapenable is declared... no
checking whether hypot is declared... yes
checking whether expm1 is declared... yes
checking whether acosh is declared... yes
checking whether asinh is declared... yes
checking whether atanh is declared... yes
checking whether ldexp is declared... yes
checking whether frexp is declared... yes
checking whether isinf is declared... yes
checking whether finite is declared... yes
checking whether isfinite is declared... no
checking whether isnan is declared... yes
checking whether log1p is declared... yes
checking for long double stdio... yes
checking for extended floating point registers... yes
checking for IEEE arithmetic interface type... gnux86
checking for FPU_SETCW... yes
checking for IEEE compiler flags... none
checking for IEEE comparisons... yes
checking for IEEE denormalized values... yes
...

When Cygwin builds gcc it answers yes to these questions:
checking ieeefp.h usability... no
checking ieeefp.h presence... no

It is good to see that GSL check the need for FPU_SETCW. 

GSL, like GCC, uses "-lm" whereas GCC's libjava builds and uses it's own
libfdlibm.a (but unfortunately _seems_ to use "-lm" in a few places).


If these programs CAN be compiled on target i686-pc-cygwin (old gcc) WITHOUT
errors and can NOT be compiled on target i686-pc-linux-gnu (newer gcc) WITHOUT
errors then NEWER gcc is not implementing it's math with the same accuracy as
the older gcc does. 

I am using the same computer to run both tests so, in theory, it would be
possible to alter GCC 4.3.0 (and 4.2.1, etc.) so that it's math results were as
accurate as they once were.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180

[Bug target/32191] ICE with complex __float128

[fxcoudert at gcc dot gnu dot org]

--- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-06-03 13:45 
---
(In reply to comment #3)
> fndecl is already NULL there.
> 
>> #1  0x0068d0bd in expand_complex_libcall (bsi=0x7fbfffed20,

In tree.c, at line 7225, we define the builtins for complex multiplication:

for (mode = MIN_MODE_COMPLEX_FLOAT; mode <= MAX_MODE_COMPLEX_FLOAT; ++mode)
  {
char mode_name_buf[4], *q;
const char *p;
enum built_in_function mcode, dcode;
tree type, inner_type;

type = lang_hooks.types.type_for_mode (mode, 0);
if (type == NULL)
  continue;

But when mode == TC, lang_hooks.types.type_for_mode (mode, 0) is NULL and the
corresponding builtin is never defined.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32191

[Bug fortran/32196] Upgrading GNU/Linux to libc6_2.6~20070518-2 fails gfortran.dg/secnds.f

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2007-06-03 14:14 
---
open_errors.f90 is testing for some OS dependent text in error messages.  If
you could extract that from the testsuite, compile it, and run it, you may see
that it works  fine, but some text has changed.  I would very much appreciate
if you could post the output from that program.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32196

[Bug target/16589] [4.0/4.1/4.2/4.3 regression] [m68k] segmentation fault on identical array accesses in the ?: operators' body

[schwab at suse dot de]

--- Comment #19 from schwab at suse dot de  2007-06-03 15:14 ---
Fixed by .


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|4.1.3   |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16589

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

[rob1weld at aol dot com]

--- Comment #3 from rob1weld at aol dot com  2007-06-03 15:15 ---
Here is simple test for the "float-store" issue:

main() {
 double v = 1E308;
 double x = (v * v) / v;
 printf("Try compiling with and without -ffloat-store\n");
 printf("(1E308 * 1E308) / 1E308\n");
 printf("Correct output is 'inf 0' - Incorrect output is '1e+308 1'.\n");
 printf("%g %d\n", x, x==v);
}


Reading the info file for cpp I notice in the node "Common Predefined Macros"
that we define various macros for many things but nothing for "-ffloat-store".

We have __NO_INLINE__ for -fno-inline
We have __USER_LABEL_PREFIX__ for -f(no-)underscores
We have __EXCEPTIONS for -fno-exceptions
We have __NEXT_RUNTIME__ for -fnext-runtime
We have __SSP__ for -fstack-protector
We have __SSP_ALL__ for -fstack-protector-all

On the basis that using "-ffloat-store" alters the resulting output of gcc I
propose we use cpp_define() in gcc-4_3-trunk/gcc/c-cppbuiltin.c to add
"__FLOAT_STORE__" for -ffloat-store. 

We should also fix the code so the math is as accurate as the standard provides
for; regardless of use of -ffloat-store or -ffast-math, -msoft-float,
-mfpmath=xyz, -msse*, -minline-float-*, -minline-sqrt-*, or anything else.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

[rob1weld at aol dot com]

--- Comment #4 from rob1weld at aol dot com  2007-06-03 16:05 ---
I copied
gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm/.libs/libfdlibm.a
to my current directory and instead of using "-lm" I used "./libfdlibm.a" ...

Guess what.


I propose this simple and useful fix:

We need to re-arrange gcc to build a directory like
"gcc-4_3-build/libdecnumber" and "gcc-4_3-build/prev-libdecnumber" called
"gcc-4_3-build/libfdlibm" "gcc-4_3-build/prev-libfdlibm".

The first pass can build it using "-O0" so it is certain to work (or we must
fix that) and the next pass can build it with profiling and "-O3" enabled. 

Profiling works on 4.2.0 (but not on 4.3.0). A message can be printed that if
profiling the math library fails to rebuild by typing "make nomathprofile".

The third pass can use the profiled information to build the math library in a
fully optimized state.

The resulting super-optimized math library can then be used for the libjava
library in the fourth "library build pass" and any other language that wants to
take advantage of this. 

No effort would be wasted and we would have a fast / accurate library that
works on all platforms - OR is the libfdlibm not a good plan and should be
removed from libjava?


If you have this page on your computer look at
/usr/share/doc/glibc-2.5/manual/libc/Errors-in-Math-Functions.html - it is
created when you compile libc6.

That page is a report of the libc6 tests that are ran when the code is built
and shows the resulting errors for every function (as is suggested in IEEE754).


It looks like this (edited for brevity):

The table lists the ULP values for different architectures. Different
architectures have different results since their hardware support for
floating-point operations varies and also the existing hardware support is
different. 

Function  Alpha  Generic  ix86  IA64  PowerPC 

acosf  -  -- - - 
acos   -  -- - - 
cosf   1  -1 1 1 
cos2  -2 2 2 
cosl   -  -1 1 1  
logl   -  -- - 1 
log10f 2  -1 1 2 
log10  1  -- - 1 
log10l -  -1 1 1  
powl   -  -- - 1  
...


Since we link some of gcc with "-lm" and some with libfdlibm we have an
inconsistant math library upon which gcc is based. We can standardize and test
our math library to provide the same (correct) result on all platforms (as IEEE
754 requires).

Lets remove "-lm" from gcc and use libfdlibm on as many platforms as is
possible, where that doesn't work we simply let them use "-lm", like they did
before, and they will be no worse off. The rest of us will be much better off.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180

[Bug target/32191] ICE with complex __float128

[ubizjak at gmail dot com]

--- Comment #7 from ubizjak at gmail dot com  2007-06-03 16:32 ---
These missing complex types should probably be defined in i386.c (line 17710),
alongside __float128 and __float80 definitions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32191

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2007-06-03 16:35 ---
(In reply to comment #4)

> Function  Alpha  Generic  ix86  IA64  PowerPC 
> 
> acosf  -  -- - - 
> acos   -  -- - - 
> cosf   1  -1 1 1 
> cos2  -2 2 2 
> cosl   -  -1 1 1  
> logl   -  -- - 1 
> log10f 2  -1 1 2 
> log10  1  -- - 1 
> log10l -  -1 1 1  
> powl   -  -- - 1  
> ...
> Since we link some of gcc with "-lm" and some with libfdlibm we have an
> inconsistant math library upon which gcc is based. We can standardize and test
> our math library to provide the same (correct) result on all platforms (as 
> IEEE
> 754 requires).

IEEE 754 does not discuss any of the functions you list above.  In fact,
IEEE 754 places requirements on exactly one function in libm, and that is
sqrt(), which must be exact in all rounding modes.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180

[Bug c++/32197] New: ICE when compiling with gcov options

[mathieu dot lacage at sophia dot inria dot fr]

[EMAIL PROTECTED]:~/code/ns-3-history$ g++ --version
g++ (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[EMAIL PROTECTED]:~/code/ns-3-history$ g++ -o
build-dir/gcov/src/internet-node/i-ipv4-impl.o -c -g3 -Wall -Werror
-fprofile-arcs -ftest-coverage -fPIC -DRUN_SELF_TESTS -Ibuild-dir/gcov/include
src/internet-node/i-ipv4-impl.cc -save-temps

The preprocessed output is coming.


-- 
   Summary: ICE when compiling with gcov options
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mathieu dot lacage at sophia dot inria dot fr
GCC target triplet: i486-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32197

[Bug c++/32197] ICE when compiling with gcov options

[mathieu dot lacage at sophia dot inria dot fr]

--- Comment #1 from mathieu dot lacage at sophia dot inria dot fr  
2007-06-03 17:00 ---
Created an attachment (id=13654)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13654&action=view)
preprocessed output


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32197

[Bug fortran/32196] Upgrading GNU/Linux to libc6_2.6~20070518-2 fails gfortran.dg/secnds.f

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-06-03 17:07 ---


*** This bug has been marked as a duplicate of 32057 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32196

[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2007-06-03 17:07 ---
*** Bug 32196 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rob1weld at aol dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057

[Bug other/30335] CreateFileMapping fails in Vista due to lack of admin privileges

[magnus at greatlord dot com]

--- Comment #11 from magnus at greatlord dot com  2007-06-03 17:48 ---
Hi

I look at both patcher the frist one the
"GCC-v4.1-r120189-CreateFileMapping-Vista.patch" is most correct one in my
eyes. 

if you reading how CreateFileMapping works, at
http://msdn2.microsoft.com/en-us/library/aa366537.aspx

I interper it the text as u always need to use "local\\name" to support more
that one user. 

we need rember that apps can get admin right  in NT 2003 and down when they
runs so they where allown to use NULL in the last param and gain admins right
in vista this is not posible any longer, letting program getting admin right 
when user have limit right. so now all program need follow the api to proper

Now we looking at the second patch the host-mingw32.c.diff 
I have not tested it in vista or windows yet. But what I can see
it using vritualalloc that mean it alloc memory and getting allot slower
against
FileMapping we talking about allot extra comping time, and it is not a good
idea for big project like reactos, and another thing the swap file will incress
and windows does not always cleanup stuff in the swapfile until a reboot, that
is few big disages with host-mingw32.c.diff it exists allot other disgante over
it also.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30335

[Bug tree-optimization/32194] [4.3 Regression] ice for legal code with -O3 with complex in loop

[rakdver at gcc dot gnu dot org]

--- Comment #4 from rakdver at gcc dot gnu dot org  2007-06-03 19:21 ---
Subject: Bug 32194

Author: rakdver
Date: Sun Jun  3 19:21:12 2007
New Revision: 125298

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125298
Log:
PR tree-optimization/32194
* tree-predcom.c (determine_offset): Check that both references have
the same type.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-predcom.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32194

[Bug fortran/31564] Error: Type/rank mismatch in argument

[eedelman at gcc dot gnu dot org]

--- Comment #5 from eedelman at gcc dot gnu dot org  2007-06-03 19:28 
---
I never seem to get time to do anything about this bug, so I'll better unassign
it from me.


-- 

eedelman at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|eedelman at gcc dot gnu dot |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564

[Bug libgcj/32198] New: rmic fails if remote method throws superclass of RemoteException

[marcus at better dot se]

GCJ fails to build MX4J [1], whereas it works with Sun JDK 5. This is because
rmic cannot compile a remote object with a method that only declares that it
throws an exception that is a superclass of RemoteException. This should be
allowed though: 

"Each remote method must declare java.rmi.RemoteException (or a superclass of
RemoteException) in its throws clause, in addition to any application-specific
exceptions." [2]

Build output:

rmic.iiop:
 [rmic] javax/management/remote/rmi/RMIServerImpl.class added as
javax/management/remote/rmi/_RMIServerImpl_Tie.class doesn't exist.
 [rmic] RMI Compiling 1 class to
/home/marcus/src/debian/build-area/libmx4j-java-3.0.2/classes/core
 [rmic] Using SUN rmic compiler
 [rmic] IIOP has been turned on.
 [rmic] Compilation arguments:
 [rmic] '-d'
 [rmic]
'/home/marcus/src/debian/build-area/libmx4j-java-3.0.2/classes/core'
 [rmic] '-classpath'
 [rmic]
'/home/marcus/src/debian/build-area/libmx4j-java-3.0.2/classes/core:/home/marcus/src/debian/build-area/libmx4j-java-3.0.2/lib:/home/marcus/src/debian/build-area/libmx4j-java-3.0.2/dist/lib/mx4j-impl.jar:/home/marcus/src/debian/build-area/libmx4j-java-3.0.2/dist/lib/mx4j-jmx.jar:/home/marcus/src/debian/build-area/libmx4j-java-3.0.2/dist/lib/mx4j.jar:/usr/share/ant/lib/ant.jar:/usr/share/ant/lib/ant-launcher.jar:/usr/share/java/log4j-1.2.jar:/usr/share/java/commons-logging.jar:/usr/share/java/servlet-api-2.4.jar:/usr/share/java/bcel.jar:/usr/share/java/jython.jar:/usr/share/java/gnumail.jar:/usr/share/java/activation.jar:/usr/share/java/axis.jar:/usr/share/java/jaxrpc.jar:/usr/share/java/saaj.jar:/usr/lib/jvm/java-gcj/lib/tools.jar'
 [rmic] '-iiop'
 [rmic] '-g'
 [rmic]
 [rmic] The ' characters around the executable and arguments are
 [rmic] not part of the command.
 [rmic] File to be compiled:javax.management.remote.rmi.RMIServerImpl
  [antcall] Exiting
/home/marcus/src/debian/build-area/libmx4j-java-3.0.2/build/build.xml.

BUILD FAILED
/home/marcus/src/debian/build-area/libmx4j-java-3.0.2/build/build.xml:287: The
following error occurred while executing this line:
/home/marcus/src/debian/build-area/libmx4j-java-3.0.2/build/build.xml:257:
Error starting SUN rmic:
   at
org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:539)
   at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:385)
   at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:107)
   at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
   at org.apache.tools.ant.Task.perform(Task.java:364)
   at org.apache.tools.ant.Target.execute(Target.java:341)
   at org.apache.tools.ant.Target.performTasks(Target.java:369)
   at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
   at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
   at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
   at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
   at org.apache.tools.ant.Main.runBuild(Main.java:668)
   at org.apache.tools.ant.Main.startAnt(Main.java:187)
   at org.apache.tools.ant.Main.start(Main.java:150)
   at org.apache.tools.ant.Main.main(Main.java:240)
Caused by:
/home/marcus/src/debian/build-area/libmx4j-java-3.0.2/build/build.xml:257:
Error starting SUN rmic:
   at org.apache.tools.ant.taskdefs.rmic.SunRmic.execute(SunRmic.java:67)
   at org.apache.tools.ant.taskdefs.Rmic.execute(Rmic.java:529)
   at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
   at org.apache.tools.ant.Task.perform(Task.java:364)
   at org.apache.tools.ant.Target.execute(Target.java:341)
   at org.apache.tools.ant.Target.performTasks(Target.java:369)
   at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
   at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
   at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
   at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
   ...13 more
Caused by: java.lang.reflect.InvocationTargetException
   at java.lang.reflect.Method.invoke(libgcj.so.71)
   at org.apache.tools.ant.taskdefs.rmic.SunRmic.execute(SunRmic.java:54)
   ...22 more
Caused by: gnu.classpath.tools.rmic.CompilationError: newClient, defined in
javax.management.remote.rmi.RMIServer, does not throw java.rmi.RemoteException
   at
gnu.classpath.tools.rmic.SourceGiopRmicCompiler.compile(SourceGiopRmicCompiler.java:302)
   at
gnu.classpath.tools.rmic.SourceGiopRmicCompiler.run(SourceGiopRmicCompiler.java:661)
   at gnu.classpath.tools.rmic.Main.run(Main.java:259)
   at gnu.classpath.tools.rmic.Main.main(Main.java:272)
   at sun.rmi.rmic.Main.compile(Main.java:51)
   at java.lang.reflect.Method.invoke(libgcj.so.71)
   ...23 more
--- Nested Exception ---
/home/marcus/src/debian/build-area/libmx4j-java-3.0.2/build/build.xml:257:
Error starting SUN rmic:
   at org.apache.tools.ant.taskdefs.rmic.SunRmic

[Bug libobjc/32037] --enable-objc-gc on OS X won't build

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-06-03 20:40 ---
I have a fix, it is just a matter of moving stuff around in configure.ac and
adding the correct suffix for "libobjc_gc".


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-06-03 20:40:22
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32037

[Bug libobjc/32037] --enable-objc-gc on OS X won't build

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-06-03 20:46 ---
Actually since libobjc_gc does not exist for the NeXT runtime I am just
changing Makefile.in for the libobjc_gc target not to include the suffix.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32037

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2007-06-03 21:11 
---
I just ran a c version of double precision paranoia, and a single precsion f77
version with latest gcc and gfortran trunk as well as with g77 from 3.4 vintage
and in all cases I get this:

No failures, defects nor flaws have been discovered.
Rounding appears to conform to the proposed IEEE standard P754.
The arithmetic diagnosed appears to be Excellent!
END OF TEST.

Maybe I don't have the latest version of paranoia.  Can you suggest a download
URL?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180

[Bug other/30335] CreateFileMapping fails in Vista due to lack of admin privileges

[dannysmith at users dot sourceforge dot net]

--- Comment #12 from dannysmith at users dot sourceforge dot net  
2007-06-03 21:37 ---
(In reply to comment #11)
> Hi
> 
> 
> Now we looking at the second patch the host-mingw32.c.diff 
> I have not tested it in vista or windows yet. But what I can see
> it using vritualalloc that mean it alloc memory and getting allot slower
> against
> FileMapping we talking about allot extra comping time, and it is not a good
> idea for big project like reactos, and another thing the swap file will 
> incress
> and windows does not always cleanup stuff in the swapfile until a reboot, that
> is few big disages with host-mingw32.c.diff it exists allot other disgante 
> over

Huh?  This is called only once during compilation.  What evidence do you have
that CreateFileMapping is faster than VirtualAlloc here?

We are not sharing memory across processes so we don't really need to create a
named memory-mapped object. I would prefer to keep the memory object anonymous
rather than hardcoding a name that could be accessed by other processes.

Danny




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30335

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

[hjl at lucon dot org]

--- Comment #17 from hjl at lucon dot org  2007-06-03 22:41 ---
I am not sure it is a reassoc2 problem since reassoc1 does the same thing and
pre "corrects" it. However pre isn't run after reassoc2 so that the issue
created
by reassoc2 isn't "corrected". Is that possible to run pre again after
reassoc2?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183

[Bug tree-optimization/32199] New: jc1: out of memory allocating 4072 bytes after a total of 805021000 bytes

[danglin at gcc dot gnu dot org]

libjava fails to build:

/mnt/gnu/gcc/objdir/gcc/gcj
-B/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/
 -B/mnt/gnu/gcc/objdir/gcc/ -fclasspath=
-fbootclasspath=/mnt/gnu/gcc/objdir/hpp
a2.0w-hp-hpux11.11/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated
-fboot
strap-classes -g -O2 -fjni -findirect-dispatch -fno-indirect-classes -c
@org-omg
.list -fPIC -o .libs/org-omg.o

jc1: out of memory allocating 4072 bytes after a total of 805021000 bytes
make[3]: *** [org-omg.lo] Error 1
make[3]: *** Waiting for unfinished jobs

This seems similar to a previous tree optimization bug.


-- 
   Summary: jc1: out of memory allocating 4072 bytes after a total
of 805021000 bytes
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32199

[Bug tree-optimization/32200] New: IV-OPTS does not produce good code for some loops

[pinskia at gcc dot gnu dot org]

While just looking around on the pointer_plus branch I noticed that if I have
independent IVs to start, the code is much worse and there are storing to the
stack (on x86) and everything go crazy after that.
Compare:
void foo (int *a, int *b, int *c, int *d, int *e, int *f)
{
  int i;

  for (i = 0; i < 8; i++)
*(b++) = *(a++) = *(c++) = *(d++) = *(e++) = *(f++);
}



To:

void foo (int *a, int *b, int *c, int *d, int *e, int *f)
{
  int i;

  for (i = 0; i < 8; i++)
b[i] = a[i] = c[i] = d[i] = e[i] = f[i];
}


--- cut -
You will see that in the latter case, we optimize the IV based on one IV (i)
while in the first case, we have 7 IVs which is just wrong.


-- 
   Summary: IV-OPTS does not produce good code for some loops
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32200

[Bug target/26726] -fivopts producing out of bounds array refs

[pinskia at gcc dot gnu dot org]

--- Comment #15 from pinskia at gcc dot gnu dot org  2007-06-04 05:36 
---
One should note that:
/* { dg-final { scan-tree-dump-not "offset: -4B" "ivopts" { xfail i?86-*-*
x86_64-*-* } } } */

Will not match any more since switching over offset to sizetype.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726

[Bug target/32201] New: [4.3 Regression] Can not allocate %xmm0 register for variable blend insn

[ubizjak at gmail dot com]

Currently, it is not possible to use SSE 4.1 variable blend instructions in asm
statements. These instructions require the third argument to be in %xmm0, but
gcc fails to allocate correct register even when (new) "z" constraint is used.

--cut here--
typedef float V4SFmode __attribute__((vector_size(16)));

V4SFmode t (V4SFmode a, V4SFmode b, V4SFmode c)
{
  V4SFmode ret;

  asm ("blenvdps %0, %2, %3" : "=x" (ret) : "0" (a), "x" (b), "z" (c));
  return ret;
}
--cut here--

gcc -O1 -msse

prxxx.c: In function 't':
prxxx.c:7: error: can't find a register in class 'SSE_FIRST_REG' while
reloading 'asm'
prxxx.c:7: error: 'asm' operand has impossible constraints


-- 
   Summary: [4.3 Regression] Can not allocate %xmm0 register for
variable blend insn
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ssemmx, ra
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
OtherBugsDependingO 32189
 nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201