C99 and C++0x status pages
Yesterday, I spent an hour looking for the C99 and C++0x status pages in http://gcc.gnu.org/, http://gcc.gnu.org/c99status.html http://gcc.gnu.org/projects/cxx0x.html Apparently, the shortest path to the latter is Releases - GCC 4.5.1 - GCC 4.5.1 Jul 31, 2010 (changes) - Improved experimental support for the upcoming C++0x - please see the C++0x in GCC project page Those are among the most useful pages of the site, it makes no sense to bury them 4+ levels deep. -- André Majorel http://www.teaser.fr/~amajorel/
Re: Add uninitialized attribute?
On 08/30/2010 03:50 PM, Vincent Lefevre wrote: On 2010-08-30 14:46:57 +0200, Michael Matz wrote: int x = x; is the way GCC offers this idiom since about forever, no need for an attribute. Downthread I see that people worry about this generating an actual (uninitialized) access to x. They are confused. This is not a good idea as int x = x; may really generate an (uninitialized) access to x with other compilers. Absolutely so. I suspect it's even undefined behaviour in the standard language. There's no way that this idiom should appear anywhere in GNU code. Andrew.
Re: C99 and C++0x status pages
Andre Majorel wrote: Those are among the most useful pages of the site, it makes no sense to bury them 4+ levels deep. Google is your friend: when asked for g++ c++0x it returns the correct page as the first result. I always use it that way, because website messiness appears to be a de facto Internet standard and GNU is well known for its standard conformance. ;-) Best regards, Piotr
RE: Clustering switch cases
I will be looking at the patch Rahul posted and will try to see if I can improve on it. See attached patch (again) that Paulo is referring to. Sending to GCC failed due to email client issues. I have another patch for http://gcc.gnu.org/ml/gcc/2010-08/msg00413.html Which I will send out shortly. Rahul switch_case_clusters.patch Description: switch_case_clusters.patch
Re: Add uninitialized attribute?
On 8/31/2010 1:19 AM, Andrew Haley wrote: On 08/30/2010 03:50 PM, Vincent Lefevre wrote: On 2010-08-30 14:46:57 +0200, Michael Matz wrote: int x = x; is the way GCC offers this idiom since about forever, no need for an attribute. Downthread I see that people worry about this generating an actual (uninitialized) access to x. They are confused. This is not a good idea as int x = x; may really generate an (uninitialized) access to x with other compilers. Absolutely so. I suspect it's even undefined behaviour in the standard language. There's no way that this idiom should appear anywhere in GNU code. I agree; an attribute, or the __unitialized__ keyword would be much cleaner. On the other hand, I think GCC should continue to accept int x = x; as a synonym for the forseeable future; whether or not it's good language design it has been a de facto part of GNU C for a long time. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
End of GCC 4.6 Stage 1: October 27, 2010
We (GCC RMs) plan to close GCC 4.6 Stage 1 on or or about October 27, 2010 (the closing day of the GCC Summit). Major features should be checked in prior to this point. Please let us know if you have a major feature that you think you will not be able to get checked in prior to October 27th. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: How is the definition of stack canary on MIPS arch?
On 08/30/2010 08:36 PM, Adam Jiang wrote: On Mon, Aug 30, 2010 at 10:43:44AM -0700, David Daney wrote: On 08/30/2010 09:46 AM, Richard Henderson wrote: On 08/30/2010 03:45 AM, Adam Jiang wrote: When I read the source in Linux kerne, it was said that stack canary for implementing stack protector is defined as an offset to %gs on x86 architecture. How about stack canary defined on MIPS? It's not implemented for MIPS. For the Linux kernel, the MIPS stack canary would be a constant offset (that depends on PAGE_SIZE) from register $28. David Daney Thanks, David and Richard. Is there code, doc or anything on this topic I can refer to? Is it defined in gcc internally or in kernel source itself? Would you please redirect me to the right place? I am unaware of any documents. The MIPS Linux kernel ABI is not really documented anywhere, one learns it by studying and hacking on the source code. 32-bit kernels use a variant of the o32 ABI, 64-bit kernels use a variant of n64. Both dedicate register $28 as a pointer to the thread area of which the stack is a part. The form any stack canary for the MIPS Linux kernel will be determined by whomever implements it. I have done some research by googling. Here are what I've gotten. http://www.trl.ibm.com/projects/security/ssp/main.html http://www.trl.ibm.com/projects/security/ssp/ http://lxr.linux.no/linux+v2.6.35/arch/x86/include/asm/stackprotector.h However, it seems there is no documents about how this is done on MIPS. Do I miss something? At RTH said, It's not implemented for MIPS., so there was really nothing to miss. David Daney
gcc-4.4-20100831 is now available
Snapshot gcc-4.4-20100831 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100831/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 163704 You'll find: gcc-4.4-20100831.tar.bz2 Complete GCC (includes all of below) MD5=d4dbb54668eda7795b8771495212e91d SHA1=9ca5123e526e070b611dd1c770156ce66c6cbbd0 gcc-core-4.4-20100831.tar.bz2C front end and core compiler MD5=acb6af2584c839f3d57682ff0acc95ae SHA1=3dfdd4ff3a6cdc8c387cc4cb9ace6bc5e0bf525f gcc-ada-4.4-20100831.tar.bz2 Ada front end and runtime MD5=35bb3a0c17697309dd9836356cb9263e SHA1=3ea7812b48eef0e207f9fa07d1db007ac9ee888d gcc-fortran-4.4-20100831.tar.bz2 Fortran front end and runtime MD5=945699f9818d680c59d784e020541959 SHA1=c3894a19d7ca05fdada77fd97506545f9a02f257 gcc-g++-4.4-20100831.tar.bz2 C++ front end and runtime MD5=af021b5be18edd854122b6e5a8cebf43 SHA1=f2096caa79ab4c572ad1e6ee96698d10aa3fd031 gcc-java-4.4-20100831.tar.bz2Java front end and runtime MD5=9fa798f47c730852fec53dfa4cadafcc SHA1=c78b9acf2b903e09084bd8c943c1020ef53babb6 gcc-objc-4.4-20100831.tar.bz2Objective-C front end and runtime MD5=8a00f268202cbb867a9fa3c0b38f2e3b SHA1=043054c0f8859b188a847910c76b13bad4638a43 gcc-testsuite-4.4-20100831.tar.bz2 The GCC testsuite MD5=c56fa452e043e6e1a1519578dab13af9 SHA1=42e432e95b7ea6a6bccbc436e11e511f210b84a2 Diffs from 4.4-20100824 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Clustering switch cases
In fact we might want to move switch optimization up to the tree level (just because it's way easier to deal with there). Thus, lower switch to a mixture of binary tree jump-tables (possibly using perfect hashing). Doing the optimisation at the tree-level was exactly my initial idea. By splitting the switches at the tree-level, before expand_case, would then allow for expand_case to transform it either to a jump table or binary tree depending on the situation. I'd kinda hope that doing the optimization at the tree level means expand_case doesn't have to handle both types. The tree code converts sparse case ranges to explicit conditionals (or a switch on a compact perfect hash), so anything left to RTL expansion must be a jump table. Paul
Atom 2010-Q3 SPEC CPU 2K results
H.J. gcc 4.6 Atom 2010-Q3.xlsx Description: gcc 4.6 Atom 2010-Q3.xlsx
Recall: Atom 2010-Q3 SPEC CPU 2K results
Lu, Hongjiu would like to recall the message, Atom 2010-Q3 SPEC CPU 2K results.
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2010-08-31 07:04 --- Using the proposed PR36502v2.patch, which eliminates any attempts to change the default stack boundary handling in gcc trunk, I find the following regressions at -m32 on x86_64-apple-darwin10... FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os (internal compiler error) FAIL: gcc.dg/nest.c execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O1 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -Os execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -fwhopr execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O1 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -Os execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -fwhopr execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O1 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -Os execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -fwhopr execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O1 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -Os execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -fwhopr execution test while eliminating PR36502 miscompilation of the add.c test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug bootstrap/45444] [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]
--- Comment #2 from ramana at gcc dot gnu dot org 2010-08-31 08:15 --- confirmed. I was working on fixing this but you beat my patch to it. cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-31 08:15:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45444
[Bug lto/44992] ld -r breaks LTO
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-08-31 09:13 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44992
[Bug lto/44992] ld -r breaks LTO
--- Comment #8 from andi-gcc at firstfloor dot org 2010-08-31 09:32 --- Sorry this is not fixed yet, only partially. Still working on the last bits, in particular passthrough of non LTOed code like assembler functions. -- andi-gcc at firstfloor dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44992
[Bug middle-end/45458] [4.5/4.6 Regression] ICE: in add_labels_and_missing_jumps, at bb-reorder.c:1306 with-fnon-call-exceptions -freorder-blocks-and-partition -fprofile-use
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE: in |[4.5/4.6 Regression] ICE: in |add_labels_and_missing_jumps|add_labels_and_missing_jumps |, at bb-reorder.c:1306 with-|, at bb-reorder.c:1306 with- |fnon-call-exceptions - |fnon-call-exceptions - |freorder-blocks-and-|freorder-blocks-and- |partition -fprofile-use |partition -fprofile-use Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45458
[Bug c/45457] [4.6 Regression] ICE: invalid built-in macro __DBL_DENORM_MIN__
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45457
[Bug rtl-optimization/45454] [4.6 Regression] ICE: in verify_target_availability, at sel-sched.c:1614
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45454
[Bug tree-optimization/45453] [4.6 Regression] ICE: verify_cgraph_node failed: inlined_to pointer set for noninline callers with -O2 -fno-early-inlining
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-31 09:56 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-31 09:56:10 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45453
[Bug testsuite/45455] gcc.dg/vect/vect-cond-4.c uses uninitialised variable
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-31 10:01 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45455
[Bug testsuite/45455] gcc.dg/vect/vect-cond-4.c uses uninitialised variable
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-31 10:01 --- Subject: Bug 45455 Author: rguenth Date: Tue Aug 31 10:01:04 2010 New Revision: 163669 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163669 Log: 2010-08-31 Richard Guenther rguent...@suse.de PR testsuite/45455 * gcc.dg/vect/vect-cond-4.c: Fix use of uninitialized variable. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-cond-4.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45455
[Bug middle-end/45461] New: [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg
Compiler output: $ gcc -fshort-enums testcase.c testcase.c: In function 'foo': testcase.c:12:29: warning: 'enum E' is promoted to 'int' when passed through '...' [enabled by default] testcase.c:12:29: note: (so you should pass 'int' not 'enum E' to 'va_arg') testcase.c:12:29: note: if this code is reached, the program will abort testcase.c:7:1: error: INDIRECT_REF in gimple IL e = *0B; testcase.c:7:1: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r163636 - crash r161659 - crash r161170 - OK 4.5 r160526 - OK -- Summary: [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45461
[Bug middle-end/45461] [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg
--- Comment #1 from zsojka at seznam dot cz 2010-08-31 10:12 --- Created an attachment (id=21600) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21600action=view) reduced testcase $ gcc -fshort-enums pr45461.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45461
[Bug middle-end/45461] [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-31 10:16:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45461
[Bug preprocessor/45457] [4.6 Regression] ICE: invalid built-in macro __DBL_DENORM_MIN__
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-31 11:24 --- Created an attachment (id=21601) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21601action=view) gcc46-pr45457.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45457
[Bug fortran/38282] Add the remaining HPF bit intrinsics
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2010-08-31 11:26 --- Patch submitted at http://gcc.gnu.org/ml/fortran/2010-08/msg00476.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortra ||n/2010-08/msg00476.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug target/39694] [4.4 only] -print-file-name doesn't work on mingw in 100%.
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.5.0 |4.5.0 4.6.0 Summary|-print-file-name doesn't|[4.4 only] -print-file-name |work on mingw in 100%. |doesn't work on mingw in ||100%. Target Milestone|--- |4.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39694
[Bug c++/45462] New: Bad optimization in -O3 sometimes
This bug was very hard to trace. I'm on the ScummVM dev team and I develop
specifically for the PSP(MIPS). I came across a crash when trying to start one
of our engines. The bug only occurred under very specific circumstances -- I
bisected it and adding class variables or adding some code made it go away, but
I'm not sure what the pattern is.
Here's the problematic code, packaged together easily:
void Logic::logicUp(uint32 new_script) {
debug(5, new pc = %d, new_script 0x);
// going up a level - and we'll keep going this cycle
_curObjectHub.setLogicLevel(_curObjectHub.getLogicLevel() + 1);
assert(_curObjectHub.getLogicLevel() 3); // Can be 0, 1, 2
logicReplace(new_script);
}
void Logic::logicReplace(uint32 new_script) {
uint32 level = _curObjectHub.getLogicLevel();
_curObjectHub.setScriptId(level, new_script);
_curObjectHub.setScriptPc(level, new_script 0x);
}
void setScriptId(int level, uint32 x) {
WRITE_LE_UINT32(_addr + 20 + 4 * level, x);
}
uint32 getScriptId(int level) {
return READ_LE_UINT32(_addr + 20 + 4 * level);
}
void setScriptPc(int level, uint32 x) {
WRITE_LE_UINT32(_addr + 32 + 4 * level, x);
}
G++ optimized these 2 functions into 1 and came up with this code:
8934bc0 _ZN6Sword25Logic7logicUpEj:
8934bc0: 27bdfff0addiu sp,sp,-16
8934bc4: afb20008sw s2,8(sp)
8934bc8: afb10004sw s1,4(sp)
8934bcc: 30b2andis2,a1,0x # s2 = new_scip 0x
8934bd0: 00a08821moves1,a1 # s1 = new_scipt
8934bd4: 3c0508aalui a1,0x8aa # a1 = 0x8aa
8934bd8: afb0sw s0,0(sp)
8934bdc: 24a50d68addiu a1,a1,3432 # a1 = 0x8aa3432
8934be0: 00808021moves0,a0 # s0 = this
8934be4: 02403021movea2,s2 # a2 = new_script 0x
8934be8: afbf000csw ra,12(sp)
8934bec: 0e286377jal 8a18ddc _Z5debugiPKcz
8934bf0: 24040005li a0,5 # a0 = 5 (jump)
8934bf4: 8e0400d8lw a0,216(s0) # a0 = *(this + 216)
8934bf8: 88850007lwl a1,7(a0) # a1 =
8934bfc: 98850004lwr a1,4(a0) # a1 = logicLevel
8934c00: 24a20001addiu v0,a1,1 # v0 = logicLevel + 1
8934c04: a8820007swl v0,7(a0) # 7(a0) = 0.5 new logicLevel
8934c08: 2ca30003sltiu v1,a1,3 # v1 = a1 3?
8934c0c: 10600011beqzv1,8934c54
_ZN6Sword25Logic7logicUpEj+0x94 # assert
8934c10: b8820004swr v0,4(a0) # 4(a0) = 0.5 new logicLevel
8934c14: 24a20005addiu v0,a1,5 # v0 = logicLevel + 5 ???
8934c18: 00021080sll v0,v0,0x2 # v0 = 4*logicLevel + 20
(scriptId offset)
8934c1c: 00821021adduv0,a0,v0 # v0 = scriptId
8934c20: 24a30008addiu v1,a1,8 # v1 = logicLevel + 8
8934c24: a8510003swl s1,3(v0) # scriptId[3] = new_script
8934c28: 00031880sll v1,v1,0x2 # v1 = logicLevel * 4 + 32
8934c2c: b851swr s1,0(v0) # scriptId[0] = new_script
8934c30: 00831821adduv1,a0,v1 # v1 = *(this + 216)
Note the mistake in line 8934c00. v0 is used for incrementing the
logicLevel, and v0 is indeed saved into memory (ie.
_curObjectHub.setLogicLevel(_curObjectHub.getLogicLevel() + 1); )
But the optimization gcc made prevents it from realizing it needs to
use the newly incremented logicLevel value for the other calculations,
so instead it keeps using a1 in the rest of the function. This causes
it to write the new scriptId value in the wrong place, which causes
the VM to think its next scriptId is 0.
I'd like to attach the .ii files but I don't know how (can't find a button for
it). You can see the full code at
https://scummvm.svn.sourceforge.net/svnroot/scummvm/scummvm. The 'problem' code
is under the engines/sword2 directory in header.h, logic.cpp and function.cpp.
This bug does not happen on any other platform as far as I know, but there's a
huge random element involved regarding a particular memory layout.
Thanks
Yotam Barnoy
--
Summary: Bad optimization in -O3 sometimes
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yotambarnoy at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug rtl-optimization/45353] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-08-31 11:52 --- Subject: Bug 45353 Author: ebotcazou Date: Tue Aug 31 11:52:01 2010 New Revision: 163670 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163670 Log: Backport from mainline 2010-08-20 Jakub Jelinek ja...@redhat.com PR rtl-optimization/45353 * sel-sched-ir.c (sel_bb_head): Return NULL even if next_nonnote_insn after bb_note is a BARRIER. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched-ir.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45353
[Bug c++/45462] Bad optimization in -O3 sometimes
--- Comment #1 from yotambarnoy at gmail dot com 2010-08-31 11:52 --- Created an attachment (id=21602) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21602action=view) Logic.ii, where gcc makes the mistake LogicUp() is the critical function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug rtl-optimization/45353] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-08-31 11:53 --- On the 4.5 branch as well. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45353
[Bug c++/45462] Bad optimization in -O3 sometimes
--- Comment #2 from yotambarnoy at gmail dot com 2010-08-31 11:53 --- Created an attachment (id=21603) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21603action=view) header.h, used by logic.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug middle-end/45461] [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-31 11:55 --- Created an attachment (id=21604) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21604action=view) gcc46-pr45461.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45461
[Bug target/45452] Change default link order for x86_64-mingw32
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-08-31 12:17 --- Ok, patch sent to gcc's ML. This issue can lead to troubles on Windows OSes Vista or newer. But this bug isn't just x86_64-*-mingw32 one. It affects (if more recent import-libraries are used) even 32-bit mingw and cygwin, too. I addressed this in the patch I've sent. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 GCC target triplet|x86_64-w64-mingw32 |*-*-mingw* i686-*-cygwin Last reconfirmed|-00-00 00:00:00 |2010-08-31 12:17:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45452
[Bug fortran/45463] New: gfortran internal write bug
Consider the following code: program test implicit none character(40) line line = 'Hello World!' write (line, '(i3, 2x, a)') 7, trim(line) print *, line end program With the gfortran compiler (v4.5.1) the output is: 77lo World! I would expect the output to be 7 Hello World! -- David -- Summary: gfortran internal write bug Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: david dot sagan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45463
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2010-08-31 12:57 --- Testresults for PR36502v2.patch at http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg03098.html. It appears that the only additional failures triggered by this patch are listed in comment 11. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug fortran/45463] gfortran internal write bug
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-31 13:28 --- Did you see the responses to your post in c.l.f? It seems that your program is non-conforming. I leave the PR open until either I or someone else has time to verify the conformity of the program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45463
[Bug target/39694] -print-file-name doesn't work on mingw in 100%.
--- Comment #2 from pluto at agmk dot net 2010-08-31 13:45 --- no, it still doesn't work with 4.5.2 on linux hosted cross compiler. gcc finds libgcc_s pretty well during linking: % /local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/bin/i686-pc-mingw32-gcc t.c -shared-libgcc -Wl,--verbose|egrep 'libgcc.*succeeded'|sort|uniq attempt to open /local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/4.5.2/libgcc.a succeeded attempt to open /local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/libgcc_s.a succeeded but -print-file-name=libgcc_s.a doesn't work. maybe it's related to cygwin vs. linux compiler hosting? % /local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/bin/i686-pc-mingw32-g++ -v Using built-in specs. COLLECT_GCC=/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/bin/i686-pc-mingw32-g++ COLLECT_LTO_WRAPPER=/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/4.5.2/lto-wrapper Target: i686-pc-mingw32 Configured with: ../configure --target=i686-pc-mingw32 --with-arch=i686 --prefix=/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc --with-sysroot=/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc --libdir=/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib --libexecdir=/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib --with-slibdir=/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib --with-gmp-include=/home/pawels/toolchain/trunk/gcc-math-runtime/include --with-gmp-lib=/home/pawels/toolchain/trunk/gcc-math-runtime/lib --with-mpfr-include=/home/pawels/toolchain/trunk/gcc-math-runtime/include --with-mpfr-lib=/home/pawels/toolchain/trunk/gcc-math-runtime/lib --with-mpc-include=/home/pawels/toolchain/trunk/gcc-math-runtime/include --with-mpc-lib=/home/pawels/toolchain/trunk/gcc-math-runtime/lib --disable-multilib --disable-nls --disable-libgomp --disable-libmudflap --disable-libssp --enable-tls --enable-libstdcxx-allocator=mt --disable-libstdcxx-pch --disable-lto --disable-plugin --enable-c99 --enable-long-long --disable-win32-registry --enable-threads=win32 --disable-sjlj-exceptions --enable-shared --enable-fully-dynamic-string --enable-__cxa_atexit --enable-languages=c,c++ --enable-checking=release --disable-symvers --with-long-double-128 --disable-cld --disable-bootstrap Thread model: win32 gcc version 4.5.2 20100813 (prerelease) (GCC) % /local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/bin/i686-pc-mingw32-g++ -print-file-name=libgcc_s.a libgcc_s.a % /local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/bin/i686-pc-mingw32-g++ -print-file-name=libgcc.a /local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/4.5.2/libgcc.a % /local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/bin/i686-pc-mingw32-g++ -print-search-dirs install: /local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/4.5.2/ programs: =/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/4.5.2/:/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/4.5.2/:/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/:/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/4.5.2/:/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/:/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/4.5.2/../../../../i686-pc-mingw32/bin/i686-pc-mingw32/4.5.2/:/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/4.5.2/../../../../i686-pc-mingw32/bin/ libraries: =/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/4.5.2/:/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/4.5.2/../../../../i686-pc-mingw32/lib/i686-pc-mingw32/4.5.2/:/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/lib/gcc/i686-pc-mingw32/4.5.2/../../../../i686-pc-mingw32/lib/:/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/mingw/lib/i686-pc-mingw32/4.5.2/:/local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/mingw/lib/ -- pluto at agmk dot net changed: What|Removed |Added Known to fail|4.4.0 |4.4.0 4.5.0 Known to work|4.5.0 4.6.0 | Summary|[4.4 only] -print-file-name |-print-file-name doesn't |doesn't work on mingw in|work on mingw in 100%. |100%. | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39694
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #13 from hjl dot tools at gmail dot com 2010-08-31 13:48 --- (In reply to comment #9) Created an attachment (id=21599) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21599action=view) [edit] rely on PREFERRED_STACK_BOUNDARY_DEFAULT for intel darwin You should keep #undef MAIN_STACK_BOUNDARY #define MAIN_STACK_BOUNDARY 128 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug c++/45464] New: Warning missing using -Wall when comparing unsigned int and sum of unsigned chars.
The following code will warn for line 6 but not for line 5, however, I
_think_the type of a + a + a is the same as the type of a + a.
int main()
{
unsigned char a=0;
unsigned int b =0;
bool test1 =( b a + a);//no warning, why
bool test2 =( b a + a + a);//warning
if (wtf1 wtf2) return 1;
}
--
Summary: Warning missing using -Wall when comparing unsigned int
and sum of unsigned chars.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brutus at free dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45464
[Bug c++/45464] Warning missing using -Wall when comparing unsigned int and sum of unsigned chars.
--- Comment #1 from brutus at free dot fr 2010-08-31 13:53 ---
There is a small mystake to the snippet, it should read instead:
int main()
{
unsigned char a = 0;
unsigned int b = 0;
bool test1 =( b a + a);
bool test2 =( b a + a + a);
if (test1 test2) return 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45464
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #14 from hjl dot tools at gmail dot com 2010-08-31 13:54 --- (In reply to comment #12) Testresults for PR36502v2.patch at http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg03098.html. It appears that the only additional failures triggered by this patch are listed in comment 11. Please try this patch: http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01916.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug target/44606] Wrong SPE floating point during computation
--- Comment #5 from Kyle dot D dot Moffett at boeing dot com 2010-08-31 14:03 --- Created an attachment (id=21605) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21605action=view) Further stripped testcase with problematic section identified Ok, I've spent a bit more time fiddling with this testcase, and I believe I can display exactly where the bug happens. In the attached test.c file, you can see a section like this: saved_r = total_r; saved_g = total_g; saved_b = total_b; Minify(2*x + 10, 15.0); save2_r = total_r; save2_g = total_g; save2_b = total_b; The Minify() macro is supposed to add nonzero values to total_[rgb] but when compiled with -O2 (or -O1 and a few extra optimizations) the values of save2_[rgb] are the same as those of saved_[rgb]. I'm also attaching a Makefile I used while testing this program. In the Makefile I enable -O1 and then turn off every optimization pass that is not strictly necessary to reproduce the bug. The Makefile simply builds 2 copies of the program, one with -O0 and one with -O2, then runs them and compares their output. Some kind of loop optimization or unrolling seems to be involved. The specific optimizations which are mandatory for the bug to show up are below, if any of these is turned off the bug seems to go away: -fdce -fguess-branch-probability -fschedule-insns -ftree-ch -ftree-dominator-opts -ftree-loop-optimize Cheers, Kyle Moffett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
[Bug target/44606] Wrong SPE floating point during computation
--- Comment #6 from Kyle dot D dot Moffett at boeing dot com 2010-08-31 14:04 --- Created an attachment (id=21606) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21606action=view) Makefile for test.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #5 from sfilippone at uniroma2 dot it 2010-08-31 14:04 --- (In reply to comment #4) Ok, I could reduce this quite a bit: Good :) In the meantime, I tried with MOLD= in place of SOURCE=, and in the full application it still gives a segfault; I think that variant should be checked as well. Actually, MOLD= is preferrable for the kind of thing I am doing, but since it's an F2008 feature I had to put it under IFDEF for the time being. Salvatore -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-31 14:17 --- (In reply to comment #5) In the meantime, I tried with MOLD= in place of SOURCE=, and in the full application it still gives a segfault; I think that variant should be checked as well. Note that for MOLD there is PR 44541 left (which I am about to fix). Up to now MOLD works only with non-polymorphic expressions. Once the PR is fixed, polymorphics should work too. Until this has happened, please refrain from opening further PRs on MOLD. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug c++/45462] Bad optimization in -O3 sometimes
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-31 14:17 ---
inline __attribute__((__always_inline__)) uint32 READ_UINT32(const void *ptr)
{
struct Unaligned32 { uint32 val; } __attribute__ ((__packed__));
return ((const Unaligned32 *)ptr)-val;
}
and similar look like they might violate C aliasing rules. Try using
-fno-strict-aliasing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #7 from sfilippone at uniroma2 dot it 2010-08-31 14:18 --- (In reply to comment #6) Note that for MOLD there is PR 44541 left (which I am about to fix). Up to now MOLD works only with non-polymorphic expressions. Once the PR is fixed, polymorphics should work too. Until this has happened, please refrain from opening further PRs on MOLD. Fine. Waiting for it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug middle-end/45461] [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-31 14:19 --- Looks obvious. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45461
[Bug fortran/45463] gfortran internal write bug
--- Comment #2 from david dot sagan at gmail dot com 2010-08-31 14:20 --- (In reply to comment #1) Did you see the responses to your post in c.l.f? It seems that your program is non-conforming. I leave the PR open until either I or someone else has time to verify the conformity of the program. Sorry. When I looked after I had posted the question there was only one response and that response said it was a bug so I submitted this bug report. Now other people have posted saying that the program is non-conforming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45463
[Bug preprocessor/41943] include search path composition is bogus
--- Comment #9 from ktietz at gcc dot gnu dot org 2010-08-31 14:31 --- Fixed on trunk and won't be backported to 4.5.x, therefore I close this bug -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41943
[Bug fortran/45463] gfortran internal write bug
--- Comment #3 from david dot sagan at gmail dot com 2010-08-31 14:32 --- (In reply to comment #2) Sorry. When I looked after I had posted the question there was only one response and that response said it was a bug so I submitted this bug report. Now other people have posted saying that the program is non-conforming. Update: More responses in comp.lang.fortran bring up the point that if trim(line) is supposed to return a temporary, the code might be conforming. Seems that the situation is not clear... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45463
[Bug c++/45462] Bad optimization in -O3 sometimes
--- Comment #4 from yotambarnoy at gmail dot com 2010-08-31 15:24 --- Good job picking up on that. There must be a better way of telling the compiler to generate lwr and lwl MIPS instructions without breaking strict aliasing rules...? Thanks a bunch! -- yotambarnoy at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2010-08-31 15:39 --- Created an attachment (id=21607) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21607action=view) rely on PREFERRED_STACK_BOUNDARY_DEFAULT and MAIN_STACK_BOUNDARY -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2010-08-31 15:48 --- (In reply to comment #14) Please try this patch: http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01916.html With the patch above and PR36502v3.patch, I still get... FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os (internal compiler error) which appears as... Executing on host: /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100830/gcc/testsuite/gcc.c-torture/execute/builtins/sprintf-chk.c /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100830/gcc/testsuite/gcc.c-torture/execute/builtins/sprintf-chk-lib.c /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100830/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -Os -lm -m32 -o /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/gcc/sprintf-chk.x7 (timeout = 300) /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100830/gcc/testsuite/gcc.c-torture/execute/builtins/sprintf-chk.c:197:1: internal compiler error: in div_data_align, at dwarf2out.c:595 Interestingly, if I run... /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/cc1 -quiet -v -imultilib i386 -iprefix /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/ -isystem /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/include -isystem /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/include-fixed -D__DYNAMIC__ /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100830/gcc/testsuite/gcc.c-torture/execute/builtins/sprintf-chk.c -fPIC -quiet -dumpbase sprintf-chk.c -mmacosx-version-min=10.6.5 -m32 -mtune=generic -auxbase sprintf-chk -Os -w -version -o /var/tmp//ccVmszmK.s (obtained with -v) through gdb, the crash is suppressed and the result sprintf-chk.x7 binary executes fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug middle-end/45461] [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-31 16:13 --- Subject: Bug 45461 Author: jakub Date: Tue Aug 31 16:13:14 2010 New Revision: 163678 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163678 Log: PR middle-end/45461 * builtins.c (dummy_object): Return a MEM_REF instead of INDIRECT_REF. * gcc.dg/pr45461.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr45461.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45461
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2010-08-31 16:30 --- With http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01916.html and the patch in comment 15, I am also still failing at -m32 on x86_64-apple-darwin10... FAIL: gcc.dg/nest.c execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O1 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -Os execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -fwhopr execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O1 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -Os execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -fwhopr execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O1 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -Os execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -fwhopr execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O1 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -Os execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -flto execution test FAIL: gcc.dg/torture/stackalign/alloca-4.c -O2 -fwhopr execution test as well as a new additional failure of... FAIL: gcc.target/i386/stack-usage-realign.c scan-file main\t48\tdynamic,bounded which wasn't present with just the patch from comment 11. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2010-08-31 16:36 --- Created an attachment (id=21608) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21608action=view) assembly from failing gcc.dg/nest.c execution test at -m32 on x86_64-apple-darwin10 Generated with... /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100830/gcc/testsuite/gcc.dg/nest.c -O2 -pg -lm -m32 --save-temps -o ./nest.exe using a gcc built with the patches from comments 14 and 15. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug fortran/45463] gfortran internal write bug
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-31 16:40 --- (In reply to comment #3) (In reply to comment #2) Sorry. When I looked after I had posted the question there was only one response and that response said it was a bug so I submitted this bug report. Now other people have posted saying that the program is non-conforming. Update: More responses in comp.lang.fortran bring up the point that if trim(line) is supposed to return a temporary, the code might be conforming. Seems that the situation is not clear... IMNSHO, it's not conforming. trim(line) is associated with line. I don't see how one could interpret the standard in in other way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45463
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2010-08-31 16:41 --- (In reply to comment #18) In gdb, the failing nest.exe exection shows... Starting program: /Users/howarth/stack_align_bug2/nest.exe Reading symbols for shared libraries ++. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x 0x931e6f30 in misaligned_stack_error_ () (gdb) bt #0 0x931e6f30 in misaligned_stack_error_ () #1 0x93293cc4 in monstartup () #2 0x1e9e in main () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2010-08-31 16:42 --- Created an attachment (id=21609) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21609action=view) assembly from failing gcc.dg/torture/stackalign/alloca-4.c -O1 execution test at -m32 on x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2010-08-31 16:46 --- (In reply to comment #20) Created alloca-4.s with... /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100830/gcc/testsuite/gcc.dg/torture/stackalign/alloca-4.c -O1 -m32 -mincoming-stack-boundary=2 -mpreferred-stack-boundary=2 -lm -m32 --save-temps -o ./alloca-4.exe against patches from comments 14 and 15. The test case backtraces in gdb as... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x 0x931e6f30 in misaligned_stack_error_ () (gdb) bt #0 0x931e6f30 in misaligned_stack_error_ () #1 0x8fe0c582 in __dyld__ZL9commatizeyPc () #2 0x1db5 in bar (p=0xb340 , size=5) at /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100830/gcc/testsuite/gcc.dg/torture/stackalign/alloca-4.c:10 #3 0x1e7b in main () at /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100830/gcc/testsuite/gcc.dg/torture/stackalign/alloca-4.c:38 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug middle-end/45461] [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-31 16:47 --- 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=45461
[Bug fortran/45463] gfortran internal write bug
--- Comment #5 from kargl at gcc dot gnu dot org 2010-08-31 16:49 --- (In reply to comment #4) (In reply to comment #3) (In reply to comment #2) Sorry. When I looked after I had posted the question there was only one response and that response said it was a bug so I submitted this bug report. Now other people have posted saying that the program is non-conforming. Update: More responses in comp.lang.fortran bring up the point that if trim(line) is supposed to return a temporary, the code might be conforming. Seems that the situation is not clear... IMNSHO, it's not conforming. trim(line) is associated with line. I don't see how one could interpret the standard in in other way. In fact, 16.5.7 in F2003, is fairly unambiguous. The code is nonconforming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45463
[Bug debug/45465] New: Wrong type reported by gdb
This is a somewhat curious issue as one needs fairly recent gcc (= 4.5) _and_
gdb ( 2010-07-29 ) to reproduce.
- snip -
#!/bin/sh
# To reproduce:
# - use g++ 4.5 or 4.6 (but not 4.4)
# - use gdb from CVS from 2010-07-29 or newer
echo
templatetypename _ForwardIterator
void x(_ForwardIterator __first)
{
}
templatetypename T
struct vector
{
T* _M_start;
vector() { x(_M_start); }
};
struct foo {};
int main()
{
vectorfoo flist;
foo *f = new foo;
}
foo.cpp
CXX=/usr/local/bin/i686-pc-linux-gnu-g++-4.5.0
CXX=/usr/bin/g++
CXX=/usr/local/bin/i686-pc-linux-gnu-g++-4.6.0
${CXX} -g foo.cpp -o foo
GDB=~/bin/gdb-7.1 # works
GDB=~/bin/gdb-7.0 # works
GDB=~/debugger/fsf-git/gdb/gdb # fails
${GDB} -ex 'set confirm off' \
-ex 'b main' -ex 'run' -ex 'p f' -ex 'q'\
./foo
# GNU gdb (GDB) 7.2.50.20100728-cvs
# [...]
# Breakpoint 1 at 0x80486d2: file foo.cpp, line 18.
# Breakpoint 1, main () at foo.cpp:18
# #18 foo *f = new foo;
# $1 = (_ForwardIterator) 0x402b8ff4
- snip -
The type 'ForwardIterator' is wrong, should be (foo *)
--
Summary: Wrong type reported by gdb
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andre dot poenitz at nokia dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45465
[Bug debug/45465] Wrong type reported by gdb
--- Comment #1 from andre dot poenitz at nokia dot com 2010-08-31 17:08 --- This is also tracked on gdb's bugzilla as http://sourceware.org/bugzilla/show_bug.cgi?id=11961 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45465
[Bug debug/45465] Wrong type reported by gdb
--- Comment #2 from andre dot poenitz at nokia dot com 2010-08-31 17:08 --- This is now also tracked on the gcc bugzilla as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45465 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45465
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #26 from andrew at atrens dot ca 2010-08-31 17:14 --- (In reply to comment #25) try -march=i686 it should be the best What about the fact that Geode LX does not have a NOPL instruction, while i686 does. Couldn't that result in binaries that crash? --Andrew -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #28 from jason at gcc dot gnu dot org 2010-08-31 17:26 --- (In reply to comment #18) The optimization question in Comment #11 was answered incorrectly. The C++ standard in fact requires that Y be initialized before the constructor is run; see [basic.start.init]. I disagree. In C++03, [basic.start.init] says Objects of POD types (3.9) with static storage duration initialized with constant expressions (5.19) shall be initialized before any dynamic initialization takes place. 5.19 [expr.const] says An arithmetic constant expression shall satisfy the requirements for an integral constant expression, except that floating literals need not be cast to integral or enumeration type, and conversions to floating point types are permitted. Note that this does not allow an arithmetic constant expression to involve const variables of floating point type, so X + 2.0 is not an arithmetic constant expression, so Y is not required to have static initialization. But it is allowed to, as explained in comment #14. I think this distinction is not observable in C++03. But with C++0x constexpr it is; declaring Y as constexpr would be ill-formed unless X is also declared constexpr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug fortran/45466] New: Bus Error: C program calls Fortran Function which has returned value as Character string
The program will crash if compile with version 4.4.3 or 4.3.2 but works with
4.1.2.
Main program is written in C. (see the following)
/*
* C file passdouble.c
* To compile the program, using the following command.
*gcc passdouble.c requestdouble.o -lgfortran
*/
#include stdio.h
extern char* requestdouble_(double*,double*);
int main()
{
double lat=10.0;
double lon=20.0;
requestdouble_(lat,lon);
return 0;
}
The Fortran function is in the file requestdouble.f90 shown below.
! gfortran -c -g -Wall requestdouble.f90
FUNCTION requestdouble(rlat,rlng)
!
IMPLICIT NONE
!
! Arguments
!
! Input scalars
REAL(KIND=8), INTENT(IN) :: rlat ! - latitude -
REAL(KIND=8), INTENT(IN) :: rlng ! - longitude -
!
CHARACTER(LEN=16) :: requestdouble
!
PRINT *, ' requestdouble rlat=',rlat,' rlng=',rlng
requestdouble=''
RETURN
END FUNCTION requestdouble
Here is how it compiled and ran.
gfortran -c -g -Wall requestdouble.f90
gcc passdouble.c requestdouble.o -lgfortran
a.out
Bus error
--
Summary: Bus Error: C program calls Fortran Function which has
returned value as Character string
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Lulin dot Song at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #13 from paolo at gcc dot gnu dot org 2010-08-31 17:40 --- Subject: Bug 44480 Author: paolo Date: Tue Aug 31 17:39:51 2010 New Revision: 163686 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163686 Log: 2010-08-31 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/44480 * include/bits/hashtable.h (_Hashtable::_M_begin_bucket_index): Add, caching the index of the first non-empty bucket. (begin, cbegin): Use it. (_Hashtable::_Hashtable(_InputIterator, _InputIterator, ...), _Hashtable(const _Hashtable), _Hashtable(_Hashtable), swap(_Hashtable), clear): Adjust. (_M_insert_bucket, _M_insert, erase(const_iterator), erase(const key_type), _M_rehash): Update it. * include/bits/hashtable.h (_Hashtable::_M_erase): Remove. (erase(const_iterator)): Inline the latter. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #29 from mmitchel at gcc dot gnu dot org 2010-08-31 17:41 --- Jason -- I can't argue with that as a literal reading of the standard, but is there any reason why the standard doesn't allow const float variables in (not necessarily integral) constant expressions just as we allow const int variables? -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #14 from paolo dot carlini at oracle dot com 2010-08-31 17:41 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.
--- Comment #26 from davidxl at gcc dot gnu dot org 2010-08-31 17:45 --- Good observation re. the number of IVs in the final set. This usually points to some problem/bug in the cost function. I briefly looked at this case -- it indeed exposes two more bugs in the cost model: 1) the computation cost of the all the cost pairs in an assignment can actually not simply be added together, because many rewrite expressions can be commoned. We now have the mechanism to compute with common loop invariants for register pressure estimation, and this mechnasim needs to be extended for computation cost. 2) the offset is not stripped when computing loop invariant expression ids -- this can cause problem in overestimating reg pressure. (The case arises more often with loop unrolling). David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-31 17:45 --- I think the return value for character(16) returns are passed via the first argument. So I think this is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #2 from kargl at gcc dot gnu dot org 2010-08-31 17:53 ---
Try compiling with -fdump-tree-original and inspecting the
expected argument lists. You really don't want to use a
function here. Use a subroutine.
include stdio.h
void requestdouble_(double*, double*, char *, int *len);
int main()
{
char str[20];
int len;
double lat=10.0;
double lon=20.0;
requestdouble_(lat, lon, str, len);
return 0;
}
subroutine requestdouble(rlat,rlng,str)
IMPLICIT NONE
REAL(KIND=8), INTENT(IN) :: rlat ! - latitude -
REAL(KIND=8), INTENT(IN) :: rlng ! - longitude -
CHARACTER(LEN=*) :: str
PRINT *, ' requestdouble rlat=', rlat,' rlng=', rlng
str=''
RETURN
END subroutine requestdouble
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #3 from kargl at gcc dot gnu dot org 2010-08-31 17:53 --- Closing as INVALID. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #4 from Lulin dot Song at gmail dot com 2010-08-31 18:02 --- (In reply to comment #1) I think the return value for character(16) returns are passed via the first argument. So I think this is invalid. If the return value of function 'requestdouble' is changed to be integer or double, the program will work. Do you mean that only if the return value is character string, then it will be passed back through first argument (at 'rlat' posistion)? Confused.(In reply to comment #1) I think the return value for character(16) returns are passed via the first argument. So I think this is invalid. If the return value of function 'requestdouble' is changed to be integer or double, the program will work. Do you mean that only if the return value is character string, then it will be passed back through first argument (at 'rlat' posistion)? Confused. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #27 from rootkit85 at yahoo dot it 2010-08-31 18:02 --- you could try but i'm not sure that NOPL is mandatory for the i686 arch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #5 from Lulin dot Song at gmail dot com 2010-08-31 18:06
---
(In reply to comment #2)
Try compiling with -fdump-tree-original and inspecting the
expected argument lists. You really don't want to use a
function here. Use a subroutine.
include stdio.h
void requestdouble_(double*, double*, char *, int *len);
int main()
{
char str[20];
int len;
double lat=10.0;
double lon=20.0;
requestdouble_(lat, lon, str, len);
return 0;
}
subroutine requestdouble(rlat,rlng,str)
IMPLICIT NONE
REAL(KIND=8), INTENT(IN) :: rlat ! - latitude -
REAL(KIND=8), INTENT(IN) :: rlng ! - longitude -
CHARACTER(LEN=*) :: str
PRINT *, ' requestdouble rlat=', rlat,' rlng=', rlng
str=''
RETURN
END subroutine requestdouble
Thanks. I do know how to work around it with subroutine which I already did in
my program. But it doesn't explain why 4.1.2 version allows return character
string from function. Our program works well until the gcc upgrade.
Is this new standard?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug debug/41736] missing DW_TAG_template_*_ in some cases
--- Comment #4 from tromey at gcc dot gnu dot org 2010-08-31 18:33 --- Created an attachment (id=21610) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21610action=view) a simple test case I'm attaching temargs.cc, a simple test case from the gdb test suite. I compiled this with today's svn trunk gcc. When I dump the resulting DWARF I see good results for Basedouble, ...: 147: Abbrev Number: 5 (DW_TAG_structure_type) 48 DW_AT_name: (indirect string, offset: 0x43): Basedouble, 23, ( a_global), S::f 4c DW_AT_byte_size : 1 4d DW_AT_decl_file : 1 4e DW_AT_decl_line : 29 4f DW_AT_sibling : 0xb4 253: Abbrev Number: 6 (DW_TAG_template_type_param) 54 DW_AT_name: T 56 DW_AT_type: 0xb4 [...] But I don't see the right results for Baselong, It is missing all the template parameters: 1d0: Abbrev Number: 5 (DW_TAG_structure_type) d1 DW_AT_name: (indirect string, offset: 0x191): Baselong int, 47, ( a_global), S::f d5 DW_AT_byte_size : 1 d6 DW_AT_decl_file : 1 d7 DW_AT_decl_line : 29 d8 DW_AT_sibling : 0x105 2dc: Abbrev Number: 16 (DW_TAG_structure_type) dd DW_AT_name: (indirect string, offset: 0x157): Innerfloat e1 DW_AT_byte_size : 1 e2 DW_AT_decl_file : 1 e3 DW_AT_decl_line : 32 3e4: Abbrev Number: 6 (DW_TAG_template_type_param) e5 DW_AT_name: Z e7 DW_AT_type: 0x10c 3eb: Abbrev Number: 12 (DW_TAG_subprogram) ec DW_AT_external: 1 ed DW_AT_name: (indirect string, offset: 0xa8): inner_m f1 DW_AT_decl_file : 1 f2 DW_AT_decl_line : 34 f3 DW_AT_MIPS_linkage_name: (indirect string, offset: 0xb0): _ZN4BaseIlLi47EXadL_Z8a_globalEEXadL_ZN1S1f5InnerIfE7inner_mEv f7 DW_AT_declaration : 1 f8 DW_AT_object_pointer: 0xfc 4fc: Abbrev Number: 11 (DW_TAG_formal_parameter) fd DW_AT_type: 0x113 101 DW_AT_artificial : 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41736
[Bug tree-optimization/45314] [4.5/4.6 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange
--- Comment #3 from bero at arklinux dot org 2010-08-31 18:48 --- Created an attachment (id=21611) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21611action=view) (fairly stupid) Workaround Attaching workaround for people coming across this bug report when googling the error message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45314
[Bug fortran/38282] Add the remaining HPF bit intrinsics
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2010-08-31 18:57
---
Subject: Bug 38282
Author: fxcoudert
Date: Tue Aug 31 18:56:46 2010
New Revision: 163691
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163691
Log:
PR fortran/38282
* f95-lang.c (gfc_init_builtin_functions): Define popcount{,l,ll}
and parity{,l,ll} builtins.
* trans-intrinsic.c (gfc_conv_intrinsic_popcnt_poppar): New function.
(gfc_conv_intrinsic_function): Call above new functions.
* simplify.c (gfc_simplify_popcnt, gfc_simplify_poppar): New
functions.
* intrinsic.texi: Document POPCNT and POPPAR.
* gfortran.dg/popcnt_poppar_1.F90: New test.
* gfortran.dg/popcnt_poppar_2.F90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/popcnt_poppar_1.F90
trunk/gcc/testsuite/gfortran.dg/popcnt_poppar_2.F90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/f95-lang.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/intrinsic.h
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug tree-optimization/45412] [4.6 Regression] ICE: SIGSEGV in update_ssa (tree-flow-inline.h:479) with -O2 -fipa-cp-clone -ftracer
--- Comment #4 from zsojka at seznam dot cz 2010-08-31 19:07 --- Created an attachment (id=21612) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21612action=view) different testcase, probably better This one needs only -O2 to reproduce: $ valgrind -q --trace-children=yes gcc -O2 pr45412-2.c ... ==32673== Invalid read of size 8 ==32673==at 0x8F1D95: update_ssa (tree-flow-inline.h:479) ==32673==by 0x7BDA67: execute_function_todo (passes.c:1206) ==32673==by 0x7BE07E: execute_todo (passes.c:1283) ==32673==by 0x7C0739: execute_one_pass (passes.c:1591) ==32673==by 0x7C0964: execute_pass_list (passes.c:1623) ==32673==by 0x7C0976: execute_pass_list (passes.c:1624) ==32673==by 0x903E45: tree_rest_of_compilation (tree-optimize.c:452) ==32673==by 0xAC0C05: cgraph_expand_function (cgraphunit.c:1469) ==32673==by 0xAC3609: cgraph_optimize (cgraphunit.c:1548) ==32673==by 0xAC3B59: cgraph_finalize_compilation_unit (cgraphunit.c:1012) ==32673==by 0x4E0E4E: c_write_global_declarations (c-decl.c:9735) ==32673==by 0x8ABAD4: toplev_main (toplev.c:983) ==32673== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==32673== pr45412-2.c: In function 'bar': pr45412-2.c:6:1: 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45412
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #6 from kargl at gcc dot gnu dot org 2010-08-31 19:09 --- (In reply to comment #5) Thanks. I do know how to work around it with subroutine which I already did in my program. But it doesn't explain why 4.1.2 version allows return character string from function. Our program works well until the gcc upgrade. Is this new standard? I don't know what you mean by 'new standard'. I have gfortran 4.3.x, 4.4.x, 4.5.x, and 4.6.0 installed. -fdump-tree-original for these compilers all show 4.3 requestdouble (__result, .__result, rlat, rlng) 4.4, 4.5, and 4.6: requestdouble (character(kind=1)[1:.__result] __result, integer(kind=4) .__result, real(kind=8) rlat, real(kind=8) rlng) The first returned argument is a pointer to the string and the second returned argument is the length. I don't know what 4.1 and 4.2 do. You're clearly (ab)using the abi to do mixed language program, and you need to investigate the calling conventions when you have problems. -- steve -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
Re: [Bug c++/45462] Bad optimization in -O3 sometimes
On Aug 31, 2010, at 8:24 AM, yotambarnoy at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #4 from yotambarnoy at gmail dot com 2010-08-31 15:24 --- Good job picking up on that. There must be a better way of telling the compiler to generate lwr and lwl MIPS instructions without breaking strict aliasing rules...? Have you tried using memcpy? Thanks a bunch! -- yotambarnoy at gmail dot com changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug c++/45462] Bad optimization in -O3 sometimes
--- Comment #5 from pinskia at gmail dot com 2010-08-31 19:09 --- Subject: Re: Bad optimization in -O3 sometimes On Aug 31, 2010, at 8:24 AM, yotambarnoy at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #4 from yotambarnoy at gmail dot com 2010-08-31 15:24 --- Good job picking up on that. There must be a better way of telling the compiler to generate lwr and lwl MIPS instructions without breaking strict aliasing rules...? Have you tried using memcpy? Thanks a bunch! -- yotambarnoy at gmail dot com changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #8 from sfilippone at uniroma2 dot it 2010-08-31 19:20 --- (In reply to comment #7) (In reply to comment #6) Fine. Waiting for it Consider the following variation: upon exit from DOIT, the ACSR variable should be deallocated (since it was MOVE_ALLOCed to atx%a) but it is not, hence double free. === [sfili...@localhost bug23]$ ./bug23_1 Allocation status acsr: T Allocation status atx: T T T 1 3 4 5 1 1 2 3 0 0 0 0 0 0 0 0 1.1.2. 3.0.0. 0.0.0. 0.0.0. *** glibc detected *** ./bug23_1: double free or corruption (!prev): 0x023bbfe0 *** === Backtrace: = /lib64/libc.so.6[0x3d69675676] ./bug23_1[0x401876] ./bug23_1[0x4018da] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3d6961ec5d] ./bug23_1[0x400869] === Memory map: 0040-00402000 r-xp 08:05 2187330 /home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug23/bug2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #9 from sfilippone at uniroma2 dot it 2010-08-31 19:21 --- Created an attachment (id=21613) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21613action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug target/45250] [4.6 Regression] FAIL: tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/check_nan.cc
--- Comment #7 from jakub at gcc dot gnu dot org 2010-08-31 19:48 --- Created an attachment (id=21614) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21614action=view) gcc46-pr45250.patch The problem is that the PA backend has quite lame setup, where FRAME_POINTER_REGNUM is the same as HARD_FRAME_POINTER_REGNUM and ARG_POINTER_REGNUM, thus the replacements var-tracking is doing in order to decrease size of loclists and use DW_OP_fbreg where possible, aren't reliable, as the testcase shows, because the same hard register can be used for arbitrary other data. The following patch fixes it by not doing the replacements on PA and similar targets at all when doing VALUE based var-tracking. Ideally PA backend would be fixed up to use different (fixed) hard regno, made up and always eliminated, for FRAME_POINTER_REGNUM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45250
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2010-08-31 19:50 --- Created an attachment (id=21615) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21615action=view) assembly from stock build of gcc.dg/nest.c execution test at -m32 on x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2010-08-31 19:55 --- Created an attachment (id=21616) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21616action=view) assembly from stock build of gcc.dg/torture/stackalign/alloca-4.c -O1 execution test at -m32 on x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2010-08-31 19:57 --- Created an attachment (id=21617) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21617action=view) diff between nest.s.stock and nest.s show alignment changes in failing test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug target/36502] i386/darwin generates unnecessary stack ops in every function
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2010-08-31 19:59 --- Created an attachment (id=21618) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21618action=view) diff between alloca-4.s.stock and alloca-4.s show alignment changes in failing test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
[Bug c/45467] New: gcc won't warn about an uninitialized value
Hello,
I've compiled the following code using `gcc -std=c99 -O -g -Wall gcctest.c -o
gcctest':
#include stdio.h
static int array[32];
#if 0 // If '#if 1' is used, GCC warns correctly about the use of uninitialized
variable 'i' below.
void foo(void);
void foo(void)
#else
static void foo(void)
#endif
{
for (int i; i 32; ++i)
{
if (!array[i])
break;
}
}
int main(void)
{
foo();
return 0;
}
The problem is that GCC 4.5.1 does not warn about the use of the uninitialized
variable `i' on the line containing `if (!array[i])'. GCC 3.4.6 did this
correctly.
A perhaps interesting fact is that when the snippet is compiled with `#if 1'
instead of `#if 0', GCC 4.5.1 does warn correctly.
Thanks, Jelle
--
Summary: gcc won't warn about an uninitialized value
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jellegeerts at gmail dot com
GCC host triplet: mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #1 from jellegeerts at gmail dot com 2010-08-31 20:02 --- Created an attachment (id=21619) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21619action=view) output of `gcc -v -save-temps -std=c99 -O -g -Wall gcctest.c -o gcctest' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #2 from jellegeerts at gmail dot com 2010-08-31 20:03 --- Created an attachment (id=21620) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21620action=view) output of `gcc -v -save-temps -std=c99 -O -g -Wall gcctest.c -o gcctest' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #3 from jellegeerts at gmail dot com 2010-08-31 20:03 --- Created an attachment (id=21621) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21621action=view) the `.i' file that GCC created -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #4 from jellegeerts at gmail dot com 2010-08-31 20:04 --- Created an attachment (id=21622) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21622action=view) `.i' file that GCC created -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug debug/45465] Wrong type reported by gdb
--- Comment #3 from tromey at gcc dot gnu dot org 2010-08-31 20:12 --- This was purely a gdb bug. It only showed up with a newish gcc because older ones don't emit DW_TAG_template_*. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45465
