[Bug target/38344] [4.3 Regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-12-06 08:11
---
r142149 | ebotcazou | 2008-11-24 09:36:43 +0100 (Mon, 24 Nov 2008) | 4 lines
* df-scan.c (df_get_call_refs): For unconditional noreturn calls
add EH_USES regs as artificial uses.
(df_get_entry_block_def_set): Don't handle EH_USES here.
This patch is a no-op on anything else than IA-64 anyway:
[EMAIL PROTECTED]:~/svn/gcc-4_3-branch/gcc grep -r --exclude=*svn*
--exclude=*ChangeLog* EH_USES .
./doc/tm.texi:@defmac EH_USES (@var{regno})
./doc/tm.texi:TARGET_STRUCT_VALUE_RTX, FRAME_POINTER_REGNUM, EH_USES,
./config/m32c/m32c.h:#define EH_USES(REGNO) 0 /* FIXME */
./config/ia64/ia64.h:#define EH_USES(REGNO) ia64_eh_uses (REGNO)
./df-scan.c:#ifdef EH_USES
./df-scan.c: BOTTOM of the block with noreturn call, as EH_USES registers
need
./df-scan.c:if (EH_USES (i))
./df-scan.c:#ifdef EH_USES
./df-scan.c:if (EH_USES (i))
./df-problems.c:#ifdef EH_USES
./df-problems.c:#ifdef EH_USES
./df-problems.c: /* Create the chains for the artificial uses from the EH_USES
at the
./dce.c:#ifdef EH_USES
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38344
[Bug middle-end/38422] [4.4 Regression] union/bitfield causes cc1/cc1plus to run out of memory.
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-06 08:28 --- Likely caused by PR35422. Endless recursion, always fold_converting the same type and operand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38422
[Bug target/38344] [4.3 Regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-12-06 08:32 --- And I cannot reproduce with a cross: [EMAIL PROTECTED]:~/build/gcc-4_3-branch/arm-linux-gnueabi gcc/cc1plus -quiet -nostdinc++ -v -g -O2 -Wswitch-enum -Wextra -Wall -version -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -fPIC link.ii ignoring nonexistent directory /home/eric/install/gcc-4_3-branch/lib/gcc/arm-linux-gnueabi/4.3.3/include ignoring nonexistent directory /home/eric/install/gcc-4_3-branch/lib/gcc/arm-linux-gnueabi/4.3.3/include-fixed ignoring nonexistent directory /home/eric/install/gcc-4_3-branch/lib/gcc/../../arm-linux-gnueabi/sys-include ignoring nonexistent directory /home/eric/install/gcc-4_3-branch/lib/gcc/../../arm-linux-gnueabi/include #include ... search starts here: #include ... search starts here: End of search list. GNU C++ (GCC) version 4.3.3 20081205 (prerelease) [gcc-4_3-branch revision 142479] (arm-linux-gnueabi) compiled by GNU C version 4.2.1 (SUSE Linux), GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: d154bbd8150682481739de030e4f70a8 [EMAIL PROTECTED]:~/build/gcc-4_3-branch/arm-linux-gnueabi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38344
[Bug middle-end/38074] [4.4 Regression] missed inlining on Core2 Duo due to apparent wrong branch prediction/profile
--- Comment #12 from hubicka at gcc dot gnu dot org 2008-12-06 08:35 --- Subject: Bug 38074 Author: hubicka Date: Sat Dec 6 08:34:20 2008 New Revision: 142517 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142517 Log: PR tree-optimization/38074 * cgraphbuild.c (compute_call_stmt_bb_frequency): Fix handling of 0 entry frequency. * predict.c (combine_predictions_for_bb): Ignore predictor predicting in both dirrection for first match heuristics. (tree_bb_level_predictions): Disable noreturn heuristic when there is no returning path. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphbuild.c trunk/gcc/predict.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38074
[Bug tree-optimization/38224] libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold
--- Comment #3 from edwintorok at gmail dot com 2008-12-06 08:37 --- This got fixed somewhere between r142405 and r142487, because r142487 has bootstrapped successfully. -- edwintorok at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38224
[Bug middle-end/38074] [4.4 Regression] missed inlining on Core2 Duo due to apparent wrong branch prediction/profile
--- Comment #13 from jakub at gcc dot gnu dot org 2008-12-06 08:59 --- Fixed, thanks. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38074
[Bug tree-optimization/38224] libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-06 09:00 --- Reopening... -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38224
[Bug middle-end/38371] Fold check error during bootstrap
--- Comment #5 from jakub at gcc dot gnu dot org 2008-12-06 09:01 --- *** Bug 38224 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||edwintorok at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38371
[Bug tree-optimization/38224] libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold
--- Comment #5 from jakub at gcc dot gnu dot org 2008-12-06 09:01 --- To close as dup of PR38371. *** This bug has been marked as a duplicate of 38371 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38224
[Bug fortran/38425] New: I/O: POS= compile-time diagnostics
Cf. http://gcc.gnu.org/ml/fortran/2008-12/msg00043.html !-- character(len=30) :: str open(3,access='stream') ! C919 (R913) If io-unit is not a file-unit-number, the ! io-control-spec-list shall not contain a REC= specifier ! or a POS= specifier. write(str,*, pos=4) 5 ! C927 (R913) If a POS= specifier appears, the ! io-control-spec-list shall not contain a REC= specifier. write(3,pos=5,rec=4) 5 !Fortran runtime error: REC=specifier must be positive write(3,rec=-3) 44 !Fortran runtime error: POS=specifier must be positive write(3,pos=-4) 44 end -- Summary: I/O: POS= compile-time diagnostics Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38425
[Bug c/8960] Segfault with __attribute__ ((mode (...))) in start_function:5702
--- Comment #12 from tkoenig at gcc dot gnu dot org 2008-12-06 09:37 --- Still present with current trunk. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-07-22 04:05:50 |2008-12-06 09:37:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8960
[Bug middle-end/38426] New: Incorrect code produced with -momit-leaf-frame-pointer -fno-unit-at-a-time
GCC-4.4 [EMAIL PROTECTED]: pushl %ebp pushl %edi pushl %esi pushl %ebx subl$28, %esp movl-2100956, %ebx movl56(%ebx), %ebp %ebp is used as a spare register in a non-leaf function. -- Summary: Incorrect code produced with -momit-leaf-frame-pointer - fno-unit-at-a-time Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38426
[Bug middle-end/38426] Incorrect code produced with -momit-leaf-frame-pointer -fno-unit-at-a-time
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2008-12-06 09:52 --- Created an attachment (id=16839) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16839action=view) Preprocessed source mingw32-gcc -S -Os -momit-leaf-frame-pointer -fno-unit-at-a-time win32.i C source: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/win32.c?revision=37615content-type=text%2Fplain -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38426
[Bug middle-end/38422] [4.4 Regression] union/bitfield causes cc1/cc1plus to run out of memory.
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-06 10:03 --- http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00389.html -- 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|NEW |ASSIGNED Last reconfirmed|2008-12-06 02:53:20 |2008-12-06 10:03:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38422
[Bug libstdc++/38421] libstdc++-v3/include/tr1/ell_integral.tcc contains __ea identifier
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-06 10:22 --- Let's take care of this. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-06 10:22:08 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38421
[Bug libstdc++/38421] libstdc++-v3/include/tr1/ell_integral.tcc contains __ea identifier
--- Comment #2 from paolo at gcc dot gnu dot org 2008-12-06 10:26 --- Subject: Bug 38421 Author: paolo Date: Sat Dec 6 10:25:24 2008 New Revision: 142519 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142519 Log: 2008-12-06 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/38421 * include/tr1/ell_integral.tcc: Avoid __ea, future SPU badname. * doc/xml/manual/appendix_contributing.xml: Add __ea to the list of badnames. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/xml/manual/appendix_contributing.xml trunk/libstdc++-v3/include/tr1/ell_integral.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38421
[Bug libstdc++/38421] libstdc++-v3/include/tr1/ell_integral.tcc contains __ea identifier
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-06 10:27 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38421
[Bug c/27007] Missed optimization of comparison with 'limited range'
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-12-06 10:51 ---
This is now fixed:
$ cat foo.c
int foo(unsigned char x)
{
return (x+1) != 0;
}
$ gcc -O3 -fdump-tree-optimized -S foo.c
$ cat foo.s
.file foo.c
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
pushl %ebp
movl$1, %eax
movl%esp, %ebp
popl%ebp
ret
.size foo, .-foo
.ident GCC: (GNU) 4.4.0 20081122 (experimental)
.section.note.GNU-stack,,@progbits
$ cat foo.c.123t.optimized
;; Function foo (foo)
Analyzing Edge Insertions.
foo (unsigned char x)
{
bb 2:
return 1;
}
I'm not sure how to write a test case for this.
Should it just be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27007
[Bug fortran/38425] I/O: POS= compile-time diagnostics
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-06 11:05 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-06 11:05:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38425
[Bug c/27007] Missed optimization of comparison with 'limited range'
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-12-06 11:05 --- Yep. Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail||4.2.4 Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27007
[Bug c++/38424] ice: segmentation fault
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-06 11:10 --- It seems that this was fixed recently (works for me with r142437). I can confirm this crash with r141893. Please update your tree and verify the problem is fixed. If not, re-open this bug. Thanks. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38424
[Bug c++/38427] New: crash for reference init code
I just tried to compile the following C++ source code
with the GNU C compiler version 4.4 snapshot 20081205.
struct S
{
int ref;
S() : ref() {
};
};
The compiler said
$ ~/gcc/20081205/results/bin/g++ jun17.cc
jun17.cc: In constructor 'S::S()':
jun17.cc:5: warning: default-initialization of 'int S::ref', which has
reference type
jun17.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Here is valgrind helping out with a stack backtrace
==32646== Invalid read of size 2
==32646==at 0x54A935: cp_gimplify_expr (cp-gimplify.c:435)
==32646==by 0x6FB6F4: gimplify_expr (gimplify.c:6255)
==32646==by 0x704DD6: gimplify_stmt (gimplify.c:5006)
==32646==by 0x705E4B: gimplify_cleanup_point_expr (gimplify.c:4808)
==32646==by 0x6FC164: gimplify_expr (gimplify.c:6576)
==32646==by 0x704DD6: gimplify_stmt (gimplify.c:5006)
==32646==by 0x7058B5: gimplify_bind_expr (gimplify.c:1264)
==32646==by 0x6FBF36: gimplify_expr (gimplify.c:6430)
==32646==by 0x704DD6: gimplify_stmt (gimplify.c:5006)
==32646==by 0x704EBD: gimplify_body (gimplify.c:7226)
==32646==by 0x7051B4: gimplify_function_tree (gimplify.c:7304)
==32646==by 0x58B259: c_genericize (c-gimplify.c:107)
==32646== Address 0x0 is not stack'd, malloc'd or (recently) free'd
This code used to compile ok on snapshot 20081128
--
Summary: crash for reference init code
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
GCC host triplet: suse-linux-x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38427
[Bug c++/38427] [4.4 Regression] crash for reference init code
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-12-06 12:03 --- Confirmed. It would be error-recovery if GCC rejected the code as required (2.95.4 rejects it). Default-initialization of references is not valid. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid, ice-on- ||invalid-code Known to work||2.95.4 4.3.2 Last reconfirmed|-00-00 00:00:00 |2008-12-06 12:03:39 date|| Summary|crash for reference init|[4.4 Regression] crash for |code|reference init code Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38427
[Bug fortran/38415] procedure pointer assignment to abstract interface
--- Comment #2 from janus at gcc dot gnu dot org 2008-12-06 12:17 --- Subject: Bug 38415 Author: janus Date: Sat Dec 6 12:15:49 2008 New Revision: 142520 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142520 Log: 2008-12-06 Janus Weil [EMAIL PROTECTED] PR fortran/38415 * expr.c (gfc_check_pointer_assign): Added a check for abstract interfaces in procedure pointer assignments, removed check involving gfc_compare_interfaces until PR38290 is fixed completely. 2008-12-06 Janus Weil [EMAIL PROTECTED] PR fortran/38415 * gfortran.dg/proc_ptr_2.f90: Extended. * gfortran.dg/proc_ptr_11.f90: Modified. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38415
[Bug fortran/38415] procedure pointer assignment to abstract interface
--- Comment #3 from janus at gcc dot gnu dot org 2008-12-06 12:18 --- Fixed with r142520. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38415
[Bug fortran/38290] procedure pointer assignment checking
--- Comment #6 from janus at gcc dot gnu dot org 2008-12-06 12:23 --- Reopening. The check for comparing the interfaces was taken out again in r142520, since there were problems with intrinsics. Details will follow. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug fortran/38290] procedure pointer assignment checking
--- Comment #7 from burnus at gcc dot gnu dot org 2008-12-06 12:25 --- Check backed out in PR 38415, cf. http://gcc.gnu.org/ml/fortran/2008-12/msg00089.html I'm afraid I'll have to remove the gfc_compare_interfaces check in gfc_check_pointer_assign again, since I just noticed that it has lots of problems with intrinsics (both in lvalue and rvalue) -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|janus at gcc dot gnu dot org|burnus at gcc dot gnu dot ||org Status|REOPENED|ASSIGNED Last reconfirmed|2008-12-02 11:46:51 |2008-12-06 12:25:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug c/38428] New: ice for Linux kernel code with -O2
I just tried to compile the Linux kernel version 2.6.27.7 with the GNU C compiler version 4.4 snapshot 20081205. The compiler said drivers/scsi/qla2xxx/qla_os.c: In function 'qla2x00_free_device': drivers/scsi/qla2xxx/qla_os.c:1809: internal compiler error: in gimple_rhs_has_side_effects, at gimple.c:2343 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O2 required. -- Summary: ice for Linux kernel code with -O2 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38428
[Bug c/38428] ice for Linux kernel code with -O2
--- Comment #1 from dcb314 at hotmail dot com 2008-12-06 12:28 --- Created an attachment (id=16840) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16840action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38428
[Bug middle-end/38422] [4.4 Regression] union/bitfield causes cc1/cc1plus to run out of memory.
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-06 12:48 --- Subject: Bug 38422 Author: jakub Date: Sat Dec 6 12:47:15 2008 New Revision: 142521 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142521 Log: PR middle-end/38422 * fold-const.c (fold_unary) CASE_CONVERT: Don't convert MULT_EXPR operands to mult_type if it isn't narrower than op0's type. * gcc.c-torture/execute/pr38422.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr38422.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38422
[Bug c/38428] ice for Linux kernel code with -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-06 12:50 --- reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38428
[Bug middle-end/38422] [4.4 Regression] union/bitfield causes cc1/cc1plus to run out of memory.
--- Comment #5 from jakub at gcc dot gnu dot org 2008-12-06 12:49 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38422
[Bug middle-end/38428] [4.4 Regression] ice for Linux kernel code with -O2
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Keywords||ice-on-valid-code Known to work||4.3.2 Summary|ice for Linux kernel code |[4.4 Regression] ice for |with -O2|Linux kernel code with -O2 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38428
[Bug middle-end/38428] [4.4 Regression] ice for Linux kernel code with -O2
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-12-06 13:05 ---
typedef unsigned int __u32;
typedef __u32 uint32_t;
typedef struct {
volatile struct {
uint32_t online : 1;
} flags;
} scsi_qla_host_t;
int qla2x00_wait_for_hba_online(scsi_qla_host_t *ha) {
int return_status;
scsi_qla_host_t *pha = to_qla_parent(ha);
if (pha-flags.online)
return_status = (0x4000 0x3fff);
else
return_status = 0x102;
return (return_status);
}
--
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-12-06 13:05:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38428
[Bug middle-end/38428] [4.4 Regression] ice for Linux kernel code with -O2
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-06 13:06 --- Apparently caused by my PR37248 patch. We have a volatile bitfield, and the patch (similarly to 4.3) creates a TREE_THIS_VOLATILE TREE_SIDE_EFFECTS BIT_FIELD_REF, but apparently the trunk is upset about it. Either we just don't try to optimize volatile bitfields at all (don't create BIT_FIELD_REFs for them), or some changes are needed to handle volatile BIT_FIELD_REFs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38428
[Bug debug/36748] scev const-prop pass adds bad line numbers
--- Comment #2 from jan dot kratochvil at redhat dot com 2008-12-06 13:22 --- It looks fixed in 4.4 for me, tested on: GNU C (GCC) version 4.4.0 20081202 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20081202 (experimental), GMP version 4.2.2, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Line 13 in .line_debug is now assigned only to the main address (in Fedora gcc-4.3.2-7.x86_64 it was assigned also to the factorial address). Expecting it got fixed by Jakub Jelinek as a part of the Bug 36690. -- jan dot kratochvil at redhat dot com changed: What|Removed |Added CC||jan dot kratochvil at redhat ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36748
[Bug fortran/38290] procedure pointer assignment checking
--- Comment #8 from janus at gcc dot gnu dot org 2008-12-06 13:57 --- Created an attachment (id=16841) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16841action=view) patch v1 Here is a draft patch which correctly copies the typespec and formal args for a PROCEDURE statement with INTRINSIC interface. It also makes gfc_compare_interfaces work with intrinsics and re-enables the interface check for procedure pointer assignments. Stuff like the following should work now: procedure(iabs),pointer::p1 procedure(f), pointer::p2 ! valid p1 = iabs p2 = iabs p1 = f p2 = f p2 = p1 p1 = p2 ! invalid p1 = abs p2 = abs contains integer function f(x) integer :: x f = 317 end function end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug debug/36748] scev const-prop pass adds bad line numbers
--- Comment #3 from drow at gcc dot gnu dot org 2008-12-06 15:18 --- I tried 4.4.0 20081130; it does not look fixed. bb 8: # mult_acc.14_40 = PHI mult_acc.14_17(6) [break.c : 12] D.2737_41 = value_13 + -1; [break.c : 12] D.2738_42 = (unsigned int) D.2674_12; [break.c : 12] D.2739_43 = 2 - D.2738_42; [break.c : 12] D.2740_44 = (int) D.2739_43; value_39 = D.2737_41 + D.2740_44; There are no references to code on line 13 or 25, which are the opening braces. But those lines are now associated with line 12 and 24, which are the declarations of main and factorial respectively. The references are still introduced by scev. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36748
[Bug debug/36748] scev const-prop pass adds bad line numbers
-- drow 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-12-06 15:19:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36748
[Bug target/38306] [4.4 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-06 15:37 --- If the code layout (see comment #2) is indeed causing the slow-down, this problem might have been fixed along with bug 38074. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug tree-optimization/33928] [4.3/4.4 Regression] 22% performance slowdown from 4.2.2 to 4.3/4.4.0 in floating-point code
--- Comment #39 from lucier at math dot purdue dot edu 2008-12-06 16:37 --- I may have narrowed down the problem a bit. With this compiler (revision 118491): pythagoras-277% /tmp/lucier/install/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../../mainline/configure --enable-checking=release --prefix=/tmp/lucier/install --enable-languages=c Thread model: posix gcc version 4.3.0 20061105 (experimental) one gets (on a faster machine than previous reports) (time (direct-fft-recursive-4 a table)) 133 ms real time 140 ms cpu time (140 user, 0 system) no collections 64 bytes allocated no minor faults no major faults With this compiler (revision 118474): pythagoras-24% /tmp/lucier/install/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../../mainline/configure --enable-checking=release --prefix=/tmp/lucier/install --enable-languages=c Thread model: posix gcc version 4.3.0 20061104 (experimental) one gets (time (direct-fft-recursive-4 a table)) 116 ms real time 108 ms cpu time (108 user, 0 system) no collections 64 bytes allocated no minor faults no major faults and you see the typical problem with assembly code from direct.i with the later compiler. Paolo may have been right about fwprop, this patch was installed that day: Author: bonzini Date: Sat Nov 4 08:36:45 2006 New Revision: 118475 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118475 Log: 2006-11-03 Paolo Bonzini [EMAIL PROTECTED] Steven Bosscher [EMAIL PROTECTED] * fwprop.c: New file. * Makefile.in: Add fwprop.o. * tree-pass.h (pass_rtl_fwprop, pass_rtl_fwprop_with_addr): New. * passes.c (init_optimization_passes): Schedule forward propagation. * rtlanal.c (loc_mentioned_in_p): Support NULL value of the second parameter. * timevar.def (TV_FWPROP): New. * common.opt (-fforward-propagate): New. * opts.c (decode_options): Enable forward propagation at -O2. * gcse.c (one_cprop_pass): Do not run local cprop unless touching jumps. * cse.c (fold_rtx_subreg, fold_rtx_mem, fold_rtx_mem_1, find_best_addr, canon_for_address, table_size): Remove. (new_basic_block, insert, remove_from_table): Remove references to table_size. (fold_rtx): Process SUBREGs and MEMs with equiv_constant, make simplification loop more straightforward by not calling fold_rtx recursively. (equiv_constant): Move here a small part of fold_rtx_subreg, do not call fold_rtx. Call avoid_constant_pool_reference to process MEMs. * recog.c (canonicalize_change_group): New. * recog.h (canonicalize_change_group): New. * doc/invoke.texi (Optimization Options): Document fwprop. * doc/passes.texi (RTL passes): Document fwprop. Added: trunk/gcc/fwprop.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/common.opt trunk/gcc/cse.c trunk/gcc/doc/invoke.texi trunk/gcc/doc/passes.texi trunk/gcc/gcse.c trunk/gcc/opts.c trunk/gcc/passes.c trunk/gcc/recog.c trunk/gcc/recog.h trunk/gcc/rtlanal.c trunk/gcc/timevar.def trunk/gcc/tree-pass.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug bootstrap/38300] [4.4 Regression] libstdc++ and libgcj contain a reference to _Unwind_GetIPInfo
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-12-06 16:49 --- Remember we don't want to match darwin10. Mike Stump recommended recently that not worrying about darwin1 and darwin2 would be okay. So the alternative would be... *-*-darwin[3-8]|*-*-darwin[3-8].*) ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38300
[Bug bootstrap/38300] [4.4 Regression] libstdc++ and libgcj contain a reference to _Unwind_GetIPInfo
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-12-06 16:53 --- Ignore my last comment. I misread the proposed syntax. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38300
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #1 from sabre at nondot dot org 2008-12-06 18:42 --- This is a bug in the C front-end. They need to use __builtin_choose_expr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug fortran/38425] I/O: POS= compile-time diagnostics
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-12-06 18:43 --- On it -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-12-06 11:05:21 |2008-12-06 18:43:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38425
[Bug target/38306] [4.4 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
--- Comment #11 from jv244 at cam dot ac dot uk 2008-12-06 18:54 --- (In reply to comment #10) If the code layout (see comment #2) is indeed causing the slow-down, this problem might have been fixed along with bug 38074. No, timings are still identical: gcc version 4.4.0 20081206 (experimental) [trunk revision 142525] (GCC) Time for evaluation [s]:5.028 gcc version 4.3.3 20080912 (prerelease) (GCC) Time for evaluation [s]:4.376 (note that the regression is on opteron) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #2 from joseph at codesourcery dot com 2008-12-06 19:09 --- Subject: Re: __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression On Sat, 6 Dec 2008, sabre at nondot dot org wrote: This is a bug in the C front-end. They need to use __builtin_choose_expr. No, it's a bug in the C++ front end, at least as regards the initializer. It's expressly documented that this is allowed in initializers. See also my note in http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01061.html about how what should be allowed with __builtin_constant_p goes beyond what I put in my formal models of desired constant expression semantics for GCC in 2004. If you get this wrong for C then GCC will fail to bootstrap, as it's part of the GNU C semantics GCC relies on when being built with GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug fortran/38430] New: [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails
With revision 142513 these test passed. From revision 142516 and on, these tests have failed as follows (together with related tests: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/dg.exp ... ... FAIL: gfortran.dg/streamio_1.f90 -O0 execution test FAIL: gfortran.dg/streamio_10.f90 -O0 execution test FAIL: gfortran.dg/streamio_14.f90 -O0 execution test FAIL: gfortran.dg/streamio_14.f90 -O1 execution test FAIL: gfortran.dg/streamio_16.f90 -O0 execution test FAIL: gfortran.dg/streamio_2.f90 -O0 execution test FAIL: gfortran.dg/streamio_6.f90 -O0 execution test FAIL: gfortran.dg/streamio_8.f90 -O0 execution test With the messages in the logfile being all similar: PASS: gfortran.dg/streamio_1.f90 -O0 (test for excess errors) At line 13 of file /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/streamio_1.f90 (unit = 11, file = 'fort.11')^M Fortran runtime error: POS=specifier too large^M FAIL: gfortran.dg/streamio_1.f90 -O0 execution test Remember, this is one of those targets with no truncation support (neither ftruncate nor chsize). Is that related? (Not evident by a glance at streamio_1.f90 but perhaps the library itself does.) Is this perhaps due to lack of some other support? Looks very much seek-related. Author of suspect patches in the revision range CC:ed, but I'll assign myself this PR while I investigate whether there's a deficiency in the (l)seek support of this target, particularly with -D_FILE_OFFSET_BITS=64. -- Summary: [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: hp at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails
-- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-06 19:16:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
[Bug middle-end/38431] New: [graphite] several ICEs with CP2K
the current graphite branch segfaults ICEs on several files from CP2K. Compiling with '-O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -fgraphite -fgraphite-identity' To reproduce get http://www.pci.uzh.ch/vandevondele/tmp/CP2K_2008_12_03.tgz untar and type make at least on the following files: mltfftsg.F mltfftsg_tools.F harris_force_types.F ai_moments.F cp_units.F ps_wavelet_util.F cp_fm_basic_linalg.F ps_wavelet_kernel.F ai_angmom.F distribution_optimize.F qs_util.F atom_fit.F atom_operators.F dynamical_coeff_types.F pw_spline_utils.F pw_poisson_types.F xc_derivative_set_types.F cp_ddapc_methods.F qs_all_potential.F qs_operators_ao.F I have ICEs. The first one is: ai_moments.F: In function cossin: ai_moments.F:44: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make: *** [ai_moments.o] Error The same files compile fine with '-O0 -fgraphite -fgraphite-identity' so I guess it is related to applying graphite to optimized code (or the other way around). -- Summary: [graphite] several ICEs with CP2K Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-12-06 19:35 --- This very well could be the ftruncate issue since I did modify the code path. however, it seems that if these test cases worked before then we are unnecessarily doing the ftruncate for the pos= code path in data_transfer_init. I am looking at that right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails
--- Comment #2 from hp at gcc dot gnu dot org 2008-12-06 20:09 --- If there was an ftruncate call in the execution path, then I'd see the required ftruncate or chsize support not present message in the log, and I don't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze
--- Comment #11 from steven at gcc dot gnu dot org 2008-12-06 20:17 --- Created an attachment (id=16842) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16842action=view) Remove overeager solver Bootstrapped and tested on ia64-unknown-linux-gnu. Time-tested by compiling cc1-i/cc1plus-i files for ia64, CSiBE, and various test cases for old PRs about slow data flow solving. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug fortran/38318] moving the allocation of temps out of loops.
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-06 20:25 --- This could also be useful when done in the middle-end, see PR 21046. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||21046 Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-06 20:25:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-06 21:01
---
I did miss an fbuf_flush. I am not sure why it matters unless it is avoiding
some actual disk operations for us. Try this and let me know.
@@ -2146,7 +2155,10 @@ data_transfer_init (st_parameter_dt *dtp
/* Required for compatibility between 4.3 and 4.4 runtime. Check
to see if we might be reading what we wrote before */
if (dtp-u.p.current_unit-mode == WRITING)
- flush(dtp-u.p.current_unit-s);
+ {
+ fbuf_flush (dtp-u.p.current_unit, 1);
+ flush(dtp-u.p.current_unit-s);
+ }
if (dtp-pos file_length (dtp-u.p.current_unit-s))
dtp-u.p.current_unit-endfile = NO_ENDFILE;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
[Bug middle-end/38428] [4.4 Regression] ice for Linux kernel code with -O2
--- Comment #5 from jakub at gcc dot gnu dot org 2008-12-06 21:08 --- Subject: Bug 38428 Author: jakub Date: Sat Dec 6 21:06:43 2008 New Revision: 142527 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142527 Log: PR middle-end/38428 * tree-ssa-operands.c (get_expr_operands) case BIT_FIELD_REF: Set gimple_set_has_volatile_ops if the BIT_FIELD_REF is volatile. * gcc.c-torture/compile/pr38428.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr38428.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-operands.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38428
[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails
--- Comment #4 from hp at gcc dot gnu dot org 2008-12-06 21:15 --- (In reply to comment #3) Try this and let me know. Will do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
[Bug middle-end/38428] [4.4 Regression] ice for Linux kernel code with -O2
--- Comment #6 from jakub at gcc dot gnu dot org 2008-12-06 21:17 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38428
[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-06 21:25 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00409.html Approval mail never made it through, but you can see traces of it here: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00410.html -- steven at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||12/msg00409.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #3 from sabre at nondot dot org 2008-12-06 21:31 --- Ok, so this is a special case when __builtin_constant_p is immediately the operand of ?:? Do you allow things like __builtin_constant_p(...)+0 as the operand? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails
--- Comment #5 from hp at gcc dot gnu dot org 2008-12-06 21:33 --- Sorry, it didn't help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
[Bug fortran/38291] Rejects I/O with POS= if FMT=*
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-12-06 21:54 --- Subject: Bug 38291 Author: jvdelisle Date: Sat Dec 6 21:53:11 2008 New Revision: 142528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142528 Log: 2008-12-06 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/38291 * io/transfer.c (data_transfer_init): Add fbuf_flush inadvertently ommitted. Add check for invalid use of REC= with ACCESS=stream. Fix comment. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38291
[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code
--- Comment #11 from steven at gcc dot gnu dot org 2008-12-06 22:05 --- What's the status of this bug? Fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948
[Bug fortran/38432] New: Add warning for endless loops
Ignoring overflows, the following program would run for ever. NAG f95 prints the Warning: DO loop has zero iteration count integer :: i do i = 1, -3, 1 end do end -- Summary: Add warning for endless loops Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38432
[Bug fortran/38432] Add warning for loops which are never executed
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-06 22:18 --- I wanted to write: That loop will never be run, sorry for the miswording. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|Add warning for endless |Add warning for loops which |loops |are never executed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38432
[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze
--- Comment #13 from zadeck at naturalbridge dot com 2008-12-06 22:33 --- Subject: Re: [4.3/4.4 Regression] Hang in df_analyze steven at gcc dot gnu dot org wrote: --- Comment #12 from steven at gcc dot gnu dot org 2008-12-06 21:25 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00409.html Approval mail never made it through, but you can see traces of it here: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00410.html just to make it official, approved. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug c++/11211] trivial static initializers of const objects should be done at compile time
--- Comment #6 from sabre at nondot dot org 2008-12-06 22:44 --- FWIW, llvm-g++ gets this right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11211
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #4 from joseph at codesourcery dot com 2008-12-06 22:53 --- Subject: Re: __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression On Sat, 6 Dec 2008, sabre at nondot dot org wrote: Ok, so this is a special case when __builtin_constant_p is immediately the operand of ?:? Do you allow things like __builtin_constant_p(...)+0 as the operand? Yes, this is a (documented) special case required to be compatible with existing GNU C code. __builtin_constant_p(...)+0 is not allowed as the condition; the bcp_call property propagates though parentheses and through being an operand of __builtin_choose_expr, but not otherwise. For example, ((__builtin_choose_expr(1, (__builtin_constant_p(...)), 1))) has the bcp_call property. I think the description in my formal model is right for how this property propagates, except it leaves it unclear what the property is for the result of a conditional expression where both the condition and the selected half of the expression have the bcp_call property. In that case, I don't think the conditional expression should have the property, and it doesn't in the implementation on c-4_5-branch. The formal model seems unclear here, but I think it should be interpreted as the bcp_call property being lost through the implicit conversion of the ?: operands to a common type. What I didn't realise when writing the formal model is that the conditional expression, with a bcp_call condition, must be treated like the *folded* version of the selected half of the expression, since __builtin_constant_p tests constancy of the folded version. If __builtin_constant_p accepts (0 foo()) as constant then this needs to be accepted in the selected half of the initializer. And for optimal handling of the use case for this use of __builtin_constant_p (in particular, detecting constant insn conditions when building GCC), such expressions as (0 foo()) should be accepted as constant by __builtin_constant_p (0 may have been a macro expansion of TARGET_64BIT or similar). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug rtl-optimization/36365] [4.3 Regression] Hang in df_analyze
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-06 22:54 --- Subject: Bug 36365 Author: steven Date: Sat Dec 6 22:52:43 2008 New Revision: 142529 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142529 Log: PR rtl-optimization/36365 * df-core.c (df_worklist_dataflow_overeager): Remove. (df_worklist_dataflow): Don't call it, use double-queue only. * params.def (PARAM_DF_DOUBLE_QUQUQ_THRESHOLD_FACTOR): Remove. Modified: trunk/gcc/ChangeLog trunk/gcc/df-core.c trunk/gcc/params.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug rtl-optimization/36365] [4.3 Regression] Hang in df_analyze
--- Comment #14 from steven at gcc dot gnu dot org 2008-12-06 22:54 --- Fixed in GCC 4.4. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|[4.3/4.4 Regression] Hang in|[4.3 Regression] Hang in |df_analyze |df_analyze http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug tree-optimization/37853] [4.4 Regression] gcc.dg/vect/vect-67.c failing since PRE rewrite
--- Comment #2 from dominiq at lps dot ens dot fr 2008-12-06 23:56 --- The output of -ftree-vectorizer-verbose=6 gives: /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:30: note: not vectorized: too many BBs in loop. /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][8] and ia[i_91][1][9] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][8] and ia[i_91][1][10] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][8] and ia[i_91][1][11] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][8] and ia[i_91][1][12] ... /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][20] and ia[i_91][1][21] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][20] and ia[i_91][1][22] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][20] and ia[i_91][1][23] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][21] and ia[i_91][1][22] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][21] and ia[i_91][1][23] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][22] and ia[i_91][1][23] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: not vectorized: complicated access pattern. /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:9: note: vectorized 0 loops in function. The failure appeared between revisions 137614 (passed) and 137631, most of them are branches or FE patches but 137620 (IPA-unlikely?) and 137631. Compiling with -fno-tree-pre does not help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37853
[Bug c++/38433] New: Incorrect handling of line termination character with trailing spaces
In the attached file, there is a comment terminated with a line-termination character (\) followed by spaces. This should NOT be considered a line terminator, yet gcc considers it as such. From 2.1/2 in the C++03 standard: Each instance of a new-line character and an immediately preceding backslash character is deleted, splicing physical source lines to form logical source lines. That is, only backslashes immediately followed by a newline are considered line terminators. The existing behavior of gcc violates the standard and conflicts with the behavior of other popular C++ compilers (EDG, MSVC). -- Summary: Incorrect handling of line termination character with trailing spaces Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eric dot niebler at gmail dot com GCC build triplet: Configured with: ../gcc-4.3.0/configure --enable- languages=c,c++ GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38433
[Bug c++/38433] Incorrect handling of line termination character with trailing spaces
--- Comment #1 from eric dot niebler at gmail dot com 2008-12-06 23:59 --- Created an attachment (id=16843) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16843action=view) Compile with: g++ -Wall test.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38433
[Bug tree-optimization/37853] [4.4 Regression] gcc.dg/vect/vect-67.c failing since PRE rewrite
--- Comment #3 from dominiq at lps dot ens dot fr 2008-12-07 00:11 --- Fails also on x86_64-unknown-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00519.html ia64-unknown-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00518.html, powerpc64-suse-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00517.html, i686-pc-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00515.html powerpc-unknown-eabisim: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00503.html ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37853
[Bug tree-optimization/37853] [4.4 Regression] gcc.dg/vect/vect-67.c failing since PRE rewrite
--- Comment #4 from dominiq at lps dot ens dot fr 2008-12-07 00:17 --- The failure appeared at revision 137631 (not in r137630, see http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg01011.html). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37853
[Bug c++/38433] Incorrect handling of line termination character with trailing spaces
--- Comment #2 from joseph at codesourcery dot com 2008-12-07 00:28 --- Subject: Re: New: Incorrect handling of line termination character with trailing spaces On Sat, 6 Dec 2008, eric dot niebler at gmail dot com wrote: In the attached file, there is a comment terminated with a line-termination character (\) followed by spaces. This should NOT be considered a line terminator, yet gcc considers it as such. From 2.1/2 in the C++03 standard: Each instance of a new-line character and an immediately preceding backslash character is deleted, splicing physical source lines to form logical source lines. This (removal of such spaces) is part of how GCC defines the implementation-defined mapping in translation phase 1. There are no input files that GCC interprets as representing a program that enters phase 2 with backslash-space at the end of a line. That is, only backslashes immediately followed by a newline are considered line terminators. The existing behavior of gcc violates the standard and conflicts with the behavior of other popular C++ compilers (EDG, MSVC). No, it conforms to the standard but does not allow certain programs to be represented. (I think this is a bad idea, but that's another matter.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38433
[Bug c++/38433] Incorrect handling of line termination character with trailing spaces
--- Comment #3 from eric dot niebler at gmail dot com 2008-12-07 00:46 --- If you are referring to 2.1/1 ... Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set (introducing new-line characters for end-of-line indicators) if necessary. Trigraph sequences (2.3) are replaced by corresponding single-character internal representations. Any source file character not in the basic source character set (2.2) is replaced by the universal-character-name that designates that character. (An implementation may use any internal encoding, so long as an actual extended character encountered in the source file, and the same extended character expressed in the source file as a universal-character-name (i.e. using the \u notation), are handled equivalently.) I read this as permitting a mapping of characters, but not a deletion of characters, which is what gcc is doing. The only deletion of characters I see permitted is the deletion of a newline and an IMMEDIATELY preceding backslash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38433
[Bug c++/38433] Incorrect handling of line termination character with trailing spaces
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-07 00:54 --- (In reply to comment #3) I read this as permitting a mapping of characters, but not a deletion of characters, which is what gcc is doing. The only deletion of characters I see permitted is the deletion of a newline and an IMMEDIATELY preceding backslash. I don't think it is deleting in the sense you are thinking of; it maps backslash followed by spaces followed by a return into just a return. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38433
[Bug preprocessor/8270] [4.2/4.3/4.4 Regression] back-slash white space newline with comments, no warning
--- Comment #39 from pinskia at gcc dot gnu dot org 2008-12-07 01:01 --- From JSM in PR 38433: On Sat, 6 Dec 2008, eric dot niebler at gmail dot com wrote: In the attached file, there is a comment terminated with a line-termination character (\) followed by spaces. This should NOT be considered a line terminator, yet gcc considers it as such. From 2.1/2 in the C++03 standard: Each instance of a new-line character and an immediately preceding backslash character is deleted, splicing physical source lines to form logical source lines. This (removal of such spaces) is part of how GCC defines the implementation-defined mapping in translation phase 1. There are no input files that GCC interprets as representing a program that enters phase 2 with backslash-space at the end of a line. That is, only backslashes immediately followed by a newline are considered line terminators. The existing behavior of gcc violates the standard and conflicts with the behavior of other popular C++ compilers (EDG, MSVC). No, it conforms to the standard but does not allow certain programs to be represented. (I think this is a bad idea, but that's another matter.) --- CUT --- Which explains why this is conforming to the standard and is allowed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug preprocessor/38433] Incorrect handling of line termination character with trailing spaces
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-07 00:58 --- *** This bug has been marked as a duplicate of 8270 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38433
[Bug preprocessor/8270] [4.2/4.3/4.4 Regression] back-slash white space newline with comments, no warning
--- Comment #38 from pinskia at gcc dot gnu dot org 2008-12-07 00:58 --- *** Bug 38433 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||eric dot niebler at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug tree-optimization/37853] [4.4 Regression] gcc.dg/vect/vect-67.c failing since PRE rewrite
--- Comment #5 from hjl dot tools at gmail dot com 2008-12-07 01:11 --- See PR 36792. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37853
[Bug fortran/38425] I/O: POS= compile-time diagnostics
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-07 01:12 --- Subject: Bug 38425 Author: jvdelisle Date: Sun Dec 7 01:10:42 2008 New Revision: 142534 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142534 Log: 2008-12-06 Jerry DeLisle [EMAIL PROTECTED] PR fortran/38425 * io.c (check_io_constraints): Check constraints on REC=, POS=, and internal unit with POS=. Fix punctuation on a few error messages. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38425
[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures
--- Comment #9 from hjl dot tools at gmail dot com 2008-12-07 01:13 --- Those 3 still aren't fixed: FAIL: gcc.dg/vect/vect-67.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/no-scevccp-outer-13.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-7.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 See http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00654.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792
[Bug fortran/38425] I/O: POS= compile-time diagnostics
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-12-07 01:17 --- Subject: Bug 38425 Author: jvdelisle Date: Sun Dec 7 01:15:46 2008 New Revision: 142535 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142535 Log: 2008-12-06 Jerry DeLisle [EMAIL PROTECTED] PR fortran/38425 * gfortran.dg/io_constraints_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/io_constraints_5.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38425
[Bug fortran/38425] I/O: POS= compile-time diagnostics
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-12-07 01:18 --- Fixed on trunk: -- 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=38425
[Bug tree-optimization/33928] [4.3/4.4 Regression] 22% performance slowdown from 4.2.2 to 4.3/4.4.0 in floating-point code
--- Comment #40 from bonzini at gnu dot org 2008-12-07 02:55 --- IIUC this is a typical case in which CSE was fixing something that earlier passes messed up. Unfortunately fwprop does (better) what CSE was meant to do, but does not do what I assumed was already done before CSE. If the problem is aliasing/FRE, then I think Richi is the one who could fix it for good in the tree passes. If there is more to it, however, I can take a look at why fwprop is generating the ugly code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug c/35608] gcc.c-torture/compile/limits-structnest.c fails -O2 -Os
--- Comment #6 from dirtyepic at gentoo dot org 2008-12-07 06:42 --- This is up to four failures now: FAIL: gcc.c-torture/compile/limits-structnest.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/limits-structnest.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/limits-structnest.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/limits-structnest.c -Os (test for excess errors) (rev 142383) -- dirtyepic at gentoo dot org changed: What|Removed |Added CC||dirtyepic at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35608
[Bug c++/37922] code generation error
--- Comment #3 from rwgk at yahoo dot com 2008-12-07 07:34 --- Created an attachment (id=16844) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16844action=view) reproducer, no dependencies, no includes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug c++/37922] code generation error
--- Comment #4 from rwgk at yahoo dot com 2008-12-07 07:44 ---
Testing with:
g++ (GCC) 4.4.0 20081206 (experimental)
svn revision 142514
pr37922repro1.cpp should always exit with status 0.
However, it fails this test when compiling with -O3 and -O2:
g++ -Wall -fPIC -O3 pr37922repro1.cpp
./a.out ; echo $status
2
g++ -Wall -fPIC -O2 pr37922repro1.cpp
./a.out ; echo $status
2
g++ -Wall -fPIC -O1 pr37922repro1.cpp
./a.out ; echo $status
0
g++ -Wall -fPIC -O0 pr37922repro1.cpp
./a.out ; echo $status
0
The -fPIC is critical.
The problem region in the reproducer is marked with comments:
// THE PROBLEM IS AROUND HERE
if (proper_order 0) {
proper_order *= -1;
proper_r = -proper_r; // THIS FAILS ...
}
if (proper_order 1) {
rot_mx rmi = proper_r.minus_unit_mx(); // ... THEREFORE WRONG HERE
Sorry it is still 556 lines long, but I already spent 2 1/2 hours
reducing it this far. At least, it is completely self-contained and
compiles in fractions of a second.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
