[Bug target/45296] register long double ICE at -O2, -Os, -O3

--- Comment #5 from ubizjak at gmail dot com 2010-08-17 06:57 --- (In reply to comment #3) > Here's another example of valid gnu99 code: > > register long double F80a __asm__("st"); > register long double F80b __asm__("st(1)"); > > void x87_add() { > F80a += F80b; > } > > int main(

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

--- Comment #10 from jakub at gcc dot gnu dot org 2010-08-17 06:55 --- Subject: Bug 45186 Author: jakub Date: Tue Aug 17 06:55:25 2010 New Revision: 163293 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163293 Log: PR fortran/45186 * trans.c (gfc_annotate_with_lo

[Bug c/38354] Spurious error: initializer element is not computable at load time

--- Comment #3 from adam at consulting dot net dot nz 2010-08-17 06:28 --- AMD64 non-large code model. Functions occupy lower 2GB of the address space. Cannot compile an array of 32-bit function addresses: #include #include #include void fn() { printf("Hello, World\n"); } uint32

[Bug target/45296] register long double ICE at -O2, -Os, -O3

--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-17 06:12 --- The GCC manual says that the register should be call-saved, that isn't the case in your testcase, so it isn't valid. But, more importantly, the i387 floating point stack is even more special, as the st* registers chang

