[Bug bootstrap/22259] [4.1 Regression] spawnv cannot execute gcc/as
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-07-02 08:08 --- One option: have gcc/Makefile stamp-as target test build and output appropriate script to MS Windows BATCH file as.bat. I tried to copy the assembler in the tree, instead of making a script pointing to it. It works. Is there any drawback to this approach? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22259
[Bug libstdc++/22272] endless loop during compile of all-target-libstdc++-v3
--- Additional Comments From lehmann at ans-netz dot de 2005-07-02 08:53 --- I can't install APAR IY26685 because it is already included in AIX's ML11 for 4.3.3. - I already have that fix installed.: All of the selected fixes in your download list are currently installed on your system or are included in the maintenance level installed on your system. What do you expect me to do now? -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22272
[Bug bootstrap/22259] [4.1 Regression] spawnv cannot execute gcc/as
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-07-02 08:55 --- Created an attachment (id=9192) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9192action=view) Patch Attached patch implements the idea of making a special case for mingw32 in stamp-as, stamp-collect-ld and stamp-nm (gcc/Makefile.in). It does fix this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22259
[Bug c/22275] New: bitfield layout change (regression?)
the following testcase is extracted from WINE. It is to some degree problematic because BOOL is a signed int, but we use 1 bit wide bitfields here. Also the :0 might be a GNU extension. The problem is that with gcc 3.3.5: gcc -O2 -o xx xx.c ; ./xx no output but with gcc 4.1 branch: /home/marcus/projects/gcc/BIN/bin/gcc -O2 -march=i586 -mtune=i586 xx.c -o xx; ./xx xx: xx.c:24: main: Assertion `sizeof(CABINETSTATE) == 8' failed. so the layout and final size of this struct changed. -- Summary: bitfield layout change (regression?) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug c/22275] bitfield layout change (regression?)
--- Additional Comments From marcus at jet dot franken dot de 2005-07-02 09:00 --- Created an attachment (id=9193) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9193action=view) xx.c testcase extracted from WINE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug target/16331] x86-64 inline asm register constraints insufficient WRT ABI
--- Additional Comments From falk at debian dot org 2005-07-02 10:17 --- (In reply to comment #4) The first call of pokus() completely ignores the assigned value of the variable r8 -- instead the value '6' into it for the call. The second call assumes the the register r8 should be used for the call, but by now the wrong value has bee placed into it. I cannot reproduce this with gcc 3.3.6, the generated assembly looks just fine for me: test: 0: 55 push %rbp 1: 48 89 e5mov%rsp,%rbp 4: e8 00 00 00 00 callq 9 test+0x9 5: R_X86_64_PC32hokus+0xfffc 9: 41 89 c0mov%eax,%r8d c: 41 b9 06 00 00 00 mov$0x6,%r9d 12: be 02 00 00 00 mov$0x2,%esi 17: ba 03 00 00 00 mov$0x3,%edx 1c: b9 04 00 00 00 mov$0x4,%ecx 21: 44 89 c7mov%r8d,%edi 24: e8 00 00 00 00 callq 29 test+0x29 25: R_X86_64_PC32 pokus+0xfffc 29: e8 00 00 00 00 callq 2e test+0x2e 2a: R_X86_64_PC32 hokus+0xfffc 2e: 41 b9 06 00 00 00 mov$0x6,%r9d 34: 41 b8 05 00 00 00 mov$0x5,%r8d 3a: b9 04 00 00 00 mov$0x4,%ecx 3f: ba 03 00 00 00 mov$0x3,%edx 44: be 02 00 00 00 mov$0x2,%esi 49: 44 89 c7mov%r8d,%edi 4c: b8 00 00 00 00 mov$0x0,%eax 51: e8 00 00 00 00 callq 56 test+0x56 52: R_X86_64_PC32 pokus+0xfffc 56: c9 leaveq Please retry and give the exact version and flags you used. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331
[Bug middle-end/22276] New: [4.1 regression] bootstrap failure on i686-pc-mingw32
Building gcc on i686-pc-mingw32 (with patch from http://gcc.gnu.org/ml/gcc-patches/2005-05/msg9.html) fails with: ./xgcc -B./ -B/mingw/i686-pc-mingw32/bin/ -isystem /mingw/i686-pc-mingw32/include -isystem /mingw/i686-pc-mingw32/sys-include -L/home/FX/ibin/gcc/../ld -O2 -I../../gcc/gcc/../winsup/w32api/include -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I./../intl -I../../gcc/gcc/../libcpp/include -I/home/FX/local/include -I/home/FX/local/include -fexceptions -c ../../gcc/gcc/unwind-dw2-fde.c -o libgcc/./unwind-dw2-fde.o ../../gcc/gcc/unwind-dw2-fde.c: In function 'init_object_mutex_once': ../../gcc/gcc/unwind-dw2-fde.c:67: internal compiler error: vector VEC(tree,base) index domain error, in compute_flow_sensitive_aliasing at tree-ssa-alias.c:910 -- Summary: [4.1 regression] bootstrap failure on i686-pc-mingw32 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22276
[Bug middle-end/22276] [4.1 regression] bootstrap failure on i686-pc-mingw32
--- Additional Comments From giovannibajo at libero dot it 2005-07-02 11:00 --- Provide a preprocessed testcase, this bug might be target-independent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22276
[Bug ada/22277] New: ACATS ICE cc40001 in first_vi_for_offset, at tree-ssa-structalias.c:2566
On x86_64-linux as of LAST_UPDATED: Sat Jul 2 09:40:45 UTC 2005 +===GNAT BUG DETECTED==+ | 4.1.0 20050702 (experimental) (x86_64-unknown-linux-gnu) GCC error: | | in first_vi_for_offset, at tree-ssa-structalias.c:2566 | | Error detected at cc40001.adb:148:5 | The test was PASS as of LAST_UPDATED: Tue Jun 28 20:57:27 UTC 2005. Note: to bootstrap Ada on x86_64 you need the following patch to workaround PR22212. Index: Makefile.in === RCS file: /cvs/gcc/gcc/gnattools/Makefile.in,v retrieving revision 1.4 diff -u -r1.4 Makefile.in --- Makefile.in 30 Mar 2005 08:56:55 - 1.4 +++ Makefile.in 2 Jul 2005 13:04:19 - @@ -112,7 +112,7 @@ TOOLS_FLAGS_TO_PASS_NATIVE= \ CC=../../xgcc -B../../ \ CFLAGS=$(CFLAGS) \ - ADAFLAGS=$(ADAFLAGS) \ + ADAFLAGS=$(ADAFLAGS) -O0 \ INCLUDES=$(INCLUDES_FOR_SUBDIR) \ ADA_INCLUDES=-I../rts $(ADA_INCLUDES_FOR_SUBDIR) \ exeext=$(exeext) \ -- Summary: ACATS ICE cc40001 in first_vi_for_offset, at tree-ssa- structalias.c:2566 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22277
[Bug tree-optimization/22212] [4.1 Regression] SEGV in is_gimple_variable during loop-ivopts while building Ada RTS
--- Additional Comments From laurent at guerby dot net 2005-07-02 13:08 --- cxa4006 and cxa4017 fail the same way (STORAGE_ERROR) as vms_conv.adb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22212
[Bug tree-optimization/22037] [4.1 Regression] internal compiler error: verify_ssa failed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 14:30 --- (In reply to comment #10) The bug is really in cleanup_tree_cfg which is doing the merge of the two BBs. This patch fixes the problem but I have not yet bootstrapped it yet: This patch does not bootstrap. I think it is better to disable the optimization in tree cfg and let leter tree passes fix it up. I am looking into fix it still. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22037
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 15:08 --- 3.4.0 also fails on your test so it is not the bit-field changes in 4.0.0 which caused this. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |middle-end Keywords||ABI Known to fail||3.4.0 4.0.0 4.1.0 Summary|bitfield layout change |[3.4/4.0/4.1 Regression] |(regression?) |bitfield layout change ||(regression?) Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug tree-optimization/22212] [4.1 Regression] SEGV in is_gimple_variable during loop-ivopts while building Ada RTS
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-07-02 16:04 --- Subject: Re: [4.1 Regression] SEGV in is_gimple_variable during loop-ivopts while building Ada RTS cxa4006 and cxa4017 fail the same way (STORAGE_ERROR) as vms_conv.adb. See the email I sent to the GCC list about cxa4006. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22212
[Bug tree-optimization/14490] [tree-ssa] Simplify a - 10 150 into a 160
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-02 16:25 --- Subject: Bug 14490 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-02 16:24:31 Modified files: gcc: ChangeLog fold-const.c Added files: gcc/testsuite/gcc.dg: 20050702-1.c gcc/testsuite/gcc.dg/tree-ssa: pr14490-1.c pr14490-2.c pr14490-3.c pr14490-4.c Log message: 2005-07-02 Andrew Pinski [EMAIL PROTECTED] PR middle-end/14490 * fold-const.c (fold_binary): Handle the return value of fold_to_nonsharp_ineq_using_bound if we get back the same operand back. Implement X +- C1 CMP C2 folding to X CMP C2 -+ C1. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9317r2=2.9318 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gccr1=1.599r2=1.600 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050702-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr14490-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr14490-2.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr14490-3.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr14490-4.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14490
[Bug tree-optimization/14490] [tree-ssa] Simplify a - 10 150 into a 160
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 16:25 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14490
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
-- Bug 19987 depends on bug 14490, which changed state. Bug 14490 Summary: [tree-ssa] Simplify a - 10 150 into a 160 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14490 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
[Bug c/22278] New: gcc -O2 discards cast to volatile
In the following testcase, a read memory access should be made.
However gcc -O2 optimizes away the code inside the test function.
--- test.c
void test (char *addr) {
*((volatile char *) addr);
}
---
$ gcc -Wall -O2 -S test.c
--- test.s
test.s:
.file test.c
.text
.p2align 4,,15
.globl test
.type test, @function
test:
pushl %ebp
movl%esp, %ebp
popl%ebp
ret
.size test, .-test
.ident GCC: (GNU) 4.1.0 20050702 (experimental)
.section.note.GNU-stack,,@progbits
---
--
Summary: gcc -O2 discards cast to volatile
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olivier dot baudron at m4x dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 16:48 --- See PR 21568 and http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html. This is allowed by the C and C++ standards. *** This bug has been marked as a duplicate of 21568 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding * omitted
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 16:48 --- *** Bug 22278 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||olivier dot baudron at m4x ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
[Bug tree-optimization/22279] New: [4.1 Regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2566
On various platforms, the libstdc++ testsuite fails early with an ICE building testsuite_abi.cc. This includes at least hppa64-hpux and ia64-hpux (compilers as of 20050702 07:00 UTC) and gcc-testresults shows it on x86_64-linux; it didn't happen with 20050630 compilers. The dates show this is a different bug from bug 22071. /scratch/gcc/nightly-2005-07-02-mainline/hppa64-hp-hpux11.23/build_gcc/install/lib/gcc/hppa64-hp-hpux11.23/4.1.0/../../../../include/c++/4.1.0/bits/vector.tcc: In member function 'void std::vector_Tp, _Alloc::_M_insert_aux(__gnu_cxx::__normal_iteratortypename std::_Vector_base_Tp, _Alloc::_Tp_alloc_type::pointer, std::vector_Tp, _Alloc , const _Tp) [with _Tp = compare_symbols(const char*, const char*, bool)::symbol_pair, _Alloc = std::allocatorcompare_symbols(const char*, const char*, bool)::symbol_pair]':/scratch/gcc/nightly-2005-07-02-mainline/hppa64-hp-hpux11.23/build_gcc/install/l ib/gcc/hppa64-hp-hpux11.23/4.1.0/../../../../include/c++/4.1.0/bits/vector.tcc:249: internal compiler error: in first_vi_for_offset, at tree-ssa-structalias.c:2566 -- Summary: [4.1 Regression] ICE in first_vi_for_offset, at tree- ssa-structalias.c:2566 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22279
[Bug tree-optimization/22279] [4.1 Regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2566
-- What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Keywords||ice-on-valid-code Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22279
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From olivier dot baudron at m4x dot org 2005-07-02
16:59 ---
I am not sure this is the same problem.
Besides, the following code is *not* optimized away with -O2:
void test (volatile char *addr) {
*addr;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug tree-optimization/22279] [4.1 Regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2566
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 17:01 --- Looks like it only effects 64bit targets: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00058.html -- What|Removed |Added GCC target triplet||64bit targets http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22279
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 17:03 --- Did you read the message which I referenced? it is still not a bug if you read the message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug middle-end/22276] [4.1 regression] bootstrap failure on i686-pc-mingw32
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22276
[Bug ada/22277] [4.1 Regression] ACATS ICE cc40001 in first_vi_for_offset, at tree-ssa-structalias.c:2566
-- What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org GCC target triplet||x86_64-unknown-linux-gnu Summary|ACATS ICE cc40001 in|[4.1 Regression] ACATS ICE |first_vi_for_offset, at |cc40001 in |tree-ssa-structalias.c:2566 |first_vi_for_offset, at ||tree-ssa-structalias.c:2566 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22277
[Bug tree-optimization/22277] [4.1 Regression] ACATS ICE cc40001 in first_vi_for_offset, at tree-ssa-structalias.c:2566
-- What|Removed |Added Component|ada |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22277
[Bug libstdc++/22272] endless loop during compile of all-target-libstdc++-v3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 17:17 --- Are you building in the source directory? if so can you try building in an object directory like the instation directions recomend? -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22272
[Bug bootstrap/22259] [4.1 Regression] spawnv cannot execute gcc/as
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 17:18 --- Patch here but you forgot the changeLog :). -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||07/msg00086.html Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-07-02 17:18:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22259
[Bug middle-end/22276] [4.1 regression] bootstrap failure on i686-pc-mingw32
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 17:22 --- Are you sure that your tree-ssa-alias.c is not modified? -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22276
[Bug tree-optimization/22277] [4.1 Regression] ACATS ICE cc40001 in first_vi_for_offset, at tree-ssa-structalias.c:2566
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 17:23 --- Most likely related to PR 22279. -- What|Removed |Added BugsThisDependsOn||22279 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22277
[Bug tree-optimization/22279] [4.1 Regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2566
-- What|Removed |Added OtherBugsDependingO||22277 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22279
[Bug rtl-optimization/22258] combine causes spill failure on return value register
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 17:26 --- Confirmed. -- What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |06/msg02252.html| Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet||sh-elf Last reconfirmed|-00-00 00:00:00 |2005-07-02 17:26:19 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22258
[Bug treelang/22188] Some warnings during building
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 17:32 --- Never mind, this is comming from flex. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22188
[Bug tree-optimization/22196] Missed back prop
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 17:32 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-02 17:32:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22196
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From falk at debian dot org 2005-07-02 17:33 --- I see a difference here in that gcc doesn't know whether the referenced object is declared to be volatile, it isn't visible as in PR 21568. IMHO we actually have a bug here; I don't see anything in the standard which allows omitting the access here. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 17:42 --- Since the orginal pointer is not violatile the cast will not change any thing since the compiler can deduce it is not violatile. From C99, 5.1.2.3 P3: In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including anycaused by calling a function or accessing a volatile object). and since violatile applies the type which is being pointed to and not to the pointer, the compiler can deduce it is not needed. Casting away the violatile in a pointer changes the behavior (just like const). -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From falk at debian dot org 2005-07-02 17:53 --- (In reply to comment #5) Since the orginal pointer is not violatile the cast will not change any thing since the compiler can deduce it is not violatile. It could deduce that if it was invalid to form a pointer to non-volatile that points to a volatile object. However, I can't see any point in the standard that disallows this. So how can gcc deduce the pointed-to object is not volatile? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug tree-optimization/22037] [4.1 Regression] internal compiler error: verify_ssa failed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
18:32 ---
Here is a patch fixes the problem:
Index: tree-cfg.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-cfg.c,v
retrieving revision 2.207
diff -u -p -r2.207 tree-cfg.c
--- tree-cfg.c 28 Jun 2005 19:33:20 - 2.207
+++ tree-cfg.c 2 Jul 2005 18:29:46 -
@@ -1298,10 +1298,12 @@ tree_merge_blocks (basic_block a, basic_
tree copy;
if (!may_propagate_copy (def, use)
- /* Propagating pointers might cause the set of vops for statements
-to be changed, and thus require ssa form update. */
+ /* Propagating pointers and constants might cause the
+set of vops for statements to be changed, and thus
+require ssa form update. */
|| (is_gimple_reg (def)
- POINTER_TYPE_P (TREE_TYPE (def
+ (POINTER_TYPE_P (TREE_TYPE (def))
+ || TREE_CONSTANT (use
{
gcc_assert (is_gimple_reg (def));
Hopefully it is not too permissive, we do allow the later passes fix up the
permissiveness.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22037
[Bug tree-optimization/22279] [4.1 Regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2566
--- Additional Comments From giovannibajo at libero dot it 2005-07-02 19:10 --- Can we get a preprocessed/reduced source? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22279
[Bug tree-optimization/22280] New: [4.1 Regression] ICE in referenced_var_lookup while compiling ali.adb
This was introduced by: 2005-06-29 Daniel Berlin [EMAIL PROTECTED] * tree-complex.c (complex_variable_components): Now a hashtable. (cvc_lookup): Ditto. (cvc_insert): Ditto. (create_components): Use referenced var iterator. Initialize hashtable. Use cvc_insert/lookup. (extract_components): Use cvc_insert/lookup. (update_complex_components): Ditto. (update_complex_components_on_edge): Ditto. * tree-dfa.c (referenced_vars): Now a hashtable. (dump_referenced_vars): Use iterator. (referenced_var_lookup): New function. (referenced_var_insert): Ditto. (add_referenced_var): Use referenced_var_insert. (mark_new_vars_to_rename): Use DECL_UID. * tree-flow-inline.h (first_htab_element): New function. (end_htab_p): Ditto. . I will try to get a C testcase. It is an interaction between SRA and referenced variables. Actually thinking about it we cannot get a C testcase as in Ada, we can have ADDR_EXPR of a constructor which means we can introduce a new referenced variable which we are trying to mark to rename. Here is the backtrace: #0 fancy_abort (file=0xc1bff0 /Users/pinskia/src/cool/gcc/gcc/tree-dfa.c, line=540, function=0xd84750 referenced_var_lookup) at /Users/pinskia/src/cool/gcc/gcc/diagnostic.c:590 #1 0x00a27540 in referenced_var_lookup (uid=44) at /Users/pinskia/src/cool/gcc/gcc/tree-dfa.c:540 #2 0x00ae5698 in generate_element_init (elt=0x4392d008, init=0x43673240, list_p=0xb41c) at / Users/pinskia/src/cool/gcc/gcc/tree-sra.c:1741 #3 0x00ae6b84 in scalarize_init (lhs_elt=0x4392d008, rhs=0x43673240, bsi=0xb598) at /Users/ pinskia/src/cool/gcc/gcc/tree-sra.c:1946 #4 0x00ae0ac0 in sra_walk_modify_expr (expr=0x446198a0, bsi=0xb598, fns=0xd88244) at / Users/pinskia/src/cool/gcc/gcc/tree-sra.c:850 #5 0x00ae11b4 in sra_walk_function (fns=0xd88244) at /Users/pinskia/src/cool/gcc/gcc/tree-sra.c: 922 #6 0x00ae70e8 in scalarize_function () at /Users/pinskia/src/cool/gcc/gcc/tree-sra.c:2107 #7 0x00ae7420 in tree_sra () at /Users/pinskia/src/cool/gcc/gcc/tree-sra.c:2166 #8 0x00603fe0 in execute_one_pass (pass=0xd3763c) at /Users/pinskia/src/cool/gcc/gcc/tree- optimize.c:714 #9 0x00604160 in execute_pass_list (pass=0xd3763c) at /Users/pinskia/src/cool/gcc/gcc/tree- optimize.c:751 #10 0x0060418c in execute_pass_list (pass=0xd28880) at /Users/pinskia/src/cool/gcc/gcc/tree- optimize.c:752 #11 0x00604884 in tree_rest_of_compilation (fndecl=0x43649480) at /Users/pinskia/src/cool/gcc/ gcc/tree-optimize.c:914 -- Summary: [4.1 Regression] ICE in referenced_var_lookup while compiling ali.adb Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc-darwin7.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22280
[Bug tree-optimization/22280] [4.1 Regression] ICE in referenced_var_lookup while compiling ali.adb
-- What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22280
[Bug tree-optimization/22280] [4.1 Regression] ICE in referenced_var_lookup while compiling ali.adb
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-02 19:28 --- We can't iterate in sequence anymore. i'll fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22280
[Bug tree-optimization/22280] [4.1 Regression] ICE in referenced_var_lookup while compiling ali.adb
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-02 19:34 --- We can't iterate in sequence anymore. i'll fix this. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-02 19:34:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22280
[Bug c++/22281] New: C-Style cast does reinterpret_cast when it should do a static_cast
The following program returns 1 instead of 0 because gcc seems not to do a
static_cast followed by a const_cast when doing the C-style cast. This is in
violation of 5.4 of the standard.
The problem first appeared in gcc 4.0.0. Here is the -v output of the version I
am currently using:
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-mpfr
--disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.1 20050617 (prerelease) (Debian 4.0.0-10)
-
struct A
{
int a;
};
struct B
{
int b;
};
struct C: public A, public B
{
};
int
main()
{
C c;
const C *cptr = c;
B* bad = (B*)cptr;
B* good = const_castB*(static_castconst B *(cptr));
return bad != good;
}
--
Summary: C-Style cast does reinterpret_cast when it should do a
static_cast
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gccbug at gammarayburst dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22281
[Bug c++/22281] [4.0/4.1 Regression] C-Style cast does reinterpret_cast when it should do a static_cast
-- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Keywords||wrong-code Summary|C-Style cast does |[4.0/4.1 Regression] C-Style |reinterpret_cast when it|cast does reinterpret_cast |should do a static_cast |when it should do a ||static_cast Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22281
[Bug c++/22281] [4.0/4.1 Regression] C-Style cast does reinterpret_cast when it should do a static_cast
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 19:55 --- This looks like basicially PR 22132 but this has a short testcase. -- What|Removed |Added OtherBugsDependingO||22132 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22281
[Bug c++/22132] [4.0/4.1 Regression] Wrong code: upcasting a const class pointer to struct the class derives from (C/old-style cast)
-- What|Removed |Added BugsThisDependsOn||22281 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22132
[Bug fortran/22282] New: loc intrinsic is not implemented in gfortran
See: http://gcc.gnu.org/onlinedocs/gcc-3.4.4/g77/Loc-Intrinsic.html -- Summary: loc intrinsic is not implemented in gfortran Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22282
[Bug fortran/22282] loc intrinsic is not implemented in gfortran
-- What|Removed |Added OtherBugsDependingO||19292 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22282
[Bug tree-optimization/22280] [4.1 Regression] ICE in referenced_var_lookup while compiling ali.adb
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 20:45 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00102.html. I can confirm that it fixes the ICE too. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||07/msg00102.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22280
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-02 22:07 --- Prior versions of gcc did respect casts to pointer-to-volatile and did not optimize away the access. I've seen a lot of code that relies on that, and which would thus be broken by gcc 4.x (in a subtle and hard-to-debug way). One recent example is an elusive bug in Fedora Core 4's X.org package which bit many users (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161242). I can't imagine a programmer casting into a pointer to volatile without really meaning it, so if the behavior is not defined by the standard then both compatibility and the principle of least astonishment seem to suggest reverting to the old behavior. -- What|Removed |Added CC||gcc2eran at tromer dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
Re: [Bug c/22278] gcc -O2 discards cast to volatile
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | See PR 21568 and http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html. Both those issues about completely *different* from the issue submitted in this PR. In the above cases, the accessed object actually is NOT volatile. This is not the same here. In this PR, the only thing the function sees is that its parameter is not declared pointer to volatile char, but just pointer to char. That is NO basis for the compiler to assume that the cast performed inside the body is invalid assumption. No. Never. Consequently, it must assume that the pointed-to object might be effectively volatile and consequently generate corresponding code. There is a difference between cv-qualified object and a pointer to cv-qualified object. In the former cases, you do know for sure how the object behaves, in the latter you don't. Consequently you must make conervative assumptions. |What|Removed |Added | | Status|UNCONFIRMED |RESOLVED | Resolution||DUPLICATE Andrew -- Once again, refrain from closing an issue when you do not fully understand the issue at hand. The PR should be reopen as wrong-code generation. -- Gaby
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:08 --- Subject: Re: gcc -O2 discards cast to volatile pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | See PR 21568 and http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html. Both those issues about completely *different* from the issue submitted in this PR. In the above cases, the accessed object actually is NOT volatile. This is not the same here. In this PR, the only thing the function sees is that its parameter is not declared pointer to volatile char, but just pointer to char. That is NO basis for the compiler to assume that the cast performed inside the body is invalid assumption. No. Never. Consequently, it must assume that the pointed-to object might be effectively volatile and consequently generate corresponding code. There is a difference between cv-qualified object and a pointer to cv-qualified object. In the former cases, you do know for sure how the object behaves, in the latter you don't. Consequently you must make conervative assumptions. |What|Removed |Added | | Status|UNCONFIRMED |RESOLVED | Resolution||DUPLICATE Andrew -- Once again, refrain from closing an issue when you do not fully understand the issue at hand. The PR should be reopen as wrong-code generation. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:10 --- Subject: Re: gcc -O2 discards cast to volatile pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Did you read the message which I referenced? Not just because people disagrees with your view means that they did not read what you wrote. | it is still not a bug if you read the message. I read the message and it bears no ressemblance to the specific case at hand here. Please stop closing PR based on half-digested material. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:10 --- Subject: Re: gcc -O2 discards cast to volatile falk at debian dot org [EMAIL PROTECTED] writes: | I see a difference here in that gcc doesn't know whether the referenced | object is declared to be volatile, it isn't visible as in PR 21568. Fully agreed. | IMHO we actually have a bug here; I don't see anything in the standard which | allows omitting the access here. again agreed. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:11 --- Subject: Re: gcc -O2 discards cast to volatile pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Since the orginal pointer is not violatile How do you know that? Just looking at function *parameter*? Sorry, that is no reason. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:12 --- Subject: Re: gcc -O2 discards cast to volatile falk at debian dot org [EMAIL PROTECTED] writes: | According to Joseph Myers, the question is whether this counts as access to | a volatile object, which is implementation defined (6.7.3#6). However, | extend.texi doesn't answer this, so I'll reopen it as a documentation problem. | We could then either document it does not constitute an access, or change | the behavior and state that it does. | | | -- |What|Removed |Added | | Status|RESOLVED|UNCONFIRMED |Keywords||documentation It is also wrong-code. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug tree-optimization/22280] [4.1 Regression] ICE in referenced_var_lookup while compiling ali.adb
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-02 22:18 --- Subject: Bug 22280 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-02 22:18:24 Modified files: gcc: ChangeLog tree-sra.c Log message: 2005-07-02 Daniel Berlin [EMAIL PROTECTED] Fix PR tree-optimization/22280 * tree-sra.c (generate_element_init): Remove useless loop. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9319r2=2.9320 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-sra.c.diff?cvsroot=gccr1=2.65r2=2.66 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22280
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From falk at debian dot org 2005-07-02 22:19 --- (In reply to comment #8) I can't imagine a programmer casting into a pointer to volatile without really meaning it, so if the behavior is not defined by the standard then both compatibility and the principle of least astonishment seem to suggest reverting to the old behavior. I agree in principle. It might just turn out to be too hard to guarantee, in which case we might as well document that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 22:20 --- (In reply to comment #13) It is also wrong-code. This is the opposite view of what JSM said on IRC. Take it up with him if you believe otherwise. Basically this is all implemention defined and since we did not document before, we have a chance to define it to what we want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:20 --- Subject: Re: gcc -O2 discards cast to volatile gcc2eran at tromer dot org [EMAIL PROTECTED] writes: | Prior versions of gcc did respect casts to pointer-to-volatile and did not | optimize away the access. I've seen a lot of code that relies on that, and which | would thus be broken by gcc 4.x (in a subtle and hard-to-debug way). One recent | example is an elusive bug in Fedora Core 4's X.org package which bit many users | (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161242). | | I can't imagine a programmer casting into a pointer to volatile without really | meaning it, so if the behavior is not defined by the standard then both | compatibility and the principle of least astonishment seem to suggest reverting | to the old behavior. We must be careful in distinguishing between the following two situations: (1) volatile int foo = 0; *(volatile int*) (int*) (foo); (2) int bar = 0; *(volatile int*) (bar); The former is well-formed and GCC should be careful. In the specific case at hand, the first cast may be passed to the function that is subject of this PR, and GCC has no way of knowing what is going behind the scene. Consequently, it must make the conservative assumption. The latter is just not well-founded based on the C standard. It is a QoI whether GCC should honor it or not. I have no strong opinion there, except saying that it is questionable. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug tree-optimization/22280] [4.1 Regression] ICE in referenced_var_lookup while compiling ali.adb
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 22:26 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22280
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:39 --- Subject: Re: gcc -O2 discards cast to volatile pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | (In reply to comment #13) | | It is also wrong-code. | | This is the opposite view of what JSM said on IRC. Sorry, I do not follow IRC, and it would be unfortunate that PRs get closed based on claims we do not have logs for so that users and people can look at them and scrutinize. Furthermore, the fundamental issue is whether this *(volatile int*) (int*) (foo); (or equivalent) where foo has been defined volatile int should be treated differently from *(volatile int*) (foo); or foo; For all useful purposes, it helps remembering that GCC is not an academic exercise in C standard reading. | Take it up with him if you believe otherwise. | Basically this is all implemention defined and since we did not | document before, we have a chance to define it to what we want. and it is hard to believe we (GCC developers aiming at useful compiler, as opposed to students doing academic exercise) will define it to be either contradictory or the most useless as possible. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 22:49 --- For all useful purposes, it helps remembering that GCC is not an academic exercise in C standard reading. Ok, then all of your comments about extensions to C++ should be thrown out the window since I know you are against extensions. If someone is going to program in C or C++, they should know they are going to get into trouble when programming and get something different than what they expect and should go read the standard to double check if they got it right or the compiler is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug target/21742] [4.1 Regression] unrecognized insn for struct-layout-1 tests with complex members
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-02 23:06 --- Subject: Bug 21742 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-02 23:06:43 Modified files: gcc: ChangeLog expr.c Log message: PR middle-end/21742 * expr.c (write_complex_part): Use adjust_address for MEM. (read_complex_part): Same. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9320r2=2.9321 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gccr1=1.799r2=1.800 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21742
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-02 23:30 --- (In reply to comment #17) Furthermore, the fundamental issue is whether this *(volatile int*) (int*) (foo); (or equivalent) where foo has been defined volatile int should be treated differently from *(volatile int*) (foo); or foo; How about this? int foo; *(volatile int*) (foo); In other words, why should the compiler bother at all with the qualifiers of what the pointer really points to? It seems simplest and most natural to decree that any dereference of a pointer-to-volatile (regardless of its origin) is to be treated as volatile and thus never optimized away. In other words, volatile should treated as a property of the type of the pointer being dereferenced, not of the actual object being pointed to. By analogy, if I write long bar = 42; x = *(char*)bar; then the compiler won't optimize this (into a SEGV?) just because it can easily tell that bar didn't really originate from a char*. Rather, it will take my word that (char*)bar should be treated just like any char*. Sure, it might optimize this subject to the usual semantics of char* -- but in case of volatiles, these semantics (should) forbid certain optimizations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From falk at debian dot org 2005-07-02 23:45 --- (In reply to comment #19) How about this? int foo; *(volatile int*) (foo); In other words, why should the compiler bother at all with the qualifiers of what the pointer really points to? Because the standard says so. As Nathan Sidwell explains in the thread linked above, it would be both pretty difficult to define the language extension you want semantically clean, and to implement it in gcc. So nobody tried yet. (Giving a warning would probably be less difficult to implement, unfortunately nobody tried either.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 23:54 --- Subject: Re: gcc -O2 discards cast to volatile pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | For all useful purposes, it helps remembering that GCC is not an | academic exercise in C standard reading. | Ok, then all of your comments about extensions to C++ should be | thrown out the window No, you just chose to selectively misread statements. That is unfortunate, but we have to live with it. | since I know you are against extensions. You know nothing about me, so lease stick to GCC. | If someone is going to program in C or C++, they should know they are | going to get into trouble when programming and get something | different than what they expect and should go read the standard to | double check if they got it right or the compiler is correct. yes, but that is orthogonal to the issue at hand. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
Re: [Bug c/22278] gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes: | --- Additional Comments From gcc2eran at tromer dot org 2005-07-02 23:30 --- | (In reply to comment #17) | Furthermore, the fundamental issue is whether this | | *(volatile int*) (int*) (foo); | | (or equivalent) where foo has been defined volatile int should be | treated differently from | | *(volatile int*) (foo); | | or | | foo; | | How about this? | | int foo; | *(volatile int*) (foo); It was included in my previous message. | In other words, why should the compiler bother at all with the qualifiers of | what the pointer really points to? Because the language definition says that the compiler should preserve a semantics and the compiler better bothers. | It seems simplest and most natural to | decree that any dereference of a pointer-to-volatile (regardless of | its origin) is to be treated as volatile and thus never optimized | away. In other words, volatile should treated as a property of the | type of the pointer being dereferenced, not of the actual object | being pointed to. but that is a fundamental departure from the language semantics. Replace volatile with const -- both are qualifiers -- and observe the disaster that would ensue. The volatile cv-qualified is interesting in the sense that it is fuzzily defined, but there are identities that the compiler must preserve. -- Gaby
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-03 00:03 --- Subject: Re: gcc -O2 discards cast to volatile gcc2eran at tromer dot org [EMAIL PROTECTED] writes: | --- Additional Comments From gcc2eran at tromer dot org 2005-07-02 23:30 --- | (In reply to comment #17) | Furthermore, the fundamental issue is whether this | | *(volatile int*) (int*) (foo); | | (or equivalent) where foo has been defined volatile int should be | treated differently from | | *(volatile int*) (foo); | | or | | foo; | | How about this? | | int foo; | *(volatile int*) (foo); It was included in my previous message. | In other words, why should the compiler bother at all with the qualifiers of | what the pointer really points to? Because the language definition says that the compiler should preserve a semantics and the compiler better bothers. | It seems simplest and most natural to | decree that any dereference of a pointer-to-volatile (regardless of | its origin) is to be treated as volatile and thus never optimized | away. In other words, volatile should treated as a property of the | type of the pointer being dereferenced, not of the actual object | being pointed to. but that is a fundamental departure from the language semantics. Replace volatile with const -- both are qualifiers -- and observe the disaster that would ensue. The volatile cv-qualified is interesting in the sense that it is fuzzily defined, but there are identities that the compiler must preserve. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c++/18279] [4.0/4.1 regression] missing function bodies from -fdump-translation-unit
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-03 01:15 --- Subject: Bug 18279 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-03 01:15:01 Modified files: gcc: ChangeLog c-decl.c tree-dump.c Log message: PR c++/18279 * c-decl.c (c_write_global_declarations): Dump contents of external scope to. * tree-dump.c (dequeue_and_dump): Dump abstract origin of a decl. TRY_FINALLY_EXPR, RETURN_EXPR, CASE_LABEL_EXPR, LABEL_EXPR, GOTO_EXPR, SWITCH_EXPR: Add. (dump_enabled_p): Return TRUE if PHASE is TDI_all and any dump is enabled. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9322r2=2.9323 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gccr1=1.671r2=1.672 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-dump.c.diff?cvsroot=gccr1=1.43r2=1.44 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18279
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 01:19
---
(In reply to comment #22)
| int foo;
| *(volatile int*) (foo);
It was included in my previous message.
Then it's still eluding me, since your foo (the object?) was volatile.
| In other words, why should the compiler bother at all with the qualifiers of
| what the pointer really points to?
Because the language definition says that the compiler should preserve
a semantics and the compiler better bothers.
Of course, but please forgive my ignorance -- where does does the standard
prescribe these semantics? The N869 draft (I don't have the standard; is N869
best fall-back?) says this:
[6.7.3/6] An object that has volatile-qualified type may be modified in ways
unknown to the lementation or have other unknown side effects. Therefore any
expression referring to such an object shall be evaluated strictly according to
the rules of the abstract machine, as described in 5.1.2.3. [...]
All other references to the semantics volatile likewise talk about objects. So,
what is an object?
[3.15/1] object: region of data storage in the execution environment, the
contents of which can represent values
[3.15/2] NOTE When referenced, an object may be interpreted as having a
particular type; see 6.3.2.1.
What indeed is the type of an object?
[6.3.2.1/1] [...] When an object is said to have a particular type, the type is
specified by the lvalue used to designate the object. [...]
And also, later on:
[6.5.3.2/4] The unary * operator denotes indirection. If the operand [...]
points to an object, the result is an lvalue designating the
object. If the operand has type pointer to type, the result has type
type. [...]
And just to be sure about whether volatile is part of the type thus specified
by the lvalue:
[6.2.5/26] [...] The qualified or unqualified versions of a type are distinct
types [...].
So the way I read it, the object designated by *(volatile int*)(anything) has a
volatile-qualified type and should thus be evaluated strictly according to the
rules of the abstract machine.
but that is a fundamental departure from the language semantics.
Replace volatile with const -- both are qualifiers -- and observe
the disaster that would ensue.
I must be showing my ignorance again, but what disaster would that be?
BTW, according to your interpretation, what is the standard-compliant behavior
of the following?
void quux(int *bar) {
*bar = 42;
}
volatile int foo;
quux((int*)foo);
I'm asking because as of 4.0.0, the assignment is optimized away by -O3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From joseph at codesourcery dot com 2005-07-03 01:27 --- Subject: Re: gcc -O2 discards cast to volatile On Sun, 3 Jul 2005, gcc2eran at tromer dot org wrote: Of course, but please forgive my ignorance -- where does does the standard prescribe these semantics? The N869 draft (I don't have the standard; is N869 best fall-back?) says this: Get the standard, not ancient drafts. As I pointed out on the gcc list a while back, N1124 is the result of merging C99 with TC1 and TC2 and is freely available on the WG14 site. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-03 01:42 ---
Subject: Re: gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| but that is a fundamental departure from the language semantics.
| Replace volatile with const -- both are qualifiers -- and observe
| the disaster that would ensue.
|
| I must be showing my ignorance again, but what disaster would that be?
If when the compiler sees const T* p, it assumes that *p is
effectively const, then it would miscompile
int foo(int* p, const int* q) {
int r = *q;
*p = r * r;
return *q;
}
If the compiler assumed that *q is effectively const, therefore cannot
have its value changed through *p, then the following assertion will fail
int i = 4;
assert(foo(i, i) == 16);
because the compiler could just return the cached value r.
There is more a pointer than just its type.
| BTW, according to your interpretation, what is the standard-compliant behavior
| of the following?
|
| void quux(int *bar) {
| *bar = 42;
| }
|
| volatile int foo;
| quux((int*)foo);
[#5] If an attempt is made to modify an object defined with
a const-qualified type through use of an lvalue with non-
const-qualified type, the behavior is undefined. If an
attempt is made to refer to an object defined with a
volatile-qualified type through use of an lvalue with non-
volatile-qualified type, the behavior is undefined.113)
The footnote says
113This applies to those objects that behave as if they were
defined with qualified types, even if they are never
actually defined as objects in the program (such as an
object at a memory-mapped input/output address).
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-03 01:43 --- Subject: Re: gcc -O2 discards cast to volatile gcc2eran at tromer dot org [EMAIL PROTECTED] writes: | (In reply to comment #22) | | int foo; | | *(volatile int*) (foo); | | It was included in my previous message. | | Then it's still eluding me, since your foo (the object?) was volatile. It was my object bar. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug fortran/20842] can't use 'END=' in output statement
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-03 01:46 --- Subject: Bug 20842 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-03 01:46:12 Modified files: gcc/fortran: ChangeLog io.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: io_invalid_1.f90 Log message: PR fortran/20842 * io.c (match_dt_element): Do not allow END tag in PRINT or WRITE statement. * gfortran.dg/io_invalid_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.479r2=1.480 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gccr1=1.26r2=1.27 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5716r2=1.5717 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/io_invalid_1.f90.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20842
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 01:46 --- (In reply to comment #24) Thanks! None of the quotes and references in comment 23 changed in N1124. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug fortran/20842] [4.0 only] can't use 'END=' in output statement
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED GCC target triplet|i686-pc-linux-gnu | Last reconfirmed|2005-04-09 19:15:06 |2005-07-03 01:47:26 date|| Summary|can't use 'END=' in output |[4.0 only] can't use 'END=' |statement |in output statement Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20842
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From hugh at mimosa dot com 2005-07-03 01:53
---
[ see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162274 ]
I feel that he gcc documentation promises that there will be an access. The
documentation can change, but it is a contract between the implementer and the C
programmer. Breaking a contract is not very nice. Especially when it can cause
quiet subtle breakage of a program.
info gcc node Volatiles with title 6.1 When is a Volatile Object Accessed?
clearly says:
Less obvious expressions are where something which looks like an access
is used in a void context. An example would be,
volatile int *src = SOMEVALUE;
*src;
With C, such expressions are rvalues, and as rvalues cause a read of
the object, GCC interprets this as a read of the volatile being pointed
to.
Now it turns out that gcc4 does *not* optimize away the access in:
void test(char *addr)
{
volatile char *t = addr;
(void) (*t);
}
Surely the motivating example in this bugzilla entry should be covered by the
same logic.
--
What|Removed |Added
CC||hugh at mimosa dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 02:30
---
(In reply to comment #25)
If when the compiler sees const T* p, it assumes that *p is
effectively const, then it would miscompile
int foo(int* p, const int* q) {
int r = *q;
*p = r * r;
return *q;
}
If the compiler assumed that *q is effectively const, therefore cannot
have its value changed through *p, then the following assertion will fail
int i = 4;
assert(foo(i, i) == 16);
because the compiler could just return the cached value r.
We need to distinguish between the semantics that that must be followed, and
optimizations that preserve these semantics. The way I understand it,
semantics-wise const is not a promise, it's only a requirement: it tells the
compiler that it can't change the object directly, that's all. Meanwhile, the
optimizer tries to do various optimizations that preserve the semantics, for
example by noting that variables don't change their values; but in your example
it can't make that assumption without aliasing analysis (which will fail), since
by itself the const-qualified argument guarantees nothing.
So the standard says the semantics are dumb: they considers just the type of the
dereferenced pointer and acts accordingly (forbid direct changes of consts,
apply strict abstrat machine for volatiles). But subject to those semantics, the
optimizer can be as smart as it wants. There's no contradiction here.
[#5] If an attempt is made to modify an object defined with
a const-qualified type through use of an lvalue with non-
const-qualified type, the behavior is undefined. If an
attempt is made to refer to an object defined with a
volatile-qualified type through use of an lvalue with non-
volatile-qualified type, the behavior is undefined.113)
OK. Then the volatile-stripping direction can be handled arbitrarily.
(In reply to comment #26)
It was my object bar.
OK. I was looking at comment 17.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-03 02:54 --- Subject: Re: gcc -O2 discards cast to volatile gcc2eran at tromer dot org [EMAIL PROTECTED] writes: | [#5] If an attempt is made to modify an object defined with | a const-qualified type through use of an lvalue with non- | const-qualified type, the behavior is undefined. If an | attempt is made to refer to an object defined with a | volatile-qualified type through use of an lvalue with non- | volatile-qualified type, the behavior is undefined.113) | | OK. Then the volatile-stripping direction can be handled arbitrarily. I do not understand that comment. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 04:14
---
(In reply to comment #30)
| OK. Then the volatile-stripping direction can be handled arbitrarily.
I do not understand that comment.
I meant that we were mostly concerned about what the standard says about the
effect of casting (say) int* into volatile int*, but the other directly is
simply undefined.
Still, consider the following variant:
void quux(int *bar) {
*(volatile int*)bar = 42;
}
volatile int foo;
quux((int*)foo);
This time there is no attempt [...] to refer to an object defined with a
volatile-qualified type through use of an lvalue with non-volatile-qualified
type. So why does gcc 4.0.0 -O3 still optimize away the assignment? And how
would you fix that with an approach that construes the standard to require
following the type of the real object?
Could the standard intend something so convoluted, when the interpretation in
comment 23 makes things perfectly sensible, well-defined and (in principle) easy
to implement?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
Re: [Bug c/22278] gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| (In reply to comment #30)
| | OK. Then the volatile-stripping direction can be handled arbitrarily.
|
| I do not understand that comment.
|
| I meant that we were mostly concerned about what the standard says about the
| effect of casting (say) int* into volatile int*, but the other directly is
| simply undefined.
That is what I do not understand. Could you point me to the relevant
passage of the C standard?
| Still, consider the following variant:
|
| void quux(int *bar) {
| *(volatile int*)bar = 42;
| }
|
| volatile int foo;
| quux((int*)foo);
|
| This time there is no attempt [...] to refer to an object defined with a
| volatile-qualified type through use of an lvalue with non-volatile-qualified
| type.
Really? What does quux() does to the object defined through foo then?
| So why does gcc 4.0.0 -O3 still optimize away the assignment? And how
| would you fix that with an approach that construes the standard to require
| following the type of the real object?
|
| Could the standard intend something so convoluted, when the interpretation in
| comment 23 makes things perfectly sensible, well-defined and (in principle)
easy
| to implement?
My understanding is that you have gotten everything backwards.
-- Gaby
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-03 04:43 ---
Subject: Re: gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| (In reply to comment #30)
| | OK. Then the volatile-stripping direction can be handled arbitrarily.
|
| I do not understand that comment.
|
| I meant that we were mostly concerned about what the standard says about the
| effect of casting (say) int* into volatile int*, but the other directly is
| simply undefined.
That is what I do not understand. Could you point me to the relevant
passage of the C standard?
| Still, consider the following variant:
|
| void quux(int *bar) {
| *(volatile int*)bar = 42;
| }
|
| volatile int foo;
| quux((int*)foo);
|
| This time there is no attempt [...] to refer to an object defined with a
| volatile-qualified type through use of an lvalue with non-volatile-qualified
| type.
Really? What does quux() does to the object defined through foo then?
| So why does gcc 4.0.0 -O3 still optimize away the assignment? And how
| would you fix that with an approach that construes the standard to require
| following the type of the real object?
|
| Could the standard intend something so convoluted, when the interpretation in
| comment 23 makes things perfectly sensible, well-defined and (in principle)
easy
| to implement?
My understanding is that you have gotten everything backwards.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-03 05:18 --- Subject: Re: gcc -O2 discards cast to volatile gcc2eran at tromer dot org [EMAIL PROTECTED] writes: | --- Additional Comments From gcc2eran at tromer dot org 2005-07-03 05:09 --- | (In reply to comment #32) | | I meant that we were mostly concerned about what the standard says about the | | effect of casting (say) int* into volatile int*, but the other directly is | | simply undefined. | | That is what I do not understand. Could you point me to the relevant | passage of the C standard? | | (my quote above should read the other *direction* is simply undefined) the other direction was very ambiguous. [...] | Really? What does quux() does to the object defined through foo then? | | It refers to it through an lvalue whose type is volatile int, which *is* | volatile-qualified. yes, you're right. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug libgcj/22283] New: Fail to build libjava under zh_TW.UTF-8 locale.
I use zh_TW.UTF-8 as the default encoding in my machine, and I found that I failed to build libjava. The error messsages are as following: (LC_ALL=zh_TW.UTF-8 make) make[2]: Entering directory `/home/jserv/build-gcj/i686-pc-linux-gnu/libjava' /bin/sh ./libtool --mode=compile /home/jserv/build-gcj/./gcc/gcj \ -B/home/jserv/build-gcj/./gcc/ \ ... `find gnu/java/awt/peer/gtk -name '*.class' -print` ... gnu/java/awt/peer/gtk/GtkComponentPeer$1$PrepareImage.class -fPIC -o .libs/gtk-awt-peer.o gnu/java/awt/peer/gtk/GtkWindowPeer.java:0: fatal error: can't open gnu/java/awt/peer/gtk/GtkComponentPeer-B/home/jserv/build-gcj/./gcc/.class: No such file or directory compilation terminated. It seems that gnu/java/awt/peer/gtk/GtkComponentPeer$1$PrepareImage.class confuses gcj, so that I did a workaround to fix the issue (attached). -- Summary: Fail to build libjava under zh_TW.UTF-8 locale. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jserv at kaffe dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22283
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From hugh at mimosa dot com 2005-07-03 05:40 --- Simple rule about const and volatile qualifiers (not restrict): the program can manipulate pointer values with and without their qualifiers. But when the program accesses an object that is a volatile object (i.e. defined, created, or fundamentally volatile), it must be via a volatile lvalue. And when the program accesses an object that was created const (defined, created, or fundamentally const), then it must not be modifying it. Optimizers must not presume more. Well, there is a tricky rule about aliasing in N1124 section 6.5 (see footnote 74 on page 68), based on the unqualified types. But we're only talking about qualifiers. And another about multiple modifications between sequence points -- again, not relevant here. So I think that gcc4 is wrong for this case: the access should not be optimized out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug libgcj/22283] Fail to build libjava under zh_TW.UTF-8 locale.
--- Additional Comments From jserv at kaffe dot org 2005-07-03 05:19 --- Created an attachment (id=9196) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9196action=view) Fix the incorrect input filenames in the Makefile of libjava -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22283
[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding * omitted
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-03 05:52 --- *outside = avail; Because at this point avail is known not to volatile. Did you read what was writting in comment #1 and #4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding * omitted
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 04:55
---
Why was this bug closed? The testcases in comment 5 do *not* pass.
Here's the first testcase, fixed to compile cleanly:
int avail;
int main() {
volatile int **outside = (volatile int**)0x0123;
*outside = avail;
// avail is now potentially modifiable externally to the program
while (*(volatile int *)avail == 0)
continue;
return 0;
}
Following the reasoning of comment 5, the read in the loop must not be optimized
away. Still, gcc 4.0.0 with -O3 produces this:
...
movl$avail, 291
movlavail, %eax
testl %eax, %eax
je .L5
xorl%eax, %eax
leave
ret
.L5:
jmp .L5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
