[Bug middle-end/45312] GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable

--- Comment #5 from t dot artem at mailcity dot com 2010-08-18 05:11 --- This crash occurs upon loading modules, so it's *very* difficult to trace/pinpoint it. Most likely no kernel options have any effect on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312

[Bug middle-end/45312] GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable

--- Comment #4 from belyshev at depni dot sinp dot msu dot ru 2010-08-18 04:40 --- It is not ok to mark suspected wrong-code bugs as WONTFIX until they are confirmed or rejected by a maintainer. Artem, it would be helpful if you at least tried to trim your kernel config until the bug d

[Bug c/45312] GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable

--- Comment #3 from t dot artem at mailcity dot com 2010-08-18 04:05 --- OK, then I'm closing this bug report, since I don't have enough experience to actually find a file that is being miscompiled. (And according to Linus it can be any out of dozens). -- t dot artem at mailcity dot

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

--- Comment #20 from hjl dot tools at gmail dot com 2010-08-18 03:59 --- (In reply to comment #19) > as we stated, you wont hit the bug with vanilla gcc + vanilla glibc. we also > arent absolutely stating "this is a gcc bug". our dissection of the problem > lead us from cryptsetup to

[Bug c/45317] New: struct union misalignment

Hi, bug or feature? I have this sample: #include #include #include #include int main(void) { union U { struct { uint32_t l; uint32_t h; } d; uint64_t q; }; struct S { uint32_t one; union U two;

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

--- Comment #19 from vapier at gentoo dot org 2010-08-18 03:39 --- as we stated, you wont hit the bug with vanilla gcc + vanilla glibc. we also arent absolutely stating "this is a gcc bug". our dissection of the problem lead us from cryptsetup to glibc to what seems like a gcc miscompi

[Bug middle-end/45316] [4.6 Regression] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -O1 -ftree-pre -fnon-call-exceptions

--- Comment #2 from hjl dot tools at gmail dot com 2010-08-18 03:36 --- It is caused by revision 161655: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug c++/45315] [4.4/4.5/4.6 Regression] ICE: tree check: expected aggr_init_expr, have call_expr in build_value_init, at cp/init.c:317

--- Comment #2 from hjl dot tools at gmail dot com 2010-08-18 03:31 --- It is caused by revision 144044: http://gcc.gnu.org/ml/gcc-cvs/2009-02/msg00210.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

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

--- Comment #18 from hjl dot tools at gmail dot com 2010-08-18 03:29 --- If you believe it is a gcc bug, please provide a small run-time testcase which can be linked with any /usr/lib64/libc.a compiled from glibc 2.12. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286

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

--- Comment #17 from vapier at gentoo dot org 2010-08-18 03:23 --- thanks for the shorter test case. could you explain why a 64bit load is used though ? if you're looking for the address of something, and you're not going through a pointer to that location, why isnt it a normal lea wit

[Bug middle-end/45316] [4.6 Regression] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -O1 -ftree-pre -fnon-call-exceptions

--- Comment #1 from zsojka at seznam dot cz 2010-08-18 01:45 --- Created an attachment (id=21510) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21510&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45316

[Bug middle-end/45316] New: [4.6 Regression] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -O1 -ftree-pre -fnon-call-exceptions

Command line: $ gcc -O1 -ftree-pre -fnon-call-exceptions testcase.C Compiler output: $ gcc -O1 -ftree-pre -fnon-call-exceptions testcase.C testcase.C: In function 'void foo()': testcase.C:21:1: error: BB 3 can not throw but has an EH edge testcase.C:21:1: internal compiler error: verify_flow_info

[Bug c++/45315] [4.4/4.5/4.6 Regression] ICE: tree check: expected aggr_init_expr, have call_expr in build_value_init, at cp/init.c:317

-- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfi

[Bug c++/45315] ICE: tree check: expected aggr_init_expr, have call_expr in build_value_init, at cp/init.c:317

--- Comment #1 from zsojka at seznam dot cz 2010-08-17 23:32 --- Created an attachment (id=21509) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21509&action=view) reduced testcase I believe the code is valid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45315

