Daniel Berlin wrote on 04/14/07 22:59:
> If there was stmt->aux we'd put it there instead (note that the
> current way wastes memory, since we really only care about UID's for
> statements that generate vdefs/vuses)
That's the thing. There currently is *no* "aux" field to do this. We
may be for
On 4/15/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote on 04/14/07 22:59:
> If there was stmt->aux we'd put it there instead (note that the
> current way wastes memory, since we really only care about UID's for
> statements that generate vdefs/vuses)
That's the thing. There c
> * hppa64-hp-hpux11.11: many failures
Most of these are "Type/rank mismatch in argument":
FAIL: gfortran.dg/assumed_charlen_function_5.f90 -O (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/assumed_charlen_function_5.f90:22: E
rror: Type/rank mismatch in arg
Thanks Tim for sending the dump files!
> for this one:
> > FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vectorized 1 loops 1
>
> there should be { target vect_unpack } added to the check. i.e.:
> - /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } }
*/
> + /* { dg-final { sc
The GCC SC has been considering the issue of maintainers for the C/C++
preprocessor, and has:
1. Appointed Tom Tromey as a non-algorithmic maintainer for the
preprocessor. Congratulations, Tom!
2. Appointed the C and C++ maintainers as co-maintainers of the
preprocessor. This appointment is not
Manuel López-Ibáñez wrote:
> Then, if the warnings are not very useful but are mandated by the
> standard, I think that the sensible thing is to make them conditional
> on -pedantic. This way, people wanting strict diagnostics for
> nonconformant code can get them, while people that don't care abo
If you try
../gcc-4.1.2/configure; make bootstrap
on a powerpc-darwin G4 system, then the bootstrap will fail because
the process builds 64-bit multilibs and tries to execute a program
with "xgcc -m64'.
In May 2005, PR 21561 reported this same problem on 32-bit x86
solaris; the workaroun
On 4/15/07, Bradley Lucier <[EMAIL PROTECTED]> wrote:
If you try
../gcc-4.1.2/configure; make bootstrap
on a powerpc-darwin G4 system, then the bootstrap will fail because
the process builds 64-bit multilibs and tries to execute a program
with "xgcc -m64'.
Again this is not magic or rock scie
On Apr 15, 2007, at 6:37 PM, Andrew Pinski wrote:
On 4/15/07, Bradley Lucier <[EMAIL PROTECTED]> wrote:
If you try
../gcc-4.1.2/configure; make bootstrap
on a powerpc-darwin G4 system, then the bootstrap will fail because
the process builds 64-bit multilibs and tries to execute a program
wi
As has been remarked on the GCC mailing lists, I've not succeeded in
getting GCC 4.2.0 out the door. However, with the limited criteria that
we target only P1 regressions not present in 4.1.x, we seem to be
getting a bit closer. The only regressions in this category are:
26792 [4.2 Regression]
On 15 April 2007 23:51, Mark Mitchell wrote:
> The broader question of why there are so many 124 P3 or higher
> regressions against 4.2.0 points to a more fundamental problem.
> Despite the fact that virtually all of the bugs open against 4.2.0 are
> also open against 4.1 or 4.3 -- or both! -- the
Dave Korn wrote:
>> Some have suggested that I try to solve this by closing GCC 4.3
>> development until 4.2.0 is done. I've considered that, but I don't
>> think it's a good idea. In practice, this whole software freedom thing
>> means that people can go off and do things on their own anyhow; p
> > Despite the fact that virtually all of the bugs open against 4.2.0 are
> > also open against 4.1 or 4.3 -- or both! -- there seems to be little
> > interest in fixing them.
> >
> > Some have suggested that I try to solve this by closing GCC 4.3
> > development until 4.2.0 is done.
>
> So he
On 4/15/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
As has been remarked on the GCC mailing lists, I've not succeeded in
getting GCC 4.2.0 out the door. However, with the limited criteria that
we target only P1 regressions not present in 4.1.x, we seem to be
getting a bit closer. The only regr
Daniel Berlin wrote:
On 4/15/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
However, I would consider asking the SC for permission to institute a
rule that would prevent contributors responsible for P1 bugs (in the
only possible bright-line sense: that the bug appeared as a result of
their patch)
> -Original Message-
> From: Mark Mitchell [mailto:[EMAIL PROTECTED]
> Sent: Sunday, April 15, 2007 4:51 PM
> To: GCC
> Subject: GCC 4.2.0 Status Report (2007-04-15)
>
> However, I would consider asking the SC for permission to institute a
> rule that would prevent contributors respons
16 matches
Mail list logo
