[Bug middle-end/25335] [4.1/4.2 Regression] reload leaves insns from earlier passes around: fatal for postinc

2006-07-20 Thread amylaar at spamcop dot net 


--- Comment #21 from amylaar at spamcop dot net  2006-07-20 17:08 ---
Subject: Re:  [4.1/4.2 Regression] reload leaves
insns from earlier passes around: fatal for postinc

Quoting pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>:

>
>
> --- Comment #20 from pinskia at gcc dot gnu dot org  2006-07-20 11:13
> ---
> This was fixed, correct?

Yes, on mainline and 4.1.


-- 


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

[Bug rtl-optimization/24194] emit_input_reload_insns secondary reload handling is unsafe

2006-07-20 Thread amylaar at spamcop dot net 


--- Comment #2 from amylaar at spamcop dot net  2006-07-20 17:57 ---
Subject: Re:  emit_input_reload_insns secondary
reload handling is unsafe

Quoting pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>:

>
>
> --- Comment #1 from pinskia at gcc dot gnu dot org  2006-07-20 11:19
> ---
> Isn't this really fixed by the TARGET_SECONDARY_RELOAD target hook?

reload_adjust_reg_for_temp checks only the first hard register for suitability
wrt. NEW_CLASS.
I.e. we check TEST_HARD_REG_BIT (reg_class_contents[(int) new_class], regno) ,
but for a two-hard-reg register we'd also have to check
TEST_HARD_REG_BIT (reg_class_contents[(int) new_class], regno) .

AFAICT the other issues in this PR have been addresssed.


-- 


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

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

2007-05-14 Thread amylaar at spamcop dot net 


--- Comment #32 from amylaar at spamcop dot net  2007-05-14 16:39 ---
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

Quoting pcarlini at suse dot de <[EMAIL PROTECTED]>:

>
> safely when the target doesn't have infinities. Therefore, I would ask you to
> untangle a bit this thing... Apparently, for some reason, for your target
> onte
> of the checks (which one? !finitef? !finite?) is not working, instead the
> final
> f != __builtin_huge_valf() catches it.

These are excepts from
arc-elf32/arc700/libstdc++-v3/include/arc-elf32/bits/c++config.h:

/* Define to 1 if you have the `finitef' function. */
/* #undef _GLIBCXX_HAVE_FINITEF */
/* Define to 1 if you have the `_finitef' function. */
/* #undef _GLIBCXX_HAVE__FINITEF */
/* Define to 1 if you have the `finite' function. */
/* #undef _GLIBCXX_HAVE_FINITE */
/* Define to 1 if you have the `_finite' function. */
/* #undef _GLIBCXX_HAVE__FINITE */
/* Define to 1 if you have the `isinf' function. */
/* #undef _GLIBCXX_HAVE_ISINF */
/* Define to 1 if you have the `_isinf' function. */
/* #undef _GLIBCXX_HAVE__ISINF */

Thus, the test that should be performed in
_ZSt14__convert_to_vIfEvPKcRT_RSt12_Ios_IostateRKPi should be:

  if (fabs(__d) > numeric_limits::max())
errno = ERANGE;

Disassembly of that method shows that the test has been
optimized away.
This is not actually surprising, because _GLIBCXX_HAVE_STRTOF
has been set, and hence strtof has been used, and
__d remained uninitalized.


-- 


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

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

2007-05-14 Thread amylaar at spamcop dot net 


--- Comment #34 from amylaar at spamcop dot net  2007-05-14 19:25 ---
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

Quoting pcarlini at suse dot de <[EMAIL PROTECTED]>:

> Now, the strange thing is that, before these two last patches (in 4_2-branch
> in
> other terms), errno doesn't turn out to be == ERANGE for your target: strtof
> should have set it...

It's lameness in newlib.

newlib/libc/stdlib/strtod.c defines:

float
_DEFUN (strtof, (s00, se),
_CONST char *s00 _AND
char **se)
{
  double retval = _strtod_r (_REENT, s00, se);
  if (isnan (retval))
return nanf (NULL);
  return (float)retval;
}


-- 


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

[Bug middle-end/16266] [4.0 regression] gcc.dg/c99-intconst-1.c compilation is very slow

2004-10-06 Thread amylaar at spamcop dot net 

--- Additional Comments From amylaar at spamcop dot net  2004-10-07 06:44 ---
Subject: Re:  [4.0 regression] gcc.dg/c99-intconst-1.c compilation is very slow

> 
> 
> --- Additional Comments From giovannibajo at libero dot it  2004-10-06 23:19 
> ---
> I cannot reproduce this on mainline 20040923 on x86-linux with a disable 
> checking compiler. So either:
> 
> - the bug is already fixed
> - the bug only appears crossing to sh-elf
> - the bug does not exist with disable-checking so we do not care
> (should we?)
> 
> Joern, can you please check which of the three above applies?

That is had to check at the moment:

../../srcw/gcc/config/sh/sh.c:9416: `DW_CC_renesas_sh' undeclared (first use in this 
function)
../../srcw/gcc/config/sh/sh.c:9416: (Each undeclared identifier is reported only once
../../srcw/gcc/config/sh/sh.c:9416: for each function it appears in.)
make[1]: *** [sh.o] Error 1
make[1]: Leaving directory `/swbuild/nightly/2004-10-07/sh-elf/gcc'
make: *** [all-gcc] Error 2


-- 


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