[Bug c++/40217] New: gcc-4.3.1 fails to produce an error message for out of memory condition
I accidentally ran my FreeBSD-71 system with 3GB RAM without the swap space and
compiled a large module with high degree of optimization.
I was getting this error:
{standard input}: Assembler messages:
{standard input}:68321: Warning: end of file not at end of a line; newline
inserted
{standard input}:69363: Error: undefined symbol `.LLSDACSE3986' in operation
{standard input}:69427: Error: undefined symbol `.LFB398' in operation
g++: Internal error: Killed: 9 (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.
This happened 100% of time, and error message stayed the same.
So gcc was getting memory allocation failure but instead of failing with the
relevant message it was passing wrong assembly to 'as'.
Adding swap cured the situation.
gcc-4.3.3 was failing in a similar way but with a bit different error message.
This should be fixed to make gcc more reliable in the random user environments.
Today by googling the above error messages you can get a lot of references of
similar situations happening to various people.
--
Summary: gcc-4.3.1 fails to produce an error message for out of
memory condition
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40217
[Bug c++/40217] gcc-4.3.1 fails to produce an error message for out of memory condition
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-21 06:25 --- g++: Internal error: Killed: 9 (program cc1plus) The kernel killed cc1plus because of being out of memory. So yes it did already say what happened. Also since -pipe was being used, it is hard to tell the assembler that it ran out of memory and to abort assembling too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40217
[Bug fortran/30374] unpacking intent(IN) arguments
--- Comment #4 from jv244 at cam dot ac dot uk 2009-05-21 08:34 --- Paul, 2 years ago you had a (one liner?) patch for this one, but gfortran still seem to unpack for intent(IN) data: MODULE M1 CONTAINS SUBROUTINE S1(I) INTEGER, DIMENSION(3), INTENT(IN) :: I END SUBROUTINE END MODULE USE M1 INTEGER, TARGET, DIMENSION(9) :: I INTEGER, DIMENSION(:), POINTER :: IP IP=I(1:9:3) CALL S1(IP) END -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail||4.5.0 Last reconfirmed|2007-10-26 07:25:36 |2009-05-21 08:34:53 date|| Summary|aliasing amoung dummy |unpacking intent(IN) |arguments: possibly missing |arguments |optimization| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30374
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #6 from bmei at broadcom dot com 2009-05-21 08:38 --- I only submitted small patch before. To add a pass (may need new command-line option, disabling the old rtl-level unrolling) seems to be a big issue to me. Don't know what's procedure. My code also contains my own implementation of #pragma unroll. I need to clean it up for the public patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug fortran/40218] New: incorrect location for error message
note the dot instead of the comma after target cat test.f90 INTEGER, TARGET. DIMENSION(9) :: I END gfortran test.f90 test.f90:1.8: INTEGER, TARGET. DIMENSION(9) :: I 1 Error: Invalid character in name at (1) -- Summary: incorrect location for error message Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40218
[Bug fortran/30374] unpacking intent(IN) arguments
--- Comment #5 from jv244 at cam dot ac dot uk 2009-05-21 08:40 --- (In reply to comment #4) Paul, 2 years ago you had a (one liner?) patch for this one, but gfortran still seem to unpack for intent(IN) data: ugh... no. I tested with 4.3 instead of 4.5. Instead we can close this, as this seems solved. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail|4.5.0 | Known to work||4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30374
[Bug fortran/30374] unpacking intent(IN) arguments
--- Comment #6 from jv244 at cam dot ac dot uk 2009-05-21 08:45 --- fixed -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30374
[Bug c/40216] Optimization error when compiling bfd/ecofflink.c on x86_64
--- Comment #2 from schwab at linux-m68k dot org 2009-05-21 09:00 --- This is violating the C strict aliasing rule: if (! ecoff_add_bytes ((char **) debug-external_ext, (char **) debug-external_ext_end, (symhdr-iextMax + 1) * (size_t) external_ext_size)) which has already been fixed in binutils more than 3 years ago. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40216
[Bug fortran/40195] ICE when compiling a file located in another directory
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-05-21 09:12 --- It works for me. This sounds like the issue you'd have if you didn't have write permission to the current directory. What are the permissions and ownership of the bin and source directories? What user is trying to compile? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40195
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #5 from paolo dot carlini at oracle dot com 2009-05-21 09:15 --- So, you should compare it to the previous delete, which normally should be the *only* one involving basic_string. To be clear, the expected sequence is the following, as you can check on any other linux target: operator new is called operator new is called operator delete is called 1 allocations to be released operator delete is called All memory released that is, the additional delete / new pair that you are seeing at the end is completely bogus. Of course, I would suggest also checking what happens vs optimization level (also for the *.so, thus rebuilding the library CXXFLAGS=-OX -g). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug pch/40215] Generated GCH fails to honor include guards with -no-integrated-cpp
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-21 09:41 --- Works as designed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40215
[Bug middle-end/40141] [4.3 Regression] accessing aliased __m128 miscompiles
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-21 10:27 --- Patch was posted and rejected as too invasive for 4.3. Distributors can apply the referenced patch. Thus, WONTFIX for 4.3, fixed for 4.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||05/msg00925.html Status|ASSIGNED|RESOLVED Known to fail||4.3.3 Known to work||4.4.0 Resolution||FIXED Target Milestone|4.3.4 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40141
[Bug middle-end/40026] [4.5 Regression] ICE during gimplify_init_constructor
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-21 10:29 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40026
[Bug libgcj/40182] [4.4/4.5 regression] regressions in libjava testsuite on sparc-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40182
[Bug libgcj/40180] [4.4/4.5 regression] regressions in libjava testsuite on ia64-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40180
[Bug middle-end/40095] [4.5 Regression] Revision 147342/147343 caused extra failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40095
[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
[Bug c++/40085] [4.5 Regression] ICE compiling libmudflap.c++/fail24-frag.cxx
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40085
[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40027
[Bug target/40017] [4.4/4.5 Regression] stdbool.h/altivec.h
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug c++/40007] [4.5 regression] specialization causes access problem in primary template
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40007
[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[Bug other/37515] [meta-bug] GCC 4.5 pending patches
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37515
[Bug middle-end/39509] [4.3/4.4/4.5 Regression] bad optimization(?) pure virtual function call with -O2
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-05-21 10:35 --- Which means it should work with -fno-tree-sink. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||39604 Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
[Bug target/39715] [4.5 Regression][cond-optab] extra sign extensions on Thumb
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||arm Keywords||missed-optimization Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39715
[Bug target/39716] [4.5 Regression][cond-optab] worse MAX_EXPR expansion for Thumb
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||arm Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39716
[Bug target/39725] [4.5 Regression][cond-optab] MIPS pessimizations on floating-point
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||mips-linux-gnu Keywords||missed-optimization Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39725
[Bug target/39726] [4.5 Regression][cond-optab] ColdFire pessimizations on QImode/HImode tests
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39726
[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug c++/40007] [4.5 regression] specialization causes access problem in primary template
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40007
[Bug target/40017] [4.4/4.5 Regression] stdbool.h/altivec.h
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||powerpc Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40027
[Bug middle-end/40029] [4.5 Regression] Big degradation on swim/mgrid on powerpc 32/64 after alias improvement merge (gcc r145494)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40029
[Bug c/40033] [4.5 regression] ICE with invalid statement expression
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40033
[Bug middle-end/40060] [4.5 Regression] casts loose alignment info
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40060
[Bug target/39715] [4.5 Regression][cond-optab] extra sign extensions on Thumb
--- Comment #1 from rearnsha at gcc dot gnu dot org 2009-05-21 10:49
---
Another case, compile with -mcpu=arm1136jf-s -mthumb -O2
void f(unsigned a, unsigned b, unsigned c, unsigned d)
{
if (a = b || c d)
foo();
else
bar();
}
f:
push{r4, lr}
cmp r3, r2
sbc r2, r2, r2 @ r2 = 0 or -1
neg r2, r2 @ r2 = 0 or 1
cmp r2, #0
beq .L7
.L5:
bl foo
.L1:
@ sp needed for prologue
pop {r4, pc}
.L7:
cmp r1, r0 @ r2 = 0 (by flow control)
adc r2, r2, r2 @ r2 = 0 / 1
uxtbr2, r2 @ so this is redundant
cmp r2, #0
bne .L5
bl bar
b .L1
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-05-21 10:49:12
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39715
[Bug middle-end/40079] [4.5 Regression] Revision 147294 caused extra failures
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-21 10:49 --- Only FAIL: /export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/testsuite/TestLeak.exe execution - /export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/testsuite/TestLeak.exe is still present. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40079
[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
[Bug middle-end/40091] [4.5 Regression] FAIL: g++.dg/opt/thunk3.C (test for excess errors)
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-21 10:52 --- Is this still failing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40091
[Bug middle-end/40095] [4.5 Regression] Revision 147342/147343 caused extra failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40095
[Bug rtl-optimization/40101] [4.5 Regression] 200.sixtrack ICEs in get_seqno_by_preds, at sel-sched-ir.c:3752
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40101
[Bug middle-end/40102] [4.5 Regression] Revision 147294 caused ICE: verify_cgraph_node
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-21 11:01 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2009-05-21 11:01:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40102
[Bug rtl-optimization/40107] [4.5 Regression] gcc.c-torture/execute/builtins/memmove.c and gcc.c-torture/execute/builtins/memmove-chk.c fail at -O1 on spu-elf
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40107
[Bug debug/40126] [4.5 Regression] -O2 -g results in: can't resolve `.LFE95' {*UND* section} - `.Ltext0' {.text section}
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-debug Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40126
[Bug c++/40138] [4.5 Regression] ICE with invalid va_arg
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40138
[Bug tree-optimization/40140] [4.5 Regression] ICE with -ftree-parallelize-loops
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40140
[Bug middle-end/40161] [4.5 Regression] Revision 147566 may cause many regressions
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-21 11:04 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40161
[Bug middle-end/40163] [4.5 Regression] null pointer in remove_unreachable_regions
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40163
[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap
--- Comment #30 from rguenth at gcc dot gnu dot org 2009-05-21 11:05 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
[Bug libgcj/40180] [4.4/4.5 regression] regressions in libjava testsuite on ia64-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40180
[Bug libgcj/40182] [4.4/4.5 regression] regressions in libjava testsuite on sparc-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40182
[Bug fortran/40197] [4.5 Regression] Spu fortran does not build
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40197
[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required
--- Comment #12 from billingd at gcc dot gnu dot org 2009-05-21 11:31 --- Subject: Bug 36211 Author: billingd Date: Thu May 21 11:30:55 2009 New Revision: 147762 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147762 Log: 2009-05-21 David Billinghurst billi...@gcc.gnu.org Backport from mainline: PR libstdc++/36211 * testsuite/lib/libstdc++.exp(v3_target_compile): Add cxxldflags to additional_flags rather than cxx_final. Modified: branches/gcc-4_4-branch/libstdc++-v3/ChangeLog branches/gcc-4_4-branch/libstdc++-v3/testsuite/lib/libstdc++.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required
--- Comment #13 from billingd at gcc dot gnu dot org 2009-05-21 11:32 --- Fixed in 4.4 and trunk. -- billingd at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required
-- billingd at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
[Bug tree-optimization/40087] [4.3/4.4 Regression] Number of iterations analysis wrong
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-05-21 11:37 --- Let's backport this before 4.4.1 goes out. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
[Bug tree-optimization/38747] [4.4/4.5 Regression] Wrong code due to VIEW_CONVERT_EXPR
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 Summary|[4.4 Regression] Wrong code |[4.4/4.5 Regression] Wrong |due to VIEW_CONVERT_EXPR|code due to ||VIEW_CONVERT_EXPR http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38747
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #1 from dje at gcc dot gnu dot org 2009-05-21 12:40 --- Confirmed -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org GCC target triplet|i586-pc-mingw32 |i586-pc-mingw32,powerpc-ibm- ||aix Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #2 from jakub at gcc dot gnu dot org 2009-05-21 12:53 --- See http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00248.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug tree-optimization/40219] New: iterative_hash_expr in tree.c has an out of bound reference for machine specific builtins
The function iterative_hash_expr uses built_in_decls to a map a builtin function to the __builtin_ form. It uses DECL_FUNCTION_CODE as the index. For machine specific builtins, the DECL_FUNCTION_CODE is defined by the backend, instead of being the builtin number. This means that the builtin_in_decls reference can point to random memory. In the power7 branch, I added quite a few more builtins, and this code causes crashes when it looks at memory beyond the bound of builtin_in_decls. Even if it doesn't overflow the bounds of the array, the builtin hash might pick up the wrong declaration. -- Summary: iterative_hash_expr in tree.c has an out of bound reference for machine specific builtins Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at linux dot vnet dot ibm dot com GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40219
[Bug tree-optimization/40219] iterative_hash_expr in tree.c has an out of bound reference for machine specific builtins
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-05-21 13:14 --- Created an attachment (id=17898) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17898action=view) Patch to avoid de-referencing outside array bounds This patch fixes the particular problem I saw on the power7-branch for the testsuite and building the SPEC2006 gobmk and wrf benchmarks. I will do the usual bootstrap shortly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40219
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #51 from jakub at gcc dot gnu dot org 2009-05-21 13:21 --- Subject: Bug 39942 Author: jakub Date: Thu May 21 13:21:30 2009 New Revision: 147765 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147765 Log: PR target/39942 * config/i386/x86-64.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Don't emit second .p2align 3 if MAX_SKIP is smaller than 7. * config/i386/linux.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/linux.h branches/gcc-4_4-branch/gcc/config/i386/x86-64.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #52 from jakub at gcc dot gnu dot org 2009-05-21 13:26 --- Subject: Bug 39942 Author: jakub Date: Thu May 21 13:26:13 2009 New Revision: 147766 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147766 Log: PR target/39942 * config/i386/x86-64.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Don't emit second .p2align 3 if MAX_SKIP is smaller than 7. * config/i386/linux.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/linux.h branches/gcc-4_3-branch/gcc/config/i386/x86-64.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug pch/40215] Generated GCH fails to honor include guards with -no-integrated-cpp
--- Comment #3 from sacolcor at provide dot net 2009-05-21 13:56 --- Reopening, because if this is by design, the doc page at http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html should elaborate; it does not currently mention anything about incompatibility or other difficulties with -no-integrated-cpp or -save-temps. The supplied code compiles fine if the -no-integrated-cpp flag is removed, and it seems reasonable for a user to expect that those flags would not cause an otherwise working build to break. Are precompiled headers simply incompatible with those flags? If not, then what's needed to make them work? -- sacolcor at provide dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40215
[Bug middle-end/40029] [4.5 Regression] Big degradation on swim/mgrid on powerpc 32/64 after alias improvement merge (gcc r145494)
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-21 14:04 --- That's DO 100 J=1,N DO 100 I=1,M CU(I+1,J) = .5D0*(P(I+1,J)+P(I,J))*U(I+1,J) CV(I,J+1) = .5D0*(P(I,J+1)+P(I,J))*V(I,J+1) Z(I+1,J+1) = (FSDX*(V(I+1,J+1)-V(I,J+1))-FSDY*(U(I+1,J+1) 1 -U(I+1,J)))/(P(I,J)+P(I+1,J)+P(I+1,J+1)+P(I,J+1)) H(I,J) = P(I,J)+.25D0*(U(I+1,J)*U(I+1,J)+U(I,J)*U(I,J) 1 +V(I,J+1)*V(I,J+1)+V(I,J)*V(I,J)) 100 CONTINUE right? 4.4 can do predictive commoning on it while trunk can't - this also unrolls the loop twice. On trunk we are likely confused by PRE that already partially performs what predictive commoning would do. Disabling PRE makes predictive commoning work but doesn't unroll the loop (same as with disabling PRE in 4.4). It is likely the full redundancies PRE discovers that cause the unrolling. That said - this looks like yet another unfortunate pass ordering problem to me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-21 14:04:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40029
[Bug target/39856] [4.4/4.5 Regression] ICE in subst_stack_regs_pat, at reg-stack.c:1386
--- Comment #8 from jakub at gcc dot gnu dot org 2009-05-21 14:07 --- Patch has been posted almost a month ago: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01926.html Vlad, could you please ping it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39856
[Bug middle-end/40029] [4.5 Regression] Big degradation on swim/mgrid on powerpc 32/64 after alias improvement merge (gcc r145494)
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-21 14:10 --- Testcase: SUBROUTINE CALC1 IMPLICIT REAL*8 (A-H, O-Z) PARAMETER (N1=1335, N2=1335) COMMON U(N1,N2), V(N1,N2), P(N1,N2), 2CU(N1,N2), CV(N1,N2), *Z(N1,N2), H(N1,N2) COMMON /CONS/ DX,DY FSDX = 4.D0/DX FSDY = 4.D0/DY DO 100 J=1,N DO 100 I=1,M CU(I+1,J) = .5D0*(P(I+1,J)+P(I,J))*U(I+1,J) CV(I,J+1) = .5D0*(P(I,J+1)+P(I,J))*V(I,J+1) Z(I+1,J+1) = (FSDX*(V(I+1,J+1)-V(I,J+1))-FSDY*(U(I+1,J+1) 1 -U(I+1,J)))/(P(I,J)+P(I+1,J)+P(I+1,J+1)+P(I,J+1)) H(I,J) = P(I,J)+.25D0*(U(I+1,J)*U(I+1,J)+U(I,J)*U(I,J) 1 +V(I,J+1)*V(I,J+1)+V(I,J)*V(I,J)) 100 CONTINUE RETURN END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40029
[Bug target/40220] New: Compile error after r147534
In r147534, Paolo (probably unintendedly) broke the VAX backend with a small change not appearing in the ChangeLog entry. The declaration of some functions were changed (probably for no reason) and the definitions were left as-is. -- Summary: Compile error after r147534 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jbglaw at lug-owl dot de GCC target triplet: vax-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40220
[Bug target/40220] Compile error after r147534
--- Comment #1 from jbglaw at lug-owl dot de 2009-05-21 14:30 --- Created an attachment (id=17899) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17899action=view) This patch fixes the error by reverting the problem-causing change. See http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01043.html and http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01356.html . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40220
[Bug middle-end/40091] [4.5 Regression] FAIL: g++.dg/opt/thunk3.C (test for excess errors)
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-05-21 14:59 --- Subject: Re: [4.5 Regression] FAIL: g++.dg/opt/thunk3.C (test for excess errors) Is this still failing? It is no longer failing on hppa64-hp-hpux11.11. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40091
[Bug middle-end/40122] missed optimization when using union of __m128i and int[4]
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-05-21 16:02 ---
With he new SRA, the optimized dump looks like:
D.6886_10 = {1, 1, 1, 1};
D.6887_11 = VIEW_CONVERT_EXPRvector long long int(D.6886_10);
D.6893_12 = VIEW_CONVERT_EXPRvector int(D.6887_11);
D.6891_14 = __builtin_ia32_pcmpeqd128 (D.6893_12, D.6893_12);
D.6890_15 = VIEW_CONVERT_EXPRvector long long int(D.6891_14);
D.6897_16 = VIEW_CONVERT_EXPRvector char(D.6890_15);
D.6896_17 = __builtin_ia32_pmovmskb128 (D.6897_16);
D.6933_21 = D.6896_17 != 65535;
return D.6933_21;
x is completely gone.
The (relevant) assembly output is
main:
movdqa .LC0, %xmm0
pcmpeqd %xmm0, %xmm0
pmovmskb%xmm0, %eax
cmpl$65535, %eax
pushl %ebp
setne %al
movl%esp, %ebp
movzbl %al, %eax
popl%ebp
ret
So even though I don't really understand the SSE instructions I
believe the new SRA does indeed help. I'll add a testcase checking
that x vanishes to the patch series as I am finalizing the final patch
set now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40122
[Bug libfortran/40212] Failure on building libgfortran
--- Comment #4 from ksong at lbl dot gov 2009-05-21 16:14 --- Thank you very much! I successively compiled. -- ksong at lbl dot gov changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40212
[Bug c/37985] [4.3/4.4/4.5 Regression] unsigned char shift lacks statement with no effect warning
--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-05-21 16:31 ---
Works with 3.4:
$ cat tmp.c
unsigned char foo(unsigned char a)
{
a 2;
return a;
}
$ gcc-3.4 -S -O3 -Wall tmp.c
tmp.c: In function `foo':
tmp.c:3: warning: statement with no effect
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0 4.5.0 4.3.3
Summary|unsigned char shift lacks |[4.3/4.4/4.5 Regression]
|statement with no effect |unsigned char shift lacks
|warning |statement with no effect
||warning
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37985
[Bug c/37985] [4.3/4.4/4.5 Regression] unsigned char shift lacks statement with no effect warning
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.5 |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37985
[Bug pch/40215] Generated GCH fails to honor include guards with -no-integrated-cpp
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-21 16:56 --- How can the PCH contain information that is lost by using an external preprocessor? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40215
[Bug pch/40215] GCH generated with -save-temps does not store preprocessor state.
--- Comment #5 from sacolcor at provide dot net 2009-05-21 18:21 --- (In reply to comment #4) How can the PCH contain information that is lost by using an external preprocessor? When I do -save-temps, it's still using the GNU CPP, not an external one, so it's not clear to me why information would be lost. I'll update the summary line so that it's clear that I'm not using an external preprocessor. When a .h.gch is built in one pass, the integrated preprocessor takes the preprocessor symbol state at the end of the file and passes it through (or around) the compile and assemble phases to be stored in the .h.gch file. It seems like the CPP should do the same thing when invoked as part of the -save-temps chain; embed that same information in the .i* files. Then when the compiler phase sees it, it could pass it through and store that information in the .h.gch. Perhaps I need to understand more about how the PCH system works; I looked for that information in the internal doc, but could not find anything. -- sacolcor at provide dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Summary|Generated GCH fails to honor|GCH generated with -save- |include guards with -no-|temps does not store |integrated-cpp |preprocessor state. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40215
[Bug bootstrap/40221] New: Powerpc bootstrap is broken in building libstdc++
I was testing my patch for 40219, and I rebuilt today's build on the Powerpc, and had the build fail in building libstdc++-v3. I backed out my change, and redid the build, and I get exactly the same failure: /bin/sh ../libtool --tag CXX --mode=compile /home/meissner/fsf-build-ppc64/trunk/./gcc/xgcc -shared-libgcc -B/home/meissner/fsf-build-ppc64/trunk/./gcc -nostdinc++ -L/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src -L/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/bin/ -B/home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/lib/ -isystem /home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/include -isystem /home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/sys-include -m32 -fPIC -mstrict-align -I/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include -I/home/meissner/fsf-src/trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -std=gnu++0x -c /home/meissner/fsf-src/trunk/libstdc++-v3/src/mutex.cc libtool: compile: /home/meissner/fsf-build-ppc64/trunk/./gcc/xgcc -shared-libgcc -B/home/meissner/fsf-build-ppc64/trunk/./gcc -nostdinc++ -L/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src -L/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/bin/ -B/home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/lib/ -isystem /home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/include -isystem /home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/sys-include -m32 -fPIC -mstrict-align -I/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include -I/home/meissner/fsf-src/trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -std=gnu++0x -c /home/meissner/fsf-src/trunk/libstdc++-v3/src/mutex.cc -fPIC -DPIC -o .libs/mutex.o In file included from /home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/functional:70, from /home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/mutex:44, from /home/meissner/fsf-src/trunk/libstdc++-v3/src/mutex.cc:25: /home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/tr1_impl/functional: In copy constructor std::function_Res(_ArgTypes ...)::function(const std::function_Res(_ArgTypes ...)) [with _Res = void, _ArgTypes = ]: /home/meissner/fsf-src/trunk/libstdc++-v3/src/mutex.cc:51: instantiated from here /home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/tr1_impl/functional:1992: error: could not convert __x to bool make: *** [mutex.lo] Error 1 Given where it occurs, I suspect it is due to this change: 2009-05-20 Benjamin Kosnik b...@redhat.com * include/tr1_impl/functional (function): Use explicit operator bool. -- Summary: Powerpc bootstrap is broken in building libstdc++ Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at linux dot vnet dot ibm dot com GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40221
[Bug fortran/40195] ICE when compiling a file located in another directory
--- Comment #2 from francois dot jacq at irsn dot fr 2009-05-21 18:27 --- (In reply to comment #1) It works for me. This sounds like the issue you'd have if you didn't have write permission to the current directory. I have all the permissions to that directory. The same command with g95 or gfortran-4.3.3 works perfectly. Anyway, the compiler itself issued an ICE message ... and this is not normal ! I also got a similar trouble (Can't delete the module file m.mod) with the binary package provided by www.equation.com (gcc-4.5 20090514), but without the ICE message ! What are the permissions and ownership of the bin and source directories? What user is trying to compile? I have all the privileges. I created myself the directory tree d:\test\bin and d:\test\source\t2.f90 because I met this trouble when installing a much more complicated software. So I decided to create a simple test cases to try and reproduce the problem. However, your remark lead me to the right explanation : the problem is not due to a change of directory as I suggested initially, but simply to the fact that a file m.mod, created by another compiler, was already located in the bin directory ! For instance, in the directory d:\source : d:\test\sourcegfortran -c t2.f90 d:\test\sourceg95 -c t2.f90 d:\test\sourcegfortran -c t2.f90 Fatal Error: Can't delete module file 'm.mod': Permission denied d:\test\source del m.mod d:\test\sourcegfortran -c t2.f90 As you see, the first and third gfortran commands work well but not the second one because of the presence of the g95 module. Notice that this second instruction did not issue the ICE message because I was testing again the equations package gcc-4.5-200090514. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40195
[Bug middle-end/40091] [4.5 Regression] FAIL: g++.dg/opt/thunk3.C (test for excess errors)
--- Comment #4 from ubizjak at gmail dot com 2009-05-21 18:30 --- Also fixed for x86, see [1]. [1] http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg01802.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40091
Re: 64 bit linux build problem for gcc 4.4.0
There's nothing like deterministic software. I started over again in a completely new build directory and the regular ../gcc-4.4.0/configure --prefix=/usr/gcc4 make is through the 3 stage bootstrap and is now compiling fortran and java. But I *know* I tried this out of the box before and it didn't work. I didn't start over again with fresh extraction of the tar balls, but that shouldn't make any difference, right? Once this build finishes I will try a fresh extraction and will report back to the mailing list. Jerry, thanks for the offer to look at logs - I'll hold off on that until I can reproduce a problem. Thanks, Arnold Date: Wed, 20 May 2009 17:44:55 -0700 From: Jerry DeLisle jvdeli...@verizon.net To: Aharon Robbins arn...@skeeve.com Subject: Re: 64 bit linux build problem for gcc 4.4.0 Aharon Robbins wrote: Jerry, Thanks for the reply. Do you have the stuff necessary for doing 32-bit builds installed also? I do, and it feels like that might be the issue. I can send you logs if you really want to see the gory details. Thanks, Arnold Date: Tue, 19 May 2009 17:05:29 -0700 From: Jerry DeLisle jvdeli...@verizon.net To: Aharon Robbins arn...@skeeve.com Cc: bug-...@gnu.org Subject: Re: 64 bit linux build problem for gcc 4.4.0 Aharon Robbins wrote: Hi. After several tries and a modicum of googling, I found that CFLAGS=-m64 ../gcc-4.4.0/configure --disable-multilib was the magic incantation to get gcc to get into the second stage of the boostrap. This is on a Fedora Core 10 system. This seems to be an old issue; google turns things up dating back to 2003. I suspect that x86_64 systems are only going to be more popular with time; the build process on those systems needs to be as easy as for 32 bit systems. Thanks, Arnold Robbins (the gawk guy :-) Aharon, I have been building gcc for several years now with no issues on x86-64 and on Fedora Core 10 ever since it was released. What exactly has been your problem? Its been as easy as 123. I have never had to set CCFLAGS or disable-multilib. Jerry You are welcome to send logs. Or least the portion where you see errors. Jerry
[Bug libfortran/40212] Failure on building libgfortran
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2009-05-21 20:32 --- *** This bug has been marked as a duplicate of 35619 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40212
[Bug bootstrap/35619] [4.3/4.4/4.5 Regression] fixed includes not being found if building in src dir
--- Comment #27 from fxcoudert at gcc dot gnu dot org 2009-05-21 20:32 --- *** Bug 40212 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35619
[Bug fortran/40195] ICE when compiling a file located in another directory
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-21 20:52
---
Thanks for your comments! With such a clear description, it was now easy to
find the issue: if a module file m.mod already exist, we look into it to check
if it's ours; if not, we delete it and write ours. The problem is that the code
doing that actually unlinks the file before closing it, which is not allowed on
Windows. The patch below fixes it (built and tested on i386-pc-mingw32):
Index: module.c
===
--- module.c(revision 147744)
+++ module.c(working copy)
@@ -4759,7 +4759,7 @@ read_md5_from_module_file (const char *
if ((file = fopen (filename, r)) == NULL)
return -1;
- /* Read two lines. */
+ /* Read the first line. */
if (fgets (buf, sizeof (buf) - 1, file) == NULL)
{
fclose (file);
@@ -4769,8 +4769,12 @@ read_md5_from_module_file (const char *
/* The file also needs to be overwritten if the version number changed. */
n = strlen (GFORTRAN module version ' MOD_VERSION ' created);
if (strncmp (buf, GFORTRAN module version ' MOD_VERSION ' created, n) !=
0)
-return -1;
+{
+ fclose (file);
+ return -1;
+}
+ /* Read a second line. */
if (fgets (buf, sizeof (buf) - 1, file) == NULL)
{
fclose (file);
(PS: the fields host, target and build in GCC bugzilla refer to three
target triplets: host is the architecture the compiler runs on, target is
the one it generates code for, and build is the architecture that was used to
compile the compiler itself. In your case, you have host = target = build =
i386-pc-mingw32.)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
GCC build triplet|20090421 (experimental) |
|[trunk revision 146519] |
GCC host triplet|Window XP i386 MinGW|
GCC target triplet|GNU Fortran (GCC) 4.5.0 |i386-pc-mingw32
Keywords||patch
Last reconfirmed|-00-00 00:00:00 |2009-05-21 20:52:47
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40195
[Bug fortran/40196] F2003: Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-21 20:53:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40196
[Bug c/40216] Optimization error when compiling bfd/ecofflink.c on x86_64
--- Comment #3 from dahowell at directv dot com 2009-05-21 21:17 --- (In reply to comment #2) So this is a false negative for -Wstrict-aliasing=3. It is flagged by -Wstrict-aliasing=2, however. Is -Wstrict-aliasing=3 not catching it because the pointer is not being dereferenced, except in the called function? Perhaps passing a pointer to a function should be treated as a dereference for the purpose of generating a warning? This seems like something that could cause a lot of legacy code to fail in unexpected ways as the optimizer gets better. Should I submit a separate bug for this code failing to generate a warning with -Wall? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40216
[Bug rtl-optimization/40105] [4.3/4.4 Regression] SH: 4.3/4.4 compilers segfault when recompiling itself on gentoo system
--- Comment #8 from kkojima at gcc dot gnu dot org 2009-05-21 23:17 --- Subject: Bug 40105 Author: kkojima Date: Thu May 21 23:17:37 2009 New Revision: 147780 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147780 Log: PR rtl-optimization/40105 Backport from mainline: 2009-04-29 Eric Botcazou ebotca...@adacore.com Steven Bosscher ste...@gcc.gnu.org * Makefile.in (cfgrtl.o): Add $(INSN_ATTR_H). * cfgrtl.c: Include insn-attr.h. (rest_of_pass_free_cfg): New function. (pass_free_cfg): Use rest_of_pass_free_cfg as execute function. 2009-04-27 Richard Sandiford rdsandif...@googlemail.com Eric Botcazou ebotca...@adacore.com * resource.c (find_basic_block): Use BLOCK_FOR_INSN to look up a label's basic block. (mark_target_live_regs): Tidy and rework obsolete comments. Change back DF problem to LIVE. If a label starts a basic block, assume that all registers that used to be live then still are. (init_resource_info): If a label starts a basic block, set its BLOCK_FOR_INSN accordingly. (free_resource_info): Undo the setting of BLOCK_FOR_INSN. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/Makefile.in branches/gcc-4_4-branch/gcc/cfgrtl.c branches/gcc-4_4-branch/gcc/resource.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40105
[Bug rtl-optimization/40105] [4.3/4.4 Regression] SH: 4.3/4.4 compilers segfault when recompiling itself on gentoo system
--- Comment #9 from kkojima at gcc dot gnu dot org 2009-05-21 23:31 --- Subject: Bug 40105 Author: kkojima Date: Thu May 21 23:31:44 2009 New Revision: 147781 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147781 Log: PR rtl-optimization/40105 Backport from mainline: 2009-04-29 Eric Botcazou ebotca...@adacore.com Steven Bosscher ste...@gcc.gnu.org * Makefile.in (cfgrtl.o): Add $(INSN_ATTR_H). * cfgrtl.c: Include insn-attr.h. (rest_of_pass_free_cfg): New function. (pass_free_cfg): Use rest_of_pass_free_cfg as execute function. 2009-04-27 Richard Sandiford rdsandif...@googlemail.com Eric Botcazou ebotca...@adacore.com * resource.c (find_basic_block): Use BLOCK_FOR_INSN to look up a label's basic block. (mark_target_live_regs): Tidy and rework obsolete comments. Change back DF problem to LIVE. If a label starts a basic block, assume that all registers that used to be live then still are. (init_resource_info): If a label starts a basic block, set its BLOCK_FOR_INSN accordingly. (free_resource_info): Undo the setting of BLOCK_FOR_INSN. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/Makefile.in branches/gcc-4_3-branch/gcc/cfgrtl.c branches/gcc-4_3-branch/gcc/resource.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40105
[Bug rtl-optimization/40105] [4.3/4.4 Regression] SH: 4.3/4.4 compilers segfault when recompiling itself on gentoo system
--- Comment #10 from kkojima at gcc dot gnu dot org 2009-05-21 23:36 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40105
[Bug target/37846] Option -mno-fused-madd should be supported on IA-64
--- Comment #2 from sje at gcc dot gnu dot org 2009-05-21 23:51 --- Subject: Bug 37846 Author: sje Date: Thu May 21 23:51:22 2009 New Revision: 147782 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147782 Log: PR target/37846 * config/ia64/ia64.opt (mfused-madd): New. * config/ia64/ia64.h (TARGET_DEFAULT): Set MASK_FUSED_MADD. * config/ia64/hpux.h (TARGET_DEFAULT): Ditto. * config/ia64/ia64.md (maddsf4, msubsf4, nmaddsf4, madddf4, madddf4_trunc, msubdf4, msubdf4_trunc, nmadddf4, nmadddf4_truncsf, maddxf4, maddxf4_truncsf, maddxf4_truncdf, msubxf4, msubxf4_truncsf msubxf4_truncdf, nmaddxf4, nmaddxf4_truncsf, nmaddxf4_truncdf): Check TARGET_FUSED_MADD. * config/ia64/vect.md (addv2sf3, subv2sf3): Force fpma/fpms instruction if !TARGET_FUSED_MADD. (fpma, fpms): Remove colon from name. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/hpux.h trunk/gcc/config/ia64/ia64.h trunk/gcc/config/ia64/ia64.md trunk/gcc/config/ia64/ia64.opt trunk/gcc/config/ia64/vect.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37846
[Bug target/37846] Option -mno-fused-madd should be supported on IA-64
--- Comment #3 from sje at gcc dot gnu dot org 2009-05-21 23:53 --- Subject: Bug 37846 Author: sje Date: Thu May 21 23:53:02 2009 New Revision: 147783 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147783 Log: PR target/37846 * gcc.target/ia64/mfused-madd-vect.c: New test. * gcc.target/ia64/mfused-madd.c: New test. * gcc.target/ia64/mno-fused-madd-vect.c: New test. * gcc.target/ia64/mno-fused-madd.c: New test. Added: trunk/gcc/testsuite/gcc.target/ia64/mfused-madd-vect.c trunk/gcc/testsuite/gcc.target/ia64/mfused-madd.c trunk/gcc/testsuite/gcc.target/ia64/mno-fused-madd-vect.c trunk/gcc/testsuite/gcc.target/ia64/mno-fused-madd.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37846
[Bug target/37846] Option -mno-fused-madd should be supported on IA-64
--- Comment #4 from sje at cup dot hp dot com 2009-05-21 23:54 --- Resolved by implementing the option. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37846
[Bug tree-optimization/40222] New: anon namespace function emitted when all uses inlined
Seen on powerpc64-linux and i686-linux, probably all targets with sufficiently recent glibc. libstdc++-v3/libsupc++/eh_globals.cc get_global is defined inside anonymous namespace thus is local to the file. All uses of get_global are inlined, but get_global is still emitted. -- Summary: anon namespace function emitted when all uses inlined Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amodra at bigpond dot net dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40222
[Bug tree-optimization/40222] anon namespace function emitted when all uses inlined
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-22 00:31 ---
The problem is the same as described in PR 36959:
get_global looks like:
namespace
{
abi::__cxa_eh_globals*
get_global() throw()
{
static __thread abi::__cxa_eh_globals global;
return global;
}
} // anonymous namespace
So we have a static variable inside the function which causes the C++ front-end
to say the function is used.
*** This bug has been marked as a duplicate of 36959 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40222
[Bug c++/36959] [4.3/4.4/4.5 Regression] C++ front-end causing a static inline function to be emitted
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-05-22 00:31 --- *** Bug 40222 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||amodra at bigpond dot net ||dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36959
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #6 from danglin at gcc dot gnu dot org 2009-05-22 00:54 ---
The backtrace from the second delete is:
(gdb) bt
#0 operator delete (p=0x8001e530) at deallocate_global.cc:51
#1 0x4000de94 in
__gnu_cxx::new_allocatorstd::_Rb_tree_nodestd::pairvoid* const,
std::pairunsigned long, unsigned long ::deallocate (
this=0x80012938, __p=0x8001e530)
at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ext/new_allocator.h:95
#2 0x4000d904 in std::_Rb_treevoid*, std::pairvoid* const,
std::pairunsigned long, unsigned long , std::_Select1ststd::pairvoid*
const, std::pairunsigned long, unsigned long , std::lessvoid*,
std::allocatorstd::pairvoid* const, std::pairunsigned long, unsigned long
::_M_put_node (
this=0x80012938, __p=0x8001e530)
at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:363
#3 0x4000cf38 in std::_Rb_treevoid*, std::pairvoid* const,
std::pairunsigned long, unsigned long , std::_Select1ststd::pairvoid*
const, std::pairunsigned long, unsigned long , std::lessvoid*,
std::allocatorstd::pairvoid* const, std::pairunsigned long, unsigned long
::_M_destroy_node
(this=0x80012938, __p=0x8001e530)
at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:384
#4 0x4000c124 in std::_Rb_treevoid*, std::pairvoid* const,
std::pairunsigned long, unsigned long , std::_Select1ststd::pairvoid*
const, std::pairunsigned long, unsigned long , std::lessvoid*,
std::allocatorstd::pairvoid* const, std::pairunsigned long, unsigned long
::_M_erase (
this=0x80012938, __x=0x8001e530)
at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:968
#5 0x4000d488 in std::_Rb_treevoid*, std::pairvoid* const,
std::pairunsigned long, unsigned long , std::_Select1ststd::pairvoid*
const, std::pairunsigned long, unsigned long , std::lessvoid*,
std::allocatorstd::pairvoid* const, std::pairunsigned long, unsigned long
::clear (
this=0x80012938)
at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:722
#6 0x4000cd28 in std::_Rb_treevoid*, std::pairvoid* const,
std::pairunsigned long, unsigned long , std::_Select1ststd::pairvoid*
const, std::pairunsigned long, unsigned long , std::lessvoid*,
std::allocatorstd::pairvoid* const, std::pairunsigned long, unsigned long
::erase (
this=0x80012938, __first={_M_node = 0x8001e530}, __last=
{_M_node = 0x80012940})
at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:1377
#7 0x4000bef4 in std::_Rb_treevoid*, std::pairvoid* const,
std::pairunsigned long, unsigned long , std::_Select1ststd::pairvoid*
const, std::pairunsigned long, unsigned long , std::lessvoid*,
std::allocatorstd::pairvoid* const, std::pairunsigned long, unsigned long
::erase (
this=0x80012938, _...@0x83fffdff0fe0)
at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:1366
#8 0x4000b210 in std::mapvoid*, std::pairunsigned long, unsigned
long, std::lessvoid*, std::allocatorstd::pairvoid* const,
std::pairunsigned long, unsigned long ::erase (this=0x80012938,
_...@0x8001e530)
at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_map.h:582
#9 0x40009ea4 in __gnu_cxx::throw_allocator_base::erase (
p=0x8001e4f8, size=35)
at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ext/throw_allocator.h:180
#10 0x4000e8cc in __gnu_cxx::throw_allocatorchar::deallocate (
this=0x83fffdff0f20, __p=0x8001e4f8 , __n=35)
at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ext/throw_allocator.h:334
#11 0x4000e35c in std::basic_stringchar, std::char_traitschar,
__gnu_cxx::throw_allocatorchar ::_Rep::_M_destroy (this=0x8001e4f8,
_...@0x83fffdff0de8)
at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.tcc:426
#12 0x4000efe0 in std::basic_stringchar, std::char_traitschar,
__gnu_cxx::throw_allocatorchar ::_Rep::_M_dispose (this=0x8001e4f8,
_...@0x83fffdff0de8)
at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:231
#13 0x4000ed6c in ~basic_string (this=0x80011580)
at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:498
#14 0x4000eca0 in __static_initialization_and_destruction_0 (
__initialize_p=0, __priority=65535) at deallocate_global.cc:68
#15 0x4000f0a8 in global destructors keyed to _Znwm ()
at deallocate_global.cc:73
#16 0x40008bc4 in __do_global_dtors_aux ()
#17 0xc0032aa0 in TE_do_list#HLO_CL_#i1_0x0 ()
from /usr/lib/pa20_64/dld.sl
#18 0xc000d198 in TE_do_program_exit
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #7 from paolo dot carlini at oracle dot com 2009-05-22 01:07 --- Any idea why this crazy thing is happening only on hpux? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #8 from paolo dot carlini at oracle dot com 2009-05-22 01:15 --- In any case, what you posted in the last comment looks to me very similar to the *first* delete on linux, not the *second*. Maybe better if you post all three deletes, one after the other. Note: without my patch throw_allocator is ***badly*** broken, but I cannot debug something like this happening only on a target which I don't have: thus, either you manage to ***really*** help here, or I have to revert my fixes to throw_allocator and nobody is going to gain anything from that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #9 from paolo at gcc dot gnu dot org 2009-05-22 01:29 --- Subject: Bug 40094 Author: paolo Date: Fri May 22 01:28:50 2009 New Revision: 147788 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147788 Log: 2009-05-21 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/40094 Revert: 2009-05-07 Paolo Carlini paolo.carl...@oracle.com * include/ext/throw_allocator.h (throw_allocator_base): Avoid out of line member functions definitions. (throw_allocator_base::_S_g, _S_map, _S_throw_prob, _S_label): Remove, use static locals instead. (throw_allocator_base::do_check_allocated, print_to_string): Declare. * src/throw_allocator.cc: New. * src/Makefile.am: Add. * config/abi/pre/gnu.ver: Add exports. * src/Makefile.in: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/configure trunk/libstdc++-v3/include/ext/throw_allocator.h trunk/libstdc++-v3/src/Makefile.am trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/src/throw_allocator.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