[Bug c++/45315] New: ICE: tree check: expected aggr_init_expr, have call_expr in build_value_init, at cp/init.c:317

Compiler output: $ gcc testcase.C testcase.C: In member function 'void B< >::foo()': testcase.C:10:18: internal compiler error: tree check: expected aggr_init_expr, have call_expr in build_value_init, at cp/init.c:317 Please submit a full bug report, with preprocessed source if appropriate. See

[Bug middle-end/45314] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

--- Comment #1 from bero at arklinux dot org 2010-08-17 22:27 --- Created an attachment (id=21508) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21508&action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45314

[Bug middle-end/45314] New: ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

i586-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../.. -I../../librender -I../../libcore -I../../libcore/asobj -I../../libcore/asobj/flash -I../../libcore/swf -I../../libcore/abc -I../../libcore/parser -I../../libbase -I../../libmedia -I../../libsound -I../../libltdl -I/usr/include/glib-2.0 -I/usr/lib/

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

--- Comment #82 from mikulas at artax dot karlin dot mff dot cuni dot cz 2010-08-17 21:17 --- -mstackrealign is available from gcc 4.5.0. For gcc 4.4 you can use my patch GCC-4.4.1-ALIGN-PATCH from this bugzilla or H.J.Lu's last patch. It basically does the same as -mstackrealign (but i

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

--- Comment #81 from jasmin at revisionfx dot com 2010-08-17 21:03 --- (In reply to comment #80) > Comment #79: > > -mstackrealign does the right thing, it realigns the stack when needed, but > keeps it 16-byte aligned on function output. It should be used. > I don't have that optio

[Bug middle-end/45229] gcc.c-torture/execute/20000412-4.c ICEs with -fgraphite-identity

--- Comment #3 from spop at gcc dot gnu dot org 2010-08-17 20:41 --- Subject: Bug 45229 Author: spop Date: Tue Aug 17 20:41:26 2010 New Revision: 163319 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163319 Log: Fix PR45229: gcc.c-torture/execute/2412-4.c ICEs with -fgraphit

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

--- Comment #80 from mikulas at artax dot karlin dot mff dot cuni dot cz 2010-08-17 20:17 --- Comment #79: -mpreferred-stack-boundary=2 adheres to the sysv ABI but it doesn't adhere to the Linux ABI (that requires 16-byte alignment), so if you compile anything with -mpreferred-stack-bo

[Bug c/45312] GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable

--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-17 19:07 --- In particular, first bisect between object files compiled without/with the patch to find one compilation unit where the problem is, provide preprocessed source for it (both without and with the patch) and gcc command l

[Bug tree-optimization/45313] [graphite] interchange-7.c is miscompiled

-- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirme

[Bug tree-optimization/45313] New: [graphite] interchange-7.c is miscompiled

In the graphite branch interchange-7.c is miscompiled with the following flags: $ gcc -O3 -fgraphite -fno-loop-block -floop-strip-mine -floop-interchange interchange-7.c $ ./a.out Aborted -- Summary: [graphite] interchange-7.c is miscompiled Product: gcc Versi

[Bug c/45312] GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable

--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-17 18:24 --- That is not a proper bug report, see http://gcc.gnu.org/bugs.html for what needs to be provided. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312

[Bug fortran/29785] Fortran 2003: POINTER Rank Remapping

--- Comment #8 from mikael at gcc dot gnu dot org 2010-08-17 18:21 --- (In reply to comment #7) > Tobias (and all): Do you think we should check for "the size of data-target > shall not be less than the size of data-pointer-object" at runtime when > -fcheck=bounds is given? > Yes. The

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

--- Comment #12 from jason at gcc dot gnu dot org 2010-08-17 18:18 --- Actually, Richard's change didn't affect this; we were already missing it because of the complex interoperation of cp_gimplify_expr and gimplify_modify_expr_rhs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=453

[Bug c/45312] New: GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable

This bug is described here: https://bugzilla.kernel.org/show_bug.cgi?id=16612 In two words: this patch: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=commitdiff;h=568132624386f53e87575195d868db9afb2e9316 makes kernel 2.6.35.2 unusable on my PC. The particular file that ge

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

