--- Comment #2 from simartin at gcc dot gnu dot org 2008-09-27 10:58
---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01880.html
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from simartin at gcc dot gnu dot org 2008-09-27 10:59
---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01880.html
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #20 from cnstar9988 at gmail dot com 2008-09-27 11:32 ---
ping...
The bug is not fixed in 4.3-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37102
--- Comment #7 from laurent at ient dot rwth-aachen dot de 2008-09-27
11:40 ---
Hello
I reopen the discussion because I noticed a problem in relation with
"__attribute__((__always_inline__))" when I tried to compile my library as a
DLL.
GCC now forces inlines well, and is now as quick
--- Comment #23 from zadeck at naturalbridge dot com 2008-09-27 12:44
---
I do not believe honza.
My measurements at -O0 on x86-42 are about 15 refs per insn.
This is based on the following stats. (These can be reproduced using a patch
that i am about to submit).
;;total ref
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2008-09-27 12:57
---
Fixed on 4.4.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #3 from steven at gcc dot gnu dot org 2008-09-27 14:09 ---
Created an attachment (id=16414)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16414&action=view)
draft patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37635
Using gcc-4.3 to compile Gauche-0.8.13/src/vm.c with -O2 takes several minutes,
this problem doesn't occur with gcc-4.2.
$ time /usr/bin/gcc-4.3 -O2 vm.i -c
real2m13.341s
user2m13.008s
sys 0m0.308s
$ time /usr/bin/gcc-4.3 -O2 testcase.i -c
real2m2.527s
user2m2.004s
sys 0m0
--- Comment #1 from edwintorok at gmail dot com 2008-09-27 16:20 ---
Created an attachment (id=16415)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16415&action=view)
testcase
time gcc-4.3 -O2 testcase.i -c
real2m13.341s
user2m13.008s
sys 0m0.308s
--
http://gcc.g
While reducing the testcase for PR37658 I found another bug:
$ gcc-4.3 -fschedule-insns testcase.i
...
testcase.i:193: error: unable to find a register to spill in class ÂAREGÂ
testcase.i:193: error: this is the insn:
(insn 17782 17785 17783 1528 testcase.i:189 (parallel [
(set (reg:
--- Comment #1 from edwintorok at gmail dot com 2008-09-27 16:28 ---
Created an attachment (id=16416)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16416&action=view)
file dumped by gcc
This is the file dumped by gcc, I am trying to get a reduced testcase using
delta, will attach
$ uname -a
CYGWIN_NT-5.1 MCKELVEY-XP 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
[EMAIL PROTECTED] ~/cvsroot/gcc-obj
$ g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /cygdrive/f/Home/cvsroot/gcc/configure --verbose
--enable-threads --disable-nls --disable-win32-registry
--
--- Comment #2 from edwintorok at gmail dot com 2008-09-27 16:40 ---
Reduced testcase:
/* gcc -fschedule-insns */
int foo(int a, int b) {
return bar(foobar(b) / foobar(a));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37659
--- Comment #3 from edwintorok at gmail dot com 2008-09-27 16:43 ---
the error message for the above testcase:
$ gcc-4.3 -fschedule-insns v.i
v.i: In function ÂfooÂ:
v.i:3: error: unable to find a register to spill in class ÂAREGÂ
v.i:3: error: this is the insn:
(insn 17 20 18 2 v.i:
$ cat b.cc
#include
using namespace std;
void init(long double& n, int k) {
n = k;
}
int main() {
long double n;
init(n, -2);
cout << n << endl;
}
$ g++ b.cc ; ./a.out
-2
$ g++ -m64 b.cc ; ./a.out
4.29497e+09
$ g++ -O1 -m64 b.cc ; ./a.out
-2
$ g++ -O2 -m64 b.cc ;
--- Comment #3 from mckelvey at maskull dot com 2008-09-27 17:38 ---
If I build from scratch with a svn update I get bug 37660.
If I then build again I get 37655, so probably this bug is not important and
just
fixed by adding -f to ln as Brian says.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-09-27 17:42 ---
SPARC64 conversions from integers to long double were fixed for 4.4 by my
patch:
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00910.html
--
jsm28 at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from bagnara at cs dot unipr dot it 2008-09-27 18:03 ---
This is good news. However, is there any known workaround for versions before
4.4?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37661
--- Comment #3 from joseph at codesourcery dot com 2008-09-27 18:20 ---
Subject: Re: long double is buggy on sparc64
On Sat, 27 Sep 2008, bagnara at cs dot unipr dot it wrote:
> This is good news. However, is there any known workaround for versions before
> 4.4?
If you want a workar
ersion 4.4.0 20080927 (experimental) (GCC)
[EMAIL PROTECTED]:~/volatile/tmp44$ cat small.c
typedef int uint16_t;
typedef int uint32_t;
uint32_t
func_18 (uint16_t p_19)
{
return 1;
}
uint32_t
func_37 (uint16_t p_38)
{
func_39 (+mod_rhs (func_18 (1) >= 1 ^ (div_rhs (1) || 0)
--- Comment #1 from regehr at cs dot utah dot edu 2008-09-27 18:41 ---
Seen using r140721.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37662
languages=c,c++
--no-create --no-recursion
Thread model: posix
gcc version 4.4.0 20080927 (experimental) (GCC)
--
Summary: ice in simplify_truth_ops_using_ranges, at tree-
vrp.c:6335
Product: gcc
Version: unknown
Status
+
--no-create --no-recursion : (reconfigured) ../configure
--program-prefix=current- --prefix=/home/regehr --enable-languages=c,c++
--no-create --no-recursion
Thread model: posix
gcc version 4.4.0 20080927 (experimental) (GCC)
--
Summary: ice in remove_range_assertions,
--- Comment #1 from regehr at cs dot utah dot edu 2008-09-27 19:00 ---
Slightly simpler testcase without the silly typecasts.
int lshift_u_u (int left, int right)
{
if (right >= sizeof (int) || left > 4294967295U >> right)
return left;
}
int mod_rhs (int rhs)
{
return rhs;
}
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-09-27 19:04
---
> If you want a workaround rather than backporting the patch, I suppose you
> could do all your conversions to long double from long long or unsigned
> long long instead of from 32-bit integer types, though the
At optimization levels -Os, -O1, and -O2, the attached program generates
incorrect loop code. It appears that when optimizing, the loop termination is
checking array end address versus current pointer. The array end address
contains all address bits while the current pointer is just the lower (16
--- Comment #1 from joel at gcc dot gnu dot org 2008-09-27 21:00 ---
Created an attachment (id=16417)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16417&action=view)
small test program
test program demonstrating problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37665
--- Comment #3 from fang at csl dot cornell dot edu 2008-09-27 21:48
---
original testcase ICEs 4.3.2 also
fang% g++-4 -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: ../gcc-4.3.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.3
--mandir=/sw/share/man --infodir=/
--- Comment #2 from fang at csl dot cornell dot edu 2008-09-27 22:09
---
With the test case, I get the same diagnostic with g++-4.3.2.
I'm not sure if the in-class using directive is supposed to work as you
expected, but what I usually write is (using your example):
template class B: A
arm-rtems was building on the SVN trunk recently. Test results reported based
on 10 Sept GCC.
http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg01309.html
This is the version tested.
gcc (GCC) 4.4.0 20080926 (experimental) [trunk revision 140712]
/n/12/joel/test-gcc/b-gcc1-arm/./gcc/xgcc
-B/n/
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37666
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|Error in|[4.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-27 22:23 ---
Most likely the same as PR 35874.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37666
--- Comment #4 from fang at csl dot cornell dot edu 2008-09-27 23:01
---
Ick.
Also fails 4.3.2, 4.0.1, 3.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37465
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-27 23:21 ---
Here is a reduced testcase:
int g_128;
int func_98 ()
{
int p_100 = 0x8EL;
int l_114 = 0x8899A862L;
int left = g_128;
int p_113 = 0x8EL * l_114;
int right = (p_113 % p_113);
if (left > (4294967295U >> rig
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
The test code
#include
class Test
{
public:
int t;
Test():t(1) {}
};
Test ex_t;
void Init() __attribute__ ((constructor));
void Init() { if(ex_t.t==0) abort(); }
int main(void) { return 0; }
aborted if compiled with gcc 4.3.2. If compiled with gcc 4.1.0 or 3.3.6 it
proceed normally. As I u
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-09-28 02:11 ---
Try
#define inline inline __attribute__((always_inline))
instead. The inline keyword changes linkage, so you have to keep it.
If you keep having problems open a new bugreport please, the performance
issue seems to
--- Comment #5 from irar at il dot ibm dot com 2008-09-28 06:17 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
39 matches
Mail list logo
