GCC 4.4.0 Status Report (2008-11-17)
Status == We are now in regression and documentation fixes only mode. When the number of P1 bugs drops to zero and the number of P1, P2 and P3 bugs reaches 100, we'll branch 4.4.0 and open 4.5 stage 1. The old register allocator hasn't been removed yet, but will be before branching. There are still several targets that haven't been converted to IRA; unless they are converted soon, they will be dropped. The unconverted targets are: arc m32c m68hc11 mmix pdp11 score vax Quality Data Priority # Change from Last Report --- --- P1 13 - 4 P2 114 - 27 P33 +- 0 --- --- Total 130 - 31 We've made a good progress on fixing P1 and especially P2 bugs, but File /tmp/X not changed so no update needed [EMAIL PROTECTED] gcc]$ cat /tmp/X "Joseph S. Myers" <[EMAIL PROTECTED]> GCC 4.4.0 Status Report (2008-11-17) Status == We are now in regression and documentation fixes only mode. When the number of P1 bugs drops to zero and the number of P1, P2 and P3 bugs reaches 100, we'll branch 4.4.0 and open 4.5 stage 1. The old register allocator hasn't been removed yet, but will be before branching. There are still several targets that haven't been converted to IRA, so unless they are converted soon, they will be dropped. The unconverted targets are: arc m32c m68hc11 mmix pdp11 score vax Quality Data Priority # Change from Last Report --- --- P1 13 - 4 P2 114 - 27 P33 +- 0 --- --- Total 130 - 31 We've made a good progress on fixing P1 and especially P2 bugs, but still have many to fix before we reach the criteria for branching 4.4.0. Several of the P2 and P1 bugs have patches posted, but not reviewed yet. All but one P1s are regressions from 4.3 and there are 25 P2 regressions from 4.3, especially those should be given attention. Previous Report === http://gcc.gnu.org/ml/gcc/2008-11/msg7.html The next report for 4.4.0 will be sent by Joseph.
GCC 4.4.0 Status Report (2008-11-17)
Status == We are now in regression and documentation fixes only mode. When the number of P1 bugs drops to zero and the number of P1, P2 and P3 bugs reaches 100, we'll branch 4.4.0 and open 4.5 stage 1. The old register allocator hasn't been removed yet, but will be before branching. There are still several targets that haven't been converted to IRA, so unless they are converted soon, they will be dropped. The unconverted targets are: arc m32c m68hc11 mmix pdp11 score vax Quality Data Priority # Change from Last Report --- --- P1 13 - 4 P2 114 - 27 P33 +- 0 --- --- Total 130 - 31 We've made a good progress on fixing P1 and especially P2 bugs, but still have many to fix before we reach the criteria for branching 4.4.0. Several of the P2 and P1 bugs have patches posted, but not reviewed yet. All but one P1s are regressions from 4.3 and there are 25 P2 regressions from 4.3, especially those should be given attention. Previous Report === http://gcc.gnu.org/ml/gcc/2008-11/msg7.html The next report for 4.4.0 will be sent by Joseph.
Re: GCC 4.4.0 Status Report (2008-11-17)
On Mon, 2008-11-17 11:34:09 +0100, Jakub Jelinek <[EMAIL PROTECTED]> wrote: > The old register allocator hasn't been removed yet, but will be before > branching. There are still several targets that haven't been converted > to IRA, so unless they are converted soon, they will be dropped. The > unconverted targets are: > [...] > pdp11 [...] > vax I didn't actually follow the development of the new IRA, but if I find the patches for other simple targets, I might work at least on VAX and probably for pdp11, too. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of:http://www.chiark.greenend.org.uk/~sgtatham/bugs.html the second : signature.asc Description: Digital signature
Re: Cygwin support
> To get around this you'd have to either > link a separate copy of the plugin for each executable, or access the > symbols in the executable indirectly through GetProcAddress and function > pointers. Hacking the compiler (or postlinker!) to emit a special constructor that does the necessary GetProcAddress invocations seems not too hard... Paolo
Re: GCC 4.4.0 Status Report (2008-11-17)
Hi, I'd like to pointer that the new __optimize__ attribute doesn't work correctly: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565 Will it be fixed in 4.4? H.J. --- On Mon, Nov 17, 2008 at 2:15 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote: > Status > == > > We are now in regression and documentation fixes only mode. > > When the number of P1 bugs drops to zero and the number of > P1, P2 and P3 bugs reaches 100, we'll branch 4.4.0 and open > 4.5 stage 1. > > The old register allocator hasn't been removed yet, but will be before > branching. There are still several targets that haven't been converted > to IRA; unless they are converted soon, they will be dropped. The > unconverted targets are: > > arc > m32c > m68hc11 > mmix > pdp11 > score > vax > > Quality Data > > > Priority # Change from Last Report > --- --- > P1 13 - 4 > P2 114 - 27 > P33 +- 0 > --- --- > Total 130 - 31 > > We've made a good progress on fixing P1 and especially P2 bugs, but > File /tmp/X not changed so no update needed > [EMAIL PROTECTED] gcc]$ cat /tmp/X > "Joseph S. Myers" <[EMAIL PROTECTED]> > GCC 4.4.0 Status Report (2008-11-17) > > Status > == > > We are now in regression and documentation fixes only mode. > > When the number of P1 bugs drops to zero and the number of > P1, P2 and P3 bugs reaches 100, we'll branch 4.4.0 and open > 4.5 stage 1. > > The old register allocator hasn't been removed yet, but will be before > branching. There are still several targets that haven't been converted > to IRA, so unless they are converted soon, they will be dropped. The > unconverted targets are: > > arc > m32c > m68hc11 > mmix > pdp11 > score > vax > > Quality Data > > > Priority # Change from Last Report > --- --- > P1 13 - 4 > P2 114 - 27 > P33 +- 0 > --- --- > Total 130 - 31 > > We've made a good progress on fixing P1 and especially P2 bugs, but > still have many to fix before we reach the criteria for branching > 4.4.0. Several of the P2 and P1 bugs have patches posted, but > not reviewed yet. > > All but one P1s are regressions from 4.3 and there are 25 P2 regressions > from 4.3, especially those should be given attention. > > Previous Report > === > > http://gcc.gnu.org/ml/gcc/2008-11/msg7.html > > The next report for 4.4.0 will be sent by Joseph. >
bootstrap with -ftree-parallelize-loops
Hi, I'm trying to bootstrap with -ftree-parallelize-loops=4 enabled (passed as BOOTCFLAGS). I'm failing at the begining of stage2 because the compiler can't find libgomp.spec Can anyone help..? Thanks, Razya
Re: bootstrap with -ftree-parallelize-loops
On Mon, Nov 17, 2008 at 11:01 AM, Razya Ladelsky <[EMAIL PROTECTED]> wrote: > Hi, > > I'm trying to bootstrap with -ftree-parallelize-loops=4 enabled (passed as > BOOTCFLAGS). > I'm failing at the begining of stage2 because the compiler can't find > libgomp.spec > Can anyone help..? You are encountering a phase ordering problem. libgomp.spec is in the libgomp target library build directory, but that is not configured and created until the target libraries are built, after the compiler is built. I am not sure if using the previously installed library and spec file with the new compiler is reliable. David
Inlining "unexpected behaviour"
Hi there,
I am coding a library to perform a statistical method. I have been using a -O2
optimisation level but I have just realised that switching it on and off
yields different results.
I have two functions cal_probability_var() and cal_heterozygosity(), the first
calls the second (see below). If I compile my code without optimisation I get
the expected result but if optimisations are allowed I get the wrong result.
My best guess is that the problem is that with optimisations the function
cal_heterozygosity() is inlined within cal_probability_var() (using gdb I
confirmed it because gdb behaves as expected for inlined functions).
To my surprise, if I swap the operators of the multiplication from:
ln_2z = log(2.0) * cal_heterozygosity(dist_matrix, table_type);
to:
ln_2z = cal_heterozygosity(dist_matrix, table_type) * log(2.0);
then the problem disappears.
My main concerned is whether the way I have coded cal_heterozygosity()
conflicts with GCC or whether there is a bug in GCC. If it is indeed my
mistake I would like to know what is wrong with the coding as I may be using
the same standards to code other functions in my library. Or, it is possible
to get access to the source code once it has been optimised?.
static long double
cal_probability_var(enumDistMatrix *dist_matrix,
enumTableType table_type)
{
gulong *table;
guint i, j;
long double ln_fij = 0.0;
long double ln_2z;
table = get_table(dist_matrix, table_type);
ln_2z = log(2.0) * cal_heterozygosity(dist_matrix, table_type);
//ln_2z = cal_heterozygosity(dist_matrix, table_type) * log(2.0);
for (i = 0 ; i < dist_matrix->k ; i++) {
for (j = 0 ; j <= i ; j++) {
ln_fij += fac_get_factorial(dist_matrix->factorials,
table[OFFSET(i, j, dist_matrix->k)]);
}
}
return (ln_2z - ln_fij);
}
static gulong
cal_heterozygosity (enumDistMatrix *dist_matrix,
enumTableType table_type)
{
gulong *table;
guint i;
gulong total = dist_matrix->n;
table = get_table(dist_matrix, table_type);
for (i = 0 ; i < dist_matrix->k ; i++) {
total -= table[OFFSET(i, i, dist_matrix->k)];
}
return total;
}
Thanks
Hazael
Re: Invalid code generated for Coldfire target
Meloun Michal wrote:
Hello all,
I tracing bug in GCC for Coldfire target, but I end in dead water and
I need some help from real experts :).
Both gcc 4.4 and 4.3 have same problem
GCC miscompile this small test case.
//-
//m68k-elf-gcc -save-temps -da -fdump-tree-all -fdump-ipa-all -c test.c -o
test.o
void dummy(char *arg);
static void test1(void)
{
char tmp[2] = "0";
}
void test2(void)
{
dummy("0");
}
//--
The file is compiled to:
#NO_APP
.file "test.c"
.section.rodata
.LC0:
.string "0"
.text
.align 2
.type test1, @function
test1:
link.w %fp,#-4
lea .LC0,%a0
move.w (%a0),-2(%fp)
unlk %fp
rts
.size test1, .-test1
.align 2
.globl test2
.type test2, @function
test2:
link.w %fp,#0
move.l %a0,-(%sp) <-- note: a0 is used uninitialized here
jsr dummy
addq.l #4,%sp
unlk %fp
rts
.size test2, .-test2
.ident "GCC: (GNU) 4.4.0 20081031 (experimental)"
And relevant part of RTL after expand pass:
;; Function test1 (test1)
;; Generating RTL for gimple basic block 2
;; tmp ={v} "0";
(insn 5 4 0 test.c:8 (set (mem/s/c:HI (plus:SI (reg/f:SI 26 virtual-stack-vars)
(const_int -2 [0xfffe])) [0 tmp+0 S2 A16])
(mem/s:HI (symbol_ref/f:SI ("*.LC0") [flags 0x2] ) [0 S2 A8])) -1 (nil))
;; Function test2 (test2)
;; Generating RTL for gimple basic block 2
;; dummy (&"0"[0]);
<--- bad insn here -
(insn 5 4 6 test.c:15 (set (mem/f/i:SI (pre_dec:SI (reg/f:SI 15 %sp)) [0 S4
A16])
(reg:SI 8 %a0)) -1 (nil))
<--
(call_insn 6 5 7 test.c:15 (call (mem:QI (symbol_ref:SI ("dummy") [flags 0x41]
) [0 S1 A8])
(const_int 4 [0x4])) -1 (nil)
(nil))
(insn 7 6 0 test.c:15 (set (reg/f:SI 15 %sp)
(plus:SI (reg/f:SI 15 %sp)
(const_int 4 [0x4]))) -1 (nil))
After some debugging, I found cause of this bug, but proper solution is
not clear for me. When "char tmp[2] = "0";" is compiled, the function
"output_constant_def"
is called and proper insn is stored into cache:
(gdb) call debug_rtx(desc->rtl)
(mem/s:HI (symbol_ref/f:SI ("*.LC0") [flags 0x2] ) [0
S2 A8])
Later, in ira pass, this insn is spitted to this (Coldfire has no memory to
memory move):
Reloads for insn # 5
Reload 0: reload_in (SI) = (symbol_ref/f:SI ("*.LC0") [flags 0x2] )
ADDR_REGS, RELOAD_FOR_INPUT (opnum = 1), inc by 2
reload_in_reg: (symbol_ref/f:SI ("*.LC0") [flags 0x2] )
reload_reg_rtx: (reg:SI 8 %a0)
...
(note 2 3 14 2 NOTE_INSN_FUNCTION_BEG)
(insn 14 2 5 2 test.c:7 (set (reg:SI 8 %a0)
(symbol_ref/f:SI ("*.LC0") [flags 0x2] )) 38
{*movsi_cf} (nil))
(insn 5 14 13 2 test.c:7 (set (mem/s/c:HI (plus:SI (reg/f:SI 14 %a6)
(const_int -2 [0xfffe])) [0 tmp+0 S2 A16])
(mem/s:HI (reg:SI 8 %a0) [0 S2 A8])) 41 {*m68k.md:906} (nil))
;; End of basic block 2 -> ( 1)
;; lr out 14 [%a6] 15 [%sp] 24 [%argptr]
The first insn is newly allocated, but second one overwrites original insn.
From local point of view, this is still OK, but this corrupt the
output_constant_def
cache (cache holds pointer to overwritten insn. So every
next access to "0" constat returns
(mem/s:HI (reg:SI 8 %a0) [0 S2 A8])) 41 {*m68k.md:906} (nil))
and not
(symbol_ref/f:SI ("*.LC0") [flags 0x2] )) 38
{*movsi_cf} (nil))
But how to fix this? By my mean, the cache must hold own immutable copy of insn.
But im not gcc expert, so I need help with proper solution. Is this patch OK?
Any other solution?
--- varasm.c.orig 2008-11-14 18:04:27.693643900 +0100
+++ varasm.c2008-11-14 17:58:06.522748300 +0100
@@ -3245,7 +3245,7 @@
}
maybe_output_constant_def_contents (desc, defer);
- return desc->rtl;
+ return copy_rtx (desc->rtl);
}
/* Subroutine of output_constant_def: Decide whether or not we need to
-
Moreover, this can be common problem on more places (at least at
gen_rtx_CONST_INT).
Ohh, and sorry for my english.
Many thanks
Michal Meloun
Can you forward all the debugging dumps? Clearly there's a structure
sharing problem here, but I'd like to see the full dumps.
Jeff
Re: GCC 4.4.0 Status Report (2008-11-17)
> The old register allocator hasn't been removed yet, but will be > before branching. There are still several targets that haven't been > converted to IRA, so unless they are converted soon, they will be > dropped. The unconverted targets are: > > m32c I'd like to once again point out that despite the efforts of myself, Vlad, and Jeff, we are not yet able to get IRA to support the m32c target. I would like to request NOT removing the old allocator until this is resolved.
Re: GCC 4.4.0 Status Report (2008-11-17)
On Mon, Nov 17, 2008 at 1:43 PM, DJ Delorie <[EMAIL PROTECTED]> wrote: > >> The old register allocator hasn't been removed yet, but will be >> before branching. There are still several targets that haven't been >> converted to IRA, so unless they are converted soon, they will be >> dropped. The unconverted targets are: >> >> m32c > > I'd like to once again point out that despite the efforts of myself, > Vlad, and Jeff, we are not yet able to get IRA to support the m32c > target. I would like to request NOT removing the old allocator until > this is resolved. What level of 'not support' is that? Is it completely unable to generate code or are there only testsuite regressions? Richard.
Re: GCC 4.4.0 Status Report (2008-11-17)
> What level of 'not support' is that? Is it completely unable to > generate code or are there only testsuite regressions? There's no definition of that macro (that we could find) that lets you build newlib successfully. I can't run the testsuite without newlib.
Re: GCC 4.4.0 Status Report (2008-11-17)
On Mon, Nov 17, 2008 at 9:33 PM, DJ Delorie <[EMAIL PROTECTED]> wrote: > >> What level of 'not support' is that? Is it completely unable to >> generate code or are there only testsuite regressions? > > There's no definition of that macro (that we could find) that lets you > build newlib successfully. How does it fail? Is it related to m32c, ehm, interesting architectural features (24 bits addresses and only 2 address registers IIRC)? Or is there a bigger problem that some of the other not-yet-converted targets may run into also? Gr. Steven
Re: GCC 4.4.0 Status Report (2008-11-17)
On Mon, Nov 17, 2008 at 12:01:45PM +0100, Jan-Benedict Glaw wrote:
> On Mon, 2008-11-17 11:34:09 +0100, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> > The old register allocator hasn't been removed yet, but will be before
> > branching. There are still several targets that haven't been converted
> > to IRA, so unless they are converted soon, they will be dropped. The
> > unconverted targets are:
> >
> [...]
> > pdp11
> [...]
> > vax
>
> I didn't actually follow the development of the new IRA, but if I find
> the patches for other simple targets, I might work at least on VAX and
> probably for pdp11, too.
On most targets it is just a matter of finding the right definition of
IRA_COVER_CLASSES macro and testing it. tm.texi describes it briefly;
if you need help with the right definition, please get in touch with Vlad
Makarov.
Given that vax has
enum reg_class { NO_REGS, ALL_REGS, LIM_REG_CLASSES };
#define GENERAL_REGS ALL_REGS
I guess
#define IRA_COVER_CLASSES \
{ \
GENERAL_REGS, LIM_REG_CLASSES \
}
in vax.h will do it, but you need to test that. pdp11 might be harder.
Jakub
Re: GCC 4.4.0 Status Report (2008-11-17)
> How does it fail? Is it related to m32c, ehm, interesting > architectural features (24 bits addresses and only 2 address > registers IIRC)? I think so. The m32c family has such a non-orthogonal register set that there's a lot of small register classes. There are few cases where GENERAL_REGS is the right class for a given insn. GCC has always had a hard time doing register allocation and reload for this target, and IRA makes it just worse enough at it that some of the newlib sources can no longer be built. Note that m32c-elf is a standard newlib-sim target, so if anyone wants to play with it, it's easy enough to build and test as a cross-compiler.
Valid optimization with constant arrays
I noticed that for a simple testcase:
int t;
void abort (void);
int f(int t, const int *a)
{
const int b[] = { 1, 2, 3};
if (!t)
return f(1, b);
return b == a;
}
int main(void)
{
if (f(0, 0))
abort ();
return 0;
}
--- CUT ---
That before 4.0 gives a different result from 4.0 and above. Is it
valid in this case to promote b to a static variable and have f return
true when called with f(0, 0) ?
I think C99 does allows this optimization (at least according to the
normative note 112) but C++ does not. I could not find anything in
C++ standard which says the compiler could put the const object in a
read-only section but I could be missing something somewhere.
Thanks,
Andrew Pinski
Re: Valid optimization with constant arrays
On Mon, 17 Nov 2008, Andrew Pinski wrote:
> I think C99 does allows this optimization (at least according to the
> normative note 112) but C++ does not. I could not find anything in
I don't know what you mean by "normative note" ("In accordance with Part 3
of the ISO/IEC Directives, this foreword, the introduction, notes,
footnotes, and examples are also for information only"), but my view
having read the comp.std.c discussion is that this is clearly not allowed
by C99. It would be if a const-qualified compound literal were being used
instead of a named variable, because of express wording allowing such
compound literals not to designate distinct objects, but each recursive
copy of a named variable with automatic storage duration must be a
distinct object where this can be detected (e.g. through the address being
taken, as here).
--
Joseph S. Myers
[EMAIL PROTECTED]
Variadic template function full specialization.
Hello all,
Following (bit weird ;-) code shows weird case of variadic template
function specialization, however I am not sure it is legal, (atleast I
haven't found any wording that would prevent such use):
enum SelectFoo {S1, S2, S3};
struct A
{
template
void foo (Args_...);
};
template <> void
A::foo (int) {} // #1 compiles fine
template <> void
A::foo () {} // #2 this won't compile (error: template-id
'foo<(SelectFoo)1u>' for 'void A::foo()' does not match any template
declaration)
template <> void
A::foo (int, int) {} // #3 this won't compile too (error:
template-id 'foo<(SelectFoo)2u>' for 'void A::foo(int, int)' does not
match any template declaration)
I have checked this code with g++-4.3.2 and g++-4.4.0-alpha20081010
(gentoo ebuild)
It seems that variadic type pack Args_... is always treated as one parameter.
When I have tried declaration like:
template
void foo (T_, More_...);
it could match specialization with two parameters only, 'foo(int,
int)' in this example.
If I would provide all three declarations ie.
struct A
{
template
void foo ();
template
void foo (T_);
template
void foo (T1_, T2_);
};
everything compiles fine, with both gcc and Comeau C/C++ online, as
one would expect.
My question is: whether all specializations (#1, #2, #3) should be accept,
or it is just illegal use of variadic templates not reported here, and
#1 is accepted incorrectly,
or this is expected result?
Piotr
