[Bug libfortran/47567] Wrong output for small absolute values with F editing

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #8 from Thomas Henlich 2011-02-05 07:53:40 UTC --- (In reply to comment #6) > In extension, the following should also print the same result: > > print "(F1.0)", 0.0 ! => 0 > print "(F1.0)", 1.0 ! => * > print "(F1.0)", 2.0 ! => *

[Bug libfortran/47567] Wrong output for small absolute values with F editing

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #7 from Thomas Henlich 2011-02-05 07:45:57 UTC --- (In reply to comment #6) > Regardless of this choice, the following should all print the same result, > which they currently don't. > > print "(F1.0)", 0.0 ! => 0 > print "(F1.0)",

[Bug libfortran/47567] Wrong output for small absolute values with F editing

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #6 from Thomas Henlich 2011-02-05 07:40:49 UTC --- (In reply to comment #3) > For this special case: > > print "(F1.0)", 0.0 ! => 0 expected * > > Up to now, we have interpreted the last sentence in F95 10.5.1.2.1 F95 > 10.2.1.

[Bug libfortran/47567] Wrong output for small absolute values with F editing

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #5 from Jerry DeLisle 2011-02-05 06:22:03 UTC --- Created attachment 23251 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23251 A proposed patch This patch regression tests OK and gives the results shown in my last comment.

[Bug tree-optimization/47615] New: [4.6 Regression] ICE: too deep recursion in phi_translate/phi_translate_1 with -ftree-pre -fno-tree-fre -fno-tree-sra

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47615 Summary: [4.6 Regression] ICE: too deep recursion in phi_translate/phi_translate_1 with -ftree-pre -fno-tree-fre -fno-tree-sra Product: gcc Version: 4.6.0 Status:

[Bug libfortran/47567] Wrong output for small absolute values with F editing

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #4 from Jerry DeLisle 2011-02-05 02:10:39 UTC --- With: print "(F0.0)", 0.001 ! => 0. print "(F0.0)", 0.01 ! => 0. print "(F0.0)", 0.1 ! => 0. print "(F1.0)", -0.0 ! => 0 print "(F1.0)", 0.001 ! => * print "(F1.0)", 0.01 ! => *

[Bug tree-optimization/46194] [4.5/4.6 Regression] gcc.dg/graphite/block-0.c FAILs with -ftree-parallelize-loops

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46194 Sebastian Pop changed: What|Removed |Added Known to work||4.6.0 Known to fail|4.6.0

[Bug tree-optimization/46194] [4.5/4.6 Regression] gcc.dg/graphite/block-0.c FAILs with -ftree-parallelize-loops

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46194 --- Comment #11 from Sebastian Pop 2011-02-05 01:39:23 UTC --- Author: spop Date: Sat Feb 5 01:39:20 2011 New Revision: 169847 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169847 Log: Fix PR46194: fix the computation of distance vector

[Bug libfortran/47567] Wrong output for small absolute values with F editing

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #3 from Jerry DeLisle 2011-02-05 01:32:42 UTC --- For this special case: print "(F1.0)", 0.0 ! => 0 expected * Up to now, we have interpreted the last sentence in F95 10.5.1.2.1 F95 10.2.1.1 to require this to print '0'. "Leadi

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47610 --- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2011-02-05 01:03:51 UTC --- On Fri, 04 Feb 2011, jakub at gcc dot gnu.org wrote: > --- Comment #4 from Jakub Jelinek 2011-02-04 > 23:08:21 UTC --- > Created attachment 23249 > --> http://gcc.g

[Bug lto/47607] FAIL: gcc.c-torture/execute/builtins/abs-2.c execution, -O2 -flto

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47607 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #3

[Bug target/47596] internal compiler error: in print_reg, at config/i386/i386.c:10894

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47596 --- Comment #5 from Jim Michaels 2011-02-04 23:12:20 UTC --- unfortunately, a release of later versions of gcc in a personal sezero build are not available.

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47610 Jakub Jelinek changed: What|Removed |Added Status|WAITING |NEW Target Milestone|---

[Bug middle-end/38878] [4.4/4.5/4.6/4.7 Regression] gcc.dg/tree-ssa/foldaddr-1.c XFAILed

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38878 Jakub Jelinek changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47610 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at

