[Bug testsuite/45324] gcc.target/i386/volatile-bitfields-1.c doesn't work with i586-linux
--- Comment #1 from ubizjak at gmail dot com 2010-08-19 06:49 ---
It is just insn preferences for IX86_TUNE_PARTIAL_REG_STALL. We are not testing
this flag but move insn, so can you please test:
Index: volatile-bitfields-1.c
===
--- volatile-bitfields-1.c (revision 163363)
+++ volatile-bitfields-1.c (working copy)
@@ -14,4 +14,4 @@
return bits.b;
}
-/* { dg-final { scan-assembler movzbl.*bits } } */
+/* { dg-final { scan-assembler mov(zbl|b).*bits } } */
The patch is pre-approved if it solves your failure.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-08-19 06:49:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45324
[Bug c++/45334] New: Base class type information not accessible in binaries compiled with g++ 4.5.0
This is a copy of an issue originally filed as gdb bug at
http://sourceware.org/bugzilla/show_bug.cgi?id=11639 that was identified as a
gcc issue in the mean time:
If 'Derived' and 'Base' are setup as shown in the attachment
void Derived::foo()
{
Base *b = this;
Base br = *b;
}
then
'print b'
yields $1 = (void *) 0xbfffee38, i.e. the type information for 'b' is
completely lost.
It should print (Base *) 0xbfffee38.
The problem is not present in g++ 4.4.
--
Summary: Base class type information not accessible in binaries
compiled with g++ 4.5.0
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andre dot poenitz at nokia dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45334
[Bug c++/45334] Base class type information not accessible in binaries compiled with g++ 4.5.0
--- Comment #1 from andre dot poenitz at nokia dot com 2010-08-19 06:58 --- Created an attachment (id=21517) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21517action=view) Example code to reproduce the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45334
[Bug target/45335] New: Use ldrd to load two consecutive words
Compile the following code with options -march=armv7-a -mthumb -O2 -fpic
struct S
{
void* p1;
void* p2;
void* p3;
void* p4;
};
void foo1(struct S* fp, struct S* otherSaveArea)
{
struct S* saveArea = fp - 1;
printf(StackSaveArea for fp %p [%p/%p]:\n, fp, saveArea, otherSaveArea);
printf( prevFrame=%p savedPc=%p meth=%p curPc=%p fp[0]=0x%08x\n,
saveArea-p1, saveArea-p2,saveArea-p3,saveArea-p4,*(unsigned
int*)fp);
}
GCC 4.6 generates
foo1:
push{r4, r5, r6, lr}
mov r4, r0
ldr r5, .L2
sub sp, sp, #8
mov r3, r1
sub r2, r0, #16
.LPIC0:
add r5, pc
mov r1, r0
mov r0, r5
bl printf(PLT)
ldr r6, [r4, #-4] // A
ldr r5, [r4, #0] // B
ldr r0, .L2+4
ldr r1, [r4, #-16]// C
ldr r2, [r4, #-12]// D
.LPIC1:
add r0, pc
ldr r3, [r4, #-8]
str r6, [sp, #0] // E
str r5, [sp, #4] // F
bl printf(PLT)
add sp, sp, #8
pop {r4, r5, r6, pc}
Notice instructions A and B loading two consecutive words, they can be written
as a single instruction
ldrdr6, r5, [r4, -4]
It results in shorter and potentially faster code. Similarly instructions C and
D can be replace by a ldrd. Instructions E and F shows a chance for strd
instruction.
We don't have a ldrd insn pattern to represent two separate loads. Maybe we can
define one and let combine to find the chances.
There is also the same opportunity for ARM instructions, but there are more
constraints on register usage. In arm mode, the first register must be even
numbered and the second register number must be exact successor of the first
one. These are similar to the constraints of ldm and stm, and our register
allocator can't handle them.
--
Summary: Use ldrd to load two consecutive words
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45335
[Bug fortran/33197] Fortran 2008: math functions
--- Comment #34 from burnus at gcc dot gnu dot org 2010-08-19 07:28 --- Subject: Bug 33197 Author: burnus Date: Thu Aug 19 07:28:17 2010 New Revision: 163364 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163364 Log: 2010-08-19 Tobias Burnus bur...@net-b.de PR fortran/36158 PR fortran/33197 * check.c (gfc_check_bessel_n2): New function. * gfortran.h (gfc_isym_id): Add GFC_ISYM_JN2 and GFC_ISYM_YN2. * intrinsic.c (add_functions): Add transformational version of the Bessel_jn/yn intrinsics. * intrinsic.h (gfc_check_bessel_n2,gfc_simplify_bessel_jn2, gfc_simplify_bessel_yn2): New prototypes. * intrinsic.texi (Bessel_jn, Bessel_yn): Document transformational variant. * simplify.c (gfc_simplify_bessel_jn, gfc_simplify_bessel_yn): Check for negative order. (gfc_simplify_bessel_n2,gfc_simplify_bessel_jn2, gfc_simplify_bessel_yn2): New functions. 2010-08-19 Tobias Burnus bur...@net-b.de PR fortran/36158 PR fortran/33197 * gfortran.dg/bessel_3.f90: New. * gfortran.dg/bessel_4.f90: New. * gfortran.dg/bessel_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/bessel_3.f90 trunk/gcc/testsuite/gfortran.dg/bessel_4.f90 trunk/gcc/testsuite/gfortran.dg/bessel_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33197
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-19 07:28 --- Subject: Bug 36158 Author: burnus Date: Thu Aug 19 07:28:17 2010 New Revision: 163364 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163364 Log: 2010-08-19 Tobias Burnus bur...@net-b.de PR fortran/36158 PR fortran/33197 * check.c (gfc_check_bessel_n2): New function. * gfortran.h (gfc_isym_id): Add GFC_ISYM_JN2 and GFC_ISYM_YN2. * intrinsic.c (add_functions): Add transformational version of the Bessel_jn/yn intrinsics. * intrinsic.h (gfc_check_bessel_n2,gfc_simplify_bessel_jn2, gfc_simplify_bessel_yn2): New prototypes. * intrinsic.texi (Bessel_jn, Bessel_yn): Document transformational variant. * simplify.c (gfc_simplify_bessel_jn, gfc_simplify_bessel_yn): Check for negative order. (gfc_simplify_bessel_n2,gfc_simplify_bessel_jn2, gfc_simplify_bessel_yn2): New functions. 2010-08-19 Tobias Burnus bur...@net-b.de PR fortran/36158 PR fortran/33197 * gfortran.dg/bessel_3.f90: New. * gfortran.dg/bessel_4.f90: New. * gfortran.dg/bessel_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/bessel_3.f90 trunk/gcc/testsuite/gfortran.dg/bessel_4.f90 trunk/gcc/testsuite/gfortran.dg/bessel_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
--- Comment #3 from burnus at gcc dot gnu dot org 2010-08-19 07:37 --- The patch implemented the compile-time version using a recurrence algorithm. TODO: Add a run-time implementation (using a recurrence algorithm). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
--- Comment #4 from burnus at gcc dot gnu dot org 2010-08-19 08:21 --- (In reply to comment #3) TODO: Add a run-time implementation (using a recurrence algorithm). Remember that all kinds of integers are allowed for N1 and N2, but that POSIX's jn/yn only allows int - thus, on can add a cast to c_int in iresolve.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158
[Bug target/45336] New: pextr{b,w,d}, (worse than) redundant extensions
Bis repetita placent.
Since PR 45294 got reclassified as a duplicate of PR 41323 and
a) chances for a new GCC specific intrinsic are null
b) unlike H.J. Lu i couldn't care less about ICC
c) i think GCC oughts to do the Right Thing
d) or at least have builtins match hardware (because inline asm gets no
scheduling love)
i'm reporting the same undue extensions this time for the whole class of
extraction ops.
$ cat pextr.cc
#include smmintrin.h
typedef long unsigned int uint64_t;
uint64_t foo8(__m128i x) { return _mm_extract_epi8(x, 4); }
uint64_t foo16(__m128i x) { return _mm_extract_epi16(x, 3); }
uint64_t foo32(__m128i x) { return _mm_extract_epi32(x, 2); }
uint64_t bar8(__v16qi x) { return __builtin_ia32_vec_ext_v16qi(x, 4); }
uint64_t bar16(__v8hi x) { return __builtin_ia32_vec_ext_v8hi(x, 3); }
uint64_t bar32(__v4si x) { return __builtin_ia32_vec_ext_v4si(x, 2); }
int main() { return 0; }
$ /usr/local/gcc-4.6-20100811/bin/g++ -O3 -march=native pextr.cc
004004a0 _Z4foo8Dv2_x:
4004a0: 66 0f 3a 14 c0 04 pextrb $0x4,%xmm0,%eax
4004a6: 0f be c0movsbl %al,%eax
4004a9: 48 98 cltq
4004ab: c3 retq
004004b0 _Z5foo16Dv2_x:
4004b0: 66 0f c5 c0 03 pextrw $0x3,%xmm0,%eax
4004b5: 98 cwtl
4004b6: 48 98 cltq
4004b8: c3 retq
004004c0 _Z5foo32Dv2_x:
4004c0: 66 0f 3a 16 c0 02 pextrd $0x2,%xmm0,%eax
4004c6: 48 98 cltq
4004c8: c3 retq
004004d0 _Z4bar8Dv16_c:
4004d0: 66 0f 3a 14 c0 04 pextrb $0x4,%xmm0,%eax
4004d6: 48 0f be c0 movsbq %al,%rax
4004da: c3 retq
004004e0 _Z5bar16Dv8_s:
4004e0: 66 0f c5 c0 03 pextrw $0x3,%xmm0,%eax
4004e5: 48 0f bf c0 movswq %ax,%rax
4004e9: c3 retq
004004f0 _Z5bar32Dv4_i:
4004f0: 66 0f 3a 16 c0 02 pextrd $0x2,%xmm0,%eax
4004f6: 48 98 cltq
4004f8: c3 retq
x86-64, Intel i7.
--
Summary: pextr{b,w,d}, (worse than) redundant extensions
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45336
[Bug target/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
--- Comment #14 from ramana at gcc dot gnu dot org 2010-08-19 08:28 --- Subject: Bug 45070 Author: ramana Date: Thu Aug 19 08:27:59 2010 New Revision: 163367 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163367 Log: For Ian Bolton ian.bol...@arm.com 2010-08-19 Ian Bolton ian.bol...@arm.com PR target/45070 * gcc.c-torture/execute/pr45070.c: New. * config/arm/arm.c (arm_output_epilogue): Ensure that return value of size 1-3 is handled correctly. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr45070.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN
--- Comment #7 from burnus at gcc dot gnu dot org 2010-08-19 09:04 --- (In reply to comment #6) This patch will generate an error. If IOSTAT or IOMSG is used, the read will continue in the loop after an error, but the error status variables will be set so that one will know an error occurred when the READ has completed. Any thoughts Tobias? I think that's useful. One can use the interactive dialog to query about the correct format (as before), if one enters the correct nml one returns without error (as before), but if one enters an invalid namelist one returns (as before) but with an error status (new) and without an warning (namelist read: misplaced = sign) [new]. (One can use iomsg to get the error string.) And without err=/iostat=, one gets a run-time error as before. [Admittedly, I have never used the ? / =? feature thus I might overlook a useful application which won't work with the new patch, but it seems as if most things continue to work.] Thus, I think the patch is fine. As it is not test-suite testable, no test case is needed. From my side the patch is OK for committal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #24 from eren at pardus dot org dot tr 2010-08-19 09:13 --- What's the situation right now, is there any progress? I have Geode LX 800MHz, and the code compiled for generic x86 architectures runs really slow . I'm thinking of producing optimized packages for Geode LX, however I'm confused as to which CFLAGS I should use. Is there any clarifications for this? I'm using gcc 4.3.5, btw. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug fortran/45337] New: intent(out) and pointer = null()
$ gfortran --version GNU Fortran (GCC) 4.5.2 20100819 (prerelease) which is wrong? and WHY? -- Summary: intent(out) and pointer = null() Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: linuxl4 at sohu dot com GCC build triplet: x86_64 - redhat - linux GCC host triplet: x86_64 - redhat - linux GCC target triplet: x86_64 - redhat - linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug fortran/45337] intent(out) and pointer = null()
--- Comment #1 from linuxl4 at sohu dot com 2010-08-19 09:14 --- module ptrmod contains subroutine lengthX(x, i) implicit none real, pointer, intent(out) :: x(:)=null() integer :: i allocate(x(i)) x=i end subroutine end module program main use ptrmod implicit none real, pointer :: x(:) integer :: i do i=1,5 call lengthX(x, i) print *, size(x), x enddo if(associated(x)) deallocate(x) x=null() end program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug fortran/45337] intent(out) and pointer = null()
--- Comment #2 from jv244 at cam dot ac dot uk 2010-08-19 09:22 --- (In reply to comment #1) module ptrmod contains subroutine lengthX(x, i) implicit none real, pointer, intent(out) :: x(:)=null() you can't initialize a dummy argument, since initialization implies save. Just put 'NULLIFY(x)' in the body of the subroutine. Intents for pointers is fine, but not Fortran95 (2003/2008?) integer :: i allocate(x(i)) x=i end subroutine end module program main use ptrmod implicit none real, pointer :: x(:) integer :: i do i=1,5 call lengthX(x, i) print *, size(x), x enddo if(associated(x)) deallocate(x) x=null() end program -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug fortran/45337] intent(out) and pointer = null()
--- Comment #3 from linuxl4 at sohu dot com 2010-08-19 09:22 --- module ptrmod implicit none type inde real :: x end type contains subroutine lengthY(indexx) implicit none type(inde), pointer, intent(out) :: indexx(:)=null() end subroutine end module program main use ptrmod implicit none type(inde), pointer :: indexx(:)=null() call lengthY(indexx) end program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug fortran/45337] intent(out) and pointer = null()
--- Comment #4 from linuxl4 at sohu dot com 2010-08-19 09:26 --- Too fast your answer interrupt My question. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug libstdc++/44952] #include iostream implies global constructor.
--- Comment #14 from hubicka at gcc dot gnu dot org 2010-08-19 09:39 --- Well, it might be easy to modify libstdc++ implementation so the static constructor compiles into single function call. Then we can teach GCC to optimize constructor containing only a call into entry in ctors table. Then we will get a lot of duplicate calls, but all at one place and we won't have the locality problem at startup. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952
[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)
--- Comment #5 from burnus at gcc dot gnu dot org 2010-08-19 09:40 --- (In reply to comment #2) Intents for pointers is fine, but not Fortran95 (2003/2008?) Intents for pointers is Fortran 2003; it applies to the pointer association status and not to the value. The programs in comment 0 and comment 2 are both invalid. type(inde), pointer :: indexx(:)=null() means that indexx is initialized - which is only possible for variables which are in static memory (SAVE; the assignment implies the SAVE). That's OK for the line above, but not for dummy arguments to subroutines. Note: In C int a = 5; and int a; a = 5; have the same meaning. In Fortran not! integer :: a = 5 means that a is in static memory (SAVE) and will only be initialized once at program start. Whereas for integer :: a; a = 5 the assignment happens every time the line is subroutine is called. * * * Regarding the accepts invalid bug: While for the program in comment 0, gfortran prints the error Error: Dummy 'x' at (1) cannot have an initializer it compiles the program in comment 2. Note: If one removes the INTENT(OUT) or has (as in comment 0) no derived-type dummy, the error is printed. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Keywords||accepts-invalid Resolution|INVALID | Summary|intent(out) and pointer = |gfortran accepts pointer |null() |initialization of DT dummy ||arguments w/ INTENT(OUT) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)
--- Comment #6 from burnus at gcc dot gnu dot org 2010-08-19 09:47 --- (In reply to comment #5) It should read: program in comment 3 (not in comment 2). To macius bat: Thanks for the bug report! It helps if you already state (a) the error message and (b) what you expect in the first description. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64 - redhat - linux | GCC host triplet|x86_64 - redhat - linux | GCC target triplet|x86_64 - redhat - linux | Last reconfirmed|-00-00 00:00:00 |2010-08-19 09:47:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug c/45320] Strict-aliasing misdetection
--- Comment #3 from strikosn at gmail dot com 2010-08-19 09:50 --- Ok, I reviewed all cases and it seems that gcc always does the right thing. The only problem left is that strict-aliasing warning Levels 2 and 3, of which Level 3 is enabled by default, do not detect this particular case of strict-aliasing, even though Level 1 detects it correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45320
[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)
--- Comment #7 from burnus at gcc dot gnu dot org 2010-08-19 09:56 --- Untested patch: Index: resolve.c === --- resolve.c (revision 163368) +++ resolve.c (working copy) @@ -9724,7 +9724,8 @@ resolve_fl_variable (gfc_symbol *sym, in gfc_error (External '%s' at %L cannot have an initializer, sym-name, sym-declared_at); else if (sym-attr.dummy -!(sym-ts.type == BT_DERIVED sym-attr.intent == INTENT_OUT)) +!(sym-ts.type == BT_DERIVED sym-attr.intent == INTENT_OUT + !sym-attr.pointer)) gfc_error (Dummy '%s' at %L cannot have an initializer, sym-name, sym-declared_at); else if (sym-attr.intrinsic) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337
[Bug rtl-optimization/44691] [4.6 Regression] ICE: RTL check: expected code 'reg', have 'plus' in rhs_regno, at rtl.h:1050
--- Comment #4 from abel at gcc dot gnu dot org 2010-08-19 10:04 --- Subject: Bug 44691 Author: abel Date: Thu Aug 19 10:03:39 2010 New Revision: 163369 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163369 Log: PR rtl-optimization/44691 * sel-sched.c (count_occurrences_1): Also punt when SUBREG_REG is not a register. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44691
[Bug rtl-optimization/44691] [4.6 Regression] ICE: RTL check: expected code 'reg', have 'plus' in rhs_regno, at rtl.h:1050
--- Comment #5 from abel at gcc dot gnu dot org 2010-08-19 10:04 --- Fixed by 163369. -- abel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44691
[Bug fortran/45338] New: Failure on interfacing a function passed as an argument as a custom operator
In the testcase below, compiled with: gfortran -c test.f90 gfortran suffers an internal compiler error: internal compiler error: in gfc_gen_symbol_decl, at fortran/trans-decl.c:893 If the commenting on the marked line is removed, then the code compiles fine. I have tested this case with versions 4.3.2, 4.4.1 and 4.6 (experimental, from svn trunk last night). It works correctly using ifort, PGI and pathscale compilers. --- module test_mod implicit none contains subroutine test_fn (cmp) interface operator(.myop.) pure function cmp (a, b) result(ret) integer, intent(in) :: a, b logical ret end function end interface integer :: a, b !print*, cmp(a, b) ! If this line is commented out, gfortran has an ! internal compiler error print*, a .myop. b end subroutine end module -- Summary: Failure on interfacing a function passed as an argument as a custom operator Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sds50 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45338
[Bug fortran/45339] New: Failure on interfacing a function passed as an argument as a custom operator
In the testcase below, compiled with: gfortran -c test.f90 gfortran suffers an internal compiler error: internal compiler error: in gfc_gen_symbol_decl, at fortran/trans-decl.c:893 If the commenting on the marked line is removed, then the code compiles fine. I have tested this case with versions 4.3.2, 4.4.1 and 4.6 (experimental, from svn trunk last night). It works correctly using ifort, PGI and pathscale compilers. --- module test_mod implicit none contains subroutine test_fn (cmp) interface operator(.myop.) pure function cmp (a, b) result(ret) integer, intent(in) :: a, b logical ret end function end interface integer :: a, b !print*, cmp(a, b) ! If this line is commented out, gfortran has an ! internal compiler error print*, a .myop. b end subroutine end module -- Summary: Failure on interfacing a function passed as an argument as a custom operator Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sds50 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45339
[Bug bootstrap/45321] [4.6 regression] ARM bootstrap failure due to stdarg_p change
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-19 10:40:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45321
[Bug fortran/45290] [F08] pointer initialization
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-19 11:11 --- There are also still problems with procedure pointers: module m implicit none procedure(f1), pointer :: pp = f1 contains integer function f1() f1 = 42 end function end module use m implicit none if (pp()/=42) call abort() end This one fails with: f951: internal compiler error: in build_function_decl, at fortran/trans-decl.c:1611 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
[Bug testsuite/38605] Out of stack space on gcc.c-torture/compile/limits-exprparen.c
--- Comment #3 from raju dot goruganti at gmail dot com 2010-08-19 11:34 --- (In reply to comment #1) These failures are also appearing on ia64-suse-linux-gnu... http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01952.html These failure also appearing in case of arm cross tool chain(which uses gcc4.4.1 and built by using cross-ng set up).But this is only occured when the host gcc verion is gcc4.1.2 but not for gcc 4.3.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38605
[Bug c++/45331] Generate clear diagnostics when a semicolon is missing at the end of a class definition
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-19 12:11 --- Bug 16189 and Bug 36888 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45331
[Bug c++/45334] Base class type information not accessible in binaries compiled with g++ 4.5.0
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-19 12:13 --- Probably Bug 44645 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45334
[Bug debug/44645] [4.5 Regression] wrong debug info for nested typedef
--- Comment #4 from redi at gcc dot gnu dot org 2010-08-19 12:19 --- *** Bug 45181 has been marked as a duplicate of this bug. *** -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||nikolay at totalviewtech dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
[Bug debug/45181] No debug information for parameter type
--- Comment #6 from redi at gcc dot gnu dot org 2010-08-19 12:19 --- *** This bug has been marked as a duplicate of 44645 *** -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45181
[Bug debug/44645] [4.5 Regression] wrong debug info for nested typedef
--- Comment #5 from redi at gcc dot gnu dot org 2010-08-19 12:22 --- *** Bug 45334 has been marked as a duplicate of this bug. *** -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||andre dot poenitz at nokia ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
[Bug c++/45334] Base class type information not accessible in binaries compiled with g++ 4.5.0
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-19 12:22 --- works with 4.4 and 4.6, so I'm marking it as a dup *** This bug has been marked as a duplicate of 44645 *** -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45334
[Bug debug/44645] [4.5 Regression] missing debug info for pointer types
--- Comment #6 from redi at gcc dot gnu dot org 2010-08-19 12:26 ---
(adjusting title to be more general)
testcase from dup Bug 45181
struct S { int f(S*); };
int S::f(S* p)
{
return 0;
}
int main()
{
S s;
return s.f(s);
}
within S::f p has type void*
Tom, CCing you as you've correctly identified this as a GCC 4.5 bug at
http://gcc.gnu.org/ml/libstdc++/2010-06/msg00159.html and
http://sourceware.org/bugzilla/show_bug.cgi?id=11639
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
||org
Known to fail|4.5.0 |4.5.0 4.5.1
Summary|[4.5 Regression] wrong debug|[4.5 Regression] missing
|info for nested typedef |debug info for pointer types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
[Bug debug/44645] [4.5 Regression] missing debug info for pointer types
--- Comment #7 from redi at gcc dot gnu dot org 2010-08-19 12:32 ---
testcase from Bug 45334 reduced to a single file:
struct Base
{
virtual ~Base();
};
Base::~Base() {}
struct Derived : Base
{
virtual ~Derived();
void foo();
};
Derived::~Derived() {}
void Derived::foo()
{
Base *b = this;
Base br = *b;
}
int main()
{
Derived d;
d.foo();
Base *b = d;
}
Within Derived::foo b has type void*
Breakpoint 1, Derived::foo (this=0x7fffe5f0) at bug.cc:18
18 Base *b = this;
(gdb) ptype b
type = void *
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-19 13:04 --- Created an attachment (id=21518) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21518action=view) gcc46-pr45336.patch If you are complaining about the 2 gradual sign extensions instead of one sign extension, then here is an untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45336
[Bug fortran/45339] Failure on interfacing a function passed as an argument as a custom operator
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-19 13:08 --- *** This bug has been marked as a duplicate of 45338 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45339
[Bug fortran/45338] Failure on interfacing a function passed as an argument as a custom operator
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-19 13:08 --- *** Bug 45339 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45338
[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
--- Comment #10 from janus at gcc dot gnu dot org 2010-08-19 13:08 --- (In reply to comment #9) (In reply to comment #4) Possible solutions: 1) Make sure we use the right symbol from the right module. 2) Do the vtab initialization inside the module that defines the class, i.e. add a module procedure like 'vtab$trivial_gradient_type$init' which does it, and call this from the main program. Then there is no name ambiguity. 3) Do it in the original module (like in #2), but statically via default initialization. Mine. I'm working on a patch which implements solution #3. It already fixes the test case, but still has a few regresssions. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-08-13 08:22:22 |2010-08-19 13:08:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-19 13:31 --- Please hold off any changes. I am talking to icc people about this. I hope to come up with a solution soon. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45336
[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-19 13:34 --- (In reply to comment #1) Created an attachment (id=21518) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21518action=view) [edit] gcc46-pr45336.patch If you are complaining about the 2 gradual sign extensions instead of one sign extension, then here is an untested fix. This patch is independent of the issue I am working on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45336
[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code
--- Comment #26 from bernds at gcc dot gnu dot org 2010-08-19 13:38 --- (In reply to comment #25) Alex Oliva posted some patches to make cselib handle autoinc stuff. No idea whether http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01038.html is the latest version or if he has a newer one. Doesn't look bad, but I dislike the name change to _addr variants for functions that look up not just addresses. I think we should just fix up all the callers to pass in a mode. I'm also not sure we need a global cselib_record_autoinc flag - why not just do that always? Shouldn't we do something else when hashing PRE_MODIFY? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug middle-end/45172] [4.6 Regression] internal compiler error: verify_flow_info failed
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-19 13:56 --- Well, the edge from the block ending with _gfortran_runtime_error_at is an EH edge, not normal edge. Not sure what exactly Fortran needs -fexceptions for currently, one reason could be pthread_cancel, but at least with OpenMP pthread_cancel isn't going to do very nice things anyway. The two (28) phi args seem to be because the successor block of the empty EH block that is being removed in ehcleanup already had another incoming edge from that block, and ehcleanup doesn't expect that. Not sure if that is a bug from before ehcleanup, or if ehcleanup should test for that case and either disallow the optimization, or resolve it somehow else. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45172
[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-19 14:07 --- Of course, this is a generic patch that can (and does) trigger in other cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45336
[Bug tree-optimization/45340] New: __builtin_expect and -Os generates stupid code
__builtin_expect and -Os generates stupid code like jump to next instruction. I will attach sources and generated asm listing. -- Summary: __builtin_expect and -Os generates stupid code Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: socketpair at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45340
[Bug fortran/45338] Failure on interfacing a function passed as an argument as a custom operator
-- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||4.2.1 4.1.2 4.3.4 4.4.0 ||4.5.0 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-08-19 14:11:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45338
[Bug tree-optimization/45340] __builtin_expect and -Os generates stupid code
--- Comment #1 from socketpair at gmail dot com 2010-08-19 14:17 --- Created an attachment (id=21519) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21519action=view) C souce file 1. gcc-Os --save-temps -fomit-frame-pointer -fno-stack-protector main.c 2. gcc -DCOOL -Os --save-temps -fomit-frame-pointer -fno-stack-protector main.c compare .s files You will see this: - testl %eax, %eax je .L2 jmp .L7 .L4: .L7: cmpl$0, 12(%esp) - I think, that jmp .L7 is stupid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45340
[Bug testsuite/45324] gcc.target/i386/volatile-bitfields-1.c doesn't work with i586-linux
--- Comment #2 from hjl at gcc dot gnu dot org 2010-08-19 14:18 --- Subject: Bug 45324 Author: hjl Date: Thu Aug 19 14:18:18 2010 New Revision: 163372 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163372 Log: Also scan movb. 2010-08-19 Uros Bizjak ubiz...@gmail.com PR testsuite/45324 * gcc.target/i386/volatile-bitfields-1.c: Also scan movb. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/volatile-bitfields-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45324
[Bug testsuite/45324] gcc.target/i386/volatile-bitfields-1.c doesn't work with i586-linux
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-19 14:20 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45324
[Bug c++/45341] New: Compiler error matching template function with array reference parameter to anonimous struct array
// gcc 4.5
// error: no matching function for call to 'func(anonymous struct [5])'
// Adding name to struct fixes the error
templateclass T, int N
void func (T()[N]);
struct
{
int i;
}
arr[5];
void test()
{
func(arr);
}
--
Summary: Compiler error matching template function with array
reference parameter to anonimous struct array
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dev at sogetthis dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45341
[Bug middle-end/45172] [4.6 Regression] internal compiler error: verify_flow_info failed
--- Comment #5 from jv244 at cam dot ac dot uk 2010-08-19 14:24 --- (In reply to comment #4) Not sure what exactly Fortran needs -fexceptions for currently, one reason could be pthread_cancel, but at least with OpenMP pthread_cancel isn't going to do very nice things anyway. We have a mixed MPI/OMP parallel Fortran code, -fexceptions is being added automagically by the openmpi compiler driver (mpif90). This might be to allow mixed C++/C/Fortran codes to work (but I couldn't quite find docs about this on the openmpi webpage). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45172
[Bug tree-optimization/45340] __builtin_expect and -Os generates stupid code
--- Comment #2 from socketpair at gmail dot com 2010-08-19 14:28 --- Created an attachment (id=21520) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21520action=view) with stupid jmp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45340
[Bug tree-optimization/45340] __builtin_expect and -Os generates stupid code
--- Comment #3 from socketpair at gmail dot com 2010-08-19 14:28 --- Created an attachment (id=21521) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21521action=view) without buggy jmp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45340
[Bug testsuite/45324] gcc.target/i386/volatile-bitfields-1.c doesn't work with i586-linux
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45324
[Bug testsuite/45342] New: FAIL: gcc.dg/tls/thr-cse-1.c scan-assembler-not emutls_get_address.*emutls_get_address.*
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tls/thr-cse-1.c -O1 -S -o thr-cse-1.s (timeout = 300) PASS: gcc.dg/tls/thr-cse-1.c (test for excess errors) FAIL: gcc.dg/tls/thr-cse-1.c scan-assembler-not emutls_get_address.*emutls_get_a ddress.* We have in the .s: b,l __emutls_get_address,%r2 ... .type __emutls_get_address, @function -- Summary: FAIL: gcc.dg/tls/thr-cse-1.c scan-assembler-not emutls_get_address.*emutls_get_address.* Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45342
[Bug c++/45341] Compiler error matching template function with array reference parameter to anonimous struct array
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-19 14:52 --- template parameters must have linkage, but an unnamed type has no linkage -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45341
[Bug c++/45341] Compiler error matching template function with array reference parameter to anonimous struct array
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-19 14:53 ---
N.B this has nothing to do with arrays, the following fails for the same
reason:
templateclass T
void func (T);
static struct
{
int i;
}
arr;
void test()
{
func(arr);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45341
[Bug c++/45341] Compiler error matching template function with array reference parameter to anonimous struct array
--- Comment #3 from dev at sogetthis dot com 2010-08-19 15:27 --- I just found out that it does compile successfully with -std=c++0x flag. In C++03, unnamed type shall not be used as a template-argument for a template type-parameter (irrespective of it's linkage). In C++0x this restriction has been removed. See 14.3.1 Template type arguments -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45341
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-08-19 15:53 --- I didn't get a chance to look. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |hubicka at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug fortran/45016] Support pointer assignment with bound-spec; wrong bounds for pointer assignment
--- Comment #4 from domob at gcc dot gnu dot org 2010-08-19 16:02 --- Subject: Bug 45016 Author: domob Date: Thu Aug 19 16:02:30 2010 New Revision: 163377 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163377 Log: 2010-08-19 Daniel Kraft d...@domob.eu PR fortran/29785 PR fortran/45016 * trans.h (struct gfc_se): New flag `byref_noassign'. * trans-array.h (gfc_conv_shift_descriptor_lbound): New method. (gfc_conv_array_extent_dim), (gfc_conv_descriptor_size): New methods. * expr.c (gfc_check_pointer_assign): Allow bounds and rank remapping and check for compile-time errors with those. * trans-decl.c (trans_associate_var): Use new routine `gfc_conv_shift_descriptor_lbound' instead of doing it manually. * trans-array.c (gfc_conv_shift_descriptor_lbound): New method. (gfc_conv_array_extent_dim), (gfc_conv_descriptor_size): New methods. (gfc_array_init_size): Use new `gfc_conv_array_extent_dim'. (gfc_conv_expr_descriptor): Handle new flag `byref_noassign'. * trans-expr.c (gfc_trans_pointer_assignment): Handle bounds and rank remapping for assignment. 2010-08-19 Daniel Kraft d...@domob.eu PR fortran/29785 PR fortran/45016 * gfortran.dg/pointer_assign_5.f90: Remove 'not implemented' error. * gfortran.dg/pointer_remapping_1.f90: New test. * gfortran.dg/pointer_remapping_2.f03: New test. * gfortran.dg/pointer_remapping_3.f08: New test. * gfortran.dg/pointer_remapping_4.f03: New test. * gfortran.dg/pointer_remapping_5.f08: New test. * gfortran.dg/pointer_remapping_6.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/pointer_remapping_1.f90 trunk/gcc/testsuite/gfortran.dg/pointer_remapping_2.f03 trunk/gcc/testsuite/gfortran.dg/pointer_remapping_3.f08 trunk/gcc/testsuite/gfortran.dg/pointer_remapping_4.f03 trunk/gcc/testsuite/gfortran.dg/pointer_remapping_5.f08 trunk/gcc/testsuite/gfortran.dg/pointer_remapping_6.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pointer_assign_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45016
[Bug fortran/29785] Fortran 2003: POINTER Rank Remapping
--- Comment #10 from domob at gcc dot gnu dot org 2010-08-19 16:02 --- Subject: Bug 29785 Author: domob Date: Thu Aug 19 16:02:30 2010 New Revision: 163377 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163377 Log: 2010-08-19 Daniel Kraft d...@domob.eu PR fortran/29785 PR fortran/45016 * trans.h (struct gfc_se): New flag `byref_noassign'. * trans-array.h (gfc_conv_shift_descriptor_lbound): New method. (gfc_conv_array_extent_dim), (gfc_conv_descriptor_size): New methods. * expr.c (gfc_check_pointer_assign): Allow bounds and rank remapping and check for compile-time errors with those. * trans-decl.c (trans_associate_var): Use new routine `gfc_conv_shift_descriptor_lbound' instead of doing it manually. * trans-array.c (gfc_conv_shift_descriptor_lbound): New method. (gfc_conv_array_extent_dim), (gfc_conv_descriptor_size): New methods. (gfc_array_init_size): Use new `gfc_conv_array_extent_dim'. (gfc_conv_expr_descriptor): Handle new flag `byref_noassign'. * trans-expr.c (gfc_trans_pointer_assignment): Handle bounds and rank remapping for assignment. 2010-08-19 Daniel Kraft d...@domob.eu PR fortran/29785 PR fortran/45016 * gfortran.dg/pointer_assign_5.f90: Remove 'not implemented' error. * gfortran.dg/pointer_remapping_1.f90: New test. * gfortran.dg/pointer_remapping_2.f03: New test. * gfortran.dg/pointer_remapping_3.f08: New test. * gfortran.dg/pointer_remapping_4.f03: New test. * gfortran.dg/pointer_remapping_5.f08: New test. * gfortran.dg/pointer_remapping_6.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/pointer_remapping_1.f90 trunk/gcc/testsuite/gfortran.dg/pointer_remapping_2.f03 trunk/gcc/testsuite/gfortran.dg/pointer_remapping_3.f08 trunk/gcc/testsuite/gfortran.dg/pointer_remapping_4.f03 trunk/gcc/testsuite/gfortran.dg/pointer_remapping_5.f08 trunk/gcc/testsuite/gfortran.dg/pointer_remapping_6.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pointer_assign_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29785
[Bug fortran/29785] Fortran 2003: POINTER Rank Remapping
--- Comment #11 from domob at gcc dot gnu dot org 2010-08-19 16:06 --- Fixed (with an extended version of the patch attached above). -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29785
[Bug fortran/45016] Support pointer assignment with bound-spec; wrong bounds for pointer assignment
--- Comment #5 from domob at gcc dot gnu dot org 2010-08-19 16:07 --- Fixed the lower bounds remapping, and the F95 issue claimed was already working. Thus closing. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45016
[Bug lto/45343] New: LTO doesn't work with Boost on MinGW
This is with Boost 1.44.0.
C:\buggcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.5.1/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../src/configure --prefix=/c/temp/gcc/dest
--enable-languages=c,c++ --with-arch=i686 --with-tune=generic
--disable-libstdcxx-pch --disable-nls --disable-shared
--disable-sjlj-exceptions --disable-win32-registry --enable-checking=release
--enable-lto
Thread model: win32
gcc version 4.5.1 (GCC)
C:\bugtype foo.cpp
#include string
#include boost/format.hpp
using namespace std;
using namespace boost;
string foo(int n) {
return str(format(foo(%1%)) % n);
}
C:\bugtype bar.cpp
#include iostream
#include ostream
#include string
#include boost/format.hpp
using namespace std;
using namespace boost;
string foo(int n);
string bar(int n) {
return str(format(bar(%1%)) % n);
}
int main() {
cout foo(1) endl;
cout bar(2) endl;
}
C:\bugg++ -Wall -Wextra -E foo.cpp -o foo.ii
C:\bugg++ -Wall -Wextra -E bar.cpp -o bar.ii
C:\bugg++ -Wall -Wextra foo.ii bar.ii -o baz.exe
C:\bugbaz
foo(1)
bar(2)
C:\bugg++ -Wall -Wextra -flto foo.ii bar.ii -o baz.exe
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:404:13:
error:
'_ZThn32_N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_2io13too_many_argsD1Ev'
has already been defined
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:404:13:
note: previously defined here
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:305:13:
error:
'_ZThn12_N5boost16exception_detail19error_info_injectorINS_2io17bad_format_stringEED0Ev'
has already been defined
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:305:13:
note: previously defined here
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:404:13:
error:
'_ZThn12_N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_2io12too_few_argsD0Ev'
has already been defined
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:404:13:
note: previously defined here
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:305:13:
error:
'_ZThn12_N5boost16exception_detail19error_info_injectorINS_2io13too_many_argsEED1Ev'
has already been defined
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:305:13:
note: previously defined here
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:411:13:
error:
'_ZThn32_NK5boost16exception_detail10clone_implINS0_19error_info_injectorINS_2io17bad_format_string5cloneEv'
has already been defined
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:411:13:
note: previously defined here
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/format/alt_sstream.hpp:123:9:
error:
'_ZTv0_n12_N5boost2io22basic_oaltstringstreamIcSt11char_traitsIcESaIcEED1Ev'
has already been defined
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/format/alt_sstream.hpp:123:9:
note: previously defined here
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:404:13:
error:
'_ZThn12_N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_2io13too_many_argsD1Ev'
has already been defined
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:404:13:
note: previously defined here
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:411:13:
error:
'_ZThn32_NK5boost16exception_detail10clone_implINS0_19error_info_injectorINS_2io12too_few_args5cloneEv'
has already been defined
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:411:13:
note: previously defined here
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:305:13:
error:
'_ZThn12_N5boost16exception_detail19error_info_injectorINS_2io13too_many_argsEED0Ev'
has already been defined
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:305:13:
note: previously defined here
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:404:13:
error:
'_ZThn32_N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_2io17bad_format_stringD1Ev'
has already been defined
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:404:13:
note: previously defined here
c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.1/../../../../include/boost/exception/exception.hpp:404:13:
error:
[Bug lto/45343] LTO doesn't work with Boost on MinGW
--- Comment #1 from gordon dot magnusson at gmail dot com 2010-08-19 17:00 --- Created an attachment (id=21522) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21522action=view) Compressed preprocessed foo.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45343
[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated
--- Comment #13 from jason at gcc dot gnu dot org 2010-08-19 17:01 --- Subject: Bug 45307 Author: jason Date: Thu Aug 19 17:00:51 2010 New Revision: 163380 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163380 Log: PR c++/45307 * gimplify.c (gimplify_init_constructor): Just return GS_UNHANDLED if ctor is empty. (gimplify_modify_expr_rhs): Adjust. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/empty-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45307
[Bug c++/45315] [4.4/4.5/4.6 Regression] ICE: tree check: expected aggr_init_expr, have call_expr in build_value_init, at cp/init.c:317
--- Comment #3 from jason at gcc dot gnu dot org 2010-08-19 17:01 --- Subject: Bug 45315 Author: jason Date: Thu Aug 19 17:01:01 2010 New Revision: 163381 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163381 Log: PR c++/45315 * init.c (build_new_1): Don't use build_value_init in a template. (build_value_init): Make sure we don't. Added: trunk/gcc/testsuite/g++.dg/init/value8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45315
[Bug lto/45343] LTO doesn't work with Boost on MinGW
--- Comment #2 from gordon dot magnusson at gmail dot com 2010-08-19 17:01 --- Created an attachment (id=21523) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21523action=view) Compressed preprocessed bar.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45343
[Bug tree-optimization/42172] inefficient bit fields assignments
--- Comment #5 from bernds at gcc dot gnu dot org 2010-08-19 17:32 --- Subject: Bug 42172 Author: bernds Date: Thu Aug 19 17:31:57 2010 New Revision: 163383 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163383 Log: PR target/42172 * combine.c (combine_validate_cost): New arg I0. All callers changed. Take its cost into account if nonnull. (insn_a_feeds_b): New static function. (combine_instructions): Look for four-insn combinations. (can_combine_p): New args PRED2, SUCC2. All callers changed. Take them into account when computing all_adjacent and looking for other uses. (combinable_i3pat): New args I0DEST, I0_NOT_IN_SRC. All callers changed. Treat them like I1DEST and I1_NOT_IN_SRC. (try_combine): New arg I0. Handle four-insn combinations. (distribute_notes): New arg ELIM_I0. All callers changed. Treat it like ELIM_I1. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42172
[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-19 17:44 --- Subject: Bug 45336 Author: jakub Date: Thu Aug 19 17:43:50 2010 New Revision: 163384 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163384 Log: PR target/45336 * simplify-rtx.c (simplify_unary_operation_1): Optimize nested SIGN_EXTENDs or ZERO_EXTENDs. Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45336
[Bug fortran/45344] New: [4.5 Regression] Many Fortran test failures
On Linux/x86, gcc 4.5 revision 163296 gave: FAIL: gfortran.dg/gomp/appendix-a/a.35.4.f90 -O (test for warnings, line 11) FAIL: gfortran.dg/gomp/appendix-a/a.35.4.f90 -O (test for excess errors) FAIL: gfortran.dg/gomp/appendix-a/a.35.6.f90 -O (test for warnings, line 9) FAIL: gfortran.dg/gomp/appendix-a/a.35.6.f90 -O (test for excess errors) FAIL: libgomp.fortran/vla4.f90 -O0 (test for warnings, line 97) FAIL: libgomp.fortran/vla4.f90 -O0 (test for excess errors) FAIL: libgomp.fortran/vla4.f90 -O1 (test for warnings, line 97) FAIL: libgomp.fortran/vla4.f90 -O1 (test for excess errors) FAIL: libgomp.fortran/vla4.f90 -O2 (test for warnings, line 97) FAIL: libgomp.fortran/vla4.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/vla4.f90 -O3 -fomit-frame-pointer (test for warnings, line 97) FAIL: libgomp.fortran/vla4.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.fortran/vla4.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for warnings, line 97) FAIL: libgomp.fortran/vla4.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.fortran/vla4.f90 -O3 -fomit-frame-pointer -funroll-loops (test for warnings, line 97) FAIL: libgomp.fortran/vla4.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.fortran/vla4.f90 -O3 -g (test for warnings, line 97) FAIL: libgomp.fortran/vla4.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/vla4.f90 -Os (test for warnings, line 97) FAIL: libgomp.fortran/vla4.f90 -Os (test for excess errors) FAIL: libgomp.fortran/vla5.f90 -O0 (test for warnings, line 69) FAIL: libgomp.fortran/vla5.f90 -O0 (test for excess errors) FAIL: libgomp.fortran/vla5.f90 -O1 (test for warnings, line 69) FAIL: libgomp.fortran/vla5.f90 -O1 (test for excess errors) FAIL: libgomp.fortran/vla5.f90 -O2 (test for warnings, line 69) FAIL: libgomp.fortran/vla5.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/vla5.f90 -O3 -fomit-frame-pointer (test for warnings, line 69) FAIL: libgomp.fortran/vla5.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.fortran/vla5.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for warnings, line 69) FAIL: libgomp.fortran/vla5.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.fortran/vla5.f90 -O3 -fomit-frame-pointer -funroll-loops (test for warnings, line 69) FAIL: libgomp.fortran/vla5.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.fortran/vla5.f90 -O3 -g (test for warnings, line 69) FAIL: libgomp.fortran/vla5.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/vla5.f90 -Os (test for warnings, line 69) FAIL: libgomp.fortran/vla5.f90 -Os (test for excess errors) Revision 163291 is OK. -- Summary: [4.5 Regression] Many Fortran test failures Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45344
[Bug fortran/45344] [4.5 Regression] Many Fortran test failures
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-19 18:20 --- It is caused by revision 163293 http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00504.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45344
[Bug bootstrap/45345] New: In function `mips16_build_function_stub' undefined reference to `ASM_OUTPUT_DEF'
I've reproduced this native and cross. /home/jay/src/gcc-4.5.1/configure -disable-nls -disable-bootstrap -prefix=/home/jay/gcc451 : In function `mips16_build_function_stub': : undefined reference to `ASM_OUTPUT_DEF' collect2: ld returned 1 exit status gmake[2]: *** [cc1-dummy] Error 1 gmake[2]: Leaving directory `/home/jay/obj/gcc451/gcc' gmake[1]: *** [all-gcc] Error 2 gmake[1]: Leaving directory `/home/jay/obj/gcc451' gmake: *** [all] Error 2 $ pwd /home/jay/obj/gcc451 $ uname -a OpenBSD mobsd.my.domain 4.7 GENERIC#2 loongson -- Summary: In function `mips16_build_function_stub' undefined reference to `ASM_OUTPUT_DEF' Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jay dot krell at cornell dot edu GCC target triplet: mips64el-unknown-openbsd4.7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45345
[Bug fortran/45344] [4.5 Regression] Many Fortran test failures
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.5.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45344
[Bug plugins/45346] New: hard-reg-set.h needs to be in the plugin include directory
I am trying to build a plugin that uses cgraph.h, which is in the plugin directory. But cgraph.h needs function.h and function.h needs hard-reg-set.h. hard-reg-set.h is not in the plugin include directory. The test case is to build a plugin where the plugin uses the header file cgraph.h or function.h. I believe this started failing at r159776 when Paul Brook added the include of hard-reg-set.h into function.h -- Summary: hard-reg-set.h needs to be in the plugin include directory Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45346
[Bug fortran/45344] [4.5 Regression] Many Fortran test failures
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-19 18:24:48 date|| Target Milestone|4.5.3 |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45344
[Bug target/45250] [4.6 Regression] FAIL: tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/check_nan.cc
--- Comment #1 from danglin at gcc dot gnu dot org 2010-08-19 18:26 --- Introduced by following change: 2010-07-22 Martin Jambor mjam...@suse.cz PR tree-optimization/44891 * tree-sra.c: Include gimple-pretty-print.h. (replace_uses_with_default_def_ssa_name): Renamed to get_repl_default_def_ssa_name, return the new SSA name instead of replacing the old one. (sra_modify_assign): Dump a message when removing a load, if the LHS is an SSA_NAME, do not do any propagation, just set the RHS to a default definition SSA NAME, type convert if necessary. * Makefile.in (tree-sra.o): Add gimple-pretty-print.h to dependencies. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||mjambor at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45250
[Bug target/45250] [4.6 Regression] FAIL: tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/check_nan.cc
--- Comment #2 from danglin at gcc dot gnu dot org 2010-08-19 18:33 --- (In reply to comment #1) Introduced by following change: 2010-07-22 Martin Jambor mjam...@suse.cz PR tree-optimization/44891 * tree-sra.c: Include gimple-pretty-print.h. (replace_uses_with_default_def_ssa_name): Renamed to get_repl_default_def_ssa_name, return the new SSA name instead of replacing the old one. (sra_modify_assign): Dump a message when removing a load, if the LHS is an SSA_NAME, do not do any propagation, just set the RHS to a default definition SSA NAME, type convert if necessary. * Makefile.in (tree-sra.o): Add gimple-pretty-print.h to dependencies. Sorry Martin, I must be blind... http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01959.html -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC|mjambor at suse dot cz | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45250
[Bug bootstrap/45345] In function `mips16_build_function_stub' undefined reference to `ASM_OUTPUT_DEF'
--- Comment #1 from jay dot krell at cornell dot edu 2010-08-19 18:37 --- Probably missing stuff in config.gcc, tm_file, like elfos.h and/or mips/elf.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45345
[Bug plugins/45346] hard-reg-set.h needs to be in the plugin include directory
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-19 18:48 --- Patch to add it is pre-approved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45346
[Bug lto/45343] LTO doesn't work with Boost on MinGW
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-19 18:59 --- Can you try with a recent snapshot for GCC 4.6? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45343
[Bug libstdc++/45347] New: concurrence.h: In constructor '__gnu_cxx::__cond::__cond()': /home/jayk/obj/gcc451/alphaev67-dec-osf5.1/libstdc++-v3/include/ext/concurrence.h:276:29: warning: missing init
Just a warning, not an error. /home/jayk/obj/gcc451/alphaev67-dec-osf5.1/libstdc++-v3/include/ext/concurrence.h: In constructor '__gnu_cxx::__cond::__cond()': /home/jayk/obj/gcc451/alphaev67-dec-osf5.1/libstdc++-v3/include/ext/concurrence.h:276:29: warning: missing initializer for member '__pthread_cond_t::__block' bash-4.1$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/jayk/libexec/gcc/alphaev67-dec-osf5.1/4.5.0/lto-wrapper Target: alphaev67-dec-osf5.1 Configured with: /home/jayk/src/gcc-4.5.0/configure -disable-nls -prefix=/home/jayk Thread model: posix gcc version 4.5.0 (GCC) bash-4.1$ uname -a OSF1 hostname V5.1 732 alpha alpha Tru64 -- Summary: concurrence.h: In constructor '__gnu_cxx::__cond::__cond()': /home/jayk/obj/gcc451/alphaev67-dec-osf5.1/libstdc++- v3/include/ext/concurrence.h:276:29: warning: missing initializer for member '__pthread_cond_t::__bloc Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jay dot krell at cornell dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45347
[Bug target/45336] pextr{b,w,d}, (worse than) redundant extensions
--- Comment #6 from tbptbp at gmail dot com 2010-08-19 19:21 ---
Subject: Re: pextr{b,w,d}, (worse than) redundant extensions
Thank you very much for this neat patch, Jakub.
Alas, in this case, zero extension would be suboptimal and any sign
extension simply wrong: i ask for a 64bit something, pextr{b,w,d}
already zero extends.
What i have trouble understanding is why there is so much inertia
fixing builtins (to match hardware and return, say, an unsigned
byte/short/int) when nobody's supposed to use those builtins but GCC
itself. I bet you could then still have those corresponding intrinsics
sign extend, even if no one's actually doing that, not even ICC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45336
[Bug middle-end/45325] [4.6 Regression] target attribute doesn't work with -march=i586
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-19 19:38 --- It is caused by revision 162918: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00129.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325
[Bug middle-end/45325] [4.6 Regression] target attribute doesn't work with -march=i586
--- Comment #5 from rth at gcc dot gnu dot org 2010-08-19 19:48 --- (In reply to comment #3) Well, I think we should back out support for that option. The set of nonsensical options doesn't include sse - but all options are included in the set of broken options. At least I expect that you can create a testcase with such ICEs for every one. Not every one, just those that expand the set of valid backend modes. Thus sse3 will not cause additional ice's, assuming sse2 is in effect globally. That's not to say this feature isn't fraught with peril. I think it should be improved though, not removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325
[Bug plugins/45346] hard-reg-set.h needs to be in the plugin include directory
--- Comment #2 from steven at gcc dot gnu dot org 2010-08-19 20:24 --- Gross. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45346
[Bug plugins/45346] hard-reg-set.h needs to be in the plugin include directory
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-19 20:28 --- The proper fix for this is not to just go back to the include everything everywhere. The proper fix is instead to move struct rtl_data out of function.h (as I have said before) and into e.g. emit-rtl.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45346
[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-08-19 20:28 --- Subject: Bug 45108 Author: jvdelisle Date: Thu Aug 19 20:28:09 2010 New Revision: 163387 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163387 Log: 2010-08-19 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/45108 * io/list_read.c (namelist_read): If namelist reading fails, use generate_error and then continue the read loop. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108
[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-08-19 20:32 --- Closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108
[Bug plugins/45348] New: cp/cp-tree.h in plugin header does not work.
If you include the header file cp/cp-tree.h in a plugin it will not compile because cp/cp-tree.h includes c-family/c-common.h which cannot be found. c-common.h is in the plugin directory but not under the c-family directory. It looks like the makefile tries to flatten the directory structure when putting headers in the plugin directory which is why c-common.h is in plugin/include and not plugin/include/c-family. I don't know if cp/cp-tree.h should be changed or if the Makefile should be changed. Test case ia a plugin that includes cp/cp-tree.h. -- Summary: cp/cp-tree.h in plugin header does not work. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45348
[Bug fortran/45143] [F2008,corrig1] Endless loop with unlimited edit descriptor
--- Comment #4 from burnus at gcc dot gnu dot org 2010-08-19 20:54 --- Do you want to backport it to 4.5? Or can the PR be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45143
[Bug c++/45349] New: template function specializations are not recognized when the template is implemented in a header, and optimization is on.
Define a prototype for a template function in a class definition and include the default implementation in the header. In a separate cpp file, create a specialization of the template function. When the function is called that matches the specialization, normally the specialized function is called, unless the g++ optimizations (-On ) are turned on. Then the specialization is out of scope, and the default template implementation is called: compile the attached code as follows: g++ special.cpp smain.cpp then run the result: ./a.out # Specialized! # Template function! Now do the same with optimization: g++ -O3 special.cpp smain.cpp and run again: ./a.out # Specialized! # Template function! With optimization on, the specialization is not called. NOTE: This does NOT occur if the class declaration is in the source modue (.cpp), only when it's included from an external header (.h). -- Summary: template function specializations are not recognized when the template is implemented in a header, and optimization is on. Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tyler dot packer at landesk dot com GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45349
[Bug c++/45349] template function specializations are not recognized when the template is implemented in a header, and optimization is on.
--- Comment #1 from tyler dot packer at landesk dot com 2010-08-19 21:36 --- Created an attachment (id=21524) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21524action=view) tar.gz of source and temporaries source tarball -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45349
[Bug c++/45349] template function specializations are not recognized when the template is implemented in a header, and optimization is on.
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-08-19 21:38 --- This is invalid code IIRC and does not requires a diagnostic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45349
[Bug c++/45349] template function specializations are not recognized when the template is implemented in a header, and optimization is on.
--- Comment #3 from tyler dot packer at landesk dot com 2010-08-19 21:40 --- Also included in the attachment is s2.cpp wich is an duplicate example of the specialization in a single module. This sample when compiled does NOT exhibit the same problem as when the class declaration (and template function) occurs in a header. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45349
[Bug c++/45349] template function specializations are not recognized when the template is implemented in a header, and optimization is on.
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-19 21:41 --- specialization is required to be done visible in the translation unit when the use is used IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45349
[Bug c++/45349] template function specializations are not recognized when the template is implemented in a header, and optimization is on.
--- Comment #5 from tyler dot packer at landesk dot com 2010-08-19 21:46 --- (In reply to comment #4) specialization is required to be done visible in the translation unit when the use is used IIRC. Makes sense, however I would assume it would work the same way when optimized (-O3). Is that not correct? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45349
[Bug c++/45349] template function specializations are not recognized when the template is implemented in a header, and optimization is on.
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-19 21:53 --- No, it's not. Your testcase violates the ODR and inlining makes that visible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45349
