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 <>
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 forewo
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
> 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
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
> >
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 successful
> 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.
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 u
> 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 des
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
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).
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 encoun
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
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
> 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 GetPr
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
> un
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 a
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 a
18 matches
Mail list logo
