--- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-06 04:15 ---
Assembler output:
f:
pushl %ebp
movl%esp, %ebp
subl$16, %esp
movq%mm0, -8(%ebp)
movq%mm1, -16(%ebp)
emms
fldla
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-06 04:12 ---
Created an attachment (id=18310)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18310&action=view)
A failing example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40983
Hi
This example fails, because in function "f", the scheduler incorrectly swapped
floating point store to "c" and load of mmx registers.
Compile with -O2 -march=pentium-mmx
--
Summary: The scheduler incorrectly swaps MMX and floating point
instructions
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-08-06
01:28 ---
Interestingly...
gfortran -O2 -fgraphite-identity -floop-interchange air.f90 -o air
compiles the air benchmark without errors but the resulting code produces...
AIRFLOW IN A BOX
Vers
6_64-apple-darwin10
Configured with: ../gcc-4.5-20090805/configure --prefix=/sw
--prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includ
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
This error doesn't occur with...
gfortran -O2 -fgraphite-identity aermod.f90 -o aermod
..or...
gfortran -O2 -fgraphite-identity -floop-interchange aermod.f90 -o aermod
Using built-in specs.
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5-20090805/configure --prefix=/sw
--prefix=/s
--- Comment #1 from spop at gcc dot gnu dot org 2009-08-06 00:26 ---
This makes me think that Tobias' regtester does not test the polyhedron
benchmarks in the extra tests, or it does not report anymore the failures.
I will investigate this issue.
--
spop at gcc dot gnu dot org chang
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
)
ivtmp.1799_745 = PHI
air.f90:1064:0: internal compiler error: verify_stmts failed
Using built-in specs.
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5-20090805/configure --prefix=/sw
--prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran
The Polyhedron 2005 induct benchmark averages 12.44 seconds run-time when
compiled with...
gfortran -ffast-math -funroll-loops -msse3 -O3 induct.f90 -o induct
but averages 20.2 seconds when compiled with -fgraphite-identity added to the
compilation flags.
This issue remains after...
http://gcc.g
--- Comment #12 from bonzini at gnu dot org 2009-08-05 23:09 ---
Created an attachment (id=18309)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18309&action=view)
another patch
This failure is related to NRV, which is why there is no C failure.
If I take care of it the patch is a
--- Comment #1 from mikpe at it dot uu dot se 2009-08-05 22:42 ---
I can reproduce this ICE on i686-linux with gcc-4.3-20090802 and
gcc-4.4-20090804. gcc-4.5 has some nasty new build requirements for c++ so I
didn't try it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40975
--- Comment #1 from paolo dot carlini at oracle dot com 2009-08-05 22:26
---
You should try to figure out the reason of those errors: whether, for some
reason, _GLIBCXX_HAVE_FENV_H is undefined, thus is not included in
tr1/cfenv. Or, the configure test for the facilities in (generated
--- Comment #11 from sje at cup dot hp dot com 2009-08-05 21:36 ---
Created an attachment (id=18308)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18308&action=view)
C++ test case that fails with plausible patch
This is cut down from libstdc++-v3 sources. I am not sure it is sti
--- Comment #6 from ubizjak at gmail dot com 2009-08-05 21:19 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from uros at gcc dot gnu dot org 2009-08-05 21:17 ---
Subject: Bug 40906
Author: uros
Date: Wed Aug 5 21:16:52 2009
New Revision: 150501
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150501
Log:
PR target/40906
* config/i386/i386.c (ix86_split_lo
--- Comment #15 from burnus at gcc dot gnu dot org 2009-08-05 20:52 ---
FIXED by reverting the bug.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2009-08-05 20:51 ---
Patch broke IA64 and was reverted (cf. 40969). Proper fix is PR 40976 which
should solve several of the remaining LTO problems as well.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-08-05 20:51 ---
The long-dead declaration is brought back to life by the following
line in gimplify_var_or_parm_decl() in gimplify.c:
tree value_expr = DECL_VALUE_EXPR (decl);
I don't know why that happens yet.
--
http:
--- Comment #14 from burnus at gcc dot gnu dot org 2009-08-05 20:47 ---
Subject: Bug 40969
Author: burnus
Date: Wed Aug 5 20:47:19 2009
New Revision: 150500
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150500
Log:
2009-08-05 Tobias Burnus
PR fortran/40969
--- Comment #5 from burnus at gcc dot gnu dot org 2009-08-05 20:47 ---
Subject: Bug 40949
Author: burnus
Date: Wed Aug 5 20:47:19 2009
New Revision: 150500
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150500
Log:
2009-08-05 Tobias Burnus
PR fortran/40969
R
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-05 20:43 ---
See also vaguely related PR 40978.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Oth
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #13 from burnus at gcc dot gnu dot org 2009-08-05 20:36 ---
(In reply to comment #11)
> This patch works:
> + if (typelist || sym->attr.if_source != IFSRC_UNKNOWN)
> +typelist = gfc_chainon_list (typelist, void_type_node);
That patch essentially undoes the patch of PR 4
Motivated by PR 40969. See also PR 40976.
For functions where the result is returned by argument, one should use C++'s
named return value optimization (NRV),
cf. http://en.wikipedia.org/wiki/Return_value_optimization
That presumably also allows to mark PURE functions which return their result a
Hi,
When I compile source code with GCC 4.4.1 (-m68060 -O3 -fomit-frame-pointer):
#include
#define umul_ppmm(xh, xl, a, b) \
__asm__ ("| Inlined umul_ppmm\n" \
"move%.l %2,%/d0\n" \
"move%.
--- Comment #8 from janus at gcc dot gnu dot org 2009-08-05 20:25 ---
I guess I'll take over then. Got a patch.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from burnus at gcc dot gnu dot org 2009-08-05 20:03 ---
(In reply to comment #10)
> It failed at a different place:
> 61if ( c1 != *c2) abort();
> (gdb) p c1
> $1 = 43 + 0 * I
> (gdb) p *c2
> $2 = -1 + 2 * I
Hmm, I honestly have no idea why this fails. In my
--- Comment #11 from hjl dot tools at gmail dot com 2009-08-05 19:52
---
This patch works:
--- ./trans-types.c.foo 2009-08-05 07:26:53.0 -0700
+++ ./trans-types.c 2009-08-05 12:51:00.0 -0700
@@ -2324,7 +2324,10 @@ gfc_get_function_type (gfc_symbol * sym)
while (n
--- Comment #10 from hjl dot tools at gmail dot com 2009-08-05 19:49
---
(In reply to comment #9)
> Thanks! I think the following patch should cure this. I think we will still
> have issues with LTO but those are inevitable and need to be solved on the
> middle end.
>
> Index: trans-t
Motivated by PR 40969.
Currently, we generate a function declaration for
procedure() :: proc
and another one for
call proc(something) ! or var = proc(something)
If no explicit interface is known, the function argument is undefined, which
causes problems with LTO, cf. PR 40949 and PR 40969.
--- Comment #9 from burnus at gcc dot gnu dot org 2009-08-05 19:33 ---
(In reply to comment #6)
> 21if ( a1 != *a2 ) abort();
> (gdb) p a1
> $1 = 0
> (gdb) p *a2
> $2 = 42
Thanks! I think the following patch should cure this. I think we will still
have issues with LTO but those
--- Comment #8 from hjl dot tools at gmail dot com 2009-08-05 19:28 ---
(In reply to comment #7)
> When we see
>
> external f_to_f, i_to_i, c_to_c
> external f_to_f8, i_to_i8, c_to_c8
>
> and do
>
> typelist = gfc_chainon_list (typelist, void_type_node);
>
> Later, we
--- Comment #7 from hjl dot tools at gmail dot com 2009-08-05 19:22 ---
When we see
external f_to_f, i_to_i, c_to_c
external f_to_f8, i_to_i8, c_to_c8
and do
typelist = gfc_chainon_list (typelist, void_type_node);
Later, we see
call f_to_f (b, %VAL (a), %REF (c), %L
--- Comment #6 from hjl dot tools at gmail dot com 2009-08-05 19:09 ---
21if ( a1 != *a2 ) abort();
(gdb) p a1
$1 = 0
(gdb) p *a2
$2 = 42
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
--- Comment #5 from hjl dot tools at gmail dot com 2009-08-05 19:07 ---
(gdb) bt
#0 0xa0010621 in __kernel_syscall_via_break ()
#1 0x203e7630 in raise () from /lib/tls/libc.so.6.1
#2 0x203ea010 in abort () from /lib/tls/libc.so.6.1
#3 0x400014b0 in f_t
--- Comment #4 from kargl at gcc dot gnu dot org 2009-08-05 19:06 ---
(In reply to comment #3)
> (In reply to comment #1)
> > Works for me on x86-64-linux and seems also to work on several other systems
> > according to the testresults mailing list.
> > (Only failure - your ia64 system:
--- Comment #3 from hjl dot tools at gmail dot com 2009-08-05 18:58 ---
(In reply to comment #1)
> Works for me on x86-64-linux and seems also to work on several other systems
> according to the testresults mailing list.
> (Only failure - your ia64 system:
> http://gcc.gnu.org/ml/gcc-tes
--- Comment #4 from hjl dot tools at gmail dot com 2009-08-05 18:47 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00284.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #7 from bangerth at gmail dot com 2009-08-05 18:47 ---
(In reply to comment #6)
> Examples where the ampersand probably makes more sense are:
>
> g++.dg/rtti/typeid8.C
> g++.dg/conversion/memfn2.C
> g++.old-deja/g++.other/asm2.C
Possibly, but in all those cases, it may also
--- Comment #2 from brian dot e dot bliss at intel dot com 2009-08-05
18:46 ---
My interpretation of that rule is that this is a legal testcase as long as ub
is even at runtime. If ub is odd, then the behavior is undefined.
Anyway - that is a subject for bug 39495. What I'm trying to
--- Comment #6 from manu at gcc dot gnu dot org 2009-08-05 18:19 ---
Examples where the ampersand probably makes more sense are:
g++.dg/rtti/typeid8.C
g++.dg/conversion/memfn2.C
g++.old-deja/g++.other/asm2.C
Not so sure about:
g++.dg/template/pseudodtor3.C
g++.dg/template/using14.C
S
Using array new as a default initializer of a constructor argument, when the
object being "newed" itself contains a constructor, crashes the compiler with
an error similar to the following:
% g++ -c gcc_bug.cpp
gcc_bug.cpp:13: internal compiler error: in copy_tree_r, at
tree-inline.c:3160
--- Comment #4 from uros at gcc dot gnu dot org 2009-08-05 18:05 ---
Subject: Bug 40906
Author: uros
Date: Wed Aug 5 18:04:42 2009
New Revision: 150497
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150497
Log:
PR target/40906
* config/i386/i386.c (ix86_split_lo
--- Comment #3 from hjl dot tools at gmail dot com 2009-08-05 18:04 ---
A patch is posed at
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00277.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from bangerth at gmail dot com 2009-08-05 17:57 ---
However, one of my gripes with the previous error message is that it's
just too obscure: where did I forget the '&', and why would I have wanted
to write them in the first place? It could have said "did you forget to
take
--- Comment #4 from bangerth at gmail dot com 2009-08-05 17:54 ---
(In reply to comment #3)
> &c.f isn't even valid, it should be &C::f
>
> I didn't check the code, but that message isn't used for member variables or
> nested types, so if it does only apply to member functions then I th
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-08-05 17:52 ---
Created an attachment (id=18307)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18307&action=view)
Patch which I am testing
This patch fixes the problem including a+1 and a+2 not aliasing each other.
It adds tw
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-08-05 16:40
---
&c.f isn't even valid, it should be &C::f
I didn't check the code, but that message isn't used for member variables or
nested types, so if it does only apply to member functions then I think
changing '&' to '()'
I'm using a gcc-4.4.1 cross-compiler to build another instance of gcc-4.4.1 for
the target system. make fails with the following error message:
make[2]: Entering directory
`/mnt/clfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3'
make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc"
"CC_FOR_TARGET=/mnt/
--- Comment #7 from ramana at gcc dot gnu dot org 2009-08-05 16:42 ---
Invalid testcase as per comment #6.
(In reply to comment #4)
> I see the same problem when I try to compile transmission release 1.73. The
> error happens with file libtransmission/fdlimit.c. Works till -O1 but fail
--- Comment #1 from jakub at gcc dot gnu dot org 2009-08-05 16:24 ---
I don't believe this is a valid OpenMP testcase.
The standard says:
"The behavior is unspecified if any intermediate result required to compute the
iteration count cannot be represented in the type determined above."
a
--- Comment #6 from pault at gcc dot gnu dot org 2009-08-05 16:10 ---
Subject: Bug 40847
Author: pault
Date: Wed Aug 5 16:10:19 2009
New Revision: 150493
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150493
Log:
2009-08-05 Paul Thomas
PR fortran/40847
* ire
We should consider marking module procedures with PRIVATE attribute as STATIC
(in the C sense) such that they can be eliminated. In the following program,
"two" could be optimized away as it cannot be called from outside the module.
However, this does not happen with
gfortran -O3 -c test.f90
--- Comment #10 from manu at gcc dot gnu dot org 2009-08-05 16:01 ---
I think we should close this as WONTFIX.
* In GCC 4.5 we only warn at -O1 with a "may be", no warning with -O{0,2,3,s}.
So it seems just a matter of optimizers exposing/hiding things.
* The testcase is a bit obscure,
--- Comment #2 from manu at gcc dot gnu dot org 2009-08-05 15:33 ---
Perhaps we could just mention both '&' and '()'? It seems a bit difficult to
check all the conditions that you mention.
BTW, shouldn't it say 'member function'? Can this be anything different than a
member function?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40971
--- Comment #8 from manu at gcc dot gnu dot org 2009-08-05 15:07 ---
OK, setting it back to NEW, but I don't have any idea about how to approach
this.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from rainer at emrich-ebersheim dot de 2009-08-05 15:01
---
doesn't reproduce.
--
rainer at emrich-ebersheim dot de changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2009-08-05 15:00 ---
I am not going to have time for this right now.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #18 from uweigand at gcc dot gnu dot org 2009-08-05 14:59
---
(In reply to comment #16)
> Uli, can you please have a look at Richard's and Paolo's patches and does one
> or the other seem like a "better" fix?
I've yet another suggestion :-) See my message at:
http://gcc.g
--- Comment #1 from jakub at gcc dot gnu dot org 2009-08-05 14:56 ---
Created an attachment (id=18306)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18306&action=view)
gcc44-pr40971.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
--- Comment #1 from rainer at emrich-ebersheim dot de 2009-08-05 14:51
---
The upstream fix is here:
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=b5282894cf194b878322bf2688bd90571bef1c69
Please, update the gcc version accordingly.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #6 from janus at gcc dot gnu dot org 2009-08-05 14:50 ---
(In reply to comment #2)
> > * trans-decl.c (create_function_arglist)
> >
> > This is OK - the new cl is threaded into the list.
>
> Actually I think that this is not done properly.
The following should fix it:
In
--- Comment #5 from pault at gcc dot gnu dot org 2009-08-05 14:47 ---
Created an attachment (id=18305)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18305&action=view)
A provisional patch for the PR
(In reply to comment #3)
> The real issue is that mold->expr_type is EXPR_VARIABLE
--- Comment #14 from hjl at gcc dot gnu dot org 2009-08-05 14:45 ---
Subject: Bug 40570
Author: hjl
Date: Wed Aug 5 14:45:15 2009
New Revision: 150487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150487
Log:
2009-07-28 H.J. Lu
Backport from mainline:
2009-
--- Comment #20 from hjl at gcc dot gnu dot org 2009-08-05 14:45 ---
Subject: Bug 40834
Author: hjl
Date: Wed Aug 5 14:45:15 2009
New Revision: 150487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150487
Log:
2009-07-28 H.J. Lu
Backport from mainline:
2009-
This prevents the build of libgomp.dll for example:
*** Warning: linker path does not have real file for library -lpthread.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the librar
--- Comment #3 from uros at gcc dot gnu dot org 2009-08-05 14:42 ---
Subject: Bug 40906
Author: uros
Date: Wed Aug 5 14:41:54 2009
New Revision: 150486
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150486
Log:
PR target/40906
* config/i386/i386.c (ix86_split_lo
extern void bar (char *);
void
foo (int f, long a)
{
{
char d[32768];
bar (d);
}
double b = f;
while (a)
{
char c[8];
__builtin_memcpy (c, &b, sizeof (c));
if (*(double *) c != 2.0)
break;
}
}
ICEs on powerpc-linux when compiled with -O -m32 -fstack-prote
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
--- Comment #6 from sebpop at gmail dot com 2009-08-05 14:04 ---
Subject: Re: [4.5 Regression][graphite] slow
compilation
What changed from 4.4 to 4.5 is that we now get to compile larger
SCoPs with Graphite. In 4.5, Graphite can deal with reductions and
other unhandled const
What changed from 4.4 to 4.5 is that we now get to compile larger
SCoPs with Graphite. In 4.5, Graphite can deal with reductions and
other unhandled constructs like the NE_EXPR that Fortran is frequently
using for representing the exit condition of DO loops.
--- Comment #4 from manu at gcc dot gnu dot org 2009-08-05 13:55 ---
What happens when a function must have a particular return type because it is
accessed through a pointer, but we want to mark it as noreturn?
Example: gcc/java/jcf.h (jcf_unexpected_eof)
I am not sure this warning is
--- Comment #10 from jason at redhat dot com 2009-08-05 13:42 ---
Subject: Re: Error message about no matching function for
call with derived class arguments could be improved
On 08/04/2009 06:42 PM, manu at gcc dot gnu dot org wrote:
> I don't even know if we have different codepaths
--- Comment #5 from janus at gcc dot gnu dot org 2009-08-05 13:21 ---
(In reply to comment #4)
> (In reply to comment #3)
> > Tobias, do you remember any of your thoughts when writing this?
>
> Well, they are essentially written in the patch email (linked from the PR
Yeah, ok, the gen
--- Comment #25 from manu at gcc dot gnu dot org 2009-08-05 13:21 ---
If anyone has any hint on where this could be caught, suggestions are welcome.
The explanation of Alexandre Oliva in comment #8 is totally obscure to me and
perhaps outdated given the age of this PR.
--
manu at gc
--- Comment #8 from jakub at gcc dot gnu dot org 2009-08-05 12:55 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from jakub at gcc dot gnu dot org 2009-08-05 12:54 ---
Subject: Bug 40924
Author: jakub
Date: Wed Aug 5 12:54:21 2009
New Revision: 150484
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150484
Log:
PR rtl-optimization/40924
* dse.c (canon_address)
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-05 12:50 ---
(In reply to comment #3)
> Tobias, do you remember any of your thoughts when writing this?
Well, they are essentially written in the patch email (linked from the PR
40383):
http://gcc.gnu.org/ml/gcc-patches/2009-
--- Comment #6 from jakub at gcc dot gnu dot org 2009-08-05 12:36 ---
Subject: Bug 40924
Author: jakub
Date: Wed Aug 5 12:36:34 2009
New Revision: 150483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150483
Log:
PR rtl-optimization/40924
* dse.c (canon_address)
--- Comment #24 from paolo dot carlini at oracle dot com 2009-08-05 12:34
---
*** Bug 40970 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #3 from paolo dot carlini at oracle dot com 2009-08-05 12:34
---
Eh, eh...
*** This bug has been marked as a duplicate of 986 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-08-05 12:29
---
Oh, you just want a warning for this. Indeed, ICC spills one with -Wall. Maybe
Manuel has an opinion...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Adde
--- Comment #1 from paolo dot carlini at oracle dot com 2009-08-05 12:25
---
This is just triggering undefined behavior: after the constructor call dim is
bound to a temporary long created on the fly from the double _dim, which
disappears by the time newValue is called. Nothing to do wi
--- Comment #21 from manu at gcc dot gnu dot org 2009-08-05 12:09 ---
Are there any failing testcases for this PR? Perhaps we can turn this into a
meta-bug, or if there are no testcases right now, it would be better to close
it (we have already enough open PRs).
--
http://gcc.gnu.or
Following wrong code compiles and executes properly with 'g++ -Wall -O2', but
compiles and terminates with std::bad_alloc() 'g++ -Wall'. In both cases
expected behaviour would have been an error from compiler stating that it is
not possible to initialize a const long & with a const double &. gcc er
--- Comment #2 from abnikant dot singh at atmel dot com 2009-08-05 11:56
---
gcc.c-torture/compile/pr32606.c compiles fine with both avr-gcc-4.3.3 and
avr-gcc-4.4.0
--
abnikant dot singh at atmel dot com changed:
What|Removed |Added
--
--- Comment #2 from abnikant dot singh at atmel dot com 2009-08-05 11:52
---
It compiles fine with both avr-gcc-4.3.3 and avr-gcc-4.4.0
--
abnikant dot singh at atmel dot com changed:
What|Removed |Added
---
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-05 11:44 ---
The code from trans-decl.c (create_function_arglist) cited in comment #2 was
committed by Tobias as r148517 just a few weeks ago, as a fix for PR 40383.
Tobias, do you remember any of your thoughts when writing this?
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-05 11:27 ---
(In reply to comment #1)
> * trans-decl.c (create_function_arglist)
>
> This is OK - the new cl is threaded into the list.
Actually I think that this is not done properly. The code in question is:
gfc
--- Comment #5 from jv244 at cam dot ac dot uk 2009-08-05 10:59 ---
Checked against the 4.4 branch, with the following timings:
4.4 w/o1.79
w 1.80
4.5 w/o4.23
w144.30
--
jv244 at cam dot ac dot uk changed:
What|Removed |A
--- Comment #2 from manu at gcc dot gnu dot org 2009-08-05 10:16 ---
At the moment the parser detects and reports the error, it doesn't know that it
is parsing an array subscript. We could test for typical errors before trying
to parse the expression but that would pessimize valid code.
--- Comment #4 from jv244 at cam dot ac dot uk 2009-08-05 10:11 ---
(In reply to comment #3)
>
> The code generation of Graphite can be exponential, didn't I mentioned
> it yet?
however, I'm relatively certain that I tested graphite when it was introduced
in 4.4, and it didn't impact c
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-08-05 10:03
---
This example has four slightly different errors:
struct B {};
struct D : B {};
struct X {};
int foo(B*&);
int i = foo( (B*)0 );
int j = foo( (D*)0 );
D* pd = 0;
int k = foo( pd );
X* px = 0;
int l = foo(
--- Comment #3 from manu at gcc dot gnu dot org 2009-08-05 10:01 ---
By the way, we would prefer a preprocessed testcase, as minimal as possible.
See http://gcc.gnu.org/bugs.html#report
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39757
--- Comment #1 from pault at gcc dot gnu dot org 2009-08-05 08:57 ---
* expr.c (simplify_const_ref)
* symbol.c (gfc_set_default_type, generate_isocbinding_symbol)
These two produce leaks.
* trans-decl.c (create_function_arglist)
This is OK - the new cl is threaded into the list.
T
--- Comment #2 from pault at gcc dot gnu dot org 2009-08-05 08:41 ---
(In reply to comment #1)
> Works for me on x86-64-linux and seems also to work on several other systems
> according to the testresults mailing list.
Works for me too at revision 150482 on x86_64/FC9
Cheers
Paul
--
1 - 100 of 102 matches
Mail list logo