[Bug rtl-optimization/47614] cpu2000 benchmark 301.apsi fails with revision 169782

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614 Pat Haugen changed: What|Removed |Added CC||bergner at gcc dot gnu.org,

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47610 John David Anglin changed: What|Removed |Added Target|hppa64-hp-hpux11.11 |hppa*-*-* Host|hppa64-h

[Bug rtl-optimization/47614] New: cpu2000 benchmark 301.apsi fails with revision 169782

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614 Summary: cpu2000 benchmark 301.apsi fails with revision 169782 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization

[Bug fortran/47613] [4.6 Regression] namelist read with -static

-o z lo.f90 troutmask:sgk[212] ./z -1 T troutmask:sgk[213] gfc45 -o z lo.f90 -static troutmask:sgk[214] ./z -1 T troutmask:sgk[215] gfc4x --version GNU Fortran (GCC) 4.6.0 20110204 (experimental) troutmask:sgk[216] gfc45 --version GNU Fortran (GCC) 4.5.3 20110131 (prerelease) So, th

[Bug target/46997] new ia64 vector instructions are broken on HP-UX (big-endian)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46997 --- Comment #4 from Steve Ellcey 2011-02-04 21:46:50 UTC --- Author: sje Date: Fri Feb 4 21:46:45 2011 New Revision: 169840 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169840 Log: 2011-02-04 Richard Henderson Steve Ellcey