--- Comment #11 from jason at gcc dot gnu dot org 2010-08-17 18:09 --- There are two issues here: 1) expand_static_init decides whether a variable needs static initialization before gimplification, and 2) Richard's MEM_REF-related change to cp_gimplify_expr caused us to stop removing th

[Bug fortran/45308] [F2003] DATE_AND_TIME does _not_ black-pad strings

--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-17 18:08 --- Subject: Bug 45308 Author: jakub Date: Tue Aug 17 18:08:05 2010 New Revision: 163312 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163312 Log: PR fortran/45308 * intrinsics/date_and_time.c (da

[Bug fortran/45304] Functions/subroutines without arguments always treated like varargs

--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-17 18:06 --- Subject: Bug 45304 Author: jakub Date: Tue Aug 17 18:06:18 2010 New Revision: 163311 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163311 Log: PR fortran/45304 * trans-decl.c (build_library_fu

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

--- Comment #10 from mmitchel at gcc dot gnu dot org 2010-08-17 17:50 --- The problem with -Wuninitialized might be the same problem I've been sermonizing about for years -- we're trying to issue sensible warnings from our optimizers, which means that as the optimizers are perturbed, th

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

--- Comment #9 from jason at gcc dot gnu dot org 2010-08-17 17:41 --- But that change was largely reversed by the fix for PR 43787. -- jason at gcc dot gnu dot org changed: What|Removed |Added ---

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

--- Comment #5 from hjl dot tools at gmail dot com 2010-08-17 17:41 --- It is caused by revision 145440: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug fortran/29785] Fortran 2003: POINTER Rank Remapping

--- Comment #7 from domob at gcc dot gnu dot org 2010-08-17 17:38 --- Tobias (and all): Do you think we should check for "the size of data-target shall not be less than the size of data-pointer-object" at runtime when -fcheck=bounds is given? -- http://gcc.gnu.org/bugzilla/show_bug

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

--- Comment #4 from fang at csl dot cornell dot edu 2010-08-17 17:26 --- Created an attachment (id=21507) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21507&action=view) delta reduced, day 2 Slowly being reduced by delta, day 2 ... -- http://gcc.gnu.org/bugzilla/show_bug.cg

[Bug libgomp/45311] New: OpenMP a DLL cannot load libgomp on Windows Vista u64

I have a DLL which now works fine on Windows XP SP3 build with mingw GCC 4.4.0. However on Vista my DLL will not even get to DllMain, so I assume the libgomp is not being loaded successfully. Do I need a Vista compatible build of gomp? Is there a difference in the msvcrt maybe? -- Su

[Bug fortran/45309] [4.6 Regression] gfortran.dg/trim_optimize_1.f90 has 4 memmove

--- Comment #3 from burnus at gcc dot gnu dot org 2010-08-17 17:06 --- (In reply to comment #2) > Note that the -O option changes the original tree dump. > I thought it only impacted later dumps. OK, with -O I also only get (MEM[(c_char * {ref-all})&b] = MEM[(c_char * {ref-all})"abcd"

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

--- Comment #8 from jakub at gcc dot gnu dot org 2010-08-17 16:53 --- Perhaps related to PR43075, before that last commit there genericization was removing empty struct assignments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45307

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

--- Comment #7 from hubicka at gcc dot gnu dot org 2010-08-17 16:45 --- oops, I've left IRC sentence unfinished. At IRC Richi told that FEs should not ever produce stores to empty structs at first place, so we don't need middle end logic of taking them away. Jakub thought that those st

[Bug fortran/45309] [4.6 Regression] gfortran.dg/trim_optimize_1.f90 has 4 memmove

--- Comment #2 from mikael at gcc dot gnu dot org 2010-08-17 16:44 --- I'm somewhat out of date (revision 163221) and I only see 2 memmoves. I don't see any string_trim either. Note that the -O option changes the original tree dump. I thought it only impacted later dumps. -- http:

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

--- Comment #6 from hubicka at gcc dot gnu dot org 2010-08-17 16:42 --- We are not removing write only vars because richi told me that there is no convenient way to tell aliasing that variable is write only. It is easy to detect for me, but bit harder to get rid of them, since at IPA pa

[Bug middle-end/45310] ICE: verify_stmts failed: Dead STMT in EH table with -O1 -fnon-call-exceptions

--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-17 16:03 --- Confirmed. "Works" on the 4.1 branch (there is no such verification). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/45016] Support pointer assignment with bound-spec; wrong bounds for pointer assignment

--- Comment #3 from domob at gcc dot gnu dot org 2010-08-17 16:00 --- Also working on this, as suggested by Tobias in PR 29785 maybe this can be done together. -- domob at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

--- Comment #5 from rguenth at gcc dot gnu dot org 2010-08-17 15:57 --- I also wonder why we can't remove such stores based on ipa-reference analysis. Reduced testcase: struct __attribute__ ((visibility ("default"))) fallible_t { }; const fallible_t fallible = fallible_t(); -- rgue

[Bug c++/45310] ICE: verify_stmts failed: Dead STMT in EH table with -O1 -fnon-call-exceptions

--- Comment #1 from zsojka at seznam dot cz 2010-08-17 15:49 --- Created an attachment (id=21506) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21506&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45310

[Bug c++/45310] New: ICE: verify_stmts failed: Dead STMT in EH table with -O1 -fnon-call-exceptions

Command line: $ gcc -O1 -fnon-call-exceptions testcase.C Compiler output: $ gcc -O1 -fnon-call-exceptions testcase.C testcase.C: In function 'void foo()': testcase.C:23:1: error: Dead STMT in EH table # VUSE <.MEM_10> D.2166_8 = *a_7; testcase.C:23:1: internal compiler error: verify_stmts failed

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

-- jv244 at cam dot ac dot uk changed: What|Removed |Added Target Milestone|4.5.2 |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186

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

--- Comment #25 from hjl dot tools at gmail dot com 2010-08-17 14:47 --- (In reply to comment #24) > I think that's beginning to look reasonable. So the problem was that without > alternative 2, such an add would match alternative 3 instead and be split? > Yes. -- http://gcc.gnu

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

--- Comment #4 from mmitchel at gcc dot gnu dot org 2010-08-17 14:41 --- I have no object to the FE removing trivial code if it can do so -- but I also think that the middle-end should be able to deduce that a function is pure later in the process and eliminate it then. I don't underst

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

--- Comment #10 from ubizjak at gmail dot com 2010-08-17 14:27 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED

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

--- Comment #9 from uros at gcc dot gnu dot org 2010-08-17 14:26 --- Subject: Bug 45296 Author: uros Date: Tue Aug 17 14:25:52 2010 New Revision: 163307 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163307 Log: PR target/45296 * reginfo.c (globalize_reg): Reject

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

--- Comment #8 from uros at gcc dot gnu dot org 2010-08-17 14:22 --- Subject: Bug 45296 Author: uros Date: Tue Aug 17 14:22:16 2010 New Revision: 163306 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163306 Log: PR target/45296 * reginfo.c (globalize_reg): Reject

[Bug middle-end/45306] ICE (Segmentation fault) while building PyQt with -fgraphite-identity

--- Comment #3 from bero at arklinux dot org 2010-08-17 14:15 --- Ignore the previous comment -- it working on x86 (32bit) was caused by not having -fgraphite-identity in the CFLAGS there. It crashes everywhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45306

[Bug fortran/45309] [4.6 Regression] gfortran.dg/trim_optimize_1.f90 has 4 memmove

--- Comment #1 from domob at gcc dot gnu dot org 2010-08-17 14:14 --- Confirmed (from my point of view) -- domob at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/45309] New: [4.6 Regression] gfortran.dg/trim_optimize_1.f90 has 4 memmove

The test case for PR 40628 has: ! { dg-final { scan-tree-dump-times "memmove" 2 "original" } } However, the original dump has: __builtin_memmove ((void *) &a, (void *) pstr.0, 3); __builtin_memmove ((void *) &a, (void *) pstr.0, (integer(kind=8)) D.1558); __builtin_memmove ((void *) &c, (void *)

[Bug fortran/45308] [F2003] DATE_AND_TIME does _not_ black-pad strings

--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-17 13:50 --- Created an attachment (id=21505) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21505&action=view) gcc46-pr45308.patch Updated patch. -- jakub at gcc dot gnu dot org changed: What|Removed

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

--- Comment #3 from hubicka at gcc dot gnu dot org 2010-08-17 13:34 --- Adding Mark and Jason to CC then, but Jakub seems right about -Wuninitialized warnings. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added -

[Bug fortran/45308] [F2003] DATE_AND_TIME does _not_ black-pad strings

--- Comment #3 from burnus at gcc dot gnu dot org 2010-08-17 13:23 --- (Add lost mid-air collision text) As Clive Page notes in c.l.f, the non-padding is required for F95 while the padding is required in F2003 - though, I would not care for the F95 version and always pad. (F95, 13.14.2

[Bug fortran/45308] [F2003] DATE_AND_TIME does _not_ black-pad strings

--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-17 13:19 --- (In reply to comment #1) > Created an attachment (id=21504) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21504&action=view) [edit] > gcc46-pr45308.patch That's quick. However, I wonder whether one should modi

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

--- Comment #13 from paolo at gcc dot gnu dot org 2010-08-17 13:16 --- Subject: Bug 45300 Author: paolo Date: Tue Aug 17 13:15:41 2010 New Revision: 163304 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163304 Log: 2010-08-17 Paolo Carlini PR libstdc++/45300

[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code

--- Comment #22 from bernds at gcc dot gnu dot org 2010-08-17 13:14 --- (In reply to comment #19) > x_addr is a VALUE that has no locs: That happens because it's an autoincrement, and cselib_subst_to_values just creates an empty value. It seems to me that we simply need to add a VALUE

[Bug fortran/45308] DATE_AND_TIME does _not_ black-pad strings

--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-17 13:13 --- Created an attachment (id=21504) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21504&action=view) gcc46-pr45308.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45308

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

--- Comment #49 from iains at gcc dot gnu dot org 2010-08-17 13:13 --- the patch attached to http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01249.html solves the problem by suppression of the epilogues in _eh_frames; the patch might be an incomplete solution to darwin<->dwarf2 issues.

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

--- Comment #12 from paolo dot carlini at oracle dot com 2010-08-17 13:07 --- Sure, I forgot to grep, was in an hurry because I'm leaving for a few days of vacations, but will do it momentarily. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45300

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

--- Comment #11 from mikpe at it dot uu dot se 2010-08-17 13:01 --- Should libstdc++-v3/include/{c_global,c_std}/cwchar also get the restrict -> __restrict treatment? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45300

[Bug fortran/45308] New: DATE_AND_TIME does _not_ black-pad strings

The following program prints (with gfortran, NAG f95, ifort) something like 20100817145358.302aa expected, the number is black padded, i.e. 20100817145659.787 (as g95, pathf95, openf95 do) The problem was reported

[Bug c++/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-17 12:49 --- It's the FEs job really. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

--- Comment #1 from hubicka at gcc dot gnu dot org 2010-08-17 12:38 --- Created an attachment (id=21503) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21503&action=view) testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45307

[Bug middle-end/45307] New: Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

Compilling: ./g++ -O2 ~/mozalloc.ii -S -m32 gives me: .type _GLOBAL__I_moz_free, @function _GLOBAL__I_moz_free: .LFB58: .cfi_startproc rep ret .cfi_endproc .LFE58: .size _GLOBAL__I_moz_free, .-_GLOBAL__I_moz_free .section.ctors,"

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

--- Comment #7 from uros at gcc dot gnu dot org 2010-08-17 12:25 --- Subject: Bug 45296 Author: uros Date: Tue Aug 17 12:25:24 2010 New Revision: 163303 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163303 Log: PR target/45296 * reginfo.c (globalize_reg): Reject

[Bug fortran/45081] [4.3/4.4/4.5/4.6 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208

--- Comment #6 from pault at gcc dot gnu dot org 2010-08-17 12:07 --- (In reply to comment #1) > Confirmed as a regression: it compiles with 4.2.4 (ppc-darwin), gives an ICE > with 4.3.4, 4.4.2, 4.5.0 and trunk. > You did not mark the PR as confirmed :-) Paul -- pault at gcc dot

[Bug libgomp/45192] OpenMP fails in DLLs

--- Comment #4 from john at quivinco dot com 2010-08-17 11:57 --- The cause has been isolated to a problem with my C code. The DLL now works on Windows XP, but not Vista 64!? -- john at quivinco dot com changed: What|Removed |Added

[Bug middle-end/45306] ICE (Segmentation fault) while building PyQt with -fgraphite-identity

--- Comment #2 from bero at arklinux dot org 2010-08-17 11:14 --- Seems to work on 32-bit x86 -- bero at arklinux dot org changed: What|Removed |Added GCC build triplet|

[Bug middle-end/45306] ICE (Segmentation fault) while building PyQt with -fgraphite-identity

--- Comment #1 from bero at arklinux dot org 2010-08-17 11:13 --- Created an attachment (id=21502) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21502&action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45306

[Bug middle-end/45306] New: ICE (Segmentation fault) while building PyQt with -fgraphite-identity

g++ -c -m64 -O2 -fgraphite-identity -DQT_USE_FAST_CONCATENATION -DQT_USE_FAST_OPERATOR_PLUS -fPIC -Wall -W -D_REENTRANT -DNDEBUG -DSIP_PROTECTED_IS_PUBLIC -Dprotected=public -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I. -I/usr/src/ark/BUILD/PyQt-x11-gpl-4.7.3/qpy/QtGui -I/usr/include/python2.7 -I/us

[Bug c++/45049] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in push_overloaded_decl, at cp/name-lookup.c:2160

--- Comment #5 from zsojka at seznam dot cz 2010-08-17 10:55 --- Created an attachment (id=21501) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21501&action=view) different testcase This one has declaration of overloaded functions in function scope. The assert is the same. $ gcc

[Bug c++/45303] Compile error when not using -ftree-ter

--- Comment #6 from jobnoorman at gmail dot com 2010-08-17 10:49 --- (In reply to comment #5) > For inline-asm? Certainly not. Consider much simpler: > void foo (void) > { > int i; > i = 6; > asm volatile ("" : : "i" (i)); > } > which will work with -O and above, but not for -O0,

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

--- Comment #10 from jakub at gcc dot gnu dot org 2010-08-17 10:47 --- Fixed then. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug fortran/45305] Array-valued calles to elementals are not simplified

--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-17 10:19 --- Note: The middle end also does not see that the expression can be optimized - and thus fails also to do so for -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45305

[Bug fortran/45305] New: Array-valued calles to elementals are not simplified

Found when looking at PR fortran/36158 If the argument is an initialization expression and not too large, it should be expanded. While the following works: real, parameteR :: bes(2) = bessel_jn([1,2], 1.0) print *, bes end The "if" is never optimized away for: if (any (abs(bessel_jn([1,2],

[Bug c++/45303] Compile error when not using -ftree-ter

--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-17 10:16 --- For inline-asm? Certainly not. Consider much simpler: void foo (void) { int i; i = 6; asm volatile ("" : : "i" (i)); } which will work with -O and above, but not for -O0, for exactly the same reason. -- ht

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

--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-17 10:06 --- Sounds like a target bug. After variable_tracking_main the notes look correct: (note 88 23 89 2 (var_location array (reg:HI 0 R0 [ pass_through_array ])) NOTE_INSN_VAR_LOCATION) (note 89 88 90 2 (var_location size (re

[Bug c++/45303] Compile error when not using -ftree-ter

--- Comment #4 from jobnoorman at gmail dot com 2010-08-17 10:04 --- (In reply to comment #1) > IMHO this isn't a bug, to simplify that into an integer you really need some > optimizations. The conversion looks very weird, if you use something saner > like (void *)&Foo::foobar, it will

[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

-- 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=45301

[Bug fortran/44471] Wrong call with variadic declaration

--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-17 09:51 --- The #c2 patch is problematic, because build_function_type shares function types, so setting TYPE_ARG_TYPES on that I'm afraid will affect all functions with (...) arguments and the same return type. So, the arglist ne

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

--- Comment #9 from rguenth at gcc dot gnu dot org 2010-08-17 09:47 --- Subject: Bug 45266 Author: rguenth Date: Tue Aug 17 09:47:44 2010 New Revision: 163297 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163297 Log: 2010-08-17 Richard Guenther PR testsuite/45266

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

--- Comment #24 from bernds at gcc dot gnu dot org 2010-08-17 09:47 --- I think that's beginning to look reasonable. So the problem was that without alternative 2, such an add would match alternative 3 instead and be split? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470

[Bug c++/45303] Compile error when not using -ftree-ter

--- Comment #3 from redi at gcc dot gnu dot org 2010-08-17 09:42 --- Looking at the diagnostics issued when -pedantic is added, I think the right conversion is (void*)(plain_foobar_t)&Foo::foobar That still uses the G++ extension, and doesn't give the asm error even without optimisatio

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

--- Comment #27 from pault at gcc dot gnu dot org 2010-08-17 09:42 --- (In reply to comment #25) > (In reply to comment #21) > > In my opinion revision 162487 is only a partial fix of the problem. If I > > split > > a modified test case in two files: [...] I still get [...] Bus error >

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

--- Comment #6 from ubizjak at gmail dot com 2010-08-17 09:38 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01226.html . -- ubizjak at gmail dot com changed: What|Removed |Added --

[Bug c++/45303] Compile error when not using -ftree-ter

--- Comment #2 from redi at gcc dot gnu dot org 2010-08-17 09:38 --- (In reply to comment #1) > IMHO this isn't a bug, to simplify that into an integer you really need some > optimizations. The conversion looks very weird, if you use something saner The conversion uses this extension h

[Bug fortran/44471] Wrong call with variadic declaration

--- Comment #4 from burnus at gcc dot gnu dot org 2010-08-17 09:35 --- Cf. PR 45304 for a partial fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44471

[Bug fortran/45304] Functions/subroutines without arguments always treated like varargs

--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-17 09:34 --- (In reply to comment #0) > shouldn't: > call bar (i) > call bar (f) > warn not just about the argument mismatch to foo, but also about bar? Yes. One should construct the function interface from the argument usage -

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

--- Comment #11 from jakub at gcc dot gnu dot org 2010-08-17 09:25 --- Should be fixed for 4.5.2, 4.6 will use a different approach. -- jakub at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c++/45303] Compile error when not using -ftree-ter

--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-17 09:21 --- IMHO this isn't a bug, to simplify that into an integer you really need some optimizations. The conversion looks very weird, if you use something saner like (void *)&Foo::foobar, it will even work with -O0. -- ht

[Bug fortran/45304] Functions/subroutines without arguments always treated like varargs

--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-17 08:59 --- Created an attachment (id=21500) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21500&action=view) gcc46-pr45304-partial.patch The partial patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45304

[Bug fortran/45304] New: Functions/subroutines without arguments always treated like varargs

In: subroutine foo (i, j) integer :: i, j, k, l k = i l = j i = i * 10 i = i + j call baz (i) i = i + j end subroutine subroutine bar (i, j) integer :: i, j, k, l k = i l = j i = i * 10 i = i + j call baz (i) i = i + j end subroutine subroutine fn () end subroutine fn pr

[Bug c++/45303] New: Compile error when not using -ftree-ter

I have the following program: main.cpp -- struct Foo { void foobar() {} }; typedef void (*plain_foobar_t)(Foo*); int main() { asm("push %0;" : : "i"((plain_foobar_t)&Foo::foobar));

[Bug c/40563] -Wc++-compat does not warn about uninitialized const field in struct

--- Comment #3 from pzhao at gcc dot gnu dot org 2010-08-17 08:30 --- Fix on trunk -- pzhao at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNE

  1   2   >