--- 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 pr
--- 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
--- 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 in
--- 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
--- 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
--- 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() {
>
--- 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|Re
--- 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 refe
--- 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
--- 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 n
--- 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,
--- 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_ar
--- 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 (exper
--- 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
--- 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
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
htt
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
--- 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)...) w
--- 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
--- 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 #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 lin
--- 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.
--- 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
duct: 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 tripl
--- 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
--- 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
--- 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
impl
hristian 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
28 matches
Mail list logo
