[Bug target/29845] sh floating point emulation is inefficient
--- Comment #4 from christian dot bruel at st dot com 2007-01-31 13:47 --- Hereattached a patch to fix a few problems: 1) Rounding to nearest must be infinity if the "infinitely precise result has a magniture at least 2 exp Emax (2-2exp-p)" (ansi 754/1985 sect 4.1). The implementation for addsf3 and adddf3 returned a NaN. 2) Infinity in divsf3.S was not set (case of 1.0/0.0). 2007-01-29 Christian Bruel <[EMAIL PROTECTED]> * config/sh/IEEE-754/m3/adddf3.S: Fix inf mantissa. * config/sh/IEEE-754/m3/addsf3.S: Likewise. * config/sh/IEEE-754/m3/divsf3.S: Intialize xff00 label. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845
[Bug target/29845] sh floating point emulation is inefficient
--- Comment #5 from christian dot bruel at st dot com 2007-01-31 13:50 --- Created an attachment (id=12986) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12986&action=view) fixes the nearest to infinity and divide by 0 bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845
[Bug target/29845] sh floating point emulation is inefficient
--- Comment #6 from christian dot bruel at st dot com 2007-01-31 13:56 --- (From update of attachment 12986) (note: this diff was made from the wrong direction. (-) shows the newest version. sorry -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845
[Bug middle-end/30807] New: sh postreload bug (might be generic in trunk)
I can only reproduce this problem on the sh target with a gcc version 3.4.3.
However my analysis makes me believe the problem still exists on the trunk.
After greg I have the following sequence :
(insn:HI 11 10 12 0 (set (reg/v/f:SI 2 r2 [orig:160 PrivateData_p ] [160])
(const_int 128 [0x80])) 122 {movsi_i} (nil)
(nil))
(insn:HI 12 11 134 0 (set (reg/v/f:SI 2 r2 [orig:160 PrivateData_p ] [160])
(plus:SI (reg/v/f:SI 2 r2 [orig:160 PrivateData_p ] [160])
(reg:SI 3 r3 [orig:162 Device_p ] [162]))) 23 {*addsi3_compact}
(insn_list 10 (insn_list 11 (nil)))
(expr_list:REG_EQUAL (plus:SI (reg:SI 3 r3 [orig:162 Device_p ] [162])
(const_int 128 [0x80]))
(nil)))
...
(insn:HI 16 135 17 0 (set (reg:SI 1 r1 [166])
(const_int 188 [0xbc])) 122 {movsi_i} (nil)
(nil))
(insn:HI 17 16 18 0 (set (reg:SI 1 r1 [166])
(plus:SI (reg:SI 1 r1 [166])
(reg/v/f:SI 2 r2 [orig:160 PrivateData_p ] [160]))) 23
{*addsi3_compact} (insn_list 16 (nil))
(expr_list:REG_EQUAL (plus:SI (reg:SI 3 r3 [orig:162 Device_p ] [162])
(const_int 316 [0x13c]))
(nil)))
'reload_combine' decides to optimize insns 16/17. After the optimisation, there
is a 'continue' and reload_combines tries other pattern.
The problem is that with this 'continue' reg_state[regno] was is updated with
the other uses (here r2).
later on insn 11/12 are optimized away, believing that r2 is dead because not
makrked in the reg_state use list, leaving it undefined.
The problem is very difficult to isolate (didn't succeed on trunk with i686)
but by reading the postreload code the bug seems latent.
--
Summary: sh postreload bug (might be generic in trunk)
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christian dot bruel at st dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnugcc
GCC target triplet: sh-superh-elf-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
[Bug middle-end/30807] sh postreload bug (might be generic in trunk)
--- Comment #1 from christian dot bruel at st dot com 2007-02-15 15:37 --- The bug might be clearer to explain like this we have 16: (set reg:r1) (const_int 188) 17: (set reg:r1) (plus (reg:r1 reg:r2) 18: (set reg:r1) (mem (plus (reg:r1) (const_int 4)) is transformed into 16: (set reg:r0) (const_int 192) 18: (set reg:r1) (mem (plus (reg:r0) (reg:r2)) since insn 18 is not reg_state[2].reg_use[i].insn, r2 might be seen as dead by another similar combine transformation on previous insns -- christian dot bruel at st dot com changed: What|Removed |Added CC||christian dot bruel at st ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
[Bug middle-end/30807] sh postreload bug (might be generic in trunk)
--- Comment #2 from christian dot bruel at st dot com 2007-02-15 15:55 --- Created an attachment (id=13052) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13052&action=view) Proposed fix for postreload combine the following patch fixes the problem in the sh 3.4.3 compiler. Since I didn't see a similar fix in the trunk, I suspect it is also needed (even if I was not able an isns similar sequence to reproduce the problem). -c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
[Bug middle-end/30807] sh postreload bug (might be generic in trunk)
--- Comment #3 from christian dot bruel at st dot com 2007-02-16 07:04 --- Created an attachment (id=13053) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13053&action=view) Add testcase. compile with sh-superh-elf-gcc (3.4.3) -O2 sh_postreload_bug.c -S -da at line 28 of sh_postreload_bug.s mov.l @(r0,r2),r1 uses an unitialized r2. in sh_postreload_bug.c.26.postreload line 47 r1 was replaced by r2 by postreload_combine. is it generic and not target specific ? see patch and other attachements for proposed analysis and fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
[Bug middle-end/30807] sh postreload bug (might be generic in trunk)
--- Comment #4 from christian dot bruel at st dot com 2007-02-16 07:42 --- looks like a similar analysis for a bigger case was proposed in http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01395.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
[Bug target/29953] [SH-4] Perfomance regression in loops. cmp/eq used instead of dt
--- Comment #3 from christian dot bruel at st dot com 2007-04-03 07:43 --- thank you for reporting this, There is indeed a data dependency on 'r2' introduced by the cmp/eq instruction, preventing the mov and the comparaison to be executed in parallel, unlike the dt on the induction variable. The use of dt seems to be quite sensitive, I checked on various versions sh-gcc (3.3.x, 3.4.x) and it was difficult to find one using the correct strategy. I'll check that issue. Regards, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29953
[Bug target/29953] [SH-4] Perfomance regression in loops. cmp/eq used instead of dt
--- Comment #4 from christian dot bruel at st dot com 2007-04-03 15:30
---
This missed optimisation appears with all counted loops. The ir in gimple
produces
j = 0;
:;
j = j + 1;
if (j <= 999)
{
goto ;
}
The transformation to do ( j=1000; j=j-1; if (j)...) will allow the decrement
and test pattern to be catched by combine.
Since this transformation needs to know about code selection (and is only
useful if the number of issued instructions is > 1), it seems best to do it in
rtl. I'm thinking about strength_reduce in loop.c when we optimize bivs.
Question: does it make sense to do this transformation in loop.c ? I'm thinking
at strength_reduce.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29953
[Bug target/33135] New: [SH] -ffinite-math-only should not be on by default
The documentation of -ffinite-math-only states
"This option should never be turned on by any '-O' option"
but for sh's -mieee it is said "the default is set to -ffinite-math-only"
(-mieee is unset by default)
as a result the -ffinite-math-only is turned on by default for the sh for all
optimisation levels.
on chapter 2 it was reenforced that: ... "*By default*, it (gcc) will act as
the compiler for a hosted implementation" ... and a conforming hosted
implementation
supports the whole standard.
So either the documentation is false or infinite float values should be
supported (by default).
The ability to perform optimum floating point code is preserved by explicitly
setting it.
--
Summary: [SH] -ffinite-math-only should not be on by default
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christian dot bruel at st dot com
GCC target triplet: sh-superh-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33135
[Bug libstdc++/42182] New: memory errors using valarrays
The valarray mask_array implementation creates out of bound memory accesses
when
the number of the True bits is smaller that the size of array, although this
is perfect legal.
This produce valgrin error at best, sometime segfaults, or infinite loops.
To reproduce, compile the attached test:
g++ -O0 va0.cxx
gnx2439$ valgrind ./a.out==1547== Memcheck, a memory error detector
==1547== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==1547== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==1547== Command: ./a.out
==1547==
==1547== Invalid read of size 1
==1547==at 0x80489D1: void std::__valarray_copy(std::_Array,
unsigned int, std::_Array, std::_Array) (in /home/bruel/tmp/a.out)
==1547==by 0x804889A: std::mask_array::operator=(std::valarray
const&) const (in /home/bruel/tmp/a.out)
==1547==by 0x80485C9: main (in /home/bruel/tmp/a.out)
==1547== Address 0x4129061 is 0 bytes after a block of size 1 alloc'd
==1547==at 0x40061CC: operator new(unsigned int) (vg_replace_malloc.c:214)
==1547==by 0x8048644: std::__valarray_get_memory(unsigned int) (in
/home/bruel/tmp/a.out)
==1547==by 0x80488E6: bool* restrict
std::__valarray_get_storage(unsigned int) (in /home/bruel/tmp/a.out)
==1547==by 0x80486EE: std::valarray::valarray(bool const&, unsigned
int) (in /home/bruel/tmp/a.out)
==1547==by 0x804857B: main (in /home/bruel/tmp/a.out)
==1547==
==1547== Invalid write of size 4
==1547==at 0x80489E3: void std::__valarray_copy(std::_Array,
unsigned int, std::_Array, std::_Array) (in /home/bruel/tmp/a.out)
==1547==by 0x804889A: std::mask_array::operator=(std::valarray
const&) const (in /home/bruel/tmp/a.out)
==1547==by 0x80485C9: main (in /home/bruel/tmp/a.out)
==1547== Address 0x4129108 is not stack'd, malloc'd or (recently) free'd
==1547==
==1547==
==1547== HEAP SUMMARY:
==1547== in use at exit: 0 bytes in 0 blocks
==1547== total heap usage: 3 allocs, 3 frees, 9 bytes allocated
==1547==
==1547== All heap blocks were freed -- no leaks are possible
==1547==
==1547== For counts of detected and suppressed errors, rerun with: -v
==1547== ERROR SUMMARY: 56 errors from 2 contexts (suppressed: 19 from 10)
--
Summary: memory errors using valarrays
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christian dot bruel at st 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=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #1 from christian dot bruel at st dot com 2009-11-26 11:32 --- Created an attachment (id=19153) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19153&action=view) reduced case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #2 from christian dot bruel at st dot com 2009-11-26 11:35 --- Created an attachment (id=19154) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19154&action=view) computed assignment test case compiled with g++ -O0 gnx2439$ valgrind ./a.out==1599== Memcheck, a memory error detector ==1599== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==1599== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==1599== Command: ./a.out ==1599== ==1599== Invalid read of size 1 ==1599==at 0x8048A0B: void std::_Array_augmented___plus(std::_Array, std::_Array, std::_Array, unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x80488D4: std::mask_array::operator+=(std::valarray const&) const (in /home/bruel/tmp/a.out) ==1599==by 0x80485E9: main (in /home/bruel/tmp/a.out) ==1599== Address 0x4129061 is 0 bytes after a block of size 1 alloc'd ==1599==at 0x40061CC: operator new(unsigned int) (vg_replace_malloc.c:214) ==1599==by 0x804867E: std::__valarray_get_memory(unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x8048920: bool* restrict std::__valarray_get_storage(unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x8048728: std::valarray::valarray(bool const&, unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x804857B: main (in /home/bruel/tmp/a.out) ==1599== ==1599== Invalid read of size 4 ==1599==at 0x8048A18: void std::_Array_augmented___plus(std::_Array, std::_Array, std::_Array, unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x80488D4: std::mask_array::operator+=(std::valarray const&) const (in /home/bruel/tmp/a.out) ==1599==by 0x80485E9: main (in /home/bruel/tmp/a.out) ==1599== Address 0x4129108 is not stack'd, malloc'd or (recently) free'd ==1599== ==1599== Invalid write of size 4 ==1599==at 0x8048A24: void std::_Array_augmented___plus(std::_Array, std::_Array, std::_Array, unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x80488D4: std::mask_array::operator+=(std::valarray const&) const (in /home/bruel/tmp/a.out) ==1599==by 0x80485E9: main (in /home/bruel/tmp/a.out) ==1599== Address 0x4129108 is not stack'd, malloc'd or (recently) free'd -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #4 from christian dot bruel at st dot com 2009-11-26 11:38 --- Created an attachment (id=19155) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19155&action=view) controversal testcase compile with -O0, Segfaults on x86 with gcc version 4.5.0 20091119 (experimental) [trunk revision 154332] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #5 from christian dot bruel at st dot com 2009-11-26 11:40 --- Created an attachment (id=19156) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19156&action=view) Proposed patch 2009-11-23 Christian Bruel * include/bits/mask_array.h (mask_array<_Tp>::operator=): Use _M_sz. (mask_array<_Tp>::operator _Op##): Likewise. * testsuite/26_numerics/valarray/mask_array.cc: New test. This patch makes the valarray_copy interates on the number of true elements rather than on the array size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #6 from christian dot bruel at st dot com 2009-11-26 12:08 --- (In reply to comment #3) > Hey, this is pointless, the issue is well known and Gaby is the reference > person in this area. > no problem, if the issue is known it can be recorded for the reference, a link to Gaby authoritative answer http://gcc.gnu.org/ml/libstdc++/2009-11/msg00099.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #8 from christian dot bruel at st dot com 2009-11-26 12:18 --- (In reply to comment #7) > What I meant, exactly, is that if any issue is well known to the concerned > people, there is no need for a Bugzilla, in particular an invalid one ;) > Well I still need to be convinced that va0.cxx here is invalid : it is a 5 lines of simple conforming code that produces a segfault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #10 from christian dot bruel at st dot com 2009-11-26 17:44 --- Paolo, I entered this defect for user reference, since the problem that originates the thread occurs in many public places such as testsuites (perenial Sec26/P26774) or class books (http://www.linux-kheops.com/doc/casteyde/cours_cpp-1.40.1/htm/x5866.htm#AEN6045) 14-21. Digging on the net, it's not difficult to find other instances of the same problem, All fail for the same reason: out of bound access from the mask array or exibit a valgrind error. FYU they pass with the proposed patch, I'm glad that it was not a bug with the library, and to have opened the discussion. just wanted to avoid future duplicate reports on the same problem an extra analysis. I didn't want to add extra burden to the maintainers of course, sorry if it was the case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug c++/32066] member/type lookup doesn't work properly with templates
--- Comment #1 from christian dot bruel at st dot com 2009-12-07 08:13
---
I'm wondering if this is not an application of the name hiding rule described
in the IEC 14882:1998 (3.3.7) that says here that the class name T::X is hidden
by the object static int T::X i, so T::X y refers to the object's name not the
class. Making the test invalid. Not certain, just a thought.
This could be reduced as
struct A
{
#ifdef X_MEMBER
static int X;
#endif
#ifdef X_NAME
struct X { };
#endif
} ;
void foo(void)
{
#ifdef X_NAME
A::X y;
#endif
#ifdef X_MEMBER
A::X = 1;
#endif
}
if both X_NAME and X_MEMBER are defined the line A::X y; becomes invalid.
--
christian dot bruel at st dot com changed:
What|Removed |Added
CC| |christian dot bruel at st
| |dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32066
[Bug c++/39982] Fail to use constructor to initialize volatile declaration (no matching function for call)
--- Comment #1 from christian dot bruel at st dot com 2009-12-07 09:08
---
A reduced case. Still doesn't compile on 4.5
struct T
{
int i;
T(int _i) ;
};
void foo()
{
volatile T t1 = 1;
}
--
christian dot bruel at st dot com changed:
What|Removed |Added
CC||christian dot bruel at st
| |dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39982
[Bug c++/32066] member/type lookup doesn't work properly with templates
--- Comment #3 from christian dot bruel at st dot com 2009-12-07 16:41
---
> The test can be reduced to this, which should not compile:
>
> struct A {
> struct X { };
> int X;
> };
> template void f(T t) {
> typename T::X x;
> }
> void foo() {
> A a;
> f(a); // error: T::X refers to the data member A::X not the struct A::X
> }
>
OK. note that with the original tests, 'int X' was declared static.
That makes the case a little bit different since 3.3.7.2 refers to "object,
function or enumerator", not class member.
So variants of this case have declarations:
struct A {
struct X { };
enum x {a, b, c} X;
};
and
struct A {
struct X { };
void X();
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32066
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #3 from christian dot bruel at st dot com 2010-01-22 11:47 --- Hello, I had a similar problem a while ago, but was never able to reproduce on trunk. I was a phasing problem between branch_shortening from sh_reorg and the delayed branch scheduler, that would change the size of a bf (2) against a bf/s+instruction (4). Thus breaking surrounding branch offsets. -fno-delayed-branch is the workaround. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #4 from christian dot bruel at st dot com 2010-01-22 12:06 --- Created an attachment (id=19689) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19689&action=view) Conservative fix. Conservatively increase length of undelayed conditional branches to prevent a problem with the ds scheduler inserting an instruction in the slot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #6 from christian dot bruel at st dot com 2010-01-22 12:58 --- (In reply to comment #5) > (In reply to comment #4) > > Conservatively increase length of undelayed conditional branches to prevent > > a > > problem with the ds scheduler inserting an instruction in the slot. > > Looks fine. A very minor nit, JUMP_P and JUMP_TABLE_DATA_P macro > can be used for the first 3 lines of the if-condition. > Thanks. I don't think I can use JUMP_TABLE_DATA_P since this is a != test and JUMP_TABLE_DATA_P includes JUMP_P. Anyway, OK for trunk ? (just need to fix the date in the ChangeLog). regtesting done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #8 from christian dot bruel at st dot com 2010-01-22 13:49 --- Created an attachment (id=19690) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19690&action=view) and cleanup with JUMP_TABLE_DATA_P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #9 from christian dot bruel at st dot com 2010-01-22 13:51 --- (In reply to comment #7) > (In reply to comment #6) > > Anyway, OK for trunk ? (just need to fix the date in the ChangeLog). > > regtesting > > done. > > OK. And the patch is pre-approved for branches too after one week or so. > > BTW, I mean JUMP_P(x) && !JUMP_TABLE_DATA_P(x): > didn't read you correctly. So I took the opportunity to cleanup every other occurrences of the same idioms in the file. OK ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug c++/19531] New: RVO is performed on volatile temporary
RVO is performed on a temporary object that is declared volatile.
That seems contradictory with the ISO standards 12.8 15 (object and copy must
have the same cv-unqualified type).
With the following piece of code, I was excepting the copy constructor and
destructor to be called.
struct String
{
int field;
String();
String(int);
~String();
String (const String &);
String (volatile const String &);
};
String name()
{
volatile String t(777);
return t;
}
checking !TREE_VOLATILE (r) in finish_function where the named return value
optimization is set up fixes the problem.
--
Summary: RVO is performed on volatile temporary
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christian dot bruel at st dot com
CC: gcc-bugs at gcc dot gnu dot org
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=19531
