--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-18 07:04 ---
Regressed with r146817 (SSA expand).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44575
--- Comment #9 from burnus at gcc dot gnu dot org 2010-06-18 07:33 ---
Patch: http://gcc.gnu.org/ml/fortran/2010-06/msg00191.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
testsuite/gfortran.dg/zero_sized_1.f90 takes almost 11 minutes to compile on my
notebook when combining aggressive loop prefetching with loop peeling:
$ time gfortran-4.5 -O3 -march=core2 zero_sized_1.f90 -S
-fprefetch-loop-arrays -funroll-loops --param max-completely-peeled-insns=2000
real
--- Comment #1 from borntraeger at de dot ibm dot com 2010-06-18 07:59
---
4.6 (trunk) is also affected
--
borntraeger at de dot ibm dot com changed:
What|Removed |Added
--- Comment #6 from wvangulik at xs4all dot nl 2010-06-18 08:33 ---
This bug can be closed it is a binutils bug. The dissambler is generating the
wrong instruction.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44564
IMO, in the following test program the variable s within the class template may
be optimized-away in every case. Although, the variable is used as an argument
for a function call, it is omit-able due to the definition of function t1 as
"static inline" with its empty body. If I use instead of a clas
--- Comment #1 from mschulze at ivs dot cs dot ovgu dot de 2010-06-18
10:11 ---
(In reply to comment #0)
> IMO, in the following test program the variable s within the class template
> may
> be optimized-away in every case. Although, the variable is used as an argument
> for a function
--- Comment #1 from pzhao at gcc dot gnu dot org 2010-06-18 10:18 ---
Confirmed. The diagnostic of clang is better.
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
---
I'm using GCC to compile some code which uses SSE intrinsics. The code is being
compiled at -O3 -mfpmath=sse.
GCC decides to use MMX instructions for some of the operations (zeroing some
memory). There are no MMX intrinsics in the source, but an SSE _mm_setzero_ps
gets compiled into a pair of movq
Given file foo.cc:
const
int arr[] = {0};
compiled to foo.o, and file bar.cc:
extern
const
int arr[];
int main() {
return arr[0];
}
compiled and linked with foo.o, you get:
s3:~/ootbc/personal/ivan$ g++ bar.cc foo.o
/tmp/ccsMPoJa.o: In function `main':
bar.cc:(.
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-18 10:44 ---
const objects at namespace scope are static by default, you need to declare it
extern in foo.cc to prevent that
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-18 10:46 ---
As -mfpmath=sse isn't supposed to change the ABI we should never emit MMX
instructions automagically.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-18 10:51 ---
9.4.2/6 says that static data members of a class have external linkage. You
should be able to adjust that by providing proper visibility attributes
or pragmas.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-18 10:52 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Summary|__builtin_va_arg overwrites |[4.5/4.6 R
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-18 10:56 ---
Works on i?86-linux.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Compo
I have observed the following behavior on several generations of GCC (starting
at Apple's 4.0) and up to 4.6. Tested on OS X, but also GNU/Linux.
It's hard to write assert-like functions because GCC does not behave equally
when the context is that of a function template, or a simple function.
Th
--- Comment #1 from akim dot demaille at gmail dot com 2010-06-18 11:49
---
Created an attachment (id=20938)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20938&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44580
--- Comment #3 from mschulze at ivs dot cs dot ovgu dot de 2010-06-18
12:01 ---
IMO, this is not a static member of a class itself, even it is defined inside
of a member function, thus I think it has not to have external linkage.
--
mschulze at ivs dot cs dot ovgu dot de changed:
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-18 13:25 ---
If class_template::class_template is instantiated in another translation
unit then it needs to refer to the same 's' ... but since the constructor calls
a static function, an instantiation in another TU would violate th
--- Comment #2 from boschmann at tp1 dot physik dot uni-siegen dot de
2010-06-18 13:29 ---
Subject: Re: [OOP] ICE with TBP of polymorphic derived
type array
Hallo Janus,
wird denn im Moment an diesem Feature gearbeitet? Eigentlich wollte ich
diesen Sommer mein Code offiziell in das
--- Comment #14 from michael dot haubenwallner at salomon dot at
2010-06-18 13:44 ---
(In reply to comment #13)
> #include
> #include
> void foo()
> {
> std::map bar;
> }
Simply compiling this source code into an rtl-enabled shared library leads to
that linker warning,
when trying to compile fftw3, I get the following error:
gcc -O2 -g -mpa-risc-1-0 -c r2cf_16.i -fPIC
r2cf_16.i: In function r2cf_16:
r2cf_16.i:119:1: internal compiler error: in simplify_subreg, at
simplify-rtx.c:5143
Please submit a full bug report,
gcc is:
gcc -v
Using built-in specs.
COLLECT_
--- Comment #1 from b dot gunreben at web dot de 2010-06-18 15:32 ---
Created an attachment (id=20939)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20939&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44581
--- Comment #2 from matz at gcc dot gnu dot org 2010-06-18 15:58 ---
It's not SSA expand (might be exposed by it, don't know), but the
bug is pre-existing already in 4.3:
long unsigned int D.2219;
struct S116 va_arg_tmp.3;
...
addr.0 = &va_arg_tmp.3;
addr.4 = (long unsigned int
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-06-18 16:39
---
Subject: Bug 40900
Author: ebotcazou
Date: Fri Jun 18 16:38:29 2010
New Revision: 161006
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161006
Log:
PR rtl-optimization/40900
* expr.c (expa
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-06-18 16:40
---
On the mainline.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #11 from paolo at gcc dot gnu dot org 2010-06-18 18:08 ---
Subject: Bug 32618
Author: paolo
Date: Fri Jun 18 18:07:45 2010
New Revision: 161009
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161009
Log:
2010-06-18 Paolo Carlini
PR libstdc++/32618
the function with array return must create a temporary array to hold the
returned value and transfer the value to destination array after function call.
Gfortran directly pass the destination array as the first fake argument. This
is wrong because destination is supposed to assigned to a value from
--- Comment #1 from yin at absoft dot com 2010-06-18 18:16 ---
Created an attachment (id=20940)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20940&action=view)
bug example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
--- Comment #12 from paolo dot carlini at oracle dot com 2010-06-18 18:22
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severit
--- Comment #2 from yin at absoft dot com 2010-06-18 18:23 ---
it should be 0.0 always, NOT to be chaotic number like C, because when ddx is
declared, it has to be initialized to 0.0 by fortran standard.
--
yin at absoft dot com changed:
What|Removed
On Linux/ia64, revision 160916 gave
FAIL: c-c++-common/torture/complex-sign-add.c -O0 execution test
FAIL: c-c++-common/torture/complex-sign-sub.c -O0 execution test
Revision 160869 is OK.
--
Summary: [4.6 Regression] c-c++-common/torture/complex-sign-add.c
Product: g
On Linux/ia64, revision 160858 gave
FAIL: gfortran.dg/typebound_proc_15.f03 -O (internal compiler error)
FAIL: gfortran.dg/typebound_proc_15.f03 -O (test for excess errors)
Revision 160826 is OK.
--
Summary: [4.6 Regression] gfortran.dg/typebound_proc_15.f03
Product:
The following code compiles without warning and has an exit value of 1, which
is correct according to the standard. However, an implicit conversion from
double to int happened without a corresponding warning. This seems incorrect to
me, and similar to bug 24525 (
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #3 from kargl at gcc dot gnu dot org 2010-06-18 18:49 ---
(In reply to comment #2)
> it should be 0.0 always, NOT to be chaotic number like C, because when ddx is
> declared, it has to be initialized to 0.0 by fortran standard.
>
Can you point the language in the Fortran S
--- Comment #4 from yin at absoft dot com 2010-06-18 19:00 ---
O.K. I doublechecked the standard. The array declared does not need to be
initialized in this case. So the return value could be any number. However,
this kind of implementation should fail in a certian case. I am trying to w
--- Comment #5 from kargl at gcc dot gnu dot org 2010-06-18 19:10 ---
(In reply to comment #4)
> O.K. I doublechecked the standard. The array declared does not need to be
> initialized in this case. So the return value could be any number. However,
> this kind of implementation should fa
the folowing testcase does a casting which results in undefined behaviour but
gcc does not warn about it.
ypedef int (*bar_t)(int x, int y, ...);
int foo(int x, int y) {
return x+y;
}
void f(int x, int y) {
bar_t bar;
/* Cast foo to variadic type... undefined behaviour */
--- Comment #1 from alvaro dot begue at gmail dot com 2010-06-18 20:42
---
I just learned about -Wconversion and gcc does indeed warn about the implicit
conversion from double to int when I specify it. Sorry for the false alarm.
--
alvaro dot begue at gmail dot com changed:
template struct A { };
template struct B { static const char c[1]; typedef A::c> C; };
ICEs in instantiate_decl.
template struct A { };
template struct B { static const int c; typedef A::c> C; };
template const int B c = sizeof (T);
ICEs too, while e.g.
template struct A { };
template st
--- Comment #16 from andi-gcc at firstfloor dot org 2010-06-18 21:11
---
This turned out to be a kernel bug, rdtsc_barrier() needed to be marked
__force_inline, otherwise gcc would not inline this function.
(although it's slightly fishy for gcc too not inline a function that
only has t
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-06-18 21:12 ---
Mine.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-18 21:18 ---
Works for me on x86_64-unknown-linux-gnu at r160947.
Can you show the backtrace for the ICE?
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-18 21:19 ---
In the link, one also finds
trim(str1) == trim(str2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40628
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-18 21:24 ---
(In reply to comment #0)
> On Linux/ia64, revision 160858 gave
> ...
> Revision 160826 is OK.
The only Fortran-related change in this range is
r160834 | janus | 2010-06-16 14:54:54 +0200 (Wed, 16 Jun 2010) | 17 lines
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-18 21:54 ---
Compiled fine until r144617, starting with r144618 gave
R.ii:2: error: âB::câ cannot appear in a constant-expression
R.ii:2: error: template argument 1 is invalid
and starting with r154042 started ICEing.
--
h
typebound_proc_15 -std=f2003
-version -o typebound_proc_15.s -fintrinsic-modules-path finclude
GNU Fortran (GCC) version 4.6.0 20100618 (experimental) [trunk revision 161008]
(ia64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20100618 (experimental) [trunk revision
161008], GMP version 4.3.2
GNU Fortran (GCC) version 4.6.0 20100618 (experimental) [trunk revision 161010]
(i686-pc-linux-gnu)
compiled by GNU C version 4.6.0 20100618 (experimental) [trunk revision
161010], GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --para
--- Comment #10 from burnus at gcc dot gnu dot org 2010-06-18 22:24 ---
Subject: Bug 44556
Author: burnus
Date: Fri Jun 18 22:23:40 2010
New Revision: 161011
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161011
Log:
2010-06-18 Tobias Burnus
PR fortran/44556
--- Comment #3 from danglin at gcc dot gnu dot org 2010-06-18 22:35 ---
Subject: Bug 43739
Author: danglin
Date: Fri Jun 18 22:34:42 2010
New Revision: 161012
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161012
Log:
Backport from mainline
2010-04-14 Steve Ellc
--- Comment #4 from danglin at gcc dot gnu dot org 2010-06-18 22:39 ---
Subject: Bug 43739
Author: danglin
Date: Fri Jun 18 22:38:32 2010
New Revision: 161013
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161013
Log:
Backport from mainline
2010-04-14 Steve Ellc
--- Comment #5 from janus at gcc dot gnu dot org 2010-06-18 23:54 ---
(In reply to comment #3)
> /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/typebound_proc_15.f03:15.23:
>
> procedure :: bar, baz { dg-error "PROCEDURE list" }
>1
> Error
--- Comment #17 from bdubbs at linuxfromscratch dot org 2010-06-19 00:05
---
I can confirm that changing inline to __always_inline in
arch/x86/include/asm/system.h fixed the panic for me.
I'm not sure if this fix is the result of an error in the kernel or gcc.
Leaving the bug open for
--- Comment #18 from kevin dot bowling at kev009 dot com 2010-06-19 00:07
---
Does it make sense for the default and distros to use an -Os kernel with modern
systems (i.e. 2M-8M cache). If gcc 4.5 won't inline this at -Os, I wonder what
other bad decisions are being made.
--
http:
--- Comment #12 from danglin at gcc dot gnu dot org 2010-06-19 00:28
---
Subject: Bug 41090
Author: danglin
Date: Sat Jun 19 00:28:18 2010
New Revision: 161018
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161018
Log:
PR c++/41090
* g++.dg/ext/label13.C: xfail
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-19 00:47 ---
(In reply to comment #5)
> Ok, actually I also get an ICE. But for some reason only when compiling by
> hand, not in the testsuite.
>
> It is fixed by this patch:
>
>
> Index: gcc/fortran/resolve.c
> =
On x86, I got
[...@gnu-6 divb]$ cat umod-2.c
extern unsigned char z;
unsigned char
foo (unsigned char x, unsigned char y)
{
z = x/y;
return x % y;
}
[...@gnu-6 divb]$ gcc -S -O3 umod-2.c
[...@gnu-6 divb]$ cat umod-2.s
.file "umod-2.c"
.text
.p2align 4,,15
.globl fo
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-19 00:52 ---
Created an attachment (id=20941)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20941&action=view)
A patch
With this patch, I got
foo:
.LFB0:
.cfi_startproc
movl%edi, %eax
divb%
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-06-19 00:58
---
Subject: Bug 44477
Author: jvdelisle
Date: Sat Jun 19 00:58:28 2010
New Revision: 161020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161020
Log:
2010-06-18 Jerry DeLisle
PR libfortran/44477
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-06-19 01:05
---
Subject: Bug 44477
Author: jvdelisle
Date: Sat Jun 19 01:05:05 2010
New Revision: 161021
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161021
Log:
2010-06-18 Jerry DeLisle
PR libfortran/44477
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-19 06:40 ---
Mine. Patch: http://gcc.gnu.org/ml/fortran/2010-06/msg00199.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
62 matches
Mail list logo
