> -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
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)
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
> > 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
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
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
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 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
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
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
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
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
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
> * 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
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
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
16 matches
Mail list logo