[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom

--- Comment #23 from hjl dot tools at gmail dot com 2010-08-17 03:46 --- Created an attachment (id=21499) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21499&action=view) A different patch We added the 2rd alternative to "*add_1" for Atom so that we always use add instead lea. It

[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN

--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-08-17 03:18 --- There was some history regarding legacy codes as the reason why this does not error out. ie looping back and trying again was a feature. I think I may put this behind -std=legacy. It does seem odd the way we are

[Bug fortran/44931] For INPUT_UNIT, INQUIRE NAME= should not return "stdin"

--- Comment #13 from jvdelisle at gcc dot gnu dot org 2010-08-17 03:13 --- Closing now -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Statu

[Bug lto/45302] New: g++.dg/lto/20100723-1 cp_lto_20100723-1_0.o-cp_lto_20100723-1_0.o link, -fcompare-debug -flto/-fwhopr ICE

ccqmDPY -frandom-seed=0x7d9c35c1 -fdump-final-insns=cp_lto_20100723-1_0.gk.gkd Reading symbols for shared libraries .++++. done GNU GIMPLE (GCC) version 4.6.0 20100816 (experimental) (x86_64-apple-darwin10.5.0) compiled by GNU C version 4.6.0 20100816 (experimental), GMP version

[Bug tree-optimization/45301] [4.6 Regression] ICE: SIGSEGV in instantiate_scev_r (tree-scalar-evolution.c:3391) with -O2 -ftree-loop-distribution -fgraphite-identity

--- Comment #1 from zsojka at seznam dot cz 2010-08-17 00:48 --- Created an attachment (id=21498) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21498&action=view) reduced testcase $ gcc -O1 -ftree-loop-distribution -fgraphite-identity -fstrict-aliasing -ftree-pre pr45301.c --

[Bug tree-optimization/45301] New: [4.6 Regression] ICE: SIGSEGV in instantiate_scev_r (tree-scalar-evolution.c:3391) with -O2 -ftree-loop-distribution -fgraphite-identity

Command line: $ gcc -O1 -ftree-loop-distribution -fgraphite-identity -fstrict-aliasing -ftree-pre testcase.c or $ gcc -O2 -ftree-loop-distribution -fgraphite-identity testcase.c Valgrind output: ==28123== Invalid read of size 8 ==28123==at 0x9210E1: instantiate_scev_r (tree-scalar-evolution.c:

[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom

--- Comment #22 from bernds at gcc dot gnu dot org 2010-08-17 00:16 --- I was looking at Spec2k/254.gap/integer.s which has many examples, all of the form. - leal(%ecx,%eax), %eax + addl%ecx, %eax -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470

[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom

--- Comment #21 from hjl dot tools at gmail dot com 2010-08-17 00:11 --- (In reply to comment #19) > Created an attachment (id=21497) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21497&action=view) [edit] > A patch which should produce more add insns > > In other words, don't we

[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom

--- Comment #20 from hjl dot tools at gmail dot com 2010-08-17 00:10 --- (In reply to comment #18) > I'm seeing some strange situations where this code is unnecessarily producing > lea insns even when not tuning for Atom. > > This code looks very strange. I don't understand why we are

[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom

--- Comment #19 from bernds at gcc dot gnu dot org 2010-08-16 23:51 --- Created an attachment (id=21497) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21497&action=view) A patch which should produce more add insns In other words, don't we at least need this patch to avoid generati

[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom

--- Comment #18 from bernds at gcc dot gnu dot org 2010-08-16 23:49 --- I'm seeing some strange situations where this code is unnecessarily producing lea insns even when not tuning for Atom. This code looks very strange. I don't understand why we aren't splitting to a lea pattern anymo

[Bug target/45296] register long double ICE at -O2, -Os, -O3

--- Comment #3 from adam at consulting dot net dot nz 2010-08-16 23:41 --- Why is this invalid gnu99 code? How does one reserve x87 stack values as global register variables so that one may use gnu99 operators such as + upon those global register variables instead of having to resort t

[Bug tree-optimization/45260] [4.5/4.6 Regression] g++4.5: -prefetch-loop-arrays internal compiler error: in verify_expr, at tree-cfg.c:2541

--- Comment #4 from changpeng dot fang at amd dot com 2010-08-16 22:39 --- This bug should be related to VIEW_CONVERT_EXPR. If I use the following statement to filter the prefetch, the bug will go away: if (contains_view_convert_expr_p (ref)) return false; Otherwise, the prefetc

[Bug target/45084] configure: error: no 8-bit type

--- Comment #5 from rwild at gcc dot gnu dot org 2010-08-16 20:55 --- Patch to fix the weird error message from configure here: (I don't have any input on the actual bug) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45084

[Bug tree-optimization/44632] [4.4/4.5 regression] wrong code for complex division

--- Comment #22 from danglin at gcc dot gnu dot org 2010-08-16 20:27 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug tree-optimization/44632] [4.4/4.5 regression] wrong code for complex division

--- Comment #21 from danglin at gcc dot gnu dot org 2010-08-16 20:25 --- Subject: Bug 44632 Author: danglin Date: Mon Aug 16 20:24:54 2010 New Revision: 163285 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163285 Log: Backport from mainline: 2010-08-09 Richard

[Bug tree-optimization/44632] [4.4/4.5 regression] wrong code for complex division

--- Comment #20 from danglin at gcc dot gnu dot org 2010-08-16 20:18 --- Subject: Bug 44632 Author: danglin Date: Mon Aug 16 20:18:08 2010 New Revision: 163284 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163284 Log: Backport from mainline: 2010-08-09 Richard

[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing

--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-16 19:33 --- Created an attachment (id=21496) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21496&action=view) First patch First implementation with compile-time resolution Todo: - Handle run-time solution - I do not yet k

[Bug c++/44524] improve diagnostic for . vs -> typo

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-16 19:12 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCON

[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict

--- Comment #10 from paolo dot carlini at oracle dot com 2010-08-16 19:02 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Statu

[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict

--- Comment #9 from paolo at gcc dot gnu dot org 2010-08-16 19:01 --- Subject: Bug 45300 Author: paolo Date: Mon Aug 16 19:01:35 2010 New Revision: 163283 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163283 Log: 2010-08-16 Paolo Carlini PR libstdc++/45300 *

[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict

--- Comment #8 from paolo dot carlini at oracle dot com 2010-08-16 18:29 --- Good point, but I think that in these whole program optimization times getting the declaration right, that is consistent with the definition, is in any case a good idea. -- http://gcc.gnu.org/bugzilla/show

[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict

--- Comment #7 from redi at gcc dot gnu dot org 2010-08-16 18:13 --- Ah I see the problem now, sorry. Even when we're using C99 features, 'restrict' is never a keyword for C++. Does __restrict even have any effect on declarations (rather than definitions)? If not, there is no semantic

[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict

--- Comment #6 from paolo dot carlini at oracle dot com 2010-08-16 17:56 --- Ok. Actually my question was born more naive, simply about replacing after so many years 'restrict' with with either '__restrict' or '__restrict__', that is something with real semantics. I understand we believ

[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict

--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-16 17:42 --- Yes, glibc headers use exclusively __restrict, perhaps it is better to use the same spelling if say somebody wants to -D__restrict= it out for testing or similar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=453

[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict

--- Comment #4 from ktietz at gcc dot gnu dot org 2010-08-16 17:40 --- (In reply to comment #3) > Let's add in CC Jakub, just in case he can see something wrong vs the C > library > with using __restrict__ here. > The normal c-library headers are using here __restrict as keyword. But

[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict

--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-16 17:35 --- Let's add in CC Jakub, just in case he can see something wrong vs the C library with using __restrict__ here. -- paolo dot carlini at oracle dot com changed: What|Removed

[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict

--- Comment #2 from paolo dot carlini at oracle dot com 2010-08-16 17:34 --- I see. I'm not sure how much difference it makes, but I think we should change those, to __restrict__. Note, in C++ 'restrict' is not a keyword in any case - not even in C++0x mode which otherwise takes C99 as

[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict

--- Comment #1 from redi at gcc dot gnu dot org 2010-08-16 17:33 --- Does the user report say anything else? Is this when using -std=c++98 -pedantic-errors? Something else? They're not used unconditionally, they're guarded by C99-related macros. -- http://gcc.gnu.org/bugzilla/show

[Bug target/41323] Add new _mm_extract_epu16 intrinsic (resquest)

--- Comment #4 from hjl dot tools at gmail dot com 2010-08-16 17:25 --- Apparently, icc treats those intrinsics as returning unsigned int. I will investigate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41323

[Bug testsuite/45266] [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90

--- Comment #8 from sje at cup dot hp dot com 2010-08-16 17:11 --- ! { dg-final { scan-tree-dump-times "memcpy|ref-all.*ref-all" 2 "original" } } worked for me on IA64 where we have 2 memcpys' in the output. Neither of my suggestions from comment #7 worked. I don't know if this will w

[Bug libstdc++/45300] New: in cstdio/cstdlib keyword restrict is used instead of __restrict

We noticed that in the headers cstdio and cstdlib the c99 keyword "restrict" is used unconditionally. AFAICS it should be used here __restrict instead. By user-report - I've got - it leads to the issue that the "restrict" keyword gets interpreted as argument name for non c99. -- Summa

[Bug debug/42487] FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges

--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-08-16 16:30 --- Does that mean darwin can't or it just was never implemented? if it is the first, I guess this should be XFAIL'd on darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42487

[Bug debug/45299] Dwarf information is wrong with optimised code.

--- Comment #5 from hariharans at picochip dot com 2010-08-16 16:28 --- Created an attachment (id=21495) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21495&action=view) address encoded assembly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45299

[Bug debug/45299] Dwarf information is wrong with optimised code.

--- Comment #4 from hariharans at picochip dot com 2010-08-16 16:24 --- Created an attachment (id=21494) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21494&action=view) assembly code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45299

[Bug debug/45299] Dwarf information is wrong with optimised code.

--- Comment #3 from hariharans at picochip dot com 2010-08-16 16:23 --- Created an attachment (id=21493) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21493&action=view) The source code -- hariharans at picochip dot com changed: What|Removed

[Bug debug/45299] Dwarf information is wrong with optimised code.

--- Comment #2 from hariharans at picochip dot com 2010-08-16 16:19 --- Created an attachment (id=21492) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21492&action=view) The source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45299

[Bug debug/45299] Dwarf information is wrong with optimised code.

--- Comment #1 from hariharans at picochip dot com 2010-08-16 16:17 --- Sorry for the incomplete description. The actual description: I saw this problem initially on 4.5.0 compiler, but the same problem happens on mainline too. In function arraysum in the attached example, the parameter

[Bug debug/45299] New: Dwarf information is wrong with optimised code.

I saw this problem initially on 4.5.0 compiler, but the same problem happens on mainline too. In function arraysum in the attached example, the parameter array, which is a pointer to array of -- Summary: Dwarf information is wrong with optimised code. Product: gcc

[Bug debug/42487] FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges

--- Comment #5 from rth at gcc dot gnu dot org 2010-08-16 15:48 --- Darwin doesn't really support -ffunction-sections. Which means that the aranges feature isn't exercised. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42487

[Bug target/41323] Add new _mm_extract_epu16 intrinsic (resquest)

--- Comment #3 from hjl dot tools at gmail dot com 2010-08-16 15:47 --- Since we implement _mm_XXX intrinsics with __builtin_ia32_XXX, we can make the prototype of __builtin_ia32_XXX to match the hardware. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41323

[Bug c/45289] gcc lacks a "posix" option for "-std" since POSIX 2008 defines special behavior

--- Comment #9 from rwild at gcc dot gnu dot org 2010-08-16 15:05 --- hit the wrong button, apologies -- rwild at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/45289] gcc lacks a "posix" option for "-std" since POSIX 2008 defines special behavior

-- rwild at gcc dot gnu dot org changed: What|Removed |Added CC||rwild at gcc dot gnu dot org AssignedTo|rguenth at gcc dot gnu

[Bug target/41323] Add new _mm_extract_epu16 intrinsic (resquest)

--- Comment #2 from hjl dot tools at gmail dot com 2010-08-16 14:54 --- Apparently, it isn't a problem for icc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41323

[Bug target/41323] Add new _mm_extract_epu16 intrinsic (resquest)

--- Comment #1 from hjl dot tools at gmail dot com 2010-08-16 14:52 --- *** Bug 45294 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41323

[Bug target/45294] pextrw, redundant zero (or otherwise) extension

--- Comment #3 from hjl dot tools at gmail dot com 2010-08-16 14:52 --- *** This bug has been marked as a duplicate of 41323 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added --

[Bug target/44319] -fzee is mishandled

--- Comment #2 from hjl dot tools at gmail dot com 2010-08-16 14:48 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRM

[Bug target/36466] internal compiler error: in choose_reload_regs, at reload1.c:6190

--- Comment #12 from lool at dooz dot org 2010-08-16 14:40 --- Ok, it's [0] because ziproxy uses "nsaddr" as an identifier for a local variable which conflicts with a compatibility #define in glibc resolv.h. Renaming to "nsaddress" for instance fixes the build, so clearly bogus source c

[Bug target/36466] internal compiler error: in choose_reload_regs, at reload1.c:6190

--- Comment #11 from tbm at gcc dot gnu dot org 2010-08-16 14:35 --- Reopening. -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED

[Bug target/36466] internal compiler error: in choose_reload_regs, at reload1.c:6190

--- Comment #10 from tbm at gcc dot gnu dot org 2010-08-16 14:34 --- Reopening since GCC should not ICE, even if the code is invalid. -- tbm at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug target/36466] internal compiler error: in choose_reload_regs, at reload1.c:6190

--- Comment #9 from lool at dooz dot org 2010-08-16 14:22 --- Also, even if it's invalid input, I guess gcc should never SEGV, but rather throw an error out? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36466

[Bug target/36466] internal compiler error: in choose_reload_regs, at reload1.c:6190

--- Comment #8 from lool at dooz dot org 2010-08-16 14:21 --- I'm not sure how the .i ends up with a zero-length array; resolv.h has: # define MAXNS 3 /* max # name servers we'll track */ [...] struct __res_state { [...] struct sockaddr_in n

[Bug ada/45298] GNATMake fails with multiple, equal -mcpu options

--- Comment #2 from michael dot gurlitz at gmail dot com 2010-08-16 14:05 --- It seems the command line I specified above may be incorrect, though it does exhibit the same error. See here for the full command: http://www.rtems.com/ml/rtems-users/2010/july/msg00038.html > powerpc-rtems4

[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux

--- Comment #10 from bonzini at gnu dot org 2010-08-16 13:48 --- Created an attachment (id=21491) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21491&action=view) patch to fix the bug This is the patch to fix the bug. I'll bootstrap/regtest it soon. Thanks H.J. for helping track

[Bug ada/45298] GNATMake fails with multiple, equal -mcpu options

--- Comment #1 from michael dot gurlitz at gmail dot com 2010-08-16 13:44 --- $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/home/rtems-4.11/bin/../libexec/gcc/i386-pc-solaris2.10/4.5.1/lto-wrapper Target: i386-pc-solaris2.10 Configured with: ../gcc-4.5.1/con

[Bug ada/45298] New: GNATMake fails with multiple, equal -mcpu options

Passing a -mcpu=xxx option after a regular argument (a filename), when an equivalent -mcpu=xxx option was specified earlier, causes gnatmake to fail: $ gnatmake -mcpu=7400 hello -o hello.exe -bargs -mcpu=7400 rtems_init.o Exception name: SYSTEM.ASSERTIONS.ASSERT_FAILURE Message: make.adb:7473 gna

[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux

--- Comment #9 from bonzini at gnu dot org 2010-08-16 13:29 --- The bug seems to be that an instruction clobbering the flags is inserted after the unspec. 140 {r127:SI=[r62:SI];[r62:SI]=unspec/v[[r62:SI],r128:SI,r129:SI] 11;flags:CCZ=cmp(unspec/v[[r62:SI],r128:SI,r129:SI] 11,r128:SI);

[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux

--- Comment #8 from hjl dot tools at gmail dot com 2010-08-16 13:19 --- Created an attachment (id=21490) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21490&action=view) The preprocessed source It should be compiled with -march=i486 -ftls-model=initial-exec -mtune=i586 -O2 -fPIC

[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

--- Comment #16 from jakub at gcc dot gnu dot org 2010-08-16 11:16 --- Re: #c12, the difference is because the source code is different. In the first preprocessed source, restore_rt isn't hidden, in the latter it is. So, in the first case (-fPIE) gcc can't assume __restore_rt is defined

[Bug middle-end/45297] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1210 with -Os -fgraphite-identity

--- Comment #1 from zsojka at seznam dot cz 2010-08-16 11:14 --- Created an attachment (id=21489) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21489&action=view) reduced testcase (from gcc.c-torture/execute/990513-1.c) $ gcc -Os -fgraphite-identity pr45297.c pr45297.c: In functio

[Bug middle-end/45297] New: [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1210 with -Os -fgraphite-identity

Command line: $ gcc -Os -fgraphite-identity testcase.c Compiler output: $ gcc -Os -fgraphite-identity testcase.c testcase.c: In function 'foo': testcase.c:2:1: internal compiler error: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1210 Please submit a full bug report, with preprocess

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

--- Comment #9 from jakub at gcc dot gnu dot org 2010-08-16 10:47 --- Created an attachment (id=21488) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21488&action=view) gcc46-pr45186.patch So, IMNSHO, either we use something like in this patch, Richard probably won't like it, but t

[Bug target/45296] register long double ICE at -O2, -Os, -O3

--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-16 10:32 --- we should reject st here. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/45294] pextrw, redundant zero (or otherwise) extension

--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-16 10:20 --- The sign extension is because the builtin returns a signed quantity (unlike the machine instruction, which zero-extends), so the conversion is inserted by the language frontend. -- rguenth at gcc dot gnu dot org

[Bug target/45294] pextrw, redundant zero (or otherwise) extension

--- Comment #1 from ubizjak at gmail dot com 2010-08-16 10:19 --- (In reply to comment #0) > This is a friendly reminder there's still no way to enjoy pextrw without undue > zero/sign extension unless inline asm is used; there's even a gradient of > ignominy from intrinsic to builtins, a

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

--- Comment #8 from jakub at gcc dot gnu dot org 2010-08-16 10:16 --- I'm pretty sure this was caused by PR41714 and that there are many places missing locus passing. Either the trans_code change should be reverted, so that it handles also STATEMENT_LISTs, or many changes in the FE need

[Bug c++/45293] ICE in iterative_hash_template_arg, at cp/pt.c:1589

--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-16 10:07 --- I get /space/rguenther/install/gcc-4.5.1/bin/g++ -S -o /dev/null footprint.ii -std=c++0x -Wfatal-errors In file included from ../../../src/Object/inst/instance_collection_pool_bundle_footprint.tcc:14:0,

[Bug rtl-optimization/45296] register long double ICE at -O2, -Os, -O3

--- Comment #1 from ubizjak at gmail dot com 2010-08-16 09:45 --- (In reply to comment #0) > At -O2 and above gcc generates: > > register_long_double_ICE.c:3:1: warning: call-clobbered register used for > global register variable Patient: Doctor, it hurts when I do this. Doctor: Then

[Bug fortran/45290] [F08] pointer initialization

--- Comment #3 from janus at gcc dot gnu dot org 2010-08-16 09:37 --- (In reply to comment #2) > (In reply to comment #0) > > Note: For procedure-pointer components I was not able to find any specific > > reference to non-NULL default initialization. > > It is allowed per: > > R440 pro

[Bug middle-end/45262] [4.2/4.3 Regression] Optimization results in wrong result on expression x>>31||(-x)>>31

--- Comment #7 from jakub at gcc dot gnu dot org 2010-08-16 09:35 --- Fixed for 4.4+. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jaku

[Bug fortran/45290] [F08] pointer initialization

--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-16 09:17 --- (In reply to comment #0) > Note: For procedure-pointer components I was not able to find any specific > reference to non-NULL default initialization. It is allowed per: R440 proc-component-def-stmt is PROCEDURE

[Bug fortran/38936] F2003: ASSOCIATE construct / improved SELECT TYPE (a=>expr)

--- Comment #8 from domob at gcc dot gnu dot org 2010-08-16 08:59 --- Also one thing to note is that associate-names associated to expressions (which must not appear in variable definition contexts) are currently accepted as actual arguments to INTENT([IN]OUT) arguments. This should pro

[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux

--- Comment #7 from bonzini at gnu dot org 2010-08-16 07:56 --- H.J., thanks very much for the analysis! Can you please attach preprocessed source code and the output of "gcc -###" when compiling this file using the compiler options you need to show this bug? -- bonzini at gnu dot o

[Bug boehm-gc/34544] pthread_default_stacksize_np failed.

--- Comment #21 from hainque at adacore dot com 2010-08-16 07:42 --- Subject: Re: pthread_default_stacksize_np failed. dave at hiauly1 dot hia dot nrc dot ca wrote: > Because of these issues, I have decided to revert the change on the > branches (probably tomorrow). I will also try to

[Bug fortran/45290] [F08] pointer initialization

--- Comment #1 from domob at gcc dot gnu dot org 2010-08-16 07:34 --- Confirmed. -- domob at gcc dot gnu dot org changed: What|Removed |Added CC|