#ifdef __cplusplus
namespace __cxxabiv1
{
typedef __cxa_cdtor_return_type (*__cxa_cdtor_type)(void *);
extern C
{
#endif
// Allocate array.
void*
__cxa_vec_new(size_t __element_count, size_t __element_size,
size_t __padding_size, __cxa_cdtor_type constructor,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-15 06:08 ---
Actually we have to becareful here.
What does the IA64 C++ ABI say about the arguments types to __cxa_vec_new, is
__cxa_cdtor_type really extern C or did they forget to specify the language
linkage?
--
pinskia
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-15 06:12 ---
(In reply to comment #1)
The other thing is that I think this is a regression from when the ARM eabi
support was added.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29095
--- Comment #3 from jaco at kroon dot co dot za 2006-09-15 06:21 ---
Ok. My understanding of CXX ABI isn't that great. Some would say I just code
with C/C++ but I also happen to know that that isn't true. Take what I say
here as I'm a user of C/C++ and my understanding of everything
_mm_cvtpi32x2_ps in xmmintrin.h could be made more efficient. the existing
version:
static __inline __m128 __attribute__((__always_inline__))
_mm_cvtpi32x2_ps(__m64 __A, __m64 __B)
{
__v4sf __zero = (__v4sf) _mm_setzero_ps ();
__v4sf __sfa = __builtin_ia32_cvtpi2ps (__zero, (__v2si)__A);
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-09-15 07:31
---
Why not use reg_last-sets?
AFAICT, reg_last[0].sets is live at that point.
Sorry, I don't understand your answer. I was suggesting to use reg_last-sets
to get the last set of the reg instead of privately
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-15 08:26 ---
Confirmed. It looks like the C++ frontend recursively parses switch
statements...
#1052 0x0815ceae in cp_parser_statement (parser=0xb7d85ea0,
in_statement_expr=0x0)
at
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-09-15 08:39 ---
I second that. In addition to that I would welcome a warning for current C++
if I use keywords that are reserved in C++0x.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20599
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-15 08:59
---
Subject: Bug 18817
Author: ebotcazou
Date: Fri Sep 15 08:59:02 2006
New Revision: 116964
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116964
Log:
PR ada/18817
* utils.c (max_size):
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-09-15 09:03
---
Fixed on mainline.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from patchapp at dberlin dot org 2006-09-15 10:05 ---
Subject: Bug number PR28526
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00582.html
--
The following conditional OpenMP inclusion does not work in gfortran
(gcc version 4.2.0 20060824 (experimental)):
program test
!$ include 'omp_lib.h'
end
$ gfortran -c -fopenmp test.f90
In file test.f90:2
!$ include 'omp_lib.h'
1
Error: Unclassifiable statement at (1)
!$ use omp_lib
works
Symptom:
$ gfortran -c test.F90
test.F90: In function 'MAIN__':
test.F90:24: internal compiler error: in gfc_trans_call, at
fortran/trans-stmt.c:325
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Version:
$ gfortran
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-09-15
13:12 ---
Olav,
Thanks for the contribution:
TYPE BLOCK
INTEGER, DIMENSION(:), POINTER :: R = NULL(),C = NULL()
TYPE(BAS), POINTER, DIMENSION(:) :: NO = NULL ()
END TYPE BLOCK
gives you a
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-09-15 13:16
---
Subject: Bug 29053
Author: jvdelisle
Date: Fri Sep 15 13:16:15 2006
New Revision: 116970
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116970
Log:
2006-09-14 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-09-15 13:32
---
Subject: Bug 29053
Author: jvdelisle
Date: Fri Sep 15 13:32:12 2006
New Revision: 116971
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116971
Log:
2006-09-15 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-09-15 13:33
---
Fixed on 4.2, will not go to 4.1.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-09-15 13:35
---
Fixed on 4.2, will not go to 4.1
*** This bug has been marked as a duplicate of 29053 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-09-15 13:35
---
*** Bug 28747 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29053
--- Comment #3 from bangerth at dealii dot org 2006-09-15 13:49 ---
Confirmed. This is the valid testcase:
struct Base {
templateclass C void method() { }
};
struct Left : public Base { };
struct Right : public Base { };
struct Join : public Left, public Right {
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-09-15
14:16 ---
Created an attachment (id=12276)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12276action=view)
A fix for the problem
The handling of default initializers can never have been quite right. The
--- Comment #2 from steven at gcc dot gnu dot org 2006-09-15 15:23 ---
Re. comment #1 Yes, it is a _Recursive_ descent parser after all...
Probably the only solution is to parse the label and not descend. This is what
the C front end does, see c_parser_statement.
--
With little or no delay between calls to secnds the wrong result is given:
secnds.f:
character*20 dum1, dum2, dum3
real t1, t2
real dat1, dat2
real dt
integer i, j, values(8)
dt = 40e-3
t1 = secnds (0.0)
call date_and_time (dum1, dum2, dum3,
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-09-15 15:51
---
Patch to fix this:
Index: intrinsics/date_and_time.c
===
*** intrinsics/date_and_time.c (revision 116941)
--- intrinsics/date_and_time.c (working
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-09-15 16:04
---
Subject: Bug 29099
Author: jvdelisle
Date: Fri Sep 15 16:03:52 2006
New Revision: 116975
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116975
Log:
2006-09-15 Jerry DeLisle [EMAIL PROTECTED]
PR
The use of fmac (-m2e, -m3e, m4-single-only) causes excess precision
problems, which show up when running paranoia:
-Multiplication appears to round correctly.
+* is neither chopped nor correctly rounded.
-Checking for sticky bit.
-Sticky bit apparently used correctly.
+Sticky bit used
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-09-15 16:08
---
Subject: Bug 29099
Author: jvdelisle
Date: Fri Sep 15 16:07:53 2006
New Revision: 116976
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116976
Log:
2006-09-15 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-09-15 16:08
---
Fixed on 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-09-15 16:14 ---
Created an attachment (id=12277)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12277action=view)
patch to add -mfused-madd option
It is debatable what the right default for this option should be.
When that is
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-15 16:24 ---
Trying a fix (but don't hold your breath, the c++ parser is unexplored
territory for me ;-)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-15 16:27 ---
Caused by:
2004-09-15 Mark Mitchell [EMAIL PROTECTED]
* config/cpu/arm/cxxabi_tweaks.h (__cxa_cdtor_return_type):
Define.
* config/cpu/generic/cxxabi_tweaks.h (__cxa_cdtor_return_type):
--- Comment #6 from pault at gcc dot gnu dot org 2006-09-15 16:31 ---
Subject: Bug 29051
Author: pault
Date: Fri Sep 15 16:30:52 2006
New Revision: 116977
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116977
Log:
2006-09-15 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #7 from pault at gcc dot gnu dot org 2006-09-15 16:39 ---
Subject: Bug 29051
Author: pault
Date: Fri Sep 15 16:38:51 2006
New Revision: 116978
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116978
Log:
2006-09-15 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #8 from pault at gcc dot gnu dot org 2006-09-15 16:39 ---
Fixed on trunk and 4.1
Thanks, Bud
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sje at cup dot hp dot com 2006-09-15 16:46 ---
I took a quick look at this bug, the fix is easy, I have included a patch I
created. The problem is that there are 172 tests in the g++ and libstdc++
test suites that have empty enums in them. If we give an error on
--- Comment #12 from uros at gcc dot gnu dot org 2006-09-15 17:42 ---
Subject: Bug 28946
Author: uros
Date: Fri Sep 15 17:42:40 2006
New Revision: 116979
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116979
Log:
PR target/28946
* config/i386/i386.md
--- Comment #3 from andy314 at gmail dot com 2006-09-15 18:13 ---
I am also experiencing extreamly slow link times with GCC 4.1 (shipping with
Suse 10.1) as opposed to link times I got with previous versions. The
application uses a lot of templates/STL and the final complied binary is
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-09-15 18:32
---
Subject: Bug 15802
Author: ebotcazou
Date: Fri Sep 15 18:32:24 2006
New Revision: 116981
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116981
Log:
PR ada/15802
* decl.c
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-15 18:33 ---
(In reply to comment #3)
I am also experiencing extreamly slow link times with GCC 4.1 (shipping with
Suse 10.1) as opposed to link times I got with previous versions. The
application uses a lot of templates/STL
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-15 18:37
---
Fixed on mainline.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janis at gcc dot gnu dot org 2006-09-15 19:17 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=revrev=79544
r79544 | bonzini | 2004-03-16 20:37:31 + (Tue, 16 Mar 2004)
--
--- Comment #13 from amylaar at gcc dot gnu dot org 2006-09-15 19:27
---
Created an attachment (id=12278)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12278action=view)
patch using reg_last[regno+i].sets
--
amylaar at gcc dot gnu dot org changed:
What|Removed
Please find below a stripped down testcase and a session log from valgrind.
The code reads input from stdin, compares what was read against a couple of
choices (exactly one in this case) and repeats reading until a single 'x' was
entered. The leak is related to the length of the input buffer
--- Comment #4 from steven at gcc dot gnu dot org 2006-09-15 21:01 ---
Created an attachment (id=12279)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12279action=view)
tentative patch
This removes the recursion cycle
cp_parser_statement - cp_parser_labeled_statement -
--
Summary: mudflap's configure tries to link a binary and fails
because I don
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: bootstrap
AssignedTo:
--- Comment #5 from steven at gcc dot gnu dot org 2006-09-15 21:22 ---
Test case:
-
extern void bar ();
extern void baz ();
#define L1(x) \
case x##0: case x##1: case x##2: case x##3: \
case x##4: case x##5: case x##6: case x##7
#define L2(x) \
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29102
--- Comment #1 from felix-gcc at fefe dot de 2006-09-15 22:14 ---
Turns out you can still do make install and get a working cross compiler after
that, so I concur it's normal and not critical.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29102
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-15 22:16 ---
Well the summary cuts off at because I don.
Can you write what you wantted to write in a comment?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29102
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.0.0 |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11341
--- Comment #17 from wilson at gcc dot gnu dot org 2006-09-15 23:05 ---
Subject: Bug 28490
Author: wilson
Date: Fri Sep 15 23:05:40 2006
New Revision: 116983
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116983
Log:
Short term fix for PR 28490.
* config/ia64/ia64.c
--- Comment #6 from steven at gcc dot gnu dot org 2006-09-15 23:48 ---
Created an attachment (id=12281)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12281action=view)
Alternative patch (less obviously safe)
This one should resolve the problem completely by not recursing with
--- Comment #6 from lopezibanez at gmail dot com 2006-09-16 00:31 ---
By using the patches of the Wcoercion project [*] and compiling with
-Wcoercion, gcc reports for the testcase mentioned in the description:
pr2707.c: In function 'main':
pr2707.c:8: warning: coercion to 'short
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot
|dot org
--- Comment #6 from lopezibanez at gmail dot com 2006-09-16 01:08 ---
In which way gcc reports the problem correctly? What gcc currently reports is
that if the prototype were missing the value would be passed as a signed int.
It is not warning you about the conversion, it warns you
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-09-16 01:28
---
Confirmed: As can be seen here. We are allocating, but not freeing pstr.6
{
char[1:D.960] * pstr.6;
int4 D.960;
int4 D.959;
char[1:_input] D.958;
static struct _jump_struct jumptable.5[2]
--- Comment #2 from lopezibanez at gmail dot com 2006-09-16 01:38 ---
Richard, could you tell which bug report do you mean?
The -Wconversion warnings does not apply to this case. Wconversion warns about
the effect of adding a prototype, not about sign conversions.
Anyway, I still
--- Comment #3 from lopezibanez at gmail dot com 2006-09-16 01:48 ---
When using -Wconverson:
pr26698.cpp:24: warning: conversion to a reference to the same type will never
use a type conversion operator
Maybe this warning should be reported always?
--
lopezibanez at gmail dot com
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-09-16 02:46
---
worked around for 4.2.0 so no longer a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
59 matches
Mail list logo
