--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34238
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34247
--- Comment #1 from andreasmeier80 at gmx dot de 2007-11-28 08:13 ---
It worked well at 2007/09/03, but is failing at leat since 2007/09/10.
So it may be caused by revision 128079:
Author: hubicka
Date: Tue Sep 4 13:05:19 2007
New Revision: 128079
URL: http://gcc.gnu.org/viewcvs?root=
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-11-28 08:31
---
> I see on my computer a lot of failures in the testsuite gcc.dg/vect. See
> http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01474.html
> The failures are there since Sepember 2007. But the other testresults don'
without g++ FE inlining, ct.C (attached in the following)correctly called
my_terminate when an exception was thrown in a destructor called in a clean-up
exception handler. However, after FE inlining, this exception was propagate out
of the clean-up exception handler and reached the catch(...) block
--- Comment #12 from ek dot kato at gmail dot com 2007-11-28 09:19 ---
Hi,
I encountered this problem today, as I would like to use latest gfortran on Mac
OS X 10.4.11.
Anyway here is the crude workaround to avoid the install name problem. It just
install libgcc_s.*.dylib with slibdir
Hello,
I try to compile gcc on a tru64 unix v5.1b.
I have this message :
yacc --name-prefix=__gettext --output plural.c
/usr/local/gcc/src/gcc-3.4.6/intl
/plural.y
usage: yacc -svdlt [-b prefix] [-p sym_prefix] [-P path] [-N num] file
*** Exit 1
Stop.
*** Exit 1
Stop.
What is the procedure to solv
--- Comment #1 from philippe dot vereecke at siih5962 dot fr 2007-11-28
09:32 ---
yacc --name-prefix=__gettext --output plural.c
/usr/local/gcc/src/gcc-3.4.6/intl
/plural.y
usage: yacc -svdlt [-b prefix] [-p sym_prefix] [-P path] [-N num] file
*** Exit 1
Stop.
*** Exit 1
Stop.
--
h
the PRESENT test of an optional variable returns TRUE in both of these calls
$ cat c.F; gfortran c.F ; ./a.out
PROGRAM MAIN
REAL A
INTEGER I
CALL SUB(A,I)
CALL SUB(A)
END
SUBROUTINE SUB(A,I)
REAL :: A
INTEGER, OPTIONAL :: I
IF (PRESENT(I
--- Comment #1 from hailijuan at gmail dot com 2007-11-28 09:17 ---
Created an attachment (id=14652)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14652&action=view)
to address the bug in g++ exception handler
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34258
Hello,
I am newly assigned to GNU CC work. I am using Win-xp-sp2 and Cygwin to
build GCC. I have successfully installed the 'binutils', but while building
GCC below errors are being issued:
--cut--
../.././gcc/config/mips/mips.md:3318:5: missing terminating " character
../.././gcc/config/mips/mip
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-28 10:14 ---
Confirmed. The mentioned patch has been applied to the trunk already.
> The patch not only causes -g divergence, it also accidentally drops subblocks
> that need to be kept around for the sake of generating debug i
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from terry at chem dot gu dot se 2007-11-28 10:33 ---
> gfortran behaves correctly with an explicit INTERFACE, but that
> should not be required (as far as I know)
Explicit interfaces are required for procedures with optional arguments. SUB
is still external to MAIN, so
I research in interval arithmetic. I bought a MacBook Pro in Spring 07 (
MacBookPro2,2; Intel Core 2 Duo 2.33 GHz; Mac OS X 10.4.11 (8S2167), Darwin
8.11.1).
Within MATLAB (Version 7.4.0.287 (R2007a) Jan 2007) I wanted to use Rump's
interval library INTLAB. On startup, INTLAB detected the needed c
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-28 12:15 ---
The two patches reduce the boostrap-debug failures that re-appear with
reverting
the part that fixes
> http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01745.html regresses the property
> that code output with -g must b
hades [TEST] cat bug-mvbits.f90
program main
implicit none
integer :: a( 1 ), b( 1 )
integer :: x, y
a = 1
b = 0
x = 1
y = 0
call mvbits (a, 0, 1, b, 1)
call mvbits (x, 0, 1, y, 1)
write (*, *) 'a: ', a
write (*, *) 'x: ', x
write (*, *)
write (*, *) 'b: ', b
write
Consider the following testcase compiled on SPU, r130287:
#define M 1000
void
foo (int *X, int *Y, int size, int n)
{
int i, j;
int acum;
for (i = 0; i < M; i++)
{
acum = 0;
for (j = 0; j < n; j++)
{
acum += (X[j] * X[j + i]);
}
Y[i] = acum;
--- Comment #2 from ubizjak at gmail dot com 2007-11-28 12:45 ---
Created an attachment (id=14653)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14653&action=view)
Patch to adjust mmx move instructions
It looks that mmx move instructions need some tuning. Attached patch fixes
you
--- Comment #3 from ubizjak at gmail dot com 2007-11-28 12:46 ---
Confirmed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from andreasmeier80 at gmx dot de 2007-11-28 13:17 ---
Today I have checked out trunk newly. So my tree is fine.
The failures are also there.
I will send the new testresults shortly.
I'm using Suse 10.1. The version of dejagnu is 1.4.4.
I see only unusual errors in gcc
--- Comment #12 from jakub at gcc dot gnu dot org 2007-11-28 13:20 ---
So, shouldn't the expression_without_side_effects_p routine just be renamed
to expression_could_trap_p, otherwise it will be confused again and again with
!TREE_SIDE_EFFECTS on the expr? The gimplify_cond_expr new hu
--- Comment #2 from vahtras at kth dot se 2007-11-28 13:22 ---
Subject: Re: present returns wrong value of optional
variables
On Wed, 2007-11-28 at 10:33 +, terry at chem dot gu dot se wrote:
> Shouldn't this error be detected by the compiler at some stage of the
> compil
--- Comment #3 from uweigand at gcc dot gnu dot org 2007-11-28 13:36
---
Hi Michael,
the problem is that there is an implicit assumption throughout the code
that you can have at most one pool constant per instruction. For example,
the pool size / splitting heuristics assume that. I t
--- Comment #13 from rakdver at kam dot mff dot cuni dot cz 2007-11-28
13:45 ---
Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME
object)
> --- Comment #12 from jakub at gcc dot gnu dot org 2007-11-28 13:20
> ---
> So, shouldn't the expression_witho
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-28 13:54 ---
If no explicit interface is known, the following produces is almost all cases
invalid code:
CALL SUB(A,I)
CALL SUB(A)
Other compilers detect this such as NAG f95:
Error: line 5: Different number of arg
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-28 14:09 ---
For a scalars x and y:
_gfortran_mvbits_i4 (&x, &C.860, &C.861, &y, &C.862);
for an arrays a and b:
_gfortran_mvbits_i4 (&parm.2, &C.872, &C.873, &parm.3, &C.875);
It actually does not surprise me that this doe
--- Comment #9 from scovich at gmail dot com 2007-11-28 14:20 ---
(In reply to comment #8)
> (In reply to comment #7)
> > Too bad they aren't defined for any machine I've tried so far...
>
> The explanation is very simple: the new macros are implemented only in
> mainline
> (would be 4
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-28 14:20 ---
The following fixes it, but I need to check for unwanted side effects:
Index: intrinsic.c
===
--- intrinsic.c (revision 130489)
+++ intrinsic.c (working
--- Comment #2 from ian at airs dot com 2007-11-28 14:29 ---
The C99 standard specifically calls out __STDC_FORMAT_MACROS as a macro which
may be defined before including . Therefore, I believe that
warning about this definition is a bug for both C and C++.
--
http://gcc.gnu.org/bu
I cannot compile the following simple program with the 3.2.3 g++ compiler.
#include
#include
using namespace std;
class A
{
public:
template
void method(void)
{
cout << "hello " << typeid(int).name() << endl;
}
};
template
void run(void)
{
--- Comment #4 from andreasmeier80 at gmx dot de 2007-11-28 14:12 ---
The new results are at
http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01515.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34253
--- Comment #9 from aldot at gcc dot gnu dot org 2007-11-28 14:47 ---
If the requested bitfield is larger than the type that was previously tried for
enum, then you have to widen the type to fulfill that constaint.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
I have had a closer look to the optimization of the polyhedron test
induct.f90.
3/4 of the runtime is spent in the subroutine 'mutual_ind_quad_cir_coil' and
1/4 in 'mutual_ind_quad_rec_coil'.
The two subroutines contain two main loops with the following structure:
do i = 1, 2*m
...
do j
--- Comment #4 from matz at gcc dot gnu dot org 2007-11-28 15:28 ---
What I meant with "normal" code is by using inline asms. As it stands it's
impossible to write inline asm instructions having more than one literal pool
operand. I consider this normal use of the capabilities GCC give
--- Comment #1 from dominiq at lps dot ens dot fr 2007-11-28 15:30 ---
Created an attachment (id=14654)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14654&action=view)
Diffs between the original file and the simplest variants
In induct.v1.f90 'nominator' and 'denominator' are unr
--- Comment #6 from matz at gcc dot gnu dot org 2007-11-28 15:59 ---
Yes, that would be a viable workaround. Perhaps even correct, given that
GCC can handle only MAX_RECOG_OPERANDS, which is only 30 at a minimum.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250
--- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-11-28
16:05 ---
Subject: Re: [4.3 Regression] VRP/SCEV miscompiles Firefox
> --- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-28 15:47
> ---
> We could clear the SCEV cache for an SSA_NAME we set a new
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-28 16:06 ---
GCC doesn't have a facility to split the inner loop and move it out of the
outer loops by introducing a array temporary.
As for completely unrolling, this only happens for innermost loops(?) and you
can tune the heu
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-28 15:47 ---
We could clear the SCEV cache for an SSA_NAME we set a new value range
(in set_value_range and set_value_range_to_varying), but I
see that SCEV also caches loop->nb_iterations which we probably would need to
clear un
--- Comment #8 from rguenther at suse dot de 2007-11-28 16:13 ---
Subject: Re: [4.3 Regression] VRP/SCEV miscompiles
Firefox
On Wed, 28 Nov 2007, rakdver at kam dot mff dot cuni dot cz wrote:
> > --- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-28 15:47
> > ---
>
--- Comment #3 from dominiq at lps dot ens dot fr 2007-11-28 16:14 ---
> Note that complete unrolling happens too late to help LIM or vectorization.
Could this be translated as a YES to my first question: the fortran frontend
should unroll computations for short vectors?
--
http://
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-28 15:41 ---
We could generate multiple asms instead, one for each parameter...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-28 16:17 ---
I would in principle say no - we can instead improve the middle-end here. But
it may pay off to not generate a loop for short vectors in case the resulting
IL is smaller for example. Of course it would duplicate lo
--- Comment #3 from tromey at gcc dot gnu dot org 2007-11-28 16:26 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #2 from aldot at gcc dot gnu dot org 2007-11-28 16:28 ---
Can still be observed on trunk.
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31529
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-28 16:33 ---
Created an attachment (id=14655)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14655&action=view)
patch for early complete unrolling of inner loops
For example with a patch like this.
--
http://gcc.gnu.or
--- Comment #10 from raj dot khem at gmail dot com 2007-11-28 16:40 ---
(In reply to comment #9)
> If the requested bitfield is larger than the type that was previously tried
> for
> enum, then you have to widen the type to fulfill that constaint.
>
is there a reference for this in th
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-28 17:08 ---
I doubt that this is a gcc bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-28 17:11 ---
Try:
pMethod p = &ClassA::templete method; // line 23, error
message
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34264
--- Comment #7 from uweigand at gcc dot gnu dot org 2007-11-28 17:11
---
(In reply to comment #4)
> For reference, our hacky approach to enforce liveness of arguments is by
> using them as operands of an inline asm, which we insert as first instruction
> in every function. When those a
--- Comment #42 from dsh at gcc dot gnu dot org 2007-11-28 17:19 ---
Created an attachment (id=14656)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14656&action=view)
Benchmarks
I ran the benchmarks for the minimal testcase (using Dan Kegel's script) on a
Core 2 Duo, AMD Dual Core
--- Comment #5 from manu at gcc dot gnu dot org 2007-11-28 17:32 ---
Dave, could you check this with a recent release?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from manu at gcc dot gnu dot org 2007-11-28 17:34 ---
So what the BSD people said about this? Did they agree with your assessment?
How many of those 26 likely bugs were considered "real" bugs by them?
It really seems too noisy and with no clear way to avoid or workaround
--- Comment #11 from aldot at gcc dot gnu dot org 2007-11-28 17:44 ---
The standard (6.7.2.2, 4) talks about the note in #7.
I read this as for this input:
8<---
enum e {ee};
struct s { __extension__ enum e baz:16; };
8<---
The smallest type that can represent en
--- Comment #9 from rask at gcc dot gnu dot org 2007-11-28 18:01 ---
Created an attachment (id=14657)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14657&action=view)
Patch v2 to enhance cse.c
This patch also handles unsigned comparisons and thus optimizes the original
testcase to
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-28 18:03
---
I consider this a bug. I have to check, but I think that the IEEE rules are
clear, even though they are not mandatory until we introduce the corresponding
standard modules. The calculation of y does overflow, and
--- Comment #43 from dank at kegel dot com 2007-11-28 18:01 ---
Of the results posted above, the only interesting one that is still slower
than gcc-2.95 is a pentium 3 with -fPIC.
(Happily, gcc-4.3 is an improvement there, but it's still worse than 2.95.)
Oddly, this one does better wit
--- Comment #12 from aldot at gcc dot gnu dot org 2007-11-28 18:28 ---
Not target specific, adjusting accordingly.
Observed everywhere with -fshort-enums
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from dominiq at lps dot ens dot fr 2007-11-28 18:18 ---
Subject: Re: Missed optimizations
> For example with a patch like this.
You also need
--- ../_gcc_clean/gcc/tree-flow.h 2007-11-16 16:17:46.0 +0100
+++ ../gcc-4.3-work/gcc/tree-flow.h 2007-11-28
--- Comment #3 from tromey at gcc dot gnu dot org 2007-11-28 18:21 ---
Can you reproduce this with anything newer than 3.4?
The 3.x release series is closed. I couldn't reproduce with 4.1.
So, barring new information, I think this is fixed.
--
tromey at gcc dot gnu dot org changed:
--- Comment #13 from pbrook at gcc dot gnu dot org 2007-11-28 19:05 ---
The short answer is don't do that.
-mabi=iwmmxt selects a bare-metal (short-enum) AAPCS variant with iWMMXt
calling conventions. As such it is incompatible with the Linux EABI supplement
(http://www.codesourcery.com
--- Comment #7 from kargl at gcc dot gnu dot org 2007-11-28 19:06 ---
(In reply to comment #6)
> I consider this a bug. I have to check, but I think that the IEEE rules are
> clear, even though they are not mandatory until we introduce the corresponding
> standard modules. The calculatio
--- Comment #1 from tromey at gcc dot gnu dot org 2007-11-28 19:06 ---
Confirmed.
I didn't see any instances of @findex or @vindex in hostconfig.texi.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from tromey at gcc dot gnu dot org 2007-11-28 19:07 ---
*** This bug has been marked as a duplicate of 14933 ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from tromey at gcc dot gnu dot org 2007-11-28 19:07 ---
*** Bug 33473 has been marked as a duplicate of this bug. ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from dominiq at lps dot ens dot fr 2007-11-28 18:48 ---
Subject: Re: Missed optimizations
With your patch the runtime went from
93.670u 0.103s 1:33.85 99.9%0+0k 0+0io 32pf+0w
to
38.741u 0.038s 0:38.85 99.7%0+0k 0+1io 32pf+0w
Pretty impressive!
Note that with
/*
% uname -a
Linux lepidus 2.4.21-sgi302r24 #1 SMP Fri Oct 22 22:43:12 PDT 2004 ia64 ia64
ia64 GNU/Linux
% gcc -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: /usr/local/gcc-4.2.2/src/gcc-4.2.2/configure
--enable-languages=c,c++,fortran --with-gnu-as
--with-as=/usr/local/b
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-28 19:23
---
(In reply to comment #7)
> a) Do other compilers have an equivalent to -fno-range-check?
Most compilers have a behaviour similar to -fno-range-check by default, only
warning about range problems (Intel, Sun, g95
--- Comment #9 from burnus at gcc dot gnu dot org 2007-11-28 19:35 ---
> > If +Inf is a representable value, you need to go fix the IO subsystem
> > to read +Inf (and NaN).
I just checked:
- NAG f95, g95, ifort and sunf95 accept (case insensitive and with optional
"+"/"-" prefix) "NAN"
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-28 19:45 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from rsandifo at gcc dot gnu dot org 2007-11-28 19:49
---
Patch applied. Thanks to David for the testing and
Mark for the review.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2007-11-28 19:49 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from rsandifo at gcc dot gnu dot org 2007-11-28 19:46
---
Subject: Bug 32406
Author: rsandifo
Date: Wed Nov 28 19:46:03 2007
New Revision: 130493
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130493
Log:
gcc/
PR target/32406
* builtins.c (expand
--- Comment #5 from meklund at cisco dot com 2007-11-28 19:43 ---
Subject: Re: feature request: generate a warning for sizeof on a pointer
Hi Manu,
This is in regards to your Comments for the gcc feature enhancement
request, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702.
On Wed,
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-28 19:43 ---
Subject: Bug 34247
Author: jakub
Date: Wed Nov 28 19:43:03 2007
New Revision: 130492
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130492
Log:
* trans-expr.c (gfc_trans_string_copy): Convert both dest
f-conv.c (if_convertible_phi_p): Fail if BB other than
loop->header has virtual phi nodes.
* gcc.c-torture/compile/20071128-1.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20071128-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu
2007-11-28 20:08 ---
Subject: Re: Expressions of parameters evaluated with too high precision
On Wed, Nov 28, 2007 at 07:23:57PM -, fxcoudert at gcc dot gnu dot org
wrote:
>
> To sum up my point of view: -fno-ra
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 20:43 ---
Subject: Bug 15803
Author: sam
Date: Wed Nov 28 20:43:25 2007
New Revision: 130495
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130495
Log:
gcc/ada/
PR ada/15803
* par-ch3.adb (P_Variant_Pa
--- Comment #14 from sam at gcc dot gnu dot org 2007-11-28 20:45 ---
Subject: Bug 17317
Author: sam
Date: Wed Nov 28 20:44:58 2007
New Revision: 130496
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130496
Log:
gcc/ada/
PR ada/17317
* par-ch4.adb (Is_Paramete
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 20:46 ---
Subject: Bug 32792
Author: sam
Date: Wed Nov 28 20:46:18 2007
New Revision: 130497
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130497
Log:
gcc/ada/
PR ada/32792
* sem_attr.adb (Analyze_Att
--- Comment #1 from sam at gcc dot gnu dot org 2007-11-28 20:48 ---
Subject: Bug 22559
Author: sam
Date: Wed Nov 28 20:48:10 2007
New Revision: 130498
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130498
Log:
gcc/ada/
PR ada/22559
* sem_ch3.adb (Build_Derive
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #3 from sam at gcc dot gnu dot org 2007-11-28 20:50 ---
Fixed in SVN trunk
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #8 from aldot at gcc dot gnu dot org 2007-11-28 20:50 ---
A toplevel 'make' does what 'make bubblestrap' did before.
See also:
http://gcc.gnu.org/ml/gcc/2005-12/msg00435.html
http://gcc.gnu.org/ml/fortran/2005-12/msg00338.html
If install.texi from the 4_2-branch mentions thi
--- Comment #15 from sam at gcc dot gnu dot org 2007-11-28 20:51 ---
Forget message, wrong # in ChangeLogs, will fix them
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17317
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 20:52 ---
Fixed in SVN trunk
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
The following invalid code snippet triggers an ICE on mainline:
==
template struct A
{
__decltype(A);
};
==
bug.cc:3: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:15697
Please submit a full bug report, [etc.]
--
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34267
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 20:55 ---
Fixed in SVN trunk
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #11 from sabre at nondot dot org 2007-11-28 20:57 ---
Please don't disable these. There are a variety of compilers that optionally
or only generate C code, particularly for the functional languages. This is
useful functionality for these compilers.
--
http://gcc.gnu.or
The following invalid code snippet triggers an ICE on mainline:
==
struct A
{
__decltype(~A);
};
==
bug.cc:3: internal compiler error: in lookup_member, at cp/search.c:1206
Please submit a full bug report,
--
Summary: [4.3 regression
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34268
The following invalid code snippets are wrongly accepted on mainline:
=
void foo() { __decltype; }
=
=
void foo() { __decltype(; }
=
--
Summary: [4.3 regression] Incomplet
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34269
--- Comment #8 from jb at gcc dot gnu dot org 2007-11-28 20:48 ---
The vectorization of dot products is covered by PR31738, I suppose
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from sam at gcc dot gnu dot org 2007-11-28 20:49 ---
Fixed in SVN trunk
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
1 - 100 of 148 matches
Mail list logo