[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 --- Comment #3 from Ian Lance Taylor 2011-02-04 21:27:40 UTC --- It's similar to PR 46878 in that this is also CC0 related, but it is different code that is splitting up the CC0 setter and the CC0 user. My sources do include the patch for PR 468

[Bug c++/47611] [trans-mem] memory allocated by default new/new_vec operator can be considered as transaction local

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47611 Aldy Hernandez changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED

[Bug other/47554] [trans-mem] expand_expr_addr_expr_1 ICE

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47554 Aldy Hernandez changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|

[Bug fortran/47613] New: [4.6 Regression] namelist read with -static

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47613 Summary: [4.6 Regression] namelist read with -static Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unas

[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 Andrew Pinski changed: What|Removed |Added See Also||http://gcc.gnu.org/bugzilla

[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 Joel Sherrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug rtl-optimization/47612] New: RTL crash when cc0 setter moved away from cc0 user

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 Summary: RTL crash when cc0 setter moved away from cc0 user Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3

[Bug tree-optimization/46886] [4.5/4.6 Regression] gfortran.dg/array_constructor_9.f90 FAILs with -ftree-parallelize-loops -fstrict-overflow -fno-tree-ch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46886 --- Comment #4 from sebpop at gmail dot com 2011-02-04 20:30:46 UTC --- On Tue, Jan 18, 2011 at 11:00, jakub at gcc dot gnu.org wrote: > Seems one extra incorrect iteration is added after GOMP_parallel_end: That extra iteration is added by this

[Bug c++/46941] [trans-mem] new/delete operator are unsafe

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #15 from Patrick Marlier 2011-02-04 20:30:15 UTC --- Filled a enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47611 Yeah don't lose time of this! On Fri, Feb 4, 2011 at 9:1

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47610 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-02-04 20:28:03 UTC --- On Fri, 04 Feb 2011, jakub at gcc dot gnu.org wrote: > Please provide preprocessed source, so I can try to reproduce it with a cross > compiler. Attached.

[Bug c++/47611] New: [trans-mem] memory allocated by default new/new_vec operator can be considered as transaction local

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47611 Summary: [trans-mem] memory allocated by default new/new_vec operator can be considered as transaction local Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: en

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47610 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug c++/46941] [trans-mem] new/delete operator are unsafe

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #14 from Aldy Hernandez 2011-02-04 20:16:07 UTC --- Yes, this is an improvement, because once has to figure out why the unadultered new operator is not handled specially by the alias oracle. You are welcome to file a PR as an enhance

[Bug c++/46941] [trans-mem] new/delete operator are unsafe

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #13 from Patrick Marlier 2011-02-04 20:13:04 UTC --- Hi Aldy, On Fri, Feb 4, 2011 at 7:40 PM, aldyh at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 > > --- Comment #12 from A

[Bug other/47554] [trans-mem] expand_expr_addr_expr_1 ICE

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47554 Aldy Hernandez changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #3 from Aldy Hernand

[Bug middle-end/47610] New: [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

6.0 --with-libelf=/opt/gnu64 --enable-languages=c,c++,objc,obj-c++,fortran,lto Thread model: posix gcc version 4.6.0 20110204 (experimental) [trunk revision 169834] (GCC)

[Bug c++/46394] [C++0X] [4.6 Regression] no matching function with default template parameter

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46394 Dodji Seketeli changed: What|Removed |Added Depends on|35722 | --- Comment #5 from Dodji Seketeli 201

[Bug target/47609] New: libstdc++ depends on libgcc_s.10.5 but gets linked to libgcc_s.10.4

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47609 Summary: libstdc++ depends on libgcc_s.10.5 but gets linked to libgcc_s.10.4 Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c++/46941] [trans-mem] new/delete operator are unsafe

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #12 from Aldy Hernandez 2011-02-04 18:40:09 UTC --- Patrick, the reason memory allocated by the C++ new operator does not get optimized by the TM-memopt pass is not because of a missing ECF_MALLOC attribute, but because the alias orac

[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548 --- Comment #6 from Joel Sherrill 2011-02-04 18:30:41 UTC --- (In reply to comment #5) > See if one of these other changes caused the problem. If so, yeah, I'll check > this one in and we'll work on the other one separately. The new error you'r

[Bug target/47608] libstdc++ links to bad libgcc_s on OS X (libgcc_s rebuilt needlessly and incorrectly)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47608 --- Comment #1 from Pierre Ossman 2011-02-04 18:12:26 UTC --- Created attachment 23246 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23246 Hackish workaround This is what I've done here to workaround the problem. Compiles fine, but I haven

[Bug tree-optimization/46728] [4.6 Regression] GCC no longer generates fmadd for pow (x, 0.75)+y on powerpc

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46728 --- Comment #2 from Michael Meissner 2011-02-04 18:11:09 UTC --- When the initial changes for bug 42694 was added that optimizes pow (x, 0.75) into sqrt(sqrt(x))*sqrt(x) under fast math, there was a desire to move this RTL optimization into the t

[Bug target/47608] New: libstdc++ links to bad libgcc_s on OS X (libgcc_s rebuilt needlessly and incorrectly)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47608 Summary: libstdc++ links to bad libgcc_s on OS X (libgcc_s rebuilt needlessly and incorrectly) Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Pri

[Bug tree-optimization/43695] [4.5 Regression] ICE: verify_flow_info failed: BB 2 is missing an EH edge with -fipa-cp-clone

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43695 --- Comment #8 from hjl at gcc dot gnu.org 2011-02-04 17:23:34 UTC --- Author: hjl Date: Fri Feb 4 17:23:30 2011 New Revision: 169835 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169835 Log: Add a testcase for PR tree-optimization/4369

[Bug target/31782] Invalid assembly code on initial dollar signs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31782 funto66 at gmail dot com changed: What|Removed |Added CC||funto66 at gmail dot com --- Co

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 --- Comment #8 from Dongsheng Song 2011-02-04 16:05:13 UTC --- On Fri, Feb 4, 2011 at 23:54, ktietz at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 > > --- Comment #7 from Kai Tietz 2011-02-04 15:54:10 > UTC --- >

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 --- Comment #7 from Kai Tietz 2011-02-04 15:54:10 UTC --- (In reply to comment #6) > (In reply to comment #5) > > My next complete building will be started at 23:50 PM(UTC), if I got > > different > > answer, I will inform you. > > OOPS, libgcc

[Bug inline-asm/23200] [4.3/4.4/4.5 Regression] rejects "i"(&var + 1)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Known to wo

[Bug inline-asm/23200] [4.3/4.4/4.5/4.6 Regression] rejects "i"(&var + 1)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200 --- Comment #47 from Jakub Jelinek 2011-02-04 15:50:58 UTC --- Author: jakub Date: Fri Feb 4 15:50:51 2011 New Revision: 169831 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169831 Log: PR inline-asm/23200 * tree-ssa-ter.c (is_r

[Bug tree-optimization/43695] [4.5 Regression] ICE: verify_flow_info failed: BB 2 is missing an EH edge with -fipa-cp-clone

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43695 --- Comment #7 from H.J. Lu 2011-02-04 15:36:05 UTC --- We should add this testcase.

[Bug tree-optimization/43695] [4.5 Regression] ICE: verify_flow_info failed: BB 2 is missing an EH edge with -fipa-cp-clone

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43695 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summa

[Bug c++/46941] [trans-mem] new/delete operator are unsafe

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #11 from Aldy Hernandez 2011-02-04 15:31:14 UTC --- Patrick. It's already on my TODO. I'm working on it.

[Bug middle-end/47602] Permit inline asm to clobber PIC register

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602 --- Comment #13 from Eric Botcazou 2011-02-04 15:23:22 UTC --- > In what way are we helping them by forcing them to know about it? How does > that help them write inline assembler which, e.g., uses the cpuid instruction, > or makes a kernel syst

[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548 --- Comment #5 from DJ Delorie 2011-02-04 15:21:40 UTC --- See if one of these other changes caused the problem. If so, yeah, I'll check this one in and we'll work on the other one separately. The new error you're seeing is one I've seen on and

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #57 from Jack Howarth 2011-02-04 15:16:42 UTC --- For the testcase in Comment 56 using my proposed patch from Comment 45... gcc-4 -dynamiclib -o libtestcall.dylib -flat_namespace -undefined suppress -single_module test_call.c gcc-4 -

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #56 from Jack Howarth 2011-02-04 15:11:29 UTC --- The following works as a testcase for PR47558 test_main.c -- void main (void) { extern int unwindcall(void); int i; i=unwindcall(); } -

[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548 --- Comment #4 from Joel Sherrill 2011-02-04 15:10:00 UTC --- (In reply to comment #3) > That's odd. Could you take my patch back out, and verify the problem goes > back > to the original one? My patch shouldn't be able to affect anything earl

[Bug middle-end/47602] Permit inline asm to clobber PIC register

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602 --- Comment #12 from H.J. Lu 2011-02-04 15:01:56 UTC --- (In reply to comment #10) > > what way are we helping them by forcing them to know about it? How does that > help them write inline assembler which, e.g., uses the cpuid instruction, or U

[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548 DJ Delorie changed: What|Removed |Added CC||dj at redhat dot com --- Comment #3 from DJ

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #21 from dave at hiauly1 dot hia.nrc.ca 2011-02-04 14:42:39 UTC --- > Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00196.html > > This is my previous janitorial patch, + a kludge which I believe should fix > the > issue on HP-U

[Bug target/47548] [regression] m32c-rtems ICEt in change_address_1, at emit-rtl.c:1933

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47548 --- Comment #2 from Joel Sherrill 2011-02-04 14:39:37 UTC --- Created attachment 23245 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23245 Next ICE With your patch, the build fails earlier. $ m32c-rtems4.11-gcc -mcpu=m32cm -g -O1 -c pr

[Bug lto/47607] FAIL: gcc.c-torture/execute/builtins/abs-2.c execution, -O2 -flto

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47607 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug middle-end/47602] Permit inline asm to clobber PIC register

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602 --- Comment #11 from Andreas Schwab 2011-02-04 14:28:00 UTC --- If you are writing assembler code you need to know your ABI in and out.

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 --- Comment #6 from Dongsheng Song 2011-02-04 14:26:44 UTC --- (In reply to comment #5) > My next complete building will be started at 23:50 PM(UTC), if I got different > answer, I will inform you. OOPS, libgcc_s_sjlj-1.dll installed OK. But the

[Bug middle-end/47602] Permit inline asm to clobber PIC register

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602 --- Comment #10 from Ian Lance Taylor 2011-02-04 14:16:32 UTC --- What advantage do we bring to our users by requiring them to be aware of the details of the PIC register when writing inline asm code? Again, those who *are* aware of the PIC regi

[Bug c++/46941] [trans-mem] new/delete operator are unsafe

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #10 from Patrick Marlier 2011-02-04 13:54:30 UTC --- (In reply to comment #8) > I will tackle the ECF_MALLOC comment separately. Should I open up a new bug report for this? or is it already on your TODO list? Patrick Marlier.

[Bug pch/47584] [4.6 regression] internal compiler error: sigsegv in libcpp/line-map.c:285

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47584 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 f

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 --- Comment #5 from Dongsheng Song 2011-02-04 13:29:09 UTC --- (In reply to comment #4) > Could you please check if this patch solves the issue for multilib? (It treats > multilib scenario like cross for installation of dll files). > > Index: co

[Bug lto/47607] FAIL: gcc.c-torture/execute/builtins/abs-2.c execution, -O2 -flto

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47607 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 f

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #55 from Jack Howarth 2011-02-04 12:31:28 UTC --- Moved conversation upstream for definitive answer from the Apple linker developer... http://lists.apple.com/archives/darwin-dev//2011/Feb/msg0.html

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #54 from Jack Howarth 2011-02-04 12:02:18 UTC --- Test results for proposed patch in Comment 45 at http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg00416.html.

[Bug lto/47607] New: FAIL: gcc.c-torture/execute/builtins/abs-2.c execution, -O2 -flto

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47607 Summary: FAIL: gcc.c-torture/execute/builtins/abs-2.c execution, -O2 -flto Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #53 from Iain Sandoe 2011-02-04 11:26:14 UTC --- (In reply to comment #52) > ain, > I think the key misassumption you are making is that the internal linker > and dyld behavior for 10.5 is valid under 10.6. Remember that unlike un

[Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47606 Summary: [trans-mem] internal compiler error in expand_block_tm with O2 Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #52 from Jack Howarth 2011-02-04 11:02:02 UTC --- ain, I think the key misassumption you are making is that the internal linker and dyld behavior for 10.5 is valid under 10.6. Remember that unlike under Leopard, where /usr/lib/lib

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #51 from Iain Sandoe 2011-02-04 10:57:39 UTC --- (In reply to comment #37) > Let me know when the dust settles and you guys agree on the path forward and I > will decloak... I've been trying to avoid reading/understanding the issue...

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #50 from Iain Sandoe 2011-02-04 10:52:38 UTC --- (In reply to comment #49) > (In reply to comment #38) > > [ you might want to re-check > http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00274.html would work with > -flat_namespace - it'

[Bug target/46788] unsigned int possible treated as signed in a union/struct

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46788 Mikael Pettersson changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #49 from Iain Sandoe 2011-02-04 10:21:27 UTC --- (In reply to comment #38) > This would avoid the need for reverting r163267. I'd rather not revert r163267 because of the behavior described in comment #35. However, I think that lib

[Bug c/47599] -fno-short-wchar does not force long wchar

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47599 --- Comment #7 from Bastien ROUCARIES 2011-02-04 09:41:04 UTC --- Sorry replace the last linux by cygwin

[Bug c/47599] -fno-short-wchar does not force long wchar

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47599 --- Comment #6 from Bastien ROUCARIES 2011-02-04 09:39:02 UTC --- I have checked with gcc -E the following program: typedef __WCHAR_TYPE__ wchar_t; under linux it output typedef int wchar_t under linux with -fno-short-char it output typedef int

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 --- Comment #4 from Kai Tietz 2011-02-04 09:33:58 UTC --- Could you please check if this patch solves the issue for multilib? (It treats multilib scenario like cross for installation of dll files). Index: config.gcc =

[Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366 --- Comment #9 from Paul Thomas 2011-02-04 09:32:01 UTC --- (In reply to comment #5) > Realloc-on-assign for scalars was implemented in r169356. > > Paul, what does it take to make this work for polymorphic scalars? Not a lot, I think. If you

[Bug c/47599] -fno-short-wchar does not force long wchar

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47599 --- Comment #5 from Bastien ROUCARIES 2011-02-04 09:25:36 UTC --- ok thanks it is defined in the header and in this case they are two bugs. Try the following program #include typedef __WCHAR_TYPE__ wchar_t; wchar_t a[] = L"aa"; int s = sizeof

[Bug middle-end/47602] Permit inline asm to clobber PIC register

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot |

[Bug c/47599] -fno-short-wchar does not force long wchar

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47599 --- Comment #4 from Andrew Pinski 2011-02-04 08:33:03 UTC --- It is a builtin type (for C++ it is exposed as the keyword, wchar_t). For C, the headers define the type, see the preprocessed source to show that is the case.

[Bug c/47599] -fno-short-wchar does not force long wchar

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47599 --- Comment #3 from Bastien ROUCARIES 2011-02-04 08:27:40 UTC --- BTW i have checked the source code, and if my memory is correct wchar_t is defined as MODIFIED_WCHAR_T = fshortwchar ? "Short int" : WCHAR_T Where wchar_t is defined by the archit

[Bug c/47599] -fno-short-wchar does not force long wchar

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47599 --- Comment #2 from Bastien ROUCARIES 2011-02-04 08:21:20 UTC --- I disagree wchar_t is a building type. Indeed L"aa" should expand to 16 bits packed char with short wchar and 32 bits with no-short-wchar. Due to the LNaaN constant specification