[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir
--- Comment #7 from gschafer at zip dot com dot au 2008-03-16 06:41 --- (In reply to comment #6) As a workaround can you try using all of the sysroot framework? Thanks for looking at this Carlos. But the sysroot stuff is not really suited to a non /usr layout. For example, with my --prefix=/temptools scenario, the sysrooted toolchain will go looking for: /temptools/usr/include /temptools/usr/lib /temptools/lib whereas my layout is: /temptools/include /temptools/lib And just to reiterate, according to http://gcc.gnu.org/install/configure.html the sysroot options apply *only* when building cross compilers. I know that Alan Modra said he now builds sysrooted compilers on native hosts, so maybe the GCC install docs need to be changed? Configure with --with-sysroot=/mnt/foo and --with-build-sysroot=/mnt/foo. Build with LDFLAGS_FOR_TARGET=--sysroot=/mnt/foo and CPPFLAGS_FOR_TARGET=--sysroot=/mnt/foo. Ok, I went ahead and tried with the above. The build system appears not to care that the sysroot framework was in use on a native build. Great. However, it doesn't work for my scenario. The build crapped out somewhere in fixincludes: The directory that should contain system headers does not exist: /temptools/usr/include make[2]: *** [stmp-fixinc] Error 1 If I fudge past that error by doing a `mkdir /temptools/usr/include', it gets a little further but craps out again: In file included from ../../../gcc-4.3.0/libgcc/../gcc/libgcc2.c:33: ../../../gcc-4.3.0/libgcc/../gcc/tsystem.h:90:19: error: stdio.h: No such file or directory ../../../gcc-4.3.0/libgcc/../gcc/tsystem.h:93:23: error: sys/types.h: No such file or directory ../../../gcc-4.3.0/libgcc/../gcc/tsystem.h:96:19: error: errno.h: No such file or directory ../../../gcc-4.3.0/libgcc/../gcc/tsystem.h:103:20: error: string.h: No such file or directory ../../../gcc-4.3.0/libgcc/../gcc/tsystem.h:104:20: error: stdlib.h: No such file or directory ../../../gcc-4.3.0/libgcc/../gcc/tsystem.h:105:20: error: unistd.h: No such file or directory ../../../gcc-4.3.0/libgcc/../gcc/tsystem.h:111:18: error: time.h: No such file or directory make[2]: *** [_muldi3.o] Error 1 As mentioned above, the sysroot stuff is clearly designed for a file system layout with /usr and DESTDIR style installs ie: /sysroot/usr/include /sysroot/usr/lib /sysroot/lib Oh well. T'was worth a try. I'm reading through the DIY instructions right now to make sense of your bootstrap process. I have a feeling that slotting in a -B $prefix/lib somewhere in the *FLAGS_FOR_TARGET could potentially solve my problem. Except that -B currently doesn't process the multilibs.. damn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
[Bug fortran/35470] Valid pointer assigment code gives compilation errors
--- Comment #7 from pault at gcc dot gnu dot org 2008-03-16 07:15 --- (In reply to comment #6) You r 'this' is better than my 'Think' Passed regression testing here on x86-64. Jerry, I did not see that you were working on it - sorry that I trampled on your toes. I took a copy of this the moment that it was posted to keep me amused during a meeting. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35470
[Bug rtl-optimization/35604] New: Label references are not updated after edge insertion
This problem can be seen by compiling testsuite/gfortran.dg/g77/ndrm2.f. The
label reference (after x87 stack compensation edge is inserted) is updated only
in final jump insn, but other references to the same label are left untouched.
We enter stack pass with:
(insn:TI 19 20 18 4 dnrm2.f:33 (set (reg/v/f:SI 1 dx [orig:73 next.2 ] [73])
(label_ref:SI 53)) 47 {*movsi_1} (expr_list:REG_EQUAL (label_ref:SI 53)
(insn_list:REG_LABEL_OPERAND 53 (nil
...
(insn 23 137 17 4 dnrm2.f:40 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v/f:SI 1 dx [orig:73 next.2 ] [73])
(label_ref:SI 53))) 5 {*cmpsi_1_insn} (insn_list:REG_LABEL_OPERAND
53 (nil)))
...
(jump_insn 24 245 355 4 dnrm2.f:40 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 53)
(pc))) 579 {*jcc_1} (expr_list:REG_DEAD (reg:CCZ 17 flags)
(expr_list:REG_BR_PROB (const_int 1500 [0x5dc])
(nil
;; End of basic block 4 - ( 13 5)
;; lr out 1 [dx] 3 [bx] 4 [si] 6 [bp] 7 [sp] 11 [st(3)] 12 [st(4)] 20
[frame]
;; live out 1 [dx] 3 [bx] 4 [si] 6 [bp] 7 [sp] 12 [st(4)] 20 [frame]
;; Succ edge 13 [15.0%] (can_fallthru)
;; Succ edge 5 [85.0%] (fallthru,can_fallthru)
Where the target code label is in BB13:
;; Pred edge 4 [15.0%] (can_fallthru)
;; Pred edge 12 [15.0%] (fallthru,can_fallthru)
(code_label/s:HI 53 325 54 13 3 (__label_30) [6 uses])
(note:HI 54 53 59 13 [bb 13] NOTE_INSN_BASIC_BLOCK)
The BB is inserted on edge between bb4 and bb13, the target code label is now
label 435 in bb37:
;; Start of basic block ( 4) - 37
;; bb 37 artificial_defs: { }
;; bb 37 artificial_uses: { u-1(6){ }u-1(7){ }}
;; Pred edge 4 [15.0%] (can_fallthru)
(code_label 435 433 434 37 31 [1 uses])
(note 434 435 381 37 [bb 37] NOTE_INSN_BASIC_BLOCK)
(insn 381 434 380 37 (set (reg:DF 9 st(1))
(reg:DF 8 st)) -1 (expr_list:REG_DEAD (reg:DF 8 st)
(nil)))
(note 380 381 53 37 NOTE_INSN_DELETED)
;; End of basic block 37 - ( 13)
;; Succ edge 13 [100.0%] (fallthru)
===
However, the problem is, that (insn 19) and (insn 23) still point to old label,
producing effectively wrong code:
movl$.L3, %edx #, next.2
movl$1, %ebx#, ix
sall$3, %eax#,
cmpl$.L3, %edx #, next.2
movl$1, -28(%ebp) #, i
fldz
movl%eax, -20(%ebp) #,
je .L31#,
This works only by pure luck.
However, with my experimental patch that produces fused compare-and-branch (a
feature of core2 processor), we enter stack pass with:
(jump_insn:TI 24 245 354 4 dnrm2.f:40 (set (pc)
(if_then_else (eq (reg/v/f:SI 1 dx [orig:73 next.2 ] [73])
(label_ref:SI 53))
(label_ref 53)
(pc))) 581 {*jcc_fused_1} (insn_list:REG_LABEL_OPERAND 53
(expr_list:REG_BR_PROB (const_int 1500 [0x5dc])
(nil
All label references are updated in a fused jump insn after edge insertion, so
this partially updated sequence is produced:
(insn 19 137 17 4 dnrm2.f:33 (set (reg/v/f:SI 1 dx [orig:73 next.2 ] [73])
(label_ref:SI 53)) 47 {*movsi_1} (expr_list:REG_EQUAL (label_ref:SI 53)
(insn_list:REG_LABEL_OPERAND 53 (nil
...
(jump_insn:TI 24 245 354 4 dnrm2.f:40 (set (pc)
(if_then_else (eq (reg/v/f:SI 1 dx [orig:73 next.2 ] [73])
(label_ref:SI 434))
(label_ref:SI 434)
(pc))) 581 {*jcc_fused_1} (insn_list:REG_LABEL_OPERAND 53
(expr_list:REG_BR_PROB (const_int 1500 [0x5dc])
(nil
leading to:
movl$.L3, %edx
movl$1, -28(%ebp)
movl$1, %ebx
fldz
movl%eax, -20(%ebp)
.p2align 4,,7
cmpl$.L31, %edx
je .L31# fused
This is still wrong code, but triggers a testsuite failure. And by changing
$.L3 into $.L31, the test succeeds also with fused compare and branch.
The conclusion is, that updating only jump insn is not enough, but all label
references should be updated to newly inserted label when edge is inserted into
control flow.
--
Summary: Label references are not updated after edge insertion
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35604
[Bug rtl-optimization/35605] New: Label references are not updated after edge insertion
This problem can be seen by compiling testsuite/gfortran.dg/g77/ndrm2.f. The
label reference (after x87 stack compensation edge is inserted) is updated only
in final jump insn, but other references to the same label are left untouched.
We enter stack pass with:
(insn:TI 19 20 18 4 dnrm2.f:33 (set (reg/v/f:SI 1 dx [orig:73 next.2 ] [73])
(label_ref:SI 53)) 47 {*movsi_1} (expr_list:REG_EQUAL (label_ref:SI 53)
(insn_list:REG_LABEL_OPERAND 53 (nil
...
(insn 23 137 17 4 dnrm2.f:40 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v/f:SI 1 dx [orig:73 next.2 ] [73])
(label_ref:SI 53))) 5 {*cmpsi_1_insn} (insn_list:REG_LABEL_OPERAND
53 (nil)))
...
(jump_insn 24 245 355 4 dnrm2.f:40 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0
--
Summary: Label references are not updated after edge insertion
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35605
[Bug c++/35606] New: Unresolved #pragma weak prevents all function aliasing in C++
Compiling this simple C++ file: #pragma weak my_weak_function extern C void my_function_to_be_renamed (void) asm (my_renamed_function); gives me the warning foo.cc:2: warning: asm declaration ignored due to conflict with previous rename This does not make sense, as there is no previous rename. Worse, the warning is telling the truth: the asm declaration really is ignored, and the function is not renamed as it should be. What is happening is that start_decl calls maybe_apply_pragma_weak before it sees the rename. Since there is a pending unresolved weak declaration, maybe_apply_pragma_weak calls decl_assembler_name on the newly created decl. This has the effect of assigning the name to the decl. When the C++ frontend gets around to applying the rename from the asm, it sees that the assembler name has already been assigned. Hence the warning, and hence the rename is ignored. This does not happen with the C frontend because the C frontend calls maybe_apply_pragma_weak from finish_decl, after the asm rename has been applied. Perhaps a similar patch would work for the C++ frontend. I haven't tried it. -- Summary: Unresolved #pragma weak prevents all function aliasing in C++ Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35606
[Bug fortran/35582] [4.1/4.2] very simple error gives segmentation fault
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-03-16 10:06 --- Subject: Bug 35582 Author: dfranke Date: Sun Mar 16 10:05:18 2008 New Revision: 133270 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133270 Log: 2008-03-16 Daniel Franke [EMAIL PROTECTED] PR fortran/35582 * gfortran.dg/write_invalid_format.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/write_invalid_format.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35582
[Bug fortran/35582] [4.1/4.2] very simple error gives segmentation fault
--- Comment #5 from dfranke at gcc dot gnu dot org 2008-03-16 10:07 --- Added testcase to testsuite. Backport unlikely as 4.3.0 (which works) is released and manpower is limited. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35582
[Bug rtl-optimization/35605] Label references are not updated after edge insertion
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-16 10:57 --- *** This bug has been marked as a duplicate of 35604 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35605
[Bug rtl-optimization/35604] Label references are not updated after edge insertion
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-16 10:57 --- *** Bug 35605 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35604
[Bug tree-optimization/35607] New: [4.4 Regression] IVOPTs produces invalid gimple
extern void (*__fini_array_start []) (void);
extern void (*__fini_array_end []) (void);
void
__libc_csu_fini (void)
{
__SIZE_TYPE__ i = __fini_array_end - __fini_array_start;
while (i-- 0)
(*__fini_array_start [i]) ();
}
./cc1 -quiet elf-init.i -O
elf-init.i: In function '__libc_csu_fini':
elf-init.i:5: error: invalid array index
(unsigned int) D.1189_5;
elf-init.i:5: internal compiler error: verify_stmts failed
The offending stmt is
# ivtmp.16_1 = PHI ivtmp.16_11(5), __fini_array_start[(unsigned int)
D.1189_5](3)
it eventually should have used i_6 which is available as
i_6 = (unsigned int) D.1189_5;
working in rev. 133101, failing since at least rev. 133134. which includes
the fix for PR31358 which is likely the cause.
--
Summary: [4.4 Regression] IVOPTs produces invalid gimple
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
OtherBugsDependingO 31358
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35607
[Bug tree-optimization/35607] [4.4 Regression] IVOPTs produces invalid gimple
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-16 11:45 --- force_gimple_operand doesn't gimplify __fini_array_start[(unsigned int) D.1189_5] because is_gimple_min_invariant returns true for it. And the verification failure is just an artifact of that. I have a patch. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-16 11:45:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35607
[Bug tree-optimization/35607] [4.4 Regression] IVOPTs produces invalid gimple
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-16 11:47 --- Hm, no. This address isn't invariant at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35607
[Bug tree-optimization/35607] [4.4 Regression] IVOPTs produces invalid gimple
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-16 12:20 --- This invariantness of (unsigned int) D.1189_5 in __fini_array_end.0_2 = (int) __fini_array_end; __fini_array_start.1_3 = (int) __fini_array_start; D.1188_4 = __fini_array_end.0_2 - __fini_array_start.1_3; D.1189_5 = D.1188_4 /[ex] 4; i_6 = (unsigned int) D.1189_5; which is then substituted into the array reference __fini_array_start[i_25] and turned into an address induction variable is there since gimplification. Because gimplification preserves the invariantness of what originally was unsigned int i = (unsigned int) (((int) __fini_array_end - (int) __fini_array_start) /[ex] 4); that is, gimplification does _not_ re-set TREE_INVARIANT on anything that had it set before. Which is, err, bogus - sort of. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35607
[Bug tree-optimization/35607] [4.4 Regression] IVOPTs produces invalid gimple
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-16 12:23 --- The concrete problem with allowing foo[(int)z_4] in a PHI node argument is that we cannot cope with immediate uses in PHI nodes and thus DCE z_4 and end up with a reference to a deleted SSA_NAME during expansion (yeah, we don't go out-of-SSA for it either). So this is a non-option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35607
[Bug tree-optimization/35607] [4.4 Regression] IVOPTs produces invalid gimple
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-16 12:32 --- One solution is to, in expand_simple_operations, expand all TREE_INVARIANT operations so we end up with # ivtmp.16_1 = PHI ivtmp.16_11(5), __fini_array_start[(unsigned int) (((int) __fini_array_end - (int) __fini_array_start) /[ex] 4)](3) instead which we can let pass verification without fatal effects. The other solution is to kill TREE_INVARIANT from everything but constants and invariant addresses during gimplification. Anyone with other options? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35607
[Bug fortran/35152] Implicit procedure with keyword=argument is accepted
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/fortra ||n/2008-03/msg00103.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2008-03-16 12:51:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35152
[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-03-16 13:01 --- $ gfortran-svn -v Target: i686-pc-linux-gnu gcc version 4.4.0 20080315 (experimental) (GCC) $ gfortran-svn -g -Wall -W transfer_assumed_size_1.f90 $ valgrind --tool=memcheck --leak-check=full a.out [...] ==6291== Invalid read of size 1 ==6291==at 0x4023A83: memmove (mc_replace_strmem.c:516) ==6291==by 0x8048C12: __transferbug_MOD_bytestostring (transfer_assumed_size_1.f90:31) ==6291==by 0x80493A0: MAIN__ (transfer_assumed_size_1.f90:41) ==6291==by 0x80494A8: main (fmain.c:21) ==6291== Address 0x425067b is 13 bytes before a block of size 2 free'd ==6291==at 0x402248F: free (vg_replace_malloc.c:323) ==6291==by 0x804912E: __transferbug_MOD_stringtobytes (transfer_assumed_size_1.f90:21) ==6291==by 0x8049383: MAIN__ (transfer_assumed_size_1.f90:41) ==6291==by 0x80494A8: main (fmain.c:21) ==6291== ==6291== Invalid read of size 1 ==6291==at 0x4023A90: memmove (mc_replace_strmem.c:516) ==6291==by 0x8048C12: __transferbug_MOD_bytestostring (transfer_assumed_size_1.f90:31) ==6291==by 0x80493A0: MAIN__ (transfer_assumed_size_1.f90:41) ==6291==by 0x80494A8: main (fmain.c:21) ==6291== Address 0x4250679 is 15 bytes before a block of size 2 free'd ==6291==at 0x402248F: free (vg_replace_malloc.c:323) ==6291==by 0x804912E: __transferbug_MOD_stringtobytes (transfer_assumed_size_1.f90:21) ==6291==by 0x8049383: MAIN__ (transfer_assumed_size_1.f90:41) ==6291==by 0x80494A8: main (fmain.c:21) [...] -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
[Bug fortran/35234] Undetected use before definition.
--- Comment #1 from dominiq at lps dot ens dot fr 2008-03-16 13:46 --- Reduced test case: program prandtl meyer implicit none integer :: i, j integer, parameter :: imax = 100 integer, parameter :: jmax = 40 real, dimension(0:jmax,0:imax) :: f1, f1_bar do i = 0, imax-1 do j = 1, jmax-1 f1_bar(j,i+1) = f1(j,i) end do end do stop end program prandtl meyer [ibook-dhum] f90/bug% gfc -O -Wuninitialized -Wall timing/prandtl_red.f [ibook-dhum] f90/bug% I think it is a duplicate of PR27120. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35234
[Bug c/35608] New: gcc.c-torture/compile/limits-structnest.c fails -O2 -Os
The gcc.c-torture/compile/limits-structnest.c started to fail at revision 133270. It was OK at 133177. Native configuration is i686-pc-linux-gnu === gcc tests === Running target unix FAIL: gcc.c-torture/compile/limits-structnest.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/limits-structnest.c -Os (test for excess errors) XPASS: gcc.dg/cpp/cmdlne-dI-M.c scan-file (^|n)cmdlne-dI-M.*:[^n]*cmdlne-dI-M.c XPASS: gcc.dg/cpp/cmdlne-dM-M.c scan-file (^|n)cmdlne-dM-M[^n]*:[^n]*cmdlne-dM-M.c === gcc Summary === # of expected passes49125 # of unexpected failures2 # of unexpected successes 2 # of expected failures 166 # of untested testcases 35 # of unsupported tests 269 : Compiler version: 4.4.020080316(experimental)(GCC) Platform: i686-pc-linux-gnu configure flags: -v --enable-languages=c,c++,fortran --enable-shared --with-syst em-zlib --without-included-gettext --enable-threads=posix --enable-nls --enable- __cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enabl e-checking=release --with-arch=core2 -- Summary: gcc.c-torture/compile/limits-structnest.c fails -O2 -Os Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jrp at dial dot pipex dot com GCC build triplet: 4.4.0 20080316 (experimental) (GCC) GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35608
[Bug tree-optimization/35607] [4.4 Regression] IVOPTs produces invalid gimple
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-16 15:45 --- Subject: Bug 35607 Author: rguenth Date: Sun Mar 16 15:45:09 2008 New Revision: 133273 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133273 Log: 2008-03-16 Richard Guenther [EMAIL PROTECTED] PR middle-end/35607 * tree-ssa-loop-niter.c (expand_simple_operations): Do not expand TREE_INVARIANT operations that are not gimple invariant. * gcc.c-torture/compile/pr35607.c: New testcase. * gcc.dg/tree-ssa/loop-19.c: Use -O2 to avoid vectorization. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr35607.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-19.c trunk/gcc/tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35607
[Bug debug/31510] [4.3/4.4 Regression] FAIL: libgomp.fortran/threadprivate[23].f90 -O3 -g
--- Comment #6 from danglin at gcc dot gnu dot org 2008-03-16 15:48 --- Subject: Bug 31510 Author: danglin Date: Sun Mar 16 15:48:09 2008 New Revision: 133274 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133274 Log: PR debug/31510 * dbxout.c (dbxout_expand_expr, case VAR_DECL): Return NULL for emulated thread local variables. Modified: trunk/gcc/ChangeLog trunk/gcc/dbxout.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31510
[Bug debug/31510] [4.3/4.4 Regression] FAIL: libgomp.fortran/threadprivate[23].f90 -O3 -g
--- Comment #7 from danglin at gcc dot gnu dot org 2008-03-16 15:50 --- Subject: Bug 31510 Author: danglin Date: Sun Mar 16 15:49:55 2008 New Revision: 133275 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133275 Log: PR debug/31510 * dbxout.c (dbxout_expand_expr, case VAR_DECL): Return NULL for emulated thread local variables. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/dbxout.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31510
[Bug debug/31510] [4.3/4.4 Regression] FAIL: libgomp.fortran/threadprivate[23].f90 -O3 -g
--- Comment #8 from danglin at gcc dot gnu dot org 2008-03-16 15:51 --- Fixed by change. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31510
[Bug c/35608] gcc.c-torture/compile/limits-structnest.c fails -O2 -Os
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-16 15:55 --- What is the excess error (look in the gcc/testsuite/gcc/gcc.log file)? usually this test blows memory/stack, so possibly just gets killed by the kernel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35608
[Bug fortran/34714] ICE-on-invalid in gfc_conv_descriptor_dtype
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-03-16 15:55 --- function func2() type(bar) func2 allocate(func1%baz(1)) end function In primary.c(match_variable), case FL_PROCEDURE, we here have a function that satisfies the first if-clause, but does not trigger the second. Hence, code-flow squirrels down to the handling of variables, instead of bailing out with an not-a-variable error. Btw, if func1 is defined with a RESULT variable instead, we produce the expected error ^^ -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-16 20:36:53 |2008-03-16 15:55:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34714
[Bug tree-optimization/35607] [4.4 Regression] IVOPTs produces invalid gimple
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-03-16 15:55 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35607
[Bug c/35608] gcc.c-torture/compile/limits-structnest.c fails -O2 -Os
--- Comment #2 from jrp at dial dot pipex dot com 2008-03-16 16:07 --- PASS: gcc.c-torture/compile/limits-structnest.c -O1 (test for excess errors) Executing on host: /home/jrp/build/gcc/xgcc -B/home/jrp/build/gcc/ -O2 -w -fn o-show-column -c -o limits-structnest.o /home/jrp/gcc/gcc/testsuite/gcc.c-tortu re/compile/limits-structnest.c(timeout = 300) xgcc: Internal error: Killed (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: xgcc: Internal error: Killed (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35608
[Bug rtl-optimization/34999] Fallthru crossing edges in partition_hot_cold_basic_blocks are not been fixed when the section ends with call insn
--- Comment #18 from danglin at gcc dot gnu dot org 2008-03-16 16:27 --- Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/pr34999.c -O2 -freorder-blocks-a nd-partition -fprofile-use -D_PROFILE_USE -fno-show-column -lm -o /test/gnu/g cc/objdir/gcc/testsuite/gcc/pr34999.x02(timeout = 300) ld: An unknown relocation type 8 was encountered when applying the relocation fo r symbol .text.unlikely at offset 0x15c in section index 1 of file /var/tmp//c cFqB2Ph.o 1 errors. collect2: ld returned 1 exit status compiler exited with status 1 output is: ld: An unknown relocation type 8 was encountered when applying the relocation fo r symbol .text.unlikely at offset 0x15c in section index 1 of file /var/tmp//c cFqB2Ph.o 1 errors. collect2: ld returned 1 exit status FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE I believe the linker is complaining about the R_PARISC_PCREL12F relocation used in this branch. 15c: 9f f3 20 00 cmpb,*= r19,r31,164 main+0x134 Thought this hot and cold stuff was disabled on hppa as it breaks a lot of stuff. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999
[Bug target/34652] arm-only miscompilation of alloca code
--- Comment #2 from mikpe at it dot uu dot se 2008-03-16 16:49 --- (In reply to comment #1) This happens with 4.1, 4.2 and trunk on old ABI. Apparently it doesn't happen with EABI. I see the problem too, on Linux/ARM/OABI with gcc-4.1.2. However, the problem is in the test case itself. Specifically the attempt to align _b: if (((unsigned long)_b)sizeof(_b)) _b++; _b is void*, so this is if (_b 4) _b += 1; at the machine level, which is totally bogus. Om my machine alloca() returned 0xbea1d97c (a multiple of 4 but not of 8), which this code changed to 0xbea1d97d. The following uses of _b as a pointer caused numerous alignment exceptions (logged by the kernel). On the other machines I tested this on (sparc, powerpc, x86), alloca() returned an address that was a multiple of 8, so the bogus alignment code didn't trigger. If you want to align _b to a multiple of 2*sizeof(void*), do something like: _b = (void*)(((unsigned long)_b + 2*sizeof(void*)-1) ~(2*sizeof(void*)-1)); Not a gcc bug, IMO. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34652
[Bug testsuite/35538] FAIL: gcc.dg/tree-ssa/ssa-store-ccp-4.c scan-tree-dump-times optimized conststaticvariable 1
--- Comment #12 from danglin at gcc dot gnu dot org 2008-03-16 16:49 --- On hppa64-hp-hpux11.11, FAIL: gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized conststa ticvariable 1 The tree dump is the same as for darwin. This target is always pic. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35538
[Bug c++/28639] [4.2 regression] ICE trying to print error on invalid template parameter
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code Priority|P4 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
[Bug c++/30299] [4.2 regression] ICE with broken template and inheritance
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.0 Priority|P4 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30299
[Bug target/34652] arm-only miscompilation of alloca code
--- Comment #3 from schwab at suse dot de 2008-03-16 17:17 --- Not a bug. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34652
[Bug ada/31108] [4.2 regression] ACATS C35507M fails
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-03-16 17:17 --- What is the status on the 4.3 branch and the trunk? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug c++/31131] [4.2 regression] ICE on invalid constructor definition
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.0 Priority|P4 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31131
[Bug c++/31446] [4.2 regression] ICE with invalid template parameter
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.0 Priority|P4 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31446
[Bug c++/31747] [4.2 Regression] ICE combining static and extern
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.0 Priority|P4 |P5 Summary|[4.2 regression] ICE|[4.2 Regression] ICE |combining static and extern |combining static and extern http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31747
[Bug middle-end/31947] [4.2 Regression] ICE in calc_dfs_tree, at dominance.c:374
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.0 4.2.1 4.2.2 |4.2.0 4.2.1 4.2.2 4.2.3 Priority|P1 |P2 Last reconfirmed|2007-12-27 16:55:53 |2008-03-16 17:21:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-03-16 17:29 --- This will not be fixed on the 4.2 branch. Closing as fixed in 4.3.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.2.1 |4.2.1 4.2.3 4.2.4 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
[Bug tree-optimization/32891] [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-16 17:32 --- This will not be fixed on the 4.2 branch. Closing as fixed for 4.3.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.2.4 Known to work||4.3.0 Resolution||FIXED Target Milestone|4.2.4 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32891
[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.4 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
[Bug c++/33841] [4.2 regression] ICE with non-integral bit-field
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.3 Known to work||4.3.0 Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33841
[Bug tree-optimization/34006] [4.2 Regression] vectorization with 64-bit integers
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |tree-optimization Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34006
[Bug fortran/35470] Valid pointer assigment code gives compilation errors
--- Comment #8 from pault at gcc dot gnu dot org 2008-03-16 19:15 --- Subject: Bug 35470 Author: pault Date: Sun Mar 16 19:14:17 2008 New Revision: 133279 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133279 Log: 2008-03-16 Paul Thomas [EMAIL PROTECTED] PR fortran/35470 * resolve.c (check_assumed_size_reference): Only visit the first reference and look directly at the highest dimension. 2008-03-16 Paul Thomas [EMAIL PROTECTED] PR fortran/35470 * gfortran.dg/subref_array_pointer_3.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/subref_array_pointer_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35470
[Bug fortran/35470] Valid pointer assigment code gives compilation errors
--- Comment #9 from pault at gcc dot gnu dot org 2008-03-16 19:15 --- Fixed on trunk Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35470
[Bug c/35609] New: [4.3/4.4 Regression] bogus is used uninitialized in this function warning
-- snip --
$ cat test.c
int foo, bar;
void decode_reloc(int reloc, int *is_alt)
{
if (reloc = 20)
*is_alt = 1;
else if (reloc = 10)
*is_alt = 0;
}
void testfunc()
{
int alt_reloc;
decode_reloc(foo, alt_reloc);
if (alt_reloc)
bar = 42;
}
$ gcc -O2 -Wall -c test.c
test.c: In function âtestfuncâ:
test.c:17: warning: âalt_relocâ is used uninitialized in this function
$
-- snip --
A may be used uninitialized in this function warning might be appropriate
here, but gcc seems to wrongly think it can prove alt_reloc was for sure
uninitialized here.
--
Summary: [4.3/4.4 Regression] bogus is used uninitialized in
this function warning
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35609
ruth
some athwartanyone it apportion
[Bug tree-optimization/35609] [4.3/4.4 Regression] is used uninitialized in this function should be may warning
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 Regression] bogus |[4.3/4.4 Regression] is |is used uninitialized in |used uninitialized in this |this function warning |function should be may ||warning Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35609
[Bug tree-optimization/35609] [4.3/4.4 Regression] is used uninitialized in this function should be may warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-16 21:30 --- So Jump threading comes along and threads the jump for some reason makes the PHI node go away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35609
[Bug tree-optimization/35609] [4.3/4.4 Regression] is used uninitialized in this function should be may warning
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-16 21:32 ---
The warning works as designed, the PHI node in question that causes the
warning only has a single incoming edge:
testfunc ()
{
int alt_reloc;
int foo.0;
bb 2:
foo.0_1 = foo;
if (foo.0_1 19)
goto bb 5;
else
goto bb 3;
bb 3:
if (foo.0_1 9)
goto bb 6;
else
goto bb 4;
bb 4:
if (alt_reloc_4(D) != 0)
goto bb 5;
else
goto bb 6;
bb 5:
bar = 42;
bb 6:
return;
}
we don't check whether the uninitialized use post-dominates the function
entry. I don't know if we should.
This is just a case of 4.3 optimizing better than 4.2 which makes the
warning less precise.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-03-16 21:32:33
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35609
[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.
--- Comment #11 from gnu_andrew at member dot fsf dot org 2008-03-16 22:29 --- Created an attachment (id=15332) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15332action=view) Move towards a CPStringBuilder-using code base -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
[Bug preprocessor/35610] New: Pasting foo and ( does not give a valid preprocessing token
MSVC++ from 2003 to 2008 and comeau compiler v4.9.3b gives no errors about
that:
//-
#define CAT(a,b) a ## b
void foo(int a) {}
void foo(int a,int b) {}
int main() {
CAT(foo,(1)); //error
CAT(foo,(1,2)); //error
return 0;
}
//-
--
Summary: Pasting foo and ( does not give a valid
preprocessing token
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andry at inbox dot ru
GCC host triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35610
[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.
--- Comment #12 from gnu_andrew at member dot fsf dot org 2008-03-16 22:45 --- Created an attachment (id=15333) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15333action=view) Move towards a CPStringBuilder-using code base -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
[Bug preprocessor/35610] Pasting foo and ( does not give a valid preprocessing token
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-16 22:46 --- Yes and GCC behavior is correct. pasting foo and ( don't make a valid preprocessing token. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|Pasting foo and ( does |Pasting foo and ( does |not give a valid|not give a valid |preprocessing token |preprocessing token http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35610
[Bug preprocessor/35610] Pasting foo and ( does not give a valid preprocessing token
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-16 22:49 --- ## only works to form a valid token, if it does not, then the code is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35610
[Bug libmudflap/28188] dynamic linkage error for shared libraries compiled and linked against libmudflapth
--- Comment #1 from starlight at binnacle dot cx 2008-03-16 22:49 --- Hit this same issue. The problem is likely that the -fvisibility=hidden option is also on the compile line. Removing it makes the problem go away, at least for single-threaded mudflap. Produced with gcc 4.2.3, x86_64 under CentOS 4.6. -- starlight at binnacle dot cx changed: What|Removed |Added CC||starlight at binnacle dot cx http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28188
[Bug preprocessor/35610] Pasting foo and ( does not give a valid preprocessing token
--- Comment #3 from andry at inbox dot ru 2008-03-16 22:56 --- (In reply to comment #2) ## only works to form a valid token, if it does not, then the code is invalid. When i can understand which token is valid then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35610
[Bug preprocessor/35610] Pasting foo and ( does not give a valid preprocessing token
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-16 23:06 --- (In reply to comment #3) When i can understand which token is valid then? By reading the C/C++ standards :). But basically in this case foo and ( are two different tokens. Examples of valid tokens: -, foo, ., ,, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35610
[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.
--- Comment #13 from gnu_andrew at member dot fsf dot org 2008-03-16 23:37 --- Created an attachment (id=15334) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15334action=view) Move towards a CPStringBuilder-using code base -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.
--- Comment #14 from gnu_andrew at member dot fsf dot org 2008-03-17 00:37 --- Created an attachment (id=15335) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15335action=view) Abstract reflection elements of CPStringBuilder to a VM class -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.
--- Comment #15 from gnu_andrew at member dot fsf dot org 2008-03-17 01:30 --- Created an attachment (id=15336) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15336action=view) Move towards a CPStringBuilder-using code base -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
[Bug libgomp/35611] New: FAIL: libgomp.c/omp-nested-1.c execution test
Executing on host: /home/dave/gnu/gcc-4.4/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4.4/objdir/gcc/ /home/dave/gnu/gcc-4.4/gcc/libgomp/testsuite/libgomp.c/omp-nested-1.c -B/home/dave/gnu/gcc-4.4/objdir/hppa-linux/./libgomp/ -I/home/dave/gnu/gcc-4.4/objdir/hppa-linux/./libgomp -I/home/dave/gnu/gcc-4.4/gcc/libgomp/testsuite/.. -fmessage-length=0 -fopenmp -O2 -L/home/dave/gnu/gcc-4.4/objdir/hppa-linux/./libgomp/.libs -lgomp -lm -o ./omp-nested-1.exe(timeout = 300) PASS: libgomp.c/omp-nested-1.c (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/dave/gnu/gcc-4.4/objdir/hppa-linux/./libgomp/.libs:/home/dave/gnu/gcc-4.4/objdir/gcc:.:/home/dave/gnu/gcc-4.4/objdir/hppa-linux/./libgomp/.libs:/home/dave/gnu/gcc-4.4/objdir/gcc:/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libstdc++-v3/.libs:/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libmudflap/.libs:/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libssp/.libs:/home/dave/gnu/gcc-4.4/objdir/hppa-linux/libgomp/.libs:/home/dave/gnu/gcc-4.4/objdir/./gcc:/home/dave/gnu/gcc-4.4/objdir/./prev-gcc:/usr/lib/debug FAIL: libgomp.c/omp-nested-1.c execution test -- Summary: FAIL: libgomp.c/omp-nested-1.c execution test Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35611
[Bug libgomp/35611] FAIL: libgomp.c/omp-nested-1.c execution test
--- Comment #1 from danglin at gcc dot gnu dot org 2008-03-17 02:16 --- The test didn't fail in revision 133125. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35611
[Bug libgomp/35611] [4.3/4.4 Regression] FAIL: libgomp.c/omp-nested-1.c execution test
--- Comment #2 from danglin at gcc dot gnu dot org 2008-03-17 02:29 --- Same failure is also present on hppa2.0w-hp-hpux11.11 (4.3.1) and hppa64-hp-hpux11.11 (4.4.0). There are quite a few other libgomp fails that are probably the same bug. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Summary|FAIL: libgomp.c/omp-nested- |[4.3/4.4 Regression] FAIL: |1.c execution test |libgomp.c/omp-nested-1.c ||execution test http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35611
[Bug fortran/35612] New: testsuite ISO_C_BIND code error
bind_c_usage_8.f03 in gcc/testsuite/gfortran.dg contains:
! PR fortran/32797
!
MODULE ISO_C_UTILITIES
USE ISO_C_BINDING
implicit none
CHARACTER(C_CHAR), DIMENSION(1), SAVE, TARGET, PRIVATE :: dummy_string=?
CONTAINS
FUNCTION C_F_STRING(CPTR) RESULT(FPTR)
use, intrinsic :: iso_c_binding
TYPE(C_PTR), INTENT(IN) :: CPTR ! The C address
CHARACTER(KIND=C_CHAR), DIMENSION(:), POINTER :: FPTR
INTERFACE
FUNCTION strlen(string) RESULT(len) BIND(C,NAME=strlen) ! {
dg-warning Implicitly declared }
USE ISO_C_BINDING
TYPE(C_PTR), VALUE :: string ! A C pointer
END FUNCTION
END INTERFACE
CALL C_F_POINTER(FPTR=FPTR, CPTR=CPTR, SHAPE=[strlen(CPTR)])
END FUNCTION
END MODULE ISO_C_UTILITIES
! { dg-final { cleanup-modules iso_c_utilities } }
The line:
TYPE(C_PTR), INTENT(IN) :: CPTR ! The C address
should be:
TYPE(C_PTR), VALUE, TARGET:: CPTR ! the C address
--
Summary: testsuite ISO_C_BIND code error
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danp57 at optonline dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35612
[Bug fortran/35613] New: testsuite ISO_C_BIND code error
bind_c_usage_8.f03 in gcc/testsuite/gfortran.dg contains:
! PR fortran/32797
!
MODULE ISO_C_UTILITIES
USE ISO_C_BINDING
implicit none
CHARACTER(C_CHAR), DIMENSION(1), SAVE, TARGET, PRIVATE :: dummy_string=?
CONTAINS
FUNCTION C_F_STRING(CPTR) RESULT(FPTR)
use, intrinsic :: iso_c_binding
TYPE(C_PTR), INTENT(IN) :: CPTR ! The C address
CHARACTER(KIND=C_CHAR), DIMENSION(:), POINTER :: FPTR
INTERFACE
FUNCTION strlen(string) RESULT(len) BIND(C,NAME=strlen) ! {
dg-warning Implicitly declared }
USE ISO_C_BINDING
TYPE(C_PTR), VALUE :: string ! A C pointer
END FUNCTION
END INTERFACE
CALL C_F_POINTER(FPTR=FPTR, CPTR=CPTR, SHAPE=[strlen(CPTR)])
END FUNCTION
END MODULE ISO_C_UTILITIES
! { dg-final { cleanup-modules iso_c_utilities } }
The line:
TYPE(C_PTR), INTENT(IN) :: CPTR ! The C address
should be:
TYPE(C_PTR), VALUE, TARGET:: CPTR ! the C address
--
Summary: testsuite ISO_C_BIND code error
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danp57 at optonline dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35613
[Bug libgomp/35614] New: libgomp info documentation file is in the wrong category
Traditionally it is accepted to pug GNU library info documentation files into Libraries category. libgomp info file goes into GNU Libraries category. The following patch fixes the bug: --- libgomp.texi.old2008-03-17 00:07:13.0 -0400 +++ libgomp.texi2008-03-17 00:07:25.0 -0400 @@ -30,7 +30,7 @@ @end copying @ifinfo [EMAIL PROTECTED] GNU Libraries [EMAIL PROTECTED] Libraries @direntry * libgomp: (libgomp).GNU OpenMP runtime library @end direntry It should be applied to http://gcc.gnu.org/viewcvs/trunk/libgomp/libgomp.texi -- Summary: libgomp info documentation file is in the wrong category Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: petrosyan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35614
[Bug libgomp/35614] libgomp info documentation file is in the wrong category
-- petrosyan at gmail dot com changed: What|Removed |Added Severity|normal |trivial http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35614
