--- Comment #4 from bobby_miesen at yahoo dot com 2007-09-14 06:02 ---
Subject: Re: GCC Compiles C++ program containing value-returning
functions that don't return a value
Thank you for clarifying that. I will let Addison-Wesley know of this as
well.
pinskia at gcc dot gnu dot org
See conversation at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01230.html.
The changed default for that option exposes the bug; -femit-class-debug-always
should not be required to emit debug info for class2.
--
Summary: debug info for class2 in g++.dg/other/unused1.C
--- Comment #1 from hp at gcc dot gnu dot org 2007-09-14 06:33 ---
I forgot to mention that this likely happens everywhere, not just for
cris-axis-elf. Compare for example
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00622.html
(r128455, before the changed default of r128474) and
--- Comment #2 from hp at gcc dot gnu dot org 2007-09-14 06:48 ---
Subject: Bug 33429
Author: hp
Date: Fri Sep 14 06:48:17 2007
New Revision: 128489
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128489
Log:
PR debug/33429
* g++.dg/other/unused1.C: XFAIL class2
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-14 09:28 ---
Actually I already know this is not handled. In fact any of the BOMs are not
handled.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following features are missing from the current version of the -finit-*
patch (PR 20441):
- Optional initialization of INTENT(OUT) variables: PR 31447
- Derived types are not initialized; there are two cases:
(a) no initializer, (b) initializer which initializes not all variables
-
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-14 09:53 ---
Initializing INTENT(OUT) variables should not be the default with
-finit-local-zero; otherwise I'm in favour of this option.
See also PR 33430 for other omissions of the -finit-* patch (cf. PR 20441).
--
burnus
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-14 09:55 ---
... and of cause:
- Signalling NaN (sNaN) should be supported as well.
(mpfr currently only supports qNaN - last not least as IEEE 754 does not
specify the bitpattern for sNaN/qNaN; IEEE 754r does, but it has not
I've found serious performance regression between GCC version 3.4.6 and
4.2/4.3.
SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark
GCC: 3.4.6 4.2.1 4.3.0 (20070907)
Composite: 6.055.014.82
The .XOR. operator is supported by several vendor compilers including IBM's XL
fortran, DEC fortran, SUN fortran and even GNU f77!
A patch has been proposed at:
See: [PATCH] Support .XOR. as a -std=legacy extension
http://gcc.gnu.org/ml/fortran/2007-09/msg00070.html
The only problem is that
--- Comment #11 from rask at gcc dot gnu dot org 2007-09-14 10:15 ---
Yes, that worked.
It is quite obvious from trying a bootstrap with -masm=intel that nobody ever
uses Intel syntax, because there are assorted issues around the edges.
Additionally, I'm now blocked by binutils bug
--- Comment #10 from rask at gcc dot gnu dot org 2007-09-14 10:42 ---
I'm testing mipsisa64-unknown-elf, sh-unknown-elf and v850-unknown-elf right
now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
--- Comment #28 from jakub at gcc dot gnu dot org 2007-09-14 11:32 ---
Thanks, Jim.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-14 11:33
---
Why marking this as blocking asynchronous I/O?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-09-14 11:37
---
Wasn't the patch for this approved?
(http://gcc.gnu.org/ml/fortran/2007-08/msg00517.html) Since stage3 has started,
it probably would be best to commit rather soon.
--
fxcoudert at gcc dot gnu dot org
--- Comment #1 from kkojima at gcc dot gnu dot org 2007-09-14 11:46 ---
I've run scimark on my box:
sh4-unknown-linux-gnu / linux-kernel 2.6.22-rc4 / SH7751R
with -O3 -ffast-math -fomit-frame-pointer -funroll-loops -ftracer
-funit-at-a-time:
gcc-3.4.6
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-14 11:31
---
I think this is related to the check in trans-types.c:
if (size INTEGER_CST_P (size))
{
if (tree_int_cst_lt (gfc_max_array_element_size, size))
internal_error (Array element size too big);
Found this while trying to bootstrap with BOOT_CFLAGS=-O3 -fipa-cp and it
miscompiled libcpp/macro.c at the stage2. Appeared somewhere in between
r122374 and r124593:
/* { dg-do run } */
/* { dg-options -O3 -fipa-cp } */
int k;
void f1 (int a, int b)
{
if (a)
while (b --)
k = 1;
--- Comment #11 from hp at gcc dot gnu dot org 2007-09-14 12:10 ---
(In reply to comment #9)
Patch submitted at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01219.html.
I'd
be glad if some with access to cris-axis-elf
I'll test that.
--
I get the error message
bug.cpp:16: internal compiler error: in create_tmp_var, at gimplify.c:487
when compiling the following code with
g++ -fopenmp -DTVMET_OPTIMIZE -c bug.cpp
where bug.cpp contains:
#include tvmet/Vector.h // Tiny Vector Matrix library using
Expression Templates
--- Comment #12 from rask at gcc dot gnu dot org 2007-09-14 13:12 ---
Testing on v850-unknown-elf suggests that getcwd() is also needed by
libgfortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
--- Comment #13 from hp at gcc dot gnu dot org 2007-09-14 13:19 ---
Sorry, build fails for cris-elf with:
libtool: compile: /home/hp/combe/cris-regobj/./gcc/xgcc
-B/home/hp/combe/cris-regobj/./gcc/ -nostdinc -B/home/hp/combe/cris-rego\
bj/cris-unknown-elf/newlib/ -isystem
--- Comment #14 from hp at gcc dot gnu dot org 2007-09-14 13:22 ---
(In reply to comment #13)
Oops, I mean:
#ifndef HAVE_ACCESS
... libgfortran_access implementation
#undef access
#define access libgfortran_access
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-09-14 13:38
---
Created an attachment (id=14208)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14208action=view)
Updated patch
(In reply to comment #13)
/home/hp/combe/combined/libgfortran/io/unix.c:1794: error: static
--- Comment #16 from rask at gcc dot gnu dot org 2007-09-14 13:43 ---
I get the same build failure on sh-unknown-elf and mipsisa64-unknown-elf. I'm
continuing without the static keyword and with s/amod/amode/g.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
--- Comment #17 from hp at gcc dot gnu dot org 2007-09-14 14:13 ---
(In reply to comment #14)
The build succeeds with my locally fixed version.
We'll see whether the test-results are meaningful; it's likely there's more to
fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/
/mnt/
gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr32912-2.c -O2 -w -fno-show-column -lm
-o
./pr32912-2.exe(timeout = 300)
/var/tmp//cclFD5RH.s: Assembler messages:
/var/tmp//cclFD5RH.s:5: Warning: bignum truncated to 8
--- Comment #5 from anhvofrcaus at gmail dot com 2007-09-14 15:16 ---
Yes, you are absolutely correct that my tree is skewed. After updating my tree
again, all ACATS tests passed beautifully. One more thing to say you guys are
fantastic.
AV
--
extern char x[] __attribute__((__weak__));
int i = (long)x;
results in 'initializer element is not computable at load time'. However, the
compiler really can't know this, as x may be either zero (since it's weak) or
may be used as C-level place holder for an assembler/linker defined absolute
--- Comment #20 from rakdver at gcc dot gnu dot org 2007-09-14 15:57
---
(In reply to comment #19)
Zdenek, the fix in Comment #5 is wrong (please look at Comment #11 why), as
cofirmed by a couple of dupes. From PR 33428:
actually the fix in loop-invariant is correct for the original
--- Comment #2 from nbkolchin at gmail dot com 2007-09-14 16:10 ---
Thank you for your reply.
Variants:
- you are not using: -m4 -ml, but some other architecture settings.
- SH7751R and SH7750R have different instruction pipeline (probably not, both
are SH4-200 variants as I know).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spark at gcc dot gnu dot org
|dot org
Compile with -O1:
long double f (long double x)
{
return __builtin_remainderl (x, x);
}
bug.c: In function 'f':
bug.c:4: internal compiler error: in cselib_record_set, at cselib.c:1515
--
Summary: [4.3 Regression] ICE in cselib_record_set, at
cselib.c:1515 on
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Hello,
I've CYGWIN_NT-5.0 (1.3.22) version installed in my system. Here I try to
install a fresh GCC version (GCC-3.4.6). But I don't have already any
compiled version of GCC in my system. So I took GCC-3.4.6 tarballs from the
recommended GNU source. Downloaded properly. As a first step, when I
The GNU compiler is asking that when a default(none)
clause is present on the OMP PARALLEL DO, and a chunk-size expression (in this
case just the variable fsize) appears in a schedule clause, that the variable
must appear in a shared or private clause. Other compilers (PGI, Pathscale) do
not
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2007-09-14
18:00 ---
Is anyone working on this bug? I ask because Apple's regress server has
effectively stopped showing testresults because of this bug. Also, I am a tad
confused by the comments that -enable-checking is now
--- Comment #7 from dorit at gcc dot gnu dot org 2007-09-14 18:49 ---
(In reply to comment #6)
I can bootstrap current trunk (r128479) with -ftree-vectorize on
x86_64-unknown-linux-gnu for some time now, and, according to
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00327.html, this
--- Comment #4 from belyshev at depni dot sinp dot msu dot ru 2007-09-14
19:15 ---
Very similar testcase with the difference that it is not fixed by r128415 and
makes current trunk segfault in VEC_tree_base_pop():
void f (unsigned int *d, unsigned int *s, int w)
{
int i;
for (i =
--- Comment #2 from ubizjak at gmail dot com 2007-09-14 19:27 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from uros at gcc dot gnu dot org 2007-09-14 19:24 ---
Subject: Bug 33438
Author: uros
Date: Fri Sep 14 19:24:26 2007
New Revision: 128502
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128502
Log:
PR target/33438
* config/i386/i386.md (fmodxf3):
--- Comment #5 from dorit at gcc dot gnu dot org 2007-09-14 20:53 ---
(In reply to comment #4)
Very similar testcase with the difference that it is not fixed by r128415 and
makes current trunk segfault in VEC_tree_base_pop():
void f (unsigned int *d, unsigned int *s, int w)
{
int
--- Comment #18 from hp at gcc dot gnu dot org 2007-09-14 21:31 ---
(In reply to comment #17)
We'll see whether the test-results are meaningful; it's likely there's more to
fix.
Unfortunately not very meaningful without a getcwd. I got curious why getcwd
would be needed, so I looked
--- Comment #19 from hp at gcc dot gnu dot org 2007-09-14 21:36 ---
(In reply to comment #18)
So, I'll update your patch to get rid of the getcwd call, attach the result
and
start a new test.
Never mind, I see you've taken care of it in the access_dup2 patch here. Doh!
Starting
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-09-14 22:10 ---
-ml and -m4 are default on sh4-unknown-linux-gnu compilers.
For 4.3.0, you could see how the default target specific options
are set with 'cc1 --target-help'. I've got the following result
on my linux box. You can
Environment:
gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) from Ubuntu repositories
Ubuntu 7.04 2.6.20-16-generic kernel
GNU gdb 6.6-debian
I run this program in GDB, and put a breakpoing right before the call to
whatever(). At this point, I print a, and the value is no good, but the
variable is
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-14 22:57 ---
This works for me on the trunk with gdb 6.3-debian.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33440
poovizhi wrote:
I've CYGWIN_NT-5.0 (1.3.22) version installed in my system. Here I try to
install a fresh GCC version (GCC-3.4.6). But I don't have already any
compiled version of GCC in my system.
If you don't already have a compiler, then you won't be able to compile
the gcc sources on your
Central Arkansas Society for Paranormal Research
http://www.casprquest.com/privateten.htm
Haunted Mountain Village 1890
http://www.1890village.com/
Mountain Village 1890
Bull Shoals Caverns
1011 C. S. Woods Boulevard
P. O. Box 444
Bull Shoals, Arkansas 72619
Phone: (870) 445-7177
Toll free:
--- Comment #2 from hjl at lucon dot org 2007-09-15 03:43 ---
It also fails on Linux/ia32 and Linux/x86-64.
--
hjl at lucon dot org changed:
What|Removed |Added
GCC
50 matches
Mail list logo
