--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-28 06:00
---
On i686-pc-linux-gnu, with both GCC 3.4.2 and GCC 4.0, I see :
__m128 size 16, align 16
Quad size 16, align 16
Base1 32 Derived1 32 Offset 20
Base2 32 Derived2 48 Offset 32
I am building a Cygwin cross
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-28 06:04
---
Using -z muldefs is beyond the scope of the C++ standard.
There is no way to win for everyone here; some people really do not want the
random names because they want predictability from the compiler.
--
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-28 06:18
---
On Cygwin, I still get 24 32 24 for Base 2.
The reason turns out to have nothing to do with PODs. Rather, it is due to the
fact that on Cygwin, BIGGEST_FIELD_ALIGNMENT is set to 8 bytes. So, even though
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-28 06:24
---
There is really no easy way to fix this problem. If we were to have -frepo set
the random seed to a known value, we'd then get link errors when linking
multiple translation units containing anonymous
--- Additional Comments From loki at inf dot u-szeged dot hu 2004-10-28 06:42
---
(In reply to comment #7)
Surely this is not valid?
The validity is the subject of bug 772 and the long thread linked from
there. This bug is for a particular ICE which is a regression; whether
--- Additional Comments From dannysmith at users dot sourceforge dot net
2004-10-28 07:14 ---
Isn't this a bug in cygming.h then? Would something like this
still retain MSVC compatibility while allowing logical alignment
for SSE[2] types?
/* This is only needed in libobjc. There we
In the example listed below, member i of object obj allocated at frame
of bar routine is not getting default-initialized to 0 but contains any
garbage left on the stack. That violates clause 8.5.1/7 of the C++ Standard.
$ cat bar.cpp
#include cstdio
struct S {
const char* s;
int
--- Additional Comments From pere at hungry dot com 2004-10-28 09:15 ---
The compiler on IA64/HP-UX (aCC: HP aC++/ANSI C B3910B A.05.50 [May 15 2003])
refuses to compile this code and gives this error message:
Error 271: x.c, line 1 # Illegal initializer.
char a[] = (x);
--- Additional Comments From davidm at hpl dot hp dot com 2004-10-28 09:24 ---
(In reply to comment #16)
Perhaps I should have read your message closer. I get timeouts for this
testcase also. However, it bootstraps fine, and the total number of
unexpected gcc failures is only 45,
--- Additional Comments From davidm at hpl dot hp dot com 2004-10-28 09:27 ---
(In reply to comment #10)
I've now checked the patch into mainline.
Thanks!
Adding the patch to gcc-3.4 requires that it be a regression. This doesn't
seem to qualify according to a strict
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-28 09:28
---
Because of the patch http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg01513.html
that adds -funroll-loops to -fprofile-generate the testcase from
comment #4 has to be compiled with
-msse -O2
A corrupt mail message, ID 1098958899494 from [EMAIL PROTECTED] has been
detected.
Dear GCC Team,
I have experienced a serious performance bug
with g++-3.4.2. In the attached code you can
see the source code which is quite simple. In
the file TypeDefinitions.h I use some typedef
statements to be able play with different types.
The problem is in file
--- Additional Comments From dkouroun at mailbox dot gr 2004-10-28 10:34 ---
Created an attachment (id=7422)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7422action=view)
The source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18192
In the file gcc/recog.h the struct insn_data has a member genfun which is
of type insn_gen_fn. This type is defined as
typedef rtx (*insn_gen_fn) (rtx, ...); which is a pointer to a function which
has an ellipsis as its second argument. The actual implementations of the
functions are however not
Hi,
# cat caller.cpp
struct ObjectAddress
{
protected:
unsigned int m_a;
unsigned int m_b;
public:
ObjectAddress(long a, long b) : m_a(a), m_b(b) {}
/* CASE 1: non-default constructor
instance of ObjectAddress (x in main()) is passed by reference
*/
~ObjectAddress() {}
/*
--- Additional Comments From horst dot reiterer at fabasoft dot com 2004-10-28
10:46 ---
Created an attachment (id=7423)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7423action=view)
Testcase tarball containing the two source files and a corresponding makefile
--
--- Additional Comments From horst dot reiterer at fabasoft dot com 2004-10-28
10:50 ---
(In reply to comment #0)
/* CASE 1: non-default constructor
(...)
/* CASE 2: default constructor
'Constructor' was of course a typo, should have been 'destructor'
--
--
What|Removed |Added
Summary|g++ passes struct by|g++ passes struct by
|reference instead of by |reference instead of by
With the following test program, I get compiler errors with g++-3.4 on both
i386-linux and x86_64-linux (but not with g++-3.3).
namespace A {
class B { };
B* transform(B*);
template class T void transform_in_place(T* p) { p = A::transform(p); }
class C { };
C*
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-28 11:42
---
Zdenek, the failure in comment #12 appears with your patch
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg00030.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17428
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 12:03
---
The definition of ObjectAddress is incompatible, there for this is undefined behavior.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 12:08
---
*** This bug has been marked as a duplicate of 12081 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 12:09
---
*** Bug 18193 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
The attached code compiles without warnings, but gives bus error on execution.
Used GNU Fortran 95 (GCC 4.0.0 20041027 (experimental)) on powerpc-apple-darwin7.5.0.
It seems that when crashing, the __result of function f somehow gets data address 0x0,
which seems
bit abnormal. Very delicate
The attached code compiles without warnings, but gives bus error on execution.
Used GNU Fortran 95 (GCC 4.0.0 20041027 (experimental)) on powerpc-apple-darwin7.5.0.
It seems that when crashing, the __result of function f somehow gets data address 0x0,
which seems
bit abnormal. Very delicate
--- Additional Comments From niilo dot sirola at tut dot fi 2004-10-28 12:33
---
*** This bug has been marked as a duplicate of 18197 ***
--
What|Removed |Added
--- Additional Comments From niilo dot sirola at tut dot fi 2004-10-28 12:33
---
*** Bug 18196 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18197
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-28 12:47
---
Subject: Bug 15286
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-28 12:47:29
Modified files:
gcc: ChangeLog final.c recog.c
--- Additional Comments From phil at mkdoc dot com 2004-10-28 12:59 ---
Is this a final verdict on this issue? This problem also affects compatibility
with the Sun 1.3 interpreter. Can I take it that the Sun 1.4 interpreter is the
benchmark reference for GCJ going forward?
Thanks.
--- Additional Comments From bangerth at dealii dot org 2004-10-28 13:08 ---
That is my view, too. It's an initializer, not an assignment.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18016
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz
2004-10-28 13:18 ---
Subject: Re: [4.0 Regression] internal compiler error: in spill_failure, at
reload1.c:1880
Hello,
Because of the patch http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg01513.html
that
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 13:26
---
Confirmed, this is a front-end issue.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From bonzini at gcc dot gnu dot org 2004-10-28 13:30
---
Jumps out of statement expressions are or were used in real code
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00770.html. I don't think
they are well-defined (except for jumps using longjmp), but I
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 13:31
---
The only thing left is documentation.
--
What|Removed |Added
Keywords|
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-10-28 13:36
---
Disabling DOM seems to paper over the bug. Investigating.
--
What|Removed |Added
stage1/xgcc -Bstage1/ -B/usr/local/ada/powerpc-apple-darwin7.5.0/bin/ -c -g -O2
-mdynamic-no-pic -gnatpg -gnata -I- -I. -Iada -I../../fsf-gcc-head/gcc/ada
../../fsf-gcc-head/gcc/ada/fname-uf.adb -o ada/fname-uf.o
../../fsf-gcc-head/gcc/ada/fname-uf.adb: In function 'Fname.Uf.Get_File_Name':
--
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18198
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 13:43
---
As I said in the other bug report this is a known bug (Daniel Berlin is working on it).
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 13:44
---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 13:53
---
This is invalid.
From [temp.dep.candidate]:
For a function call that depends on a template parameter, if the function name is an
unqualified-id
but not a template-id, the candidate functions are found
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 13:53
---
*** Bug 18195 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 14:19
---
Confirmed, a regression but I don't know if this is a middle-end problem or a
front-end problem.
The front-end produces the following code:
struct S obj[2] = {{.s=(const char *) m0}, {}};
This is a
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 14:24
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 14:25
---
Lets reopen this one.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 14:25
---
*** This bug has been marked as a duplicate of 18187 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 14:26
---
*** Bug 16998 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 14:26
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--
What|Removed |Added
Summary|bad code gen for -mcpu=G5 |bad code gen for -mcpu=G5
||and unsigned long long to
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 14:29
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From horst dot reiterer at fabasoft dot com 2004-10-28
14:31 ---
(In reply to comment #3)
The definition of ObjectAddress is incompatible,
there for this is undefined behavior.
You're right, the code relies on undefined behavior. My main question was, why
does
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 14:32
---
Hmm with the current mainline I get:
java/lang/Throwable.java: In class 'gnu.crypto.pki.provider.EncodedKeyFactory':
java/lang/Throwable.java: In method
$ gdb-5.3 cc1
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no
I'm not a bugzilla expert, therefore I sent this bug report manualy.
call:
gcj -save-temps -O0 -o popt --main=ProcessorOptimizer.Main
--classpath=JPisa.jar:SMOOD.jar:. ProcessorOptimizer/*.class
ProcessorOptimizer/*/*.class
output:
ProcessorOptimizer/DeviceRandom.class:0: internal compiler
--
What|Removed |Added
Severity|normal |critical
Status|UNCONFIRMED |NEW
Ever Confirmed|
--- Additional Comments From jsm at polyomino dot org dot uk 2004-10-28 15:05
---
Subject: Re: [4.0 Regression] ICE jumping into statement
expression
On Thu, 28 Oct 2004, bonzini at gcc dot gnu dot org wrote:
I remember using once a void statement expression ((void) ({ ... })
--- Additional Comments From steven at gcc dot gnu dot org 2004-10-28 15:16
---
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02437.html
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2004-10-28 15:19
---
vrong quode
--
What|Removed |Added
Severity|normal |critical
--- Additional Comments From steven at gcc dot gnu dot org 2004-10-28 15:22
---
Is this perhaps related to Bug 17949?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
--- Additional Comments From steven at gcc dot gnu dot org 2004-10-28 15:24
---
I am tempted to call this critical. This is *the* major quadratic
bottleneck in GCC at the moment, for reasonably normal code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17895
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-28 15:30
---
Here's a condensed version of Wolfgang's testcase:
int i=1;
class A;
templateint struct B
{
A *p;
~B()
{
--i;
p=0;
if(p) delete
--- Additional Comments From dje at gcc dot gnu dot org 2004-10-28 15:31 ---
gfortran -c -o applu.o -O3 -mcpu=power4 -ftree-loop-linear applu.f
applu.f: In function 'buts':
applu.f:633: internal compiler error: in build_classic_dist_vector, at tree-
data-ref.c:1848
--
What
--- Additional Comments From dje at gcc dot gnu dot org 2004-10-28 15:40 ---
The GDB 5.3 error comes from the macro
#define ANOFFSET(secoff, whichone) \
((whichone == -1) \
? (internal_error (__FILE__, __LINE__, Section index is uninitialized), -1
) \
:
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 15:52
---
Isn't this related to PR 17672.
--
What|Removed |Added
Keywords|
If the preprocessor finds a backslash-newline continuation on the next-to-last
line of a file which does not end with a newline (the file, not the next-to-last
line), it gives the warning.
Here's a 2-line file:
#define MYMACRO(x) \
x
and here it is in hex, to show the lack of
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 16:14
---
The warning is pretty clear at what it means:
test.defs:1:30: warning: backslash-newline at end of file
I don't see where the problem is. Also it is undefined in the C standard to have a
file not in a
--- Additional Comments From ro at techfak dot uni-bielefeld dot de 2004-10-28
16:16 ---
Subject: Re: [4.0 Regression] [unit-at-a-time] Solaris 10/x86 libobjc bootstrap
failure: invalid assembler code
Unfortunately the patch has remained unreviewed for a month now and the
bootstrap
--
What|Removed |Added
Severity|normal |minor
GCC host triplet|i686-pc-linux-gnu |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18002
The following should compile with an error message but the compiler dies in the
middle of printing an error message
#include string
template class charT
std::basic_ostream(charT) operator(std::basic_ostreamcharT os);
--
Summary: Compiler suggests submitting a bug report after
--- Additional Comments From ftg at adelphia dot net 2004-10-28 16:27 ---
I don't agree that it's clear. The file does not end with a backslash-newline
as the message states, and the message gives one no idea of what to do to
correct it.
If it is indeed the case that a file which does
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 16:30
---
Fixed since 3.2.2:
pr18201.cc:4: error: invalid use of template-name 'std::basic_ostream' in a
declarator
pr18201.cc:4: error: syntax error before `' token
pr18201.cc:4: error: `charT' was not declared
--- Additional Comments From ovidr at users dot sourceforge dot net 2004-10-28
16:30 ---
Hi, sorry, I didn't notice that I had a gnu/crypto/pki/provider/ subdirectory
and I guess gcj picked up the classes from there.
I will include gnu.zip. Unzip it to a temp directory preserving
--- Additional Comments From ovidr at users dot sourceforge dot net 2004-10-28
16:31 ---
Created an attachment (id=7424)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7424action=view)
gnu class files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17963
--- Additional Comments From dberlin at dberlin dot org 2004-10-28 16:31 ---
Subject: Re: SPEC CPU2000 173.applu tree-loop-linear
ICE
This is the minimal testcase for the problem that i came up with
subroutine buts ( ldmx, ldmy, ldmz,
$ v,
$
--- Additional Comments From giovannibajo at libero dot it 2004-10-28 16:32
---
Volker, thanks for the reduction. The bug is hideous, look at this:
class A;
template int struct B
{
A* a;
~B() { delete a; }
};
struct A {
B0 b;
};
--- Additional Comments From jsm28 at gcc dot gnu dot org 2004-10-28 16:35 ---
RTH suggested:
If we must accept this construct because it might not be
executed, a possible solution is to notice fallback==fb_lvalue
for a CALL_EXPR in c_gimplify_expr and create a temporary for
the
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 16:35
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From dberlin at dberlin dot org 2004-10-28 16:36 ---
Subject: Re: SPEC CPU2000 173.applu tree-loop-linear
ICE
No, not at all actually.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18168
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-28 16:51
---
Reduced testcase:
subroutine buts ( v )
dimension v( 5)
do i = 1, 5
do j = 1, 5
do k = 1, 5
v( i ) = v( 1 )
Recent %/%ification of error messages and warnings causes really many
tests die, because they expect ' as opening and closing quote, while in
UTF-8 locale they are different.
Shouldn't gcc/testsuite/lib/*.exp set LC_ALL=C in the environment?
I think it is bad to force users to use LC_ALL=C make
The following should compile with an error message but the compiler dies in the
middle of printing an error message
#include string
template class charT
std::basic_ostream(charT) operator(std::basic_ostreamcharT os);
--
Summary: Compiler suggests submitting a bug report after
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 16:54
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02515.html.
--
What|Removed |Added
--- Additional Comments From ron at vaniwaarden dot org 2004-10-28 16:54 ---
(In reply to comment #0)
Problem does not occur with g++ 3.2.2 or 3.4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18203
--- Additional Comments From dberlin at dberlin dot org 2004-10-28 16:55 ---
Subject: Re: SPEC CPU2000 173.applu tree-loop-linear
ICE
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-28 16:51
---
Reduced testcase:
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 16:56
---
If the problem only occurs in 3.2 and not in 3.2.2, the problem is already fixed.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 17:00
---
*** This bug has been marked as a duplicate of 14264 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 17:00
---
*** Bug 18202 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 17:01
---
This is more important now, that we have UTF8 turning the quote characters to UTF8
characters.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-28 17:02
---
Nathan, this is a result of your change to limit the maximum size of a thunk.
If we're going to keep that limit, we need to have a sorry() somewhere when
making a bigger thunk. Or, we could restore the
--- Additional Comments From nathan at gcc dot gnu dot org 2004-10-28 17:09
---
yes, I havebeen meaning to revert it, but wanted to measure the performance hit.
I will make sure I get to it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18143
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-28 17:14
---
I think we'll still want a flag allowing the user to disable verification.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14781
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-28 17:14
---
FYI, not verifying in the compiler is somewhat tricky since
the compiler relies on the verifier to create type maps it
uses later on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15735
--- Additional Comments From fafa at freesurf dot ch 2004-10-28 17:27 ---
(In reply to comment #2)
Using -z muldefs is beyond the scope of the C++ standard.
There is no way to win for everyone here; some people really do not want the
random names because they want predictability
--- Additional Comments From denisc at overta dot ru 2004-10-28 17:30 ---
Ok to apply. (Thanks for fixing !)
Denis.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18151
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
-- adapted from: A. Imran ([EMAIL PROTECTED])
package Test_126 is
task type T1;
type T2 is tagged limited record
x1: T1;
end record;
type T3 is new T2 with private;
type T3_access is access T3; -- line 12
private
type T3 is new T2 with null record; -- line
--- Additional Comments From ludovic dot brenta at insalien dot org 2004-10-28
17:51 ---
Debian bug #278686.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18204
Debian bug #278687:
-- The second parameter of T2'Class'Read is of type T2'Class,
-- which should match an object of type T3, which is derived
-- from T2.
package test_127 is
pragma elaborate_body;
end test_127;
with ada.streams;
package body test_127 is
type T1 is access all
--- Additional Comments From ericw at evcohs dot com 2004-10-28 18:02 ---
Created an attachment (id=7425)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7425action=view)
Proposed patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18151
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-10-28 18:04
---
This is fixed in tree-cleanup-branch. I'm bringing the patch into mainline.
Ben, is this test out of the libstdc++ testsuite? Do we test it by default with
make check? If not, would you mind adding it
1 - 100 of 175 matches
Mail list logo
