In the testcase below, after the inner-loop gets completely unrolled, the
enclosing i-loop does not get unrolled because of failure to analyze the loop
iv, possibly due to a bug in df:
#define N 40
#define M 10
float in[N+M], coeff[M], out[N];
void fir (){
int i,j,k;
float diff;
for (i = 0;
--
andreagrassi at sogeasoft dot com changed:
What|Removed |Added
Severity|enhancement |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33219
--- Comment #19 from jakub at gcc dot gnu dot org 2007-08-29 08:07 ---
Binary search among the routines in java_raw_api.c with -fno-inline shows
the noclass testcase fails if either ffi_java_raw_call or
ffi_java_translate_args
is compiled with -O2 -fdce, if both are compiled with -O2 -fn
program t
print*,huge(1.0d0),tiny(1.0d0)
end program t
gives the output
1.797693134862316E+30^@ 2.225073858507201E-30^@
with latest gfortran binary:
Target: i386-pc-linux-gnu
Configured with: /home/fx/gfortran_nightbuild/trunk/configure
--prefix=/home/fx/gfortran_nightbuild/irun-20070828
-
--
pcarlini at suse dot de changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33219
On 29 Aug 2007 03:15:04 -, bangerth at dealii dot org
<[EMAIL PROTECTED]> wrote:
> It is a good question in itself whether pimpl_ has a type at all -- it's a
> pointer to an incomplete type in any case :-)
All types in C++ are exported (well except for anonymous namespace
types) including inco
--- Comment #20 from jakub at gcc dot gnu dot org 2007-08-29 08:52 ---
typedef struct {
int abi;
unsigned nargs;
void **arg_types;
void *rtype;
unsigned bytes;
unsigned flags;
} ffi_cif;
void ffi_java_raw_to_ptrarray (ffi_cif *cif, void *raw, void **args);
void ffi_java_rval
--- Comment #39 from pinskia at gmail dot com 2007-08-29 08:52 ---
Subject: Re: Unnecessary anonymous namespace warnings
On 29 Aug 2007 03:15:04 -, bangerth at dealii dot org
<[EMAIL PROTECTED]> wrote:
> It is a good question in itself whether pimpl_ has a type at all -- it's a
> p
In the testcase below, after the inner-loop gets completely unrolled, the
enclosing i-loop does not get unrolled because of failure to analyze the loop
iv, possibly due to a bug in df:
#define N 40
#define M 10
float in[N+M], coeff[M], out[N];
void fir (){
int i,j,k;
float diff;
for (i = 0;
--- Comment #1 from dorit at gcc dot gnu dot org 2007-08-29 09:04 ---
> In the testcase below, after the inner-loop gets completely unrolled, the
> enclosing i-loop does not get unrolled because of failure to analyze the loop
> iv, possibly due to a bug in df:
...
> Compiler options used
--- Comment #1 from dorit at gcc dot gnu dot org 2007-08-29 09:08 ---
I accidentally entered this bug twice. I'm closing this one, and will use
PR33224 instead.
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
--
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org
|dot org
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-29 09:42
---
The patch was reversed, this should be fixed in next binaries.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
With the patch in http://gcc.gnu.org/ml/fortran/2007-08/msg00476.html (revision
127846), some formatted output are missing the last digit on Darwin (see
http://gcc.gnu.org/ml/fortran/2007-08/msg00586.html):
! { dg-do run }
! PR32554 Bug in P formatting
! Test case from the bug reporter
program gfc
--- Comment #39 from sdepagnier at avidyne dot com 2007-08-29 10:00 ---
Created an attachment (id=14131)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14131&action=view)
another test case
This test case only has problems when gcc is invoked with the -ftree-pre flag
which is part o
--- Comment #6 from cyberflex at mail dot ru 2007-08-29 10:16 ---
(In reply to comment #4)
> Created an attachment (id=14129)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14129&action=view) [edit]
> Test case that works.
>
> With the new "Test case that works" and attached test.s
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-08-29 10:32
---
MTAG_ALIASES of the SMTs are different:
SMT.469 no aliases
SMT.470 no aliases
SMT.464{ ctor_count ctor_count dtor_count SMT.465 SMT.470 }
SMT.465{ ctor_count ctor_count dtor_count SMT.470 }
SMT.466{ ctor_count cto
--- Comment #6 from raeburn at raeburn dot org 2007-08-29 11:12 ---
(In reply to comment #5)
> I don't understand the error !! It's all so simple and I don't understand
> why the compile works if I write in the second form (not inline parameter
> declaration) !!!
(This would be more sui
--- Comment #21 from jakub at gcc dot gnu dot org 2007-08-29 11:18 ---
The major difference between say i?86 or x86_64 and ppc here is that
on the former two the hard frame pointer is actually visibly, not just
artificially, used when restoring the stack pointer. ppc restores the
stack
--- Comment #22 from jakub at gcc dot gnu dot org 2007-08-29 11:41 ---
Created an attachment (id=14132)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14132&action=view)
gcc43-pr32758.patch
Here is what I will try to regtest (already verified it fixes the testcase).
Alternatively,
--- Comment #18 from tbm at cyrius dot com 2007-08-29 11:47 ---
(In reply to comment #17)
> Unassigning.
So you don't intend to fix this for 4.2? I guess the patch you commited to
trunk
is too big for 4.2 but do you think there's some kind of workaround that could
be applied to 4.2? T
--- Comment #23 from paolo dot bonzini at lu dot unisi dot ch 2007-08-29
11:47 ---
Subject: Re: [4.3 Regression] ecj1 hangs
> df_simulate_one_insn_forwards and df_simulate_one_insn_backwards
> (why we have the former when nothing ever uses it?) both call
> df_simulate_fixup_sets to f
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-08-29 11:58
---
Due to the alias differences with -g compared to without -g we have the
following
difference after tree-level optimization:
--- - 2007-08-29 13:52:02.567822000 +0200
+++ b/auto_ptr.min.ii.116t.optimized2007-
If an identifier given inside an enum is the same as an existing class
the compiler still accepts it:
<<< code <<<
class MyClass { };
MyClass g_my_class; // An instance
enum { Mode1, MyClass }; // We could have error already here
MyClass g_my_class2; // Compiler gives error here
<<< endcode <
--- Comment #24 from paolo dot bonzini at lu dot unisi dot ch 2007-08-29
12:15 ---
Subject: Re: [4.3 Regression] ecj1 hangs
> Here is what I will try to regtest (already verified it fixes the testcase).
This is wrong, because local_live changes during execution of
dce_process_block.
--- Comment #2 from sandra at codesourcery dot com 2007-08-29 12:19 ---
See patch and discussion here:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02027.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33211
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-08-29 12:25 ---
Subject: Bug 33194
Author: dgregor
Date: Wed Aug 29 12:25:01 2007
New Revision: 127896
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127896
Log:
2007-08-29 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-08-29 12:28 ---
Fixed on mailine
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-08-29 12:55
---
Fixing of the trunk was a side-effect of some major re-structuring. This won't
go on the branch for sure, no easy way to fix this another way either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
| On 29 Aug 2007 03:15:04 -, bangerth at dealii dot org
| <[EMAIL PROTECTED]> wrote:
| > It is a good question in itself whether pimpl_ has a type at all -- it's a
| > pointer to an incomplete type in any case :-)
|
| All types in C++ are exported (
--- Comment #40 from gdr at cs dot tamu dot edu 2007-08-29 13:19 ---
Subject: Re: Unnecessary anonymous namespace warnings
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
| On 29 Aug 2007 03:15:04 -, bangerth at dealii dot org
| <[EMAIL PROTECTED]> wrote:
| > It is a good question in
--- Comment #25 from jakub at gcc dot gnu dot org 2007-08-29 13:26 ---
Unfortunately it breaks e.g. memcpy-chk.c, simplified testcase here:
extern void abort (void);
typedef __SIZE_TYPE__ size_t;
extern void *memcpy (void *, const void *, size_t);
extern volatile int chk_fail_allowed;
ex
--- Comment #5 from l_belev at yahoo dot com 2007-08-29 13:35 ---
Tested this in 4.2.1 and int seems to be fixed (i.e. the compiler now does not
make difference between the 2 variants ot the code)
Thank you!
--
l_belev at yahoo dot com changed:
What|Removed
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-29 13:36 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #26 from jakub at gcc dot gnu dot org 2007-08-29 13:56 ---
Apparently dce is the only user of df_simulate_* which at the start of the
basic block compares the resulting bitmap with DF_LR_IN. All other users
of these interfaces don't do that (ifcvt, rtl-factoring, peephole2).
--- Comment #7 from andreagrassi at sogeasoft dot com 2007-08-29 13:56
---
Subject: R: Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.
Thank you so much for the speed, the kindness and the precision with which
you
I have ran into a situation where code compiled on RedHat 8.0 with gcc 3.2 runs
well. We have upgraded our systems to Fedora Core 6 with gcc 4.1.1 and now
multiple programs are dropping core files left and right. When we turn the
optimization off (create a debugable version) the programs act norm
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-29 13:09 ---
Subject: Bug 33215
Author: burnus
Date: Wed Aug 29 13:08:55 2007
New Revision: 127898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127898
Log:
2007-08-29 Christopher D. Rickett <[EMAIL PROTECTED]>
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-29 14:11 ---
Of course this is completely useless information for a bugreport. Please read
http://gcc.gnu.org/bugs.html and try again. You may also want to report to
your distributor, that is, RedHat in this case.
--
rguent
--- Comment #27 from bonzini at gnu dot org 2007-08-29 14:11 ---
> Not all basic blocks have all 4 x86_64 regular_block_artificial_regs registers
> set in DF_LR_IN and so oring this in causes infinite loop, as
> process_dce_block
> always returns something changed.
If so, your previou
--- Comment #28 from bonzini at gnu dot org 2007-08-29 14:14 ---
> Apparently dce is the only user of df_simulate_* which at the start of the
> basic block compares the resulting bitmap with DF_LR_IN.
Yes. The other two don't get infinite loops from their doing the wrong thing;
they j
module m
USE MOD, only: foo1
interface generic_intrf
module procedure foo1
end interface
is accepted although "bar" is not a host-associated procedure, but a
use-associated procedure.
(Using "PROCEDURE foo1" instead of "MODULE PROCEDURE foo1" allows
use-associated procedures.)
NAG f95 correctl
--- Comment #29 from bonzini at gnu dot org 2007-08-29 14:16 ---
(When I said "post your first patch", I meant the first one from comment #26;
if my "fixing the mess" works, it'll not be necessary anymore).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758
The following invalid program gives a memory access error. Note, without
INTRINSIC or with IMPLICIT NONE, everything works as expected.
intrinsic cpu_time
real :: time
print *, CPU_TIME(TIME)
end
--
Summary: ICE with "intrinsic" plus calling a subroutine as
functi
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-29 15:16
---
Subject: Bug 33105
Author: fxcoudert
Date: Wed Aug 29 15:16:00 2007
New Revision: 127903
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127903
Log:
PR fortran/33105
* intrinsic.c (add_fun
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-08-29 15:16
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-08-29 15:19
---
I wonder why D.9380_64, defined as
D.9380_64 = &D.8894_34->_M_use_count;
points to anything and NULL:
D.9380_64, is dereferenced, points-to anything, points-to NULL
where the single dereference site looks l
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-29 15:25
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #2 from spark at gcc dot gnu dot org 2007-08-29 15:23 ---
I suspect this might be due to not updating the rd information after unrolling.
Can you check if
analyze_insns_in_loop() (which calls df_analyze()) is being called just before
the problematic unrolling ?
--
http:
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-08-29 15:27
---
Subject: Bug 32989
Author: fxcoudert
Date: Wed Aug 29 15:22:55 2007
New Revision: 127905
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127905
Log:
PR fortran/32989
* iresolve.c (gfc_reso
--- Comment #30 from zadeck at naturalbridge dot com 2007-08-29 15:34
---
Subject: Re: [4.3 Regression] ecj1 hangs
bonzini at gnu dot org wrote:
> --- Comment #29 from bonzini at gnu dot org 2007-08-29 14:16 ---
> (When I said "post your first patch", I meant the first one fr
gfortran -std=f95 -pedantic -Wall -fall-intrinsics
gfortran.dg/char_result_7.f90
Compiles, but as g95 remarks:
Error: Specification function 'fn' at (1) must be PURE
which NAG f95 confirms:
Error: Reference to non-specification function FN in specification
and ifort joins in as well:
An expl
gfortran -fall-intrinsics -std=f95 -Wall -pedantic
gfortran.dg/elemental_subroutine_1.f90
gives no error, but ifort:
In a reference to an elemental subroutine, either all act-args shall be scalar,
or all act-args associated with INTENT(OUT) and INTENT(INOUT) dum-args shall be
conforming arrays.
The following is a common vendor extension but to my knowledge not allowed up
to Fortran 2003 (and probably also Fortran 2008):
write(*,*), 'Hello'
read(*,*), a
end
gfortran -pedantic -std=f95 -Wall accepts simply accepts it.
ifort -stand f03 reports correctly:
fortcom: Warning: a.f90, line 1:
This is a follow up to PR30746.
While I believe the test case in PR30746 is correct, I think the
gfortran.dg/host_assoc_function_1.f90 test case is wrong.
(Simplified, see testsuite for the full file)
MODULE m
REAL :: x(3) = (/ 1.5, 2.5, 3.5 /)
CONTAINS
SUBROUTINE s
if (x(2) .ne. 2.5) ca
The following is invalid Fortran 95/2003:
call sub (len, "abcdef")
unless one has used before "intrinsic len".
gfortran happily accepts this, "ifort -stand f03" diagnoses:
fortcom: Warning: intrinsic_actual_4.f90, line 17: Allowing an intrinsic
procedure name to appear as an actual argument
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-29 16:15 ---
No C is defined this way. Look at the error message, we mention why this code
is invalid.
> a.c:7: note: an argument type that has a default promotion can't match an
> empty
> parameter name list declaration
Wha
Overload resolution is picking the wrong candidate for the construction of b3,
below:
base2 b3(static_cast(b));
Instead of choosing the move constructor, it is picking the trivial copy
constructor. However, adding a normal copy constructor fixes the problem.
Naturally, this only occurs in C++0
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-08-29 16:16 ---
Created an attachment (id=14133)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14133&action=view)
Failing test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33235
--- Comment #9 from manu at gcc dot gnu dot org 2007-08-29 16:30 ---
Since "a" is called before being defined/declared is assumed:
extern int a();
See also: http://c-faq.com/decl/implfdecl.html
The error message could be a bit clearer by pointing out this explicitly:
a.c:7: error: co
--- Comment #10 from andreagrassi at sogeasoft dot com 2007-08-29 17:01
---
Subject: R: Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.
Read again your "brilliant" error message where you mention why my code is
i
--- Comment #7 from dje at gcc dot gnu dot org 2007-08-29 17:01 ---
Subject: Bug 33168
Author: dje
Date: Wed Aug 29 17:01:35 2007
New Revision: 127910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127910
Log:
2007-08-29 Paolo Bonzini <[EMAIL PROTECTED]>
PR target/331
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-29 17:09 ---
I have to look this up but I think this code is valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33226
--- Comment #11 from andreagrassi at sogeasoft dot com 2007-08-29 17:39
---
Subject: R: Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.
I accept the answer to gave me but then also the definition of
a(a)
--- Comment #5 from patchapp at dberlin dot org 2007-08-29 18:05 ---
Subject: Bug number PR31879
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02114.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #40 from eweddington at cso dot atmel dot com 2007-08-29 18:06
---
(In reply to comment #39)
> Created an attachment (id=14131)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14131&action=view) [edit]
> another test case
>
> This test case only has problems when gcc is
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-29 18:15 ---
At least for it currently crashes already for the following reduced example;
the problem seems to be the default initializer. (Another hint that this is
indeed the problem: After commenting out the "if (f->sym && f->s
--- Comment #22 from dberlin at gcc dot gnu dot org 2007-08-29 18:30
---
Subject: Re: [4.3 Regression]
tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc
On 29 Aug 2007 15:19:10 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #21 from rguenth
If -minimal-toc is used with a leaf function (that uses global memory), the
register r31 is saved/restored which causes a LHS store on the Cell's PowerPC
side.
Simple example:
int i;
int f(void)
{
return i;
}
asm:
std 30,-16(1)
ld 30,[EMAIL PROTECTED](2)
ld 9,.LC0-.LCTOC1(
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-29 18:38 ---
s/r31/r30 in comment #0, r31 is the frame pointer :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33236
--- Comment #3 from martinwguy at yahoo dot it 2007-08-29 18:45 ---
The patches contained in http://files.futaris.org/gcc/crunch.tar.bz2 not only
fix this issue but also make MaverickCrunch support work reliably in gcc-4.1.2
and gcc-4.2.0 (presumably they can also apply to TRUNK).
There
The tree memory partitioning phase is spending 430 seconds of a 490 second
compile which seems a little excessive. The test case is a slightly modified
version of another test case within bugzilla (I forget which one) but with some
syntax warning cleaned up. I'm using GCC mainline revision 127398.
--- Comment #1 from bergner at gcc dot gnu dot org 2007-08-29 18:54 ---
Created an attachment (id=14134)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14134&action=view)
Test case mentioned above.
To recreate: gcc -O1 -S -ftime-report syntax-case.i
--
http://gcc.gnu.org/bugzi
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-08-29 19:02 ---
Hi Jerry,
what was the problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33055
--- Comment #4 from pault at gcc dot gnu dot org 2007-08-29 19:19 ---
(In reply to comment #3)
> I am going to try this one.
>
Jerry,
This fixes it but I do not understand why it is necessary; nor have I
regtested. It's yours - I am going to tackle "spanned" pointers next, in the
hope
--- Comment #1 from dominiq at lps dot ens dot fr 2007-08-29 19:29 ---
Note that the problem disappears on Darwin with -m64 (excepted the problem
Error: Result of NEAREST overflows its kind at (1)).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
The following code gives an internal compiler error using gcc 4.1.2, but
compiles using 3.4. Remove the ()s around the {}s and it compiles just fine.
void reverse(void *_p, int nmemb, int size)
{
struct { char _[size]; } *p = _p, tmp;
for (int i=nmemb-1, j=0; jhttp://gcc.gnu.org/bugzilla
--- Comment #31 from andreast at gcc dot gnu dot org 2007-08-29 20:17
---
Thanks Jakub!
With this patch: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02111.html
you not only brought back the testsuite passes, you also made the bytecode
compilation work again on ppc-linux and ppc-darwin
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-29 20:41 ---
Mine, working on it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Assign
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-29 20:42 ---
That ICE is most likely PR 33140.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||compile-time-hog
Summary|Tree memory partitioning is |[4.3
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-29 20:52 ---
I think this comes down to the referenced decls is huge because of the static
"const" variable but I don't know for sure (I had looked into one of those
issues before).
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #1 from radford at blackbean dot org 2007-08-29 21:19 ---
Bug is present in 4.2.1 as well.
--
radford at blackbean dot org changed:
What|Removed |Added
--- Comment #12 from raeburn at raeburn dot org 2007-08-29 21:51 ---
Subject: Re: Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.
On Aug 29, 2007, at 13:39, andreagrassi at sogeasoft dot com wrote:
> I accept the a
All is in the title. Here is the complete output I have (my system is in
french):
g++ -DHAVE_CONFIG_H -I. -I.. -I ../src-g -O2 -MT sample1.o -MD -MP -MF
.deps/sample1.Tpo -c -o sample1.o sample1.cpp
../src/tuple.hpp: In instantiation of 'yactl::tuple_impl, std::allocator >
>::append, std::alloc
--- Comment #1 from masse_nicolas at yahoo dot fr 2007-08-29 21:57 ---
Created an attachment (id=14135)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14135&action=view)
Complete sources tree where the problem happens
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33239
--- Comment #1 from chris dot fairles at gmail dot com 2007-08-29 22:04
---
Not sure if this is same bug:
template
struct B;
template
struct B {};
template
struct B : public B {
H h;
};
template
class D : B<0,T...> {};
template
struct E;
template
struct E> {
typedef decl
seen with SVN 20070828
Matthias
/scratch/packages/gcc/snap/gcc-snapshot-20070827/build-hppa64/./gcc/xgcc
-B/scratch/packages/gcc/snap/gcc-snapshot-20070827/build-hppa64/./gcc/
-B/usr/lib/gcc-snapshot/hppa64-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/hppa64-linux-gnu/lib/ -isystem
/usr/lib/gcc-snaps
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-29 22:14 ---
*** Bug 33240 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-29 22:14 ---
*** This bug has been marked as a duplicate of 33029 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-29 22:14
---
Any news on this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33029
--- Comment #2 from dominiq at lps dot ens dot fr 2007-08-29 22:18 ---
I have run the NIST test suite and I got:
...
6 runtime errors
FM111 has NIST regression.
FM406 has NIST regression.
FM903 has NIST regression.
FM907 has NIST regression.
FM909 has NIST regression.
FM912 has NIST reg
On 29 Aug 2007 22:18:58 -, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:
> FM406 gives:
>
> ...
> COMPUTED=-0.0
> CORRECT= 0.0
Actually this is expected if you did not supply -fno-sign-zero or
-std=f95 as the default is to print negat
--- Comment #3 from pinskia at gmail dot com 2007-08-29 22:23 ---
Subject: Re: [4.3 regression] Missing last digit is some formatted output
On 29 Aug 2007 22:18:58 -, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:
> FM406 gives:
>
> ...
> COMPUTED=
--- Comment #4 from dominiq at lps dot ens dot fr 2007-08-29 23:02 ---
Subject: Re: [4.3 regression] Missing last digit is
some formatted output
> Actually this is expected if you did not supply -fno-sign-zero ...
You are right!-) I have added the option in the script I am using
and
When I try to compile the following file (attached at the end. quite big) I get
the folloring message
onefile.F90: In function MAIN__:
onefile.F90:778: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:1020
Please submit a full bug report,
with preprocessed source if approp
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||gcc-bugs at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-30 00:01 ---
The copy constructor on a fstream is invalid.
And you caused it to be created here: Seg s1 = Seg("");
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33242
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-30 00:06 ---
Yep this code is invalid.
*** This bug has been marked as a duplicate of 7498 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
1 - 100 of 115 matches
Mail list logo
