[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #5 from paulthomas2 at wanadoo dot fr 2006-10-11 06:11 --- Subject: Re: LBOUND(TRANSPOSE(I)) doesn't work FX, That's because of F95 13.14.53: Case (i): For an array section or for an array expression other than a whole array or array structure component, LBOUND(ARRAY, DIM) has the value 1. For a whole array or array structure component, LBOUND(ARRAY, DIM) has the value: (a) equal to the lower bound for subscript DIM of ARRAY if dimension DIM of ARRAY does not have extent zero or if ARRAY is an assumed-size array of rank DIM, or (b) 1 otherwise. That's what I was asking. OK, we have a problem with allocatable components too. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug driver/19353] Faulty handling of (some) user specified specs
--- Comment #7 from gschafer at zip dot com dot au 2006-10-11 06:18 --- The root cause of this bug is obvious after studying gcc.c. Essentially, the user specified specs are read _way_ too late in the process. The sequence is roughly this: 1 - search for default specs file, if found load it 2 - set up the standard search paths Look for executables and startfiles in the standard places 3 - process any user specified specs from the command line It never used to be like this! The user specified specs used to be processed immediately after the default specs were loaded (which was much saner). The behavior was changed back in 1999 for the benefit of the Java front end which wants to use -specs=libgcj.spec and have the specs file found automatically: http://gcc.gnu.org/ml/gcc-patches/1999-06n/msg00511.html gcc.c has evolved much since then so currently it's impossible for the user to override on the command line a few specs that appear in step (2) above, namely: sysroot_suffix_spec, sysroot_hdrs_suffix_spec, startfile_prefix_spec, md_startfile_prefix and md_startfile_prefix_1. Reverting the 1999 patch fixes the bug but of course breaks linking of Java user programs. In retrospect, Java should probably have implemented something a bit less fragile than this solution IMHO. Just removing startfile_prefix_spec is not the correct action because as mentioned above, other specs are also affected. Not only that, some folks (LFS in particular) have latched onto that spec and rely on it for their build procedures, even tho' it is completely *undocumented* and its usefulness is questionable. Re-titling bug to reflect reality. -- gschafer at zip dot com dot au changed: What|Removed |Added Summary|Faulty handling of |Faulty handling of (some) |startfile_prefix_spec |user specified specs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353
[Bug fortran/29428] New: Error in allocatable component function calls
program test implicit none type A integer, allocatable :: j(:) end type A type(A):: x x=f() contains function f() type(A):: f print *,I'm only called once in the fortran! f = A((/1,2/)) end function f end program calls the function twice! The code produced shows that the assignment nullifies the data field of the function, which results in it's being called a second time. Paul -- Summary: Error in allocatable component function calls Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: pault at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29428
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-11 07:26
---
With the following patch:
Index: trans-array.c
===
--- trans-array.c (revision 117560)
+++ trans-array.c (working copy)
@@ -661,10 +661,12 @@
gfc_add_modify_expr (pre, tmp, size);
tmp = gfc_conv_descriptor_lbound (desc, gfc_rank_cst[n]);
- gfc_add_modify_expr (pre, tmp, gfc_index_zero_node);
+ gfc_add_modify_expr (pre, tmp, gfc_index_one_node);
tmp = gfc_conv_descriptor_ubound (desc, gfc_rank_cst[n]);
- gfc_add_modify_expr (pre, tmp, loop-to[n]);
+ gfc_add_modify_expr (pre, tmp,
+ fold_build2 (PLUS_EXPR, gfc_array_index_type,
+ loop-to[n], gfc_index_one_node));
tmp = fold_build2 (PLUS_EXPR, gfc_array_index_type,
loop-to[n], gfc_index_one_node);
@@ -787,11 +789,17 @@
gfc_add_modify_expr (se-pre,
gfc_conv_descriptor_lbound (dest, dest_index),
- gfc_conv_descriptor_lbound (src, src_index));
+ gfc_index_one_node);
gfc_add_modify_expr (se-pre,
gfc_conv_descriptor_ubound (dest, dest_index),
- gfc_conv_descriptor_ubound (src, src_index));
+ fold_build2 (PLUS_EXPR, gfc_array_index_type,
+ gfc_index_one_node,
+ fold_build2 (MINUS_EXPR, gfc_array_index_type,
+gfc_conv_descriptor_ubound
+ (src, src_index),
+gfc_conv_descriptor_lbound
+ (src, src_index;
if (!loop-to[n])
{
I get all intrinsics that work through temporaries working right:
integer :: i(-1:1,-1:1) = 0
integer :: j(-1:2) = 0
! Was already working
write(*,*) lbound(i(-1:1,-1:1)), ubound(i(-1:1,-1:1))
write(*,*) lbound(i(:,:)), ubound(i(:,:))
write(*,*) lbound(i(0:,-1:)), ubound(i(0:,-1:))
write(*,*) lbound(i(:0,:1)), ubound(i(:0,:1))
! Fixed
write(*,*) lbound(transpose(i)), ubound(transpose(i))
write(*,*) lbound(reshape(i,(/2,2/))), ubound(reshape(i,(/2,2/)))
write(*,*) lbound(cshift(i,-1)), ubound(cshift(i,-1))
write(*,*) lbound(eoshift(i,-1)), ubound(eoshift(i,-1))
write(*,*) lbound(spread(i,1,2)), ubound(spread(i,1,2))
write(*,*) lbound(maxloc(i)), ubound(maxloc(i))
write(*,*) lbound(minloc(i)), ubound(minloc(i))
write(*,*) lbound(maxval(i,2)), ubound(maxval(i,2))
write(*,*) lbound(minval(i,2)), ubound(minval(i,2))
write(*,*) lbound(any(i==1,2)), ubound(any(i==1,2))
write(*,*) lbound(count(i==1,2)), ubound(count(i==1,2))
write(*,*) lbound(merge(i,i,.true.)), ubound(merge(i,i,.true.))
write(*,*) lbound(lbound(i)), ubound(lbound(i))
write(*,*) lbound(ubound(i)), ubound(ubound(i))
write(*,*) lbound(shape(i)), ubound(shape(i))
! Still not working
write(*,*) lbound(product(i,2)), ubound(product(i,2))
write(*,*) lbound(sum(i,2)), ubound(sum(i,2))
write(*,*) lbound(matmul(i,i)), ubound(matmul(i,i))
write(*,*) lbound(pack(i,.true.)), ubound(pack(i,.true.))
write(*,*) lbound(unpack(j,(/.true./),(/2/))),
ubound(unpack(j,(/.true./),(/2/)))
end
So I only have PRODUCT, SUM, MATMUL, PACK and UNPACK to work on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-11 07:32 --- (In reply to comment #6) Forget that patch, it's breaking lots of things :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-10-11 07:55 --- Mine. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-11 07:55:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-10-11 07:56 --- Note we don't actually know if this is a regression, as without the stricter error checking that is now present this may not be failing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-10-11 07:58 --- This is probably just another ordering issue. I'm on it. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-10-11 08:02 --- Subject: Re: LBOUND(TRANSPOSE(I)) doesn't work FX, I get all intrinsics that work through temporaries working right: Great! So I only have PRODUCT, SUM, MATMUL, PACK and UNPACK to work on. I wonder if doing the same in trans-intrinsic.c (gfc_conv_intrinsic_function) might not be the magic bullet? You could write a little function to normalise the bounds of se-expr, putting the code in the se-post, and call it from lines 3198 and 3589. You had better check the performance hit, if any, that results from touching gfc_trans_create_temp_array - run the Polyhedron suite, for example, with and without the patch. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug libstdc++/29095] [4.0/4.1/4.2 Regression] cxxabi.h __cxa_cdtor_type not declared when included from C
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-10-11 08:30 --- Subject: Bug 29095 Author: bkoz Date: Wed Oct 11 08:30:42 2006 New Revision: 117629 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117629 Log: 2006-10-09 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/29095 * libsupc++/cxxabi.h (__cxa_cdtor_type): Explicit C linkage. * config/cpu/arm/cxxabi_tweaks.h: Same. * config/cpu/generic/cxxabi_tweaks.h: Same. Modified: branches/gcc-4_1-branch/libstdc++-v3/ChangeLog branches/gcc-4_1-branch/libstdc++-v3/config/cpu/arm/cxxabi_tweaks.h branches/gcc-4_1-branch/libstdc++-v3/config/cpu/generic/cxxabi_tweaks.h branches/gcc-4_1-branch/libstdc++-v3/libsupc++/cxxabi.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29095
[Bug libstdc++/29095] [4.0/4.1/4.2 Regression] cxxabi.h __cxa_cdtor_type not declared when included from C
--- Comment #10 from bkoz at gcc dot gnu dot org 2006-10-11 08:33 --- Fixed in mainline and gcc-4.1.2. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29095
[Bug target/19636] Can't compile ethernut OS (avr-gcc)
--- Comment #12 from plessl at tik dot ee dot ethz dot ch 2006-10-11 08:44
---
I can confirm that this bug still exists on with avr-gcc (GCC) 4.0.2 (running
on Mac OS X 10.4.8/PPC, installed via Macports)
avr-gcc -Os ~/Documents/Downloads/usart.iusart.c: In function UsartIOCtl:
usart.c:821: error: unable to find a register to spill in class
BASE_POINTER_REGS
usart.c:821: error: this is the insn:
(insn 663 162 163 14 (set (mem:HI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [31 S2 A8])
(reg:HI 24 r24)) 12 {*movhi} (nil)
(nil))
usart.c:821: confused by earlier errors, bailing out
Is there any news on this bug?
--
plessl at tik dot ee dot ethz dot ch changed:
What|Removed |Added
CC||plessl at tik dot ee dot
||ethz dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug c/29429] New: Incorrect code with -O
The code below works correctly when no Optimization flag is given to gcc and
process exits as soon as a SIGHUP is sent to it.
But if it is compiled with any one of -O flags, sending SIGHUP does not
terminate the process.
sig_atomic_t hup_rcvd = 0;
void hup_handler(int signo)
{
hup_rcvd = 1;
}
int main()
{
if (signal(SIGHUP, hup_handler) == SIG_ERR) {
fprintf(stderr, signal failed\n);
return -1;
}
for (hup_rcvd = 0; !hup_rcvd; ) {
;
}
return 0;
}
--
Summary: Incorrect code with -O
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alireza dot salimi at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29429
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-10-11 09:48 --- This is a regression, oh well. Can you confirm for me that mingw32 is a target w/o __cxa_atexit? I don't suppose it will make any difference, but can you please try: - __gnu_cxx::__recursive_mutex static_mutex; + static __gnu_cxx::__recursive_mutex static_mutex; best, benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-10-11 09:55 --- Created an attachment (id=12407) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12407action=view) simple failure testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug driver/29430] New: Assembler messages: Error: invalid architecture -xarch=v8
Hello, I'me trying to build gcc4.1.1 with gcc -v gcc -v Reading specs from /logiciels/public/gcc-3.2.1/lib/gcc-lib/sparc-sun-solaris2.7/3.2.1/specs Configured with: ../configure --with-local-prefix=/logiciels/public/gcc-3.2.1 --prefix=/logiciels/public/gcc-3.2.1 --enable-thread=posix --with-as=/logiciels/public/binutils-2.13.1/bin/as --with-ld=/logiciels/public/binutils-2.13.1/bin/ld --with-gnu-as --with-gnu-ld --enable-languages=c,c++,f77,objc Thread model: posix gcc version 3.2.1 On SunOS clr34bx 5.8 Generic_108528-29 sun4u sparc SUNW,Ultra-60 ../configure --with-mpfr=/logiciels/public/gmp-4.1.4/lib --enable-shared --with-gnu-as=/logiciels/public/binutils-2.9/bin/as --with-gnu-ld=/logiciels/public/binutils-2.9/bin/ld and I've got the problem Like GCC Bugzilla Bug 25596 sol2-c1.asm: Assembler messages: Error: invalid architecture -xarch=v8 /usr/bin/ksh ../../gcc/mkconfig.sh tconfig.h /local/COMPIL/src/gcc4.1.1-2/gcc-4.1.1/objdir2/./gcc/xgcc -B/local/COMPIL/src/gcc4.1.1-2/gcc-4.1.1/objdir2/./gcc/ -B/usr/local/sparc-sun-solaris2.8/bin/ -B/usr/local/sparc-sun-solaris2.8/lib/ -isystem /usr/local/sparc-sun-solaris2.8/include -isystem /usr/local/sparc-sun-solaris2.8/sys-include -c -o crt1.o -x assembler-with-cpp ../../gcc/config/sparc/sol2-c1.asm Assembler messages: Error: invalid architecture -xarch=v8 make[2]: *** [crt1.o] Error 1 make[2]: Leaving directory `/local/COMPIL/src/gcc4.1.1-2/gcc-4.1.1/objdir2/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/local/COMPIL/src/gcc4.1.1-2/gcc-4.1.1/objdir2' make: *** [all] Error 2 I thought it was a pb of as and ld so I compiled binutils2.16 but I've got the same pb (before I've used sun as -and gnu ld) [EMAIL PROTECTED]:/local/COMPIL/src/gcc4.1.1-2/gcc-4.1.1/objdir2 [ 1504 ] echo $LD /logiciels/public/binutils-2.16/bin/ld [EMAIL PROTECTED]:/local/COMPIL/src/gcc4.1.1-2/gcc-4.1.1/objdir2 [ 1508 ] echo $AS /logiciels/public/binutils-2.16/bin/as [EMAIL PROTECTED]:/local/COMPIL/src/gcc4.1.1-2/gcc-4.1.1/objdir2 [ 1509 ] which ld /logiciels/public/binutils-2.16/bin/ld [EMAIL PROTECTED]:/local/COMPIL/src/gcc4.1.1-2/gcc-4.1.1/objdir2 [ 1510 ] which as /logiciels/public/binutils-2.16/bin/as thans in advance for your help Géraldine -- Summary: Assembler messages: Error: invalid architecture - xarch=v8 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: geraldine-n dot bert at edfgdf dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29430
[Bug c/29429] Incorrect code with -O
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-10-11 10:43 --- You need to put 'volatile' on hup_rcvd for this to work. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29429
[Bug tree-optimization/28230] [4.2 Regression] -O2 -fwrapv miscompiles gcc, binutils, gzip.
--- Comment #18 from patchapp at dberlin dot org 2006-10-11 10:45 --- Subject: Bug number PR28230 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-10/msg00607.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug driver/29430] Assembler messages: Error: invalid architecture -xarch=v8
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-10-11 10:53 --- This ../configure --with-mpfr=/logiciels/public/gmp-4.1.4/lib --enable-shared --with-gnu-as=/logiciels/public/binutils-2.9/bin/as --with-gnu-ld=/logiciels/public/binutils-2.9/bin/ld and that I thought it was a pb of as and ld so I compiled binutils2.16 but I've got the same pb (before I've used sun as -and gnu ld) seems to be contradictory. Your syntax is incorrect: --with-gnu-as and --with-gnu-ld take no argument. Configure like your 3.2.1 compiler was configured and that will work. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29430
[Bug fortran/29422] ICE with allocatable
--- Comment #1 from patchapp at dberlin dot org 2006-10-11 11:00 --- Subject: Bug number PR29422 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-10/msg00609.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29422
[Bug inline-asm/29119] [4.0/4.1/4.2 Regression] Internal compiler error while adding __asm__ statement
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-11 11:55 ---
Gimplification marks the TARGET_EXPR addressable in
{
__asm__ __volatile__(::m TARGET_EXPR D.1873, {
unsigned int __v;
unsigned int __v;
D.1873 = __v;
});
}
while it should mark the gimplified lvalue addressable.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2006-09-17 21:57:22 |2006-10-11 11:55:58
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29119
[Bug c/28940] [4.0/4.1/4.2 Regression] address selection does not work correctly
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-11 12:23 --- We're not folding return (int) *((char *) (long unsigned int) i + a + 1B) + (int) *((char *) (long unsigned int) i + b + 1B); one reason is that the C frontend decomposes a[i], one is the array-to-pointer decay code of the frontend. Compare that to the C++ frontend where we manage to fold to return retval = (int) a[(unnamed type) (long unsigned int) i + 1] + (int) b[(unnamed type) (long unsigned int) i + 1]; and so do the optimization. In particular, fold-const.c:try_move_mult_to_index does not recognize addr_expr 0x2b0bb95fd0c0 type pointer_type 0x2b0bb9615420 type integer_type 0x2b0bb96022c0 char public string-flag QI size integer_cst 0x2b0bb95f27e0 constant invariant 8 unit size integer_cst 0x2b0bb95f2810 constant invariant 1 align 8 symtab 0 alias set -1 precision 8 min integer_cst 0x2b0bb95f28a0 -128 max integer_cst 0x2b0bb95f2960 127 pointer_to_this pointer_type 0x2b0bb9615420 public unsigned DI size integer_cst 0x2b0bb95f2d80 constant invariant 64 unit size integer_cst 0x2b0bb95f2db0 constant invariant 8 align 64 symtab 0 alias set -1 constant invariant arg 0 var_decl 0x2b0bb97bcbb0 a type array_type 0x2b0bb97bcb00 type integer_type 0x2b0bb96022c0 char BLK size integer_cst 0x2b0bb97ce3f0 constant invariant 80 unit size integer_cst 0x2b0bb97ce390 constant invariant 10 align 8 symtab 0 alias set -1 domain integer_type 0x2b0bb97bca50 addressable used public static common BLK defer-output file t.i line 1 size integer_cst 0x2b0bb97ce3f0 80 unit size integer_cst 0x2b0bb97ce390 10 align 8 as a[0]. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|rtl-optimization|c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
[Bug c/28940] [4.0/4.1/4.2 Regression] address selection does not work correctly
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-11 12:30 ---
One minimal fix for this is the following (patches for this I sent many times
long time ago, but poking in the C frontend is tedious):
Index: c-typeck.c
===
*** c-typeck.c (revision 117629)
--- c-typeck.c (working copy)
*** build_unary_op (enum tree_code code, tre
*** 3032,3046
}
/* For x[y], return x+y */
! if (TREE_CODE (arg) == ARRAY_REF)
{
tree op0 = TREE_OPERAND (arg, 0);
if (!c_mark_addressable (op0))
return error_mark_node;
! return build_binary_op (PLUS_EXPR,
! (TREE_CODE (TREE_TYPE (op0)) == ARRAY_TYPE
! ? array_to_pointer_conversion (op0)
! : op0),
TREE_OPERAND (arg, 1), 1);
}
--- 3032,3044
}
/* For x[y], return x+y */
! if (TREE_CODE (arg) == ARRAY_REF
! TREE_CODE (TREE_TYPE (TREE_OPERAND (arg, 0))) != ARRAY_TYPE)
{
tree op0 = TREE_OPERAND (arg, 0);
if (!c_mark_addressable (op0))
return error_mark_node;
! return build_binary_op (PLUS_EXPR, op0,
TREE_OPERAND (arg, 1), 1);
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org, jsm28 at gcc dot gnu
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
[Bug c/28940] [4.0/4.1/4.2 Regression] address selection does not work correctly
--- Comment #9 from bonzini at gnu dot org 2006-10-11 12:47 ---
For this, on i386-pc-linux-gnu, C and C++ give the exact (pessimized) same
code:
char a[10], b[10];
int f1(int i)
{
return a[i+1] + b[i+1];
}
That RTL address selection sucks is just a fact. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
[Bug c/28940] [4.0/4.1/4.2 Regression] address selection does not work correctly
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-11 12:53 --- I get (-O -m32) for C++: _Z2f1i: .LFB2: pushl %ebp .LCFI0: movl%esp, %ebp .LCFI1: movl8(%ebp), %edx addl$1, %edx movsbl b(%edx),%eax movsbl a(%edx),%edx addl%edx, %eax popl%ebp ret which I thought was the good behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
[Bug c/28940] [4.0/4.1/4.2 Regression] address selection does not work correctly
--- Comment #11 from paolo dot bonzini at lu dot unisi dot ch 2006-10-11 13:05 --- Subject: Re: [4.0/4.1/4.2 Regression] address selection does not work correctly movl8(%ebp), %edx addl$1, %edx movsbl b(%edx),%eax movsbl a(%edx),%edx No, the good behavior has b+1(%edx) and a+1(%edx) (for non-PIC code). Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
[Bug c/29429] Incorrect code with -O
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-11 13:12 --- You need to look at preprocessed source. sig_atomic_t should have volatile qualifier on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29429
[Bug fortran/28849] Missed array shape violation with RESHAPE despite -fbounds-check
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-11 13:17 --- I'll note that the Portland, Intel and g95 compilers do not see this issue either. SunStudio does, at runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28849
[Bug inline-asm/29119] [4.0/4.1/4.2 Regression] Internal compiler error while adding __asm__ statement
--- Comment #6 from patchapp at dberlin dot org 2006-10-11 13:31 --- Subject: Bug number PR29119 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-10/msg00612.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29119
[Bug fortran/28849] Missed array shape violation with RESHAPE despite -fbounds-check
--- Comment #3 from anlauf at gmx dot de 2006-10-11 13:58 --- (In reply to comment #2) I'll note that the Portland, Intel and g95 compilers do not see this issue either. Well, I get a bounds violation with current versions of g95 (0.91) on both Linux and Cygwin: % g95 -g -fbounds-check -ftrace=full gfcbug39_bounds_check.f90 ./a.out Assignments with correct shapes after RESHAPE... a(:,1) = 1. b(:,1) = 1. 2. ...and with wrong shape (should fail with bounds checking on) At line 17 of file gfcbug39_bounds_check.f90 Traceback: not available, compile with -ftrace=frame or -ftrace=full Fortran runtime error: Array element out of bounds: 2 in (1:1), dim=2 With xlf 9.1 on AIX: % xlf95 -qsuffix=f=f90 -C -g gfcbug39_bounds_check.f90 % dbx a.out Type 'help' for help. reading symbolic information ... (dbx) run Assignments with correct shapes after RESHAPE... a(:,1) = 1.0 b(:,1) = 1.0 2.0 ...and with wrong shape (should fail with bounds checking on) Trace/BPT trap in gfc_bounds_check at line 17 17 a(:,:) = reshape (v(:), (/ 2, 1 /) ) (dbx) With Intel I had a discussion about this, as ifc7 reports a shape violation, and ifort8 and ifort9 do not. Intel does not consider this a regression, and think that reimplementing the old behavior in 8.x and 9.x would be an enhancement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28849
[Bug inline-asm/29119] [4.0/4.1 Regression] Internal compiler error while adding __asm__ statement
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-11 14:03 --- Fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] |Internal compiler error |Internal compiler error |while adding __asm__|while adding __asm__ |statement |statement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29119
[Bug inline-asm/29119] [4.0/4.1 Regression] Internal compiler error while adding __asm__ statement
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-11 14:03 --- Subject: Bug 29119 Author: rguenth Date: Wed Oct 11 14:03:37 2006 New Revision: 117633 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117633 Log: 2006-10-11 Richard Guenther [EMAIL PROTECTED] PR inline-asm/29119 * gimplify.c (gimplify_asm_expr): Mark the gimplified lvalue addressable. * gcc.dg/torture/pr29119.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr29119.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29119
[Bug c/29429] Incorrect code with -O
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-11 14:28 --- (In reply to comment #2) You need to look at preprocessed source. sig_atomic_t should have volatile qualifier on it. It is not marked for glibc 2.4: typedef int __sig_atomic_t; typedef __sig_atomic_t sig_atomic_t; So this is still not a GCC bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29429
[Bug c/29429] Incorrect code with -O
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-11 14:44 --- http://www.codecomments.com/archive263-2005-8-441109.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29429
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-10-11 14:48 --- Created an attachment (id=12408) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12408action=view) patch Please try this and see if it works. If so, let me know. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug c++/29002] [4.0 regression] ICE on array of ptr-to-member or struct containing ptr-to-member of unknown size
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-11 14:55 --- Subject: Bug 29002 Author: pinskia Date: Wed Oct 11 14:55:07 2006 New Revision: 117635 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117635 Log: 2006-10-11 Andrew Pinski [EMAIL PROTECTED] PR C++/29002 * init.c (build_zero_init): If we have an error mark node for the array size, return. 2006-10-11 Andrew Pinski [EMAIL PROTECTED] PR C++/29002 * g++.dg/init/array22.C: New test. * g++.dg/init/array23.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/init/array22.C - copied unchanged from r116962, trunk/gcc/testsuite/g++.dg/init/array22.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/init/array23.C - copied unchanged from r116962, trunk/gcc/testsuite/g++.dg/init/array23.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/init.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29002
[Bug c++/29002] [4.0 regression] ICE on array of ptr-to-member or struct containing ptr-to-member of unknown size
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-11 14:56 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29002
[Bug fortran/27701] Two routines with the same name cause an interna; error in gfortran
--- Comment #4 from patchapp at dberlin dot org 2006-10-11 15:35 --- Subject: Bug number PR27701 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-10/msg00615.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27701
[Bug fortran/29431] New: Not Implemented: complex character array constructors
In fixing PR29373, I separated off the part to do with the function declaration
from that triggered by the constructor.
! { dg-do compile }
! Tests patch for PR29373, in which the implicit character
! statement messes up the function declaration because the
! requisite functions in decl.c were told nothing about
! implicit types.
!
! Contributed by Tobias Schlueter [EMAIL PROTECTED]
!
implicit character*32 (a-z)
CHARACTER(len=255), DIMENSION(1,2) :: a
! Reporters original, which triggers another error:
! gfc_todo: Not Implemented: complex character array
! constructors.
a = reshape((/ to_string(1.0) /), (/ 1, 2 /)) ! uncommented
a = to_string(1.0)
print *, a
CONTAINS
FUNCTION to_string(x)
character*32 to_string ! moved from function declaration.
REAL, INTENT(in) :: x
WRITE(to_string, FMT=(F6.3)) x
END FUNCTION
END PROGRAM
does this
[EMAIL PROTECTED] pr29373]# /svn-4.2/bin/gfortran pr29373a.f90
pr29373a.f90: In function MAIN__:
pr29373a.f90:24: fatal error: gfc_todo: Not Implemented: complex character
array constructors
compilation terminated.
Paul
--
Summary: Not Implemented: complex character array constructors
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pault at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29431
[Bug tree-optimization/28230] [4.2 Regression] -O2 -fwrapv miscompiles gcc, binutils, gzip.
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-10-11 16:05 --- Subject: Bug 28230 Author: rguenth Date: Wed Oct 11 16:05:37 2006 New Revision: 117637 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117637 Log: 2006-10-11 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/28230 * tree-vrp.c (vrp_int_const_binop): Move flag_wrapv handling to the correct place. * gcc.dg/torture/pr28230.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr28230.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug tree-optimization/28230] [4.2 Regression] -O2 -fwrapv miscompiles gcc, binutils, gzip.
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-10-11 16:06 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug fortran/29373] implicit type declaration and contained function clash
--- Comment #6 from tobi at gcc dot gnu dot org 2006-10-11 16:07 --- You're working too fast, Paul. Before I even got to read your answer you already bring forward a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
[Bug libfortran/29423] FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-11 16:30 --- Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90 --- Comment #1 from kargl at gcc dot gnu dot org 2006-10-10 22:34 --- Update your source directory and rebuild in a clean obj directory. Done. The error still occurs. I don't see the symbol in any of the library .o files. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29423
[Bug c++/29432] New: Segfault after repeated throwing and catching of runtime_error exception with error string
The following code, when compiled using optimization (-O1, at least), produces
a segfault after several iterations of the loop. I have reproduced the bug on
two machines running the same OS and version of gcc:
$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
The code was compiled as:
$ g++ -O1 -o bug bug.cc
And run as:
$ ./bug
Segmentation fault
#include stdexcept
int main() {
while (true) {
try {
throw std::runtime_error(foo);
} catch (const std::runtime_error e) {
}
}
return 0;
}
--
Summary: Segfault after repeated throwing and catching of
runtime_error exception with error string
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cdewey at biostat dot wisc dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29432
[Bug c++/29432] Segfault after repeated throwing and catching of runtime_error exception with error string
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-11 16:47 --- gcc version 3.4.6 20060404 (Red Hat 3.4.6-3) First, you should have reported it to redhat first. Second I cannot reproduce this in 3.4.0, 4.0.0 or 4.1.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29432
[Bug libfortran/29423] FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu 2006-10-11 16:53 --- Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90 On Wed, Oct 11, 2006 at 04:30:20PM -, dave at hiauly1 dot hia dot nrc dot ca wrote: Done. The error still occurs. I don't see the symbol in any of the library .o files. Do you have libgfortran/generated/rrspacing_r4.c? Does youir OS have fabsf, frexpf, and ldexpf? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29423
[Bug fortran/29373] implicit type declaration and contained function clash
--- Comment #7 from patchapp at dberlin dot org 2006-10-11 17:00 --- Subject: Bug number PR29373 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-10/msg00620.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
[Bug fortran/29373] implicit type declaration and contained function clash
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-10-11 17:05 --- Subject: Re: implicit type declaration and contained function clash tobi at gcc dot gnu dot org wrote: --- Comment #6 from tobi at gcc dot gnu dot org 2006-10-11 16:07 --- You're working too fast, Paul. Before I even got to read your answer you already bring forward a patch. Better still, I just submitted it! :-D I have been child-minding today. Since the poor little soul is sick, I have insisted that she be properly sick in bed; meanwhile, I have had the portable on my lap in the garden, catching up on pending submissions. How are you? That resubmitted PR29431 has an interesting effect on other compilers - only g95 gets it right. ifort seems to make it up as it's going along and pgf crashes in cloud of smoke, Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
[Bug target/19636] Can't compile ethernut OS (avr-gcc)
--- Comment #13 from eweddington at cso dot atmel dot com 2006-10-11 17:05 --- (In reply to comment #12) I can confirm that this bug still exists on with avr-gcc (GCC) 4.0.2 (running on Mac OS X 10.4.8/PPC, installed via Macports) snip Is there any news on this bug? Sorry, no. Your comment has been the latest news. Can you try using GCC 4.1.1 and see if you can still reproduce this bug? That would be very informative. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug middle-end/29390] Bogus symbol inserted into valid C++ code at low optimization level
--- Comment #14 from mi at aldan dot algebra dot com 2006-10-11 17:15 --- Ok, the problem is triggered by the ``-march=pentium4'' flag: c++ -O0 -g -c -fno-strict-aliasing -pipe -march=pentium4 loctest.ii [EMAIL PROTECTED]:source/test/intltest (1127) nm loctest.o | grep LC U .LC786 U _ZNK7icu_3_66Locale7getLCIDEv vs. c++ -O0 -g -c -fno-strict-aliasing -pipe loctest.ii [EMAIL PROTECTED]:source/test/intltest (1129) nm loctest.o | grep LC U _ZNK7icu_3_66Locale7getLCIDEv Would this narrow the search for a fix down enough? The problem does not exist with the gcc-3.2.3 (tested on RedHat), nor with gcc-3.4.1 (tested on the same FreeBSD box as the originally reported 3.4.4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29390
[Bug fortran/29422] ICE with allocatable
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-11 17:42 --- Since I posted the patch, I had better take it unto myself! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-11 17:42:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29422
[Bug libfortran/29423] FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-11 17:57 --- Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90 Done. The error still occurs. I don't see the symbol in any of the library .o files. Do you have libgfortran/generated/rrspacing_r4.c? Yes. Does youir OS have fabsf, frexpf, and ldexpf? Yes, no, no. It has frexp and ldexp. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29423
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #7 from echristo at apple dot com 2006-10-11 18:14 --- I'm testing it now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #8 from echristo at apple dot com 2006-10-11 18:24 --- OK. Seems to be working (i.e. build succeeded and testing isn't blowing up). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug libfortran/29423] FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2006-10-11 18:30 --- Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90 Does youir OS have fabsf, frexpf, and ldexpf? Yes, no, no. It has frexp and ldexp. Do you have scalbnf? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29423
[Bug fortran/29422] ICE with allocatable
--- Comment #3 from dominiq at lps dot ens dot fr 2006-10-11 18:31 --- Subject: Re: ICE with allocatable Since I posted the patch, I had better take it unto myself! Be my guest!-) Dominique -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29422
[Bug c++/29433] New: Internal error while compiling code using boost::MPL
Here is a code which doesn't compile. It takes all swap space (around 2GB) and all system memory(about 1GB), compiles around 15-20 minutes and then crashes with the following message : g++: Internal error: Killed (program cc1plus) -- Summary: Internal error while compiling code using boost::MPL Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: grayyoga at gmail dot com GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug c++/29433] Internal error while compiling code using boost::MPL
--- Comment #1 from grayyoga at gmail dot com 2006-10-11 19:10 --- Created an attachment (id=12409) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12409action=view) preprocessed source file This is output of the compiler with the -save-temps switch. It's compressed 'cause there is a 1 MB limit on the attachement size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-10-11 19:11 --- Hmm. Eric, are you testing this on mingw32, or on darwin? If darwin, is this the cause of the recent massive failures? If so, I'll put this in immediately. If you can let me know in the next 2-3 hours I can get it in today. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug fortran/29434] New: array bounds of allocatable components of derived types?
The following code (derived from alloc_comp_constructor_1.f90):
! { dg-do run }
! { dg-options -fdump-tree-original }
! Test constructors of derived type with allocatable components (PR 20541).
!
! Contributed by Erik Edelmann [EMAIL PROTECTED]
!and Paul Thomas [EMAIL PROTECTED]
!
Program test_constructor
implicit none
type :: thytype
integer(4) :: a(2,2)
end type thytype
type :: mytype
integer(4), allocatable :: a(:, :)
type(thytype), allocatable :: q(:)
end type mytype
type (mytype) :: x
type (thytype) :: foo = thytype(reshape ([43, 100, 54, 76], [2,2]))
integer :: y(0:1, -1:0) = reshape ([42, 99, 55, 77], [2,2])
x = mytype(y, [foo, foo])
if (.not.allocated(x%a) .or. .not.allocated(x%q)) call abort()
print *, 'y bounds'
print *, lbound(y)
print *, ubound(y)
print *, 'x%a bounds'
print *, lbound(x%a)
print *, ubound(x%a)
end program test_constructor
compiled with ifort or gfortran, it returns
y bounds
0 -1
1 0
x%a bounds
0 -1
1 0
while compiled with g95, it returns
y bounds
0 -1
1 0
x%a bounds
1 1
2 2
What is the standard conforming answer?
Dominique
--
Summary: array bounds of allocatable components of derived types?
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: 4.2.0 20061009
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29434
[Bug c++/29433] Internal error while compiling code using boost::MPL
--- Comment #2 from grayyoga at gmail dot com 2006-10-11 19:13 --- Created an attachment (id=12410) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12410action=view) gcc -V output version and configuration information on the used gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug c++/29433] Internal error while compiling code using boost::MPL
--- Comment #3 from grayyoga at gmail dot com 2006-10-11 19:14 --- Created an attachment (id=12411) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12411action=view) Command Line and Error Message -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug c++/29024] [4.0/4.1/4.2 Regression] storage class specifier accepted for typedef (clause 7.1.1 ; 1)
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-10-11 19:31 --- Subject: Bug 29024 Author: lmillward Date: Wed Oct 11 19:31:33 2006 New Revision: 117641 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117641 Log: PR c++/29024 * cp-tree (struct cp_decl_specifier_seq): Rename to conflicting_specifiers_p * parser.c (cp_parser_set_storage_class): Set conflicting_specifiers_p for the input decl specifier if a typedef specifier is present. Rename uses of multiple_specifiers_p to conflicting_specifiers_p. (cp_parser_decl_specifier_seq) RID_TYPEDEF: If a storage class specifier has already been set for this declaration, set conflicting_specifiers_p to true on the decl_specs. * decl.c (grokdeclarator): Rename uses of multiple_specifiers_p to conflicting_specifiers_p. * g++.dg/parse/typedef8.C: New test. * g++.dg/other/mult-stor1.C: Adjust error markers. Added: trunk/gcc/testsuite/g++.dg/parse/typedef8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/other/mult-stor1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29024
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #10 from echristo at apple dot com 2006-10-11 19:34 --- Testing on darwin, the patch seems to get rid of the massive failures I was seeing. Thanks Ben. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug c++/29433] Internal error while compiling code using boost::MPL
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-11 19:36 --- This takes 79% of my 2GB of memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug middle-end/29390] Bogus symbol inserted into valid C++ code at low optimization level
--- Comment #15 from mi at aldan dot algebra dot com 2006-10-11 19:38 --- Removing either the line 16037 or the 15167 in the loctest.ii gets rid of the problem. The lines both reference a string literal (en_GB_EURO), thus the bug, likely, has something to do with how the identical literals are herded together by 3.4.x on either pentium3 or pentium4 (but not pentium2)... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29390
[Bug c++/29024] [4.0/4.1 Regression] storage class specifier accepted for typedef (clause 7.1.1 ; 1)
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-10-11 19:43 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|lmillward at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] storage |storage class specifier |class specifier accepted for |accepted for typedef (clause|typedef (clause 7.1.1 ; 1) |7.1.1 ; 1) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29024
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #11 from bkoz at gcc dot gnu dot org 2006-10-11 20:18 --- Subject: Bug 29426 Author: bkoz Date: Wed Oct 11 20:18:36 2006 New Revision: 117643 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117643 Log: 2006-10-11 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/29426 * libsupc++/guard.cc (get_static_mutex): New. (mutex_wrapper::mutex_wrapper): Use it to get properly initialized recursive mutex without ordering issues. * src/locale_init.cc (__get_locale_mutex): No need to uglify. Change to get_locale_mutex. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/guard.cc trunk/libstdc++-v3/src/locale_init.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug fortran/29371] Coredump when using -fbounds-check with pointer nullify
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-11 20:43 --- Created an attachment (id=12412) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12412action=view) The correct fix for this PR THis turns out to be completely specific to nullify, or to a pointer assign to NULL(). Looking at the code for pointer assignment, we immediately see that the descriptor data set is being added to the block, FOLLOWED by the pre and post blocks. Since -fbounds-check fixes the value of the index in the pre block, the net result is an index that is used before it is set. The fix adds the data set to the pre block, thereby putting things in the right order. I'll just regtest this and then submit it. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Attachment #12395|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29371
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #12 from dannysmith at users dot sourceforge dot net 2006-10-11 20:54 --- (In reply to comment #4) - __gnu_cxx::__recursive_mutex static_mutex; + static __gnu_cxx::__recursive_mutex static_mutex; I tried thaty before I submitted bug report. No dice. (In reply to comment #11) 2006-10-11 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/29426 * libsupc++/guard.cc (get_static_mutex): New. (mutex_wrapper::mutex_wrapper): Use it to get properly initialized recursive mutex without ordering issues. * src/locale_init.cc (__get_locale_mutex): No need to uglify. Change to get_locale_mutex. Thanks I submitted a bug report just before I went to bed and it was fixed in the morning. Wow! This fixes testsuite failures on mingw32, too. Tested with and without -mthreads. Also tested with a pending (stage 1) patch to enable __cxa_atexit like destruction on mingw32. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #28 from tromey at gcc dot gnu dot org 2006-10-11 21:06 --- I doubt those configure warnings are very important. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug libfortran/29423] FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-11 21:45 --- Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90 Do you have scalbnf? No. Just scalbn. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29423
[Bug ada/28733] GNAT crash while compiling Ada-2005 code
--- Comment #7 from laurent at guerby dot net 2006-10-11 21:53 --- Confirmed. $ gcc -c -gnat05 ada_3d-file_io-step_reader.adb +===GNAT BUG DETECTED==+ | 4.2.0 20060922 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure sinfo.adb:990| | Error detected at ada_3d-system-containers-single_list.adb:68:4 | -- laurent at guerby dot net changed: What|Removed |Added Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-10-11 21:53:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28733
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-11 21:56 --- Confirmed. Uses a lot of memory. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||memory-hog Known to fail||4.0.4 4.1.2 Last reconfirmed|-00-00 00:00:00 |2006-10-11 21:56:21 date|| Summary|Internal error while|using boost::MPL requires |compiling code using|lots of memory |boost::MPL | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug fortran/29434] array bounds of allocatable components of derived types?
--- Comment #1 from brooks at gcc dot gnu dot org 2006-10-11 22:00 --- As per discussion on the fortran@ mailing list, the answer returned by gfortran and ifort (namely, that LBOUND(x%a) is the same as LBOUND(y)) is standard-conforming, and g95 is in error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29434
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-10-11 22:04 --- This is fixed now. Or was invalid. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug preprocessor/28709] [4.0/4.1/4.2 regression] Bad diagnostic pasting tokens with ##
--- Comment #1 from mmitchel at gcc dot gnu dot org 2006-10-11 22:30 --- This patch is OK, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28709
[Bug c++/29175] [4.0/4.1/4.2 regression] ICE on invalid C++ variable length array
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29175
[Bug c++/29435] New: [4.1 Regression] segmentation fault
I get a segmentation fault compiling the attached testcase with gcc 4.1. 4.0 and 4.2 seem to work. 4.1.2 20060901 (Debian 4.1.1-13) also worked but 4.1.2 20061007 (Debian 4.1.1-16) fails, at least on x86_64. (sid)1142:[EMAIL PROTECTED]: ~] g++-4.1 -c cinepaint-plugin_main.cpp cinepaint-plugin_main.cpp: In constructor âCameraUnsign, Real::Camera(Br_ImageVec, std::vectorTNT::Array2DRgbUnsign , std::allocatorTNT::Array2DRgbUnsign , unsigned int, ProgressInfo*)â: cinepaint-plugin_main.cpp:76: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.1 Regression] segmentation fault Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29435
[Bug c++/29435] [4.1 Regression] segmentation fault
--- Comment #1 from tbm at cyrius dot com 2006-10-11 23:01 --- Created an attachment (id=12413) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12413action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29435
[Bug c++/29435] [4.1 Regression] segmentation fault
--- Comment #2 from tbm at cyrius dot com 2006-10-11 23:02 --- Ignore my comment about x86_64. I also see this on mips. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29435
[Bug c++/29435] [4.1 Regression] segmentation fault
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-11 23:05 --- I think this is a sizeof issue: sizeof (Rgb XYindex ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29435
[Bug c++/29435] [4.1 Regression] segmentation fault
--- Comment #4 from tbm at cyrius dot com 2006-10-11 23:19 --- (gdb) where #0 0x0045a5ce in cxx_sizeof_or_alignof_type (type=0x2b29cf3e6b00, op=214, complain=1 '\001') at /home/tbm/scratch/gcc-4.1/gcc/cp/typeck.c:1251 #1 0x0044a947 in cp_parser_unary_expression (parser=0x2b29cf261460, address_p=0 '\0', cast_p=0 '\0') at /home/tbm/scratch/gcc-4.1/gcc/cp/parser.c:4850 #2 0x0044ae15 in cp_parser_assignment_expression (parser=0x2b29cf261460, cast_p=Variable cast_p is not available. ) at /home/tbm/scratch/gcc-4.1/gcc/cp/parser.c:5579 #3 0x0044ba72 in cp_parser_parenthesized_expression_list (parser=0x2b29cf261460, is_attribute_list=240 'â', cast_p=0 '\0', non_constant_p=0x0) at /home/tbm/scratch/gcc-4.1/gcc/cp/parser.c:4659 #4 0x0044a324 in cp_parser_unary_expression (parser=0x2b29cf261460, address_p=0 '\0', cast_p=1 '\001') at /home/tbm/scratch/gcc-4.1/gcc/cp/parser.c:4204 #5 0x0044ac41 in cp_parser_cast_expression (parser=0x2b29cf261460, address_p=0 '\0', cast_p=0 '\0') at /home/tbm/scratch/gcc-4.1/gcc/cp/parser.c:5455 ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29435
[Bug fortran/20863] Pointer problems in PURE procedures
--- Comment #2 from brooks at gcc dot gnu dot org 2006-10-12 00:07 --- On a similar note, the following is legal code for which an error is incorrectly reported: $ cat pr20863a.f90 PURE FUNCTION give_next(i) TYPE node_type sequence TYPE(node_type), POINTER :: next END TYPE TYPE(node_type), POINTER :: node TYPE(node_type), target :: t integer, intent(in) :: i node%next = t END FUNCTION [EMAIL PROTECTED] /cygdrive/d/svn/prs $ /irun/bin/gfortran -c pr20863a.f90 In file pr20863a.f90:9 node%next = t 1 Error: Right side of assignment at (1) is a derived type containing a POINTER in a PURE procedure See discussion here for details: http://gcc.gnu.org/ml/fortran/2006-10/msg00340.html -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org Keywords||rejects-valid Summary|Pointer of host-associated |Pointer problems in PURE |type in PURE procedure |procedures http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20863
[Bug fortran/29371] Coredump when using -fbounds-check with pointer nullify
--- Comment #3 from patchapp at dberlin dot org 2006-10-12 00:15 --- Subject: Bug number PR29371 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-10/msg00635.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29371
[Bug c++/29408] [4.1/4.2 regression] parse error for valid code
--- Comment #7 from debian-gcc at lists dot debian dot org 2006-10-12 00:37 --- fails with trunk 20061012 as well. Matthias -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Known to fail|4.1.2 |4.1.2 4.2.0 Known to work|4.0.4 4.1.1 4.2.0 |4.0.4 4.1.1 Summary|[4.1 regression] parse error|[4.1/4.2 regression] parse |for valid code |error for valid code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
[Bug c++/28981] g++ -pedantic issues error array bound not integer although it is a constant
--- Comment #1 from bangerth at dealii dot org 2006-10-12 00:39 --- int array3[(const unsigned short) (20.5 * 3)]; error message from compiler is: error: array bound is not an integer constant to me this is wrong because the expression (const unsigned short) (20.5 * 3) is an integer constant It's actually not: 5.19 Constant expressions[expr.const] 1 In several places, C++ requires expressions that evaluate to an integral or enumeration constant: as array bounds (_dcl.array_, _expr.new_), as case expressions (_stmt.switch_), as bit-field lengths (_class.bit_), as enumerator initializers (_dcl.enum_), as static member initializers (_class.static.data_), and as integral or enumeration non-type template arguments (_temp.arg_). constant-expression: conditional-expression Anintegral constant-expression can involve only literals (_lex.literal_), enumerators, const variables or static data members of integral or enumeration types initialized with constant expressions (_dcl.init_), non-type template parameters of integral or enumeration types, and sizeof expressions. Floating literals (_lex.fcon_) can appear only if they are cast to integral or enumeration types. Only type conversions to integral or enumeration types can be used. In particular, except in sizeof expressions, functions, class objects, pointers, or references shall not be used, and assignment, increment, decrement, function-call, or comma operators shall not be used. Note that floating literals are only allowed if immediately cast to integral or enumeration types. No arithmetic on them is allowed. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28981
[Bug c++/22149] func pointer non-type template parm invalid access control
--- Comment #3 from bangerth at dealii dot org 2006-10-12 00:41 --- Confirmed. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-12 00:41:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22149
[Bug debug/29436] New: ICE in modified_type_die
$ cat ice.c
typedef struct S {
unsigned long flags;
}S_t;
struct dp {
S_t c;
};
typedef S_t __attribute__((__may_alias__)) cmonkey;
static void handler(void *vp)
{
struct dp *dp;
cmonkey *cm = vp;
dp-c = *cm;
}
$ gcc -m32 -std=gnu99 -W -Wall -g3 -c ice.c
ice.c:7: internal compiler error: in modified_type_die, at dwarf2out.c:8463
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://bugzilla.redhat.com/bugzilla for instructions.
Preprocessed source stored into /tmp/ccakn2Ps.out file, please attach this to
your bugreport.
$
--
Summary: ICE in modified_type_die
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
[Bug c++/23643] Incorrect conversion from derived to empty base class
--- Comment #2 from bangerth at dealii dot org 2006-10-12 00:56 --- Why exactly do you think that the empty base should not be located at the same address as the simple_base base object? W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23643
[Bug c++/24056] failed lookup of static non-member operator function with certain templated arguments
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:03 --- The operator== you want to call is used in a context in which the template argument cannot be deduced (a non-deduceable context). If you want to use this construct, you will have to write something like templated_nested::operator==int (x, y); instead of plain x == y; W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24056
[Bug c++/24605] [4.0/4.1 Regression] internal compiler error: Segmentation fault while compiling c++ file
--- Comment #19 from bangerth at dealii dot org 2006-10-12 01:06 --- Since this is solved on mainline and nobody seems to have been able to ever reproduce it anyway, there doesn't seem to be a chance of this being actively worked on on older release branches. I'll therefore close it. We can always re-open it if someone can come up with a testcase that reproducibly crashes... W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24605
[Bug c++/24605] [4.0/4.1 Regression] internal compiler error: Segmentation fault while compiling c++ file
-- bangerth at dealii dot org changed: What|Removed |Added Known to work||4.2.0 Target Milestone|4.1.2 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24605
[Bug c++/26747] bad break/continue is not dectected until the gimplifier
--- Comment #2 from bangerth at dealii dot org 2006-10-12 01:08 --- What exactly is the problem here? I get this as an error message: g/x /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc x.cc: In function #8216;void f()#8217;: x.cc:3: error: break statement not within loop or switch That seems acceptable to me... W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26747
[Bug c++/26747] bad break/continue is not dectected until the gimplifier
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-12 01:12 --- (In reply to comment #2) What exactly is the problem here? I get this as an error message: g/x /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc x.cc: In function #8216;void f()#8217;: x.cc:3: error: break statement not within loop or switch Yes but this semantics anyalsis is done while gimplifing and not while parsing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-12 01:12:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26747
[Bug debug/29436] ICE in modified_type_die
--- Comment #1 from acahalan at gmail dot com 2006-10-12 01:20 ---
Other ways to ICE gcc:
///
typedef struct S {
unsigned long flags;
}S_t;
typedef S_t __attribute__((__may_alias__)) cmonkey;
S_t *handler(void *vp)
{
cmonkey *cm = vp;
return cm;
}
typedef struct S {
unsigned long flags;
}S_t;
typedef S_t __attribute__((__may_alias__)) cmonkey;
S_t handler(void *vp)
{
cmonkey *cm = vp;
return *cm;
}
//
typedef struct S {
unsigned long flags;
}S_t;
typedef S_t __attribute__((__may_alias__)) cmonkey;
int handler(void *vp)
{
S_t dp;
cmonkey *cm = vp;
dp = *cm;
}
///
typedef struct S {
unsigned long flags;
}S_t;
typedef S_t __attribute__((__may_alias__)) cmonkey;
int handler(void *vp)
{
S_t * dp;
cmonkey *cm = vp;
*dp = *cm;
}
Besides a fix, I could use some workaround suggestions.
This itself is an attempted workaround for a suspected
bug involving memcpy, so that won't do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
[Bug c++/26747] bad break/continue is not dectected until the gimplifier
--- Comment #4 from bangerth at math dot tamu dot edu 2006-10-12 01:25 --- Subject: Re: bad break/continue is not dectected until the gimplifier Yes but this semantics anyalsis is done while gimplifing and not while parsing. But I get the message also when using -fsyntax-only... W. - Wolfgang Bangerthemail:[EMAIL PROTECTED] www: http://www.math.tamu.edu/~bangerth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26747
[Bug debug/29436] ICE in modified_type_die
--- Comment #2 from acahalan at gmail dot com 2006-10-12 01:25 ---
Hey, I don't even need to use the types. The typedef alone
is enough to ICE gcc:
typedef struct S {
unsigned long flags;
}S_t;
typedef S_t __attribute__((__may_alias__)) cmonkey;
int main(int argc, char *argv[]){
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
[Bug c++/29437] New: [decl.init.ref]/5 wrongly implemented
[decl.init.ref]/5 has the following text for initialization of
constant references with rvalues:
5 A reference to type cv1 T1 is initialized by an expression of type
cv2 T2 as follows:
[...]
-- If the initializer expression is an rvalue, with T2 a class
type, and cv1 T1 is reference-compatible with cv2 T2, the
reference is bound in one of the following ways (the choice is
implementation-defined):
-- The reference is bound to the object represented by the
rvalue (see _basic.lval_) or to a sub-object within that
object.
-- A temporary of type cv1 T2 [sic] is created, and a
constructor is called to copy the entire rvalue object
into the temporary. The reference is bound to the
temporary or to a sub-object within the temporary.93)
The constructor that would be used to make the copy shall be
callable whether or not the copy is actually done. [Example:
struct A { };
struct B : public A { } b;
extern B f();
const A rca = f(); // Either bound to the A
sub-object of the B rvalue,
// or the entire B object is
copied and the reference
// is bound to the A sub-object
of the copy
--end example]
gcc apparently implements the second alternative, i.e. it copies objects.
However, it only copies the base object, i.e. it creates a temporary of
type cv1 T1, where the standard requires cv1 T2 (not the [sic] in the
wording.
Testcase:
-
#include iostream
struct Base{
Base() { std::cout Base ctor\n; }
Base(const Base ) { std::cout Base copy ctor\n; }
~Base() { std::cout ~Base called\n; }
};
struct Derived: public Base{
Derived() { std::cout Derived ctor\n; }
~Derived() { std::cout ~Derived called\n; }
Derived(const Derived ) { std::cout Base copy ctor\n; }
};
int main ()
{
bool b = false;
const Base ref = b ? Base() : Derived();
}
g/x /home/bangerth/bin/gcc-4.2-pre/bin/c++ x.cc
g/x ./a.out
Base ctor
Derived ctor
Base copy ctor
~Derived called
~Base called
~Base called
As can be seen, only Base is copied, when we are required to copy Derived.
W.
--
Summary: [decl.init.ref]/5 wrongly implemented
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29437
[Bug c++/28254] ICE with invalid class$
--- Comment #1 from bangerth at dealii dot org 2006-10-12 01:39 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-12 01:39:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28254
