--- 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
--- 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=19689action=view)
Conservative fix.
Conservatively increase length of undelayed conditional branches to prevent a
problem
--- 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
--- 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=19690action=view)
and cleanup with JUMP_TABLE_DATA_P
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
--- 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
--- 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
--- 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
--- 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;
};
templateclass T void f(T t) {
typename T::X x;
}
void foo() {
A a;
f(a); // error: T::X refers
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
--- 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=19153action=view)
reduced case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
--- 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=19154action=view)
computed assignment test case
compiled with g++ -O0
gnx2439$ valgrind ./a.out==1599== Memcheck, a memory
--- 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=19155action=view)
controversal testcase
compile with -O0, Segfaults on x86 with
gcc version 4.5.0 20091119 (experimental
--- 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=19156action=view)
Proposed patch
2009-11-23 Christian Bruel christian.br...@st.com
* include/bits/mask_array.h
--- 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
--- 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
--- 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
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
--- 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
--- 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;
D1202:;
j = j + 1;
if (j = 999)
{
goto D1202;
}
The transformation to do ( j=1000; j=j-1; if (j
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
--- 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
--- 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=13052action=view)
Proposed fix for postreload combine
the following patch fixes the problem in the sh 3.4.3 compiler.
Since I
--- 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=13053action=view)
Add testcase.
compile with sh-superh-elf-gcc (3.4.3) -O2 sh_postreload_bug.c -S -da
at line 28
--- 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
--- 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
--- 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=12986action=view)
fixes the nearest to infinity and divide by 0 bugs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845
--- 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
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
28 matches
Mail list logo
