--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-07
08:08 ---
Roger, this is a middle-end problem in fond_cond_expr_with_comparision; that is
the routine which makes the invalid transformation. (It has a similar bug for
MAX_EXPR.) If the result of the COND_EXPR is
--- Additional Comments From mark at codesourcery dot com 2005-01-07 08:17
---
Subject: Re: [4.0 Regression] Undefined symbol: vtable for
__cxxabiv1::__vmi_class_type_info
dave at hiauly1 dot hia dot nrc dot ca wrote:
--- Additional Comments From dave at hiauly1 dot hia dot nrc
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07
09:01 ---
Subject: Bug 18828
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-07 09:01:00
Modified files:
gcc: ChangeLog builtins.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07
09:04 ---
Subject: Bug 18861
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-07 09:04:02
Modified files:
gcc: ChangeLog cfgbuild.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07
09:06 ---
Subject: Bug 19012
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-07 09:05:50
Modified files:
gcc: ChangeLog
gcc/config/i386:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07
09:08 ---
Subject: Bug 19283
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-07 09:08:11
Modified files:
gcc: ChangeLog fold-const.c
--- Additional Comments From roger dot larsson at norran dot net
2005-01-07 09:49 ---
Got a query about this bug...
It is still valid for gcc 3.3.4
My computer has been upgraded to a athlon-xp, so I tested both
g++ -Os -march=pentium3 matrix.cpp -o matrix
and
g++
This testcase:
double test (double a, double b) {
double x;
x = (a b) ? a : 1.0;
return x;
}
will ICE with '-O2 -mno-80387 -msse2':
cmove.c: In function âtestâ:
cmove.c:6: error: unrecognizable insn:
(insn 64 55 52 (parallel [
(set (reg:XF 9 st(1))
(reg:XF 8
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-01-07
10:02 ---
Fixed on mainline by Dan's patch for PR 19267:
http://gcc.gnu.org/ml/gcc-cvs/2005-01/msg00198.html
I checked all three testcases (original testcase and the ones in
comments #7 and #8).
--
--- Additional Comments From jbeulich at novell dot com 2005-01-07 10:21
---
Since the change originally having introduced this problem was also applied to
3_4-branch, will this here be applied there, too?
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-01-07
10:24 ---
Alas this is not fixed by the patch for PR18861.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18628
$ cat sel.f90
program sel
integer(kind=selected_int_kind(30)) :: j
j = 42
print *,j
end
$ gfortran sel.f90
$ ./a.out
At line 4 of file sel.f90
Internal Error: bad integer kind
$ gfortran -v
Using built-in specs.
Configured with: ../gcc-4.0-20050102/configure --prefix=/home/zfkts
--- Additional Comments From joseph at codesourcery dot com 2005-01-07
10:27 ---
Subject: Re: UCNs not recognized in identifiers
(c++/c99)
On Fri, 7 Jan 2005, zack at gcc dot gnu dot org wrote:
An obvious rebuttal to this is that the compiler used in step 4 is broken. As
you say,
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-07
10:37 ---
(In reply to comment #8)
Still fails on i686-pc-linux:
Is this something that should be put into the test suite,
so it is possible to get a better overview of when and
on which machines this fails?
Hi,
According to documentation of preprocessor (cpp.texi:1934)
the predefined macros
__GNUC__
__GNUC_MINOR__
__GNUC_PATCHLEVEL__
are defined only when the entire compiler is in use; if you invoke the
preprocessor directly, they are not defined.
But,
touch foo.c
cpp -dM -E foo.c | grep
The following compile-time error is uneecessary:
$ cat overflow.f90
program main
real :: a
a = exp(1000.)
print *,a
end program main
$ gfortran overflow.f90
In file overflow.f90:3
a = exp(1000.)
1
Error: Result of EXP overflows its kind at (1)
Assigning infinity would work
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-07
10:56 ---
I am not sure that this is indeed a bug.
Is the result of nearest for +/- infinity defined to
be +/huge ?
Look at what ifort does:
$ cat near-inf.f90
program test_nearest
real inf
inf =
--- Additional Comments From christian dot joensson at gmail dot com
2005-01-07 11:03 ---
well, running this:
# sparc32 ./gcc/contrib/test_installed --without-gcc --without-g77
--without-objc
I get this:
Running /usr/local/src/trunk/gcc/gcc/testsuite/g++.dg/pch/pch.exp ...
FAIL:
--
What|Removed |Added
Summary|PCH failures on sparc-linux |[4.0 Regression] PCH
||failures
Target Milestone|---
--- Additional Comments From uros at kss-loka dot si 2005-01-07 11:15
---
The same trick as in http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00394.html
with sqrtf applied to return value gets the code as expected.
minf:
subl$4, %esp
movss 8(%esp), %xmm0
--- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-01-07 11:19 ---
Subject: Re: Array copy operation produces garbage
Thomas dot Koenig at online dot de wrote:
--- Additional Comments From Thomas dot Koenig at online dot de
2005-01-07
--- Additional Comments From uros at kss-loka dot si 2005-01-07 11:29
---
This bugreport shows similar problem for x87 code as PR 19252 shoes for SSE
code. The cause of both probems is described in
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00394.html
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07
11:32 ---
Subject: Bug 18115
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-07 11:32:07
Modified files:
libjava: ChangeLog jni.cc
--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-07 11:37
---
I took time to look at this again, and I'm sorry to say that my reduced testcase
did print out an uninitialized variable, and was therefore wrong. My apologies
to all those who have wasted their time on this.
--- Additional Comments From uros at kss-loka dot si 2005-01-07 11:32
---
Also some discussion here:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00394.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19252
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07
11:56 ---
Subject: Bug 15553
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-07 11:56:12
Modified files:
gcc/testsuite : ChangeLog
Added files:
--- Additional Comments From nathan at gcc dot gnu dot org 2005-01-07
12:08 ---
It is somekind of inliner funkiness. make_decl_rtl is complaining
about making the rtl for a non-register auto var. I'll leave it
for an inliner guy.
--
What|Removed
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-01-07 12:12 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--
What|Removed |Added
GCC host triplet|i686-pc-linux-gnu |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19075
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-07
12:30 ---
(reply to comment #4)
After your comment, not sure either if it's a bug. The original testcase
(intrinsic_nearest.f90) fails with Intel (7 and 8) and Portland Group compilers
on i686, but works with g95
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org |org
Status|NEW
template class R, class T
struct A
{
explicit A (R (T::*xf) ()) : M (xf) {}
R operator () (T *x) const { return (x-*M) (); }
private:
R (T::*M) ();
};
template class R, class T, class C
struct B
{
explicit B (R (T::*xf) (C)) : M (xf) {}
R operator () (T *x, C y) const { return (x-*M)
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-01-07
13:14 ---
A testcase never made it to testsuite. :-(
Well, the ICE was fixed in gcc 3.2.1, I don't think we need a testcase
for that one.
The other issue is the testcase from comment #4:
--
What|Removed |Added
AssignedTo|reichelt at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|REOPENED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
13:45 ---
Confirmed.
--
What|Removed |Added
Severity|normal |minor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
13:46 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
13:47 ---
Fixed on the mainline but still a regression on the 3.4 branch.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
13:48 ---
Fixed, thanks Jakub.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
13:49 ---
Fixed thanks Jakub.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
13:52 ---
Does large test fail with 3.4.x, if so then this is not really a regression
except for PCH size.
--
What|Removed |Added
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
13:54 ---
Confirmed but I remember this error being here for a reason and there might be
a bug which this is a
dup of.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
13:57 ---
Confirmed, the bug is in the library which should support 128bit integers.
On targets where the register size is 32, we don't support 128bit integers
inside the compiler aka we
error out.
--
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-07
13:58 ---
(In reply to comment #3)
I think we should issue an error, because nml is not ASSIGNed a FORMAT, but
since g77 accepts this code I'm not sure.
g77 does bomb out at runtime, though; a warning at
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
14:00 ---
I don't know if this an excepted change, but either way the documention does
not match reality.
Oh, in 3.3.2 we did predefined those macros which is why this is a regression.
--
What
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
14:01 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
Bug 19292 depends on bug 18398, which changed state.
Bug 18398 Summary: Formatted I/O problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18398
What|Old Value |New Value
--
What|Removed |Added
Severity|minor |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19311
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
14:05 ---
Confirmed, it had worked with 4.0.0 20041124 and 3.4.0 so this is a regression.
--
What|Removed |Added
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15553
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19257
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19064
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19059
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18942
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18511
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18323
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17617
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17578
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11327
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6525
--
What|Removed |Added
Target Milestone|--- |3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6558
template class T, class A
struct C
{
static T *foo (A x) { return new T ((T) x); }
};
class A {};
A *bar ()
{
A a;
return CA, A::foo (a);
}
ICEs on gcc-3_4-branch and on HEAD, works with GCC 3.2.3.
--
Summary: ICE in stabilize_call
Product: gcc
Version:
--- Additional Comments From gdr at integrable-solutions dot net
2005-01-07 14:27 ---
Subject: Re: UCNs not recognized in identifiers (c++/c99)
joseph at codesourcery dot com [EMAIL PROTECTED] writes:
| I've had no on-list response yet to the query about this I sent to the
| WG14
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
14:27 ---
Confirmed here is another testcase for the same ICE:
template class T, class A
T *foo (A x)
{
throw ((T) x);
}
class A {};
A *bar ()
{
A a;
return fooA,A (a);
}
--
What|Removed
--- Additional Comments From joseph at codesourcery dot com 2005-01-07
15:01 ---
Subject: Re: UCNs not recognized in identifiers
(c++/c99)
On Fri, 7 Jan 2005, gdr at integrable-solutions dot net wrote:
--- Additional Comments From gdr at integrable-solutions dot net
$ cat pad.f
character*20 chr
open(7)
inquire(7,pad=chr)
print *,chr
end
$ gfortran pad.f ./a.out
$ gfortran -v ; gfortran -dumpmachine
Using built-in specs.
Configured with: ../gcc-4.0-20050102/configure --prefix=/home/zfkts
--enable-languages=c,c++,f95
Thread
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-01-07
15:07 ---
I just stumbled over this one, too.
Even shorter testcase: valgrind --tool=memcheck cc1 -quiet vg.c
==
int foo() { return 1.0 + 1.1; }
==
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-07
15:09 ---
BTW, the original case is no longer reproducible on mainline, but the test in
#35 still fails.
This happens when a pointer to volatile storage takes the address of a variable.
One way to fix this is by
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07
15:30 ---
Subject: Bug 13674
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-07 15:30:22
Modified files:
gcc: ChangeLog
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
15:31 ---
This is partly a front-end bug:
_gfortran_filename = t.f;
_gfortran_line = 3;
_gfortran_ioparm.unit = 7;
_gfortran_st_inquire ();
And a library bug.
--
What|Removed
joseph at codesourcery dot com [EMAIL PROTECTED] writes:
| I've now sent it to c++std-compat (having checked that the C++ list of
| characters also includes combining characters in more than one combining
| class so the same issues can arise there at least in principle, whether or
| not they
--- Additional Comments From gdr at integrable-solutions dot net
2005-01-07 15:39 ---
Subject: Re: UCNs not recognized in identifiers (c++/c99)
joseph at codesourcery dot com [EMAIL PROTECTED] writes:
| I've now sent it to c++std-compat (having checked that the C++ list of
|
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-07
15:40 ---
inquire (delim= ) also doesn't work (returns blanks).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19313
--- Additional Comments From dje at gcc dot gnu dot org 2005-01-07 15:40
---
patch applied
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
Because of the segfault, I assume that this is different from PR 19313.
$ cat inquire-position.f
character*20 chr
open(7)
inquire(7,position=chr)
print *,chr
end
$ gfortran inquire-position.f
$ ./a.out
Segmentation fault
$ gfortran -v ; gfortran -dumpmachine
Using
Take the following code:
void bar (const int * const x);
static const int y[];
void
foo (void)
{
bar (y);
}
This should at assemble but does not.
If I get some time this weekend I will look into fixing this.
--
Summary: variable is not emitted in the asm
Product: gcc
--- Additional Comments From schwab at suse dot de 2005-01-07 16:07 ---
Shouldn't this be rejected as y is of incomplete type?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19315
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
16:52 ---
If you trust Comeau's C compiler, then yes this is not valid code and should be
rejected.
Also one more note, this was able to compile with 3.3.2 but we called y as an
extern symbol which is
just wrong
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-07 16:56
---
Should be fixed now:
http://gcc.gnu.org/ml/gcc-cvs/2005-01/msg00184.html
--
What|Removed |Added
--- Additional Comments From nathan at gcc dot gnu dot org 2005-01-07
17:09 ---
2005-01-07 Nathan Sidwell [EMAIL PROTECTED]
PR c++/19298
* pt.c (tsubst_qualified_id): Call convert_from_reference.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07
17:09 ---
Subject: Bug 19298
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-07 17:09:16
Modified files:
gcc/cp : ChangeLog pt.c
--- Additional Comments From christian dot joensson at gmail dot com
2005-01-07 18:05 ---
well, I can't find the large test in the c++ pch testsuite. And, from the test
results posted here http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00244.html
I can't tell if the largefile test in
--- Additional Comments From dje at gcc dot gnu dot org 2005-01-07 18:22
---
Created an attachment (id=7893)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7893action=view)
swap library extension search order for -brtl
Attached is my proposed patch for this problem. Albert, would
during kernel startup I get an oops in lib/radix-tree.c
(null pointer dereference).
testcase: vanilla linux-2.6.10 sources
If You need assembly radix-tree.S sources I'll provide it tomorrow.
--
Summary: kernel built with gcc-3.4.3 works / with gcc-4.0.0
--- Additional Comments From giovannibajo at libero dot it 2005-01-07
18:43 ---
*** This bug has been marked as a duplicate of 18241 ***
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-01-07
18:43 ---
*** Bug 19316 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
Mark Mitchel's commit to fix PR c++/16405 introduced a miscompilation
in Qt. It took me a few weeks to deduce a testcase. testcase is:
=== Cut ===
extern C void abort( void );
struct A
{
A() { d = d2 = 0; width = -1; }
A( int _w ) : d( 0 ), d2( 0 ), width( _w ) {}
A b(
--
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
--
What|Removed |Added
Priority|P2 |P1
Summary|forgets to deep-copy|[4.0 Regression] forgets to
|temporary
--- Additional Comments From christian dot joensson at gmail dot com
2005-01-07 19:23 ---
oh, the last one was run with gcc cvs trunk LAST_UPDATED: Thu Jan 6 20:22:33
UTC 2005
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
19:26 ---
Hmm,
a = b (a, D.1613);
I think the problem is that we cannot remove the tempory return value for this
testcase.
Here is another testcase which is related testcase:
extern C void abort( void );
struct
--- Additional Comments From christian dot joensson at gmail dot com
2005-01-07 19:21 ---
This is what I find about largefile in the c testsuite:
Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc
-B/usr/local/src/trun\k/objdir32/gcc/ ./largefile.h -O0 -g -o largefile.h.gch
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
19:30 ---
And another one (note on most targets a is passed by reference which is where
the problem comes
from):
extern C void abort( void );
struct A
{
A() { d = d2 = 0; width = -1; }
A( int _w ) : d( 0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
20:39 ---
Some information.
It failed since at least 2004-05-12:
http://gcc.gnu.org/ml/gcc-testresults/2004-05/msg00747.html
But it passed on 2004-04-28:
http://gcc.gnu.org/ml/gcc-testresults/2004-05/msg00073.html
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
20:51 ---
(In reply to comment #8)
Some information.
One more note this is not related to the tree-ssa merge because that happened
on the 13th.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
20:53 ---
It was broken on the 2nd:
http://gcc.gnu.org/ml/gcc-testresults/2004-05/msg00231.html
Now someone has to figure out which patch broke it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
20:55 ---
Hmm but according to earlier results in April it was broken before then:
http://gcc.gnu.org/ml/gcc-testresults/2004-04/msg01175.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
1 - 100 of 148 matches
Mail list logo
