[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
--- Comment #15 from jakub at gcc dot gnu dot org 2008-06-09 06:59 --- Unless you can find a way to localize those environment changes only to the tested compiler (by setting/restoring them around every call to the compiler being tested for example), HOSTCC must set/clear all the environment variables that it uses. Unfortunately, $HOSTCC is invoked from tcl, not from shell, so e.g. sticking unset GCC_EXEC_PREFIX; into $HOSTCC doesn't work. The patch I've posted a few days ago temporarily removes it from the environment for $HOSTCC invocations in struct-layout-1.exp. Other than that, ALT_*_UNDER_TEST might contain a host compiler, so similar unsetting/setting would be needed in c-compat.exp too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug bootstrap/33781] [4.3/4.4 Regression] Arg list too long building libgcc.a
--- Comment #18 from Ralf dot Wildenhues at gmx dot de 2008-06-09 08:33 --- AFAICS this bug has a workaround patch applied, and may be worked around by modifying IRIX default settings. Are you still interested in a proper fix that avoids manual chunking? It looks like the write_entries_to_file tricks in libjava/Makefile.am can be applied in this case as well. Should I look into it? -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/36472] Small config.gcc buglet to check for enable_cld
--- Comment #1 from Keller at hlrs dot de 2008-06-09 09:00 --- Created an attachment (id=15739) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15739action=view) Patch for gcc/config.gcc The check for enable_cld in gcc/config.gcc is not correct, when $enable_cld evaluates to empty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36472
[Bug fortran/36463] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7264 with rev.136554
--- Comment #2 from dominiq at lps dot ens dot fr 2008-06-09 09:07 --- reduced test case: module other_fun use ISO_C_BINDING implicit none private ! Message to be returned by procedure pointed to ! by the C_FUNPTR character, allocatable, save :: my_message(:) ! Interface block for the procedure pointed to ! by the C_FUNPTR public abstract_fun abstract interface function abstract_fun(x) use ISO_C_BINDING import my_message implicit none integer(C_INT) x(:) character(size(my_message),C_CHAR) abstract_fun(size(x)) end function abstract_fun end interface contains ! Procedure to store the message and get the C_FUNPTR function gp(message) bind(C,name='BlAh') ! procedure(abstract_fun) make_mess character(kind=C_CHAR) message(*) type(C_FUNPTR) gp integer(C_INT64_T) i i = 1 do while(message(i) /= C_NULL_CHAR) i = i+1 end do my_message = message(int(1,kind(i)):i-1) gp = get_funloc(make_mess,aux) ! gp = aux(make_mess) end function gp ! Intermediate procedure to pass the function and get ! back the C_FUNPTR function get_funloc(x,y) procedure(abstract_fun) x type(C_FUNPTR) y external y type(C_FUNPTR) get_funloc get_funloc = y(x) end function get_funloc ! Procedure to convert the function to C_FUNPTR function aux(x) interface subroutine x() bind(C) end subroutine x end interface type(C_FUNPTR) aux aux = C_FUNLOC(x) end function aux ! Procedure pointed to by the C_FUNPTR function make_mess(x) integer(C_INT) x(:) character(size(my_message),C_CHAR) make_mess(size(x)) make_mess = transfer(my_message,make_mess(1)) end function make_mess end module other_fun -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug fortran/36463] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7264 with rev.136554
--- Comment #3 from dominiq at lps dot ens dot fr 2008-06-09 09:09 --- Withe following patch the ICE is changed to pr35971_red.f90:33.25: gp = get_funloc(make_mess,aux) 1 Error: Type/rank mismatch in argument 'x' at (1) --- /opt/gcc/_gcc_clean/gcc/fortran/resolve.c 2008-06-08 11:16:33.0 +0200 +++ /opt/gcc/gcc-4.4-work/gcc/fortran/resolve.c 2008-06-09 10:57:13.0 +0200 @@ -7912,7 +7912,7 @@ sym-attr.dimension = ifc-attr.dimension; sym-attr.recursive = ifc-attr.recursive; sym-attr.always_explicit = ifc-attr.always_explicit; - sym-as = gfc_copy_array_spec (ifc-as); + /* sym-as = gfc_copy_array_spec (ifc-as); */ copy_formal_args (sym, ifc); } else if (sym-ts.interface-name[0] != '\0') -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug bootstrap/36472] New: Small config.gcc buglet to check for enable_cld
-- Summary: Small config.gcc buglet to check for enable_cld Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Keller at hlrs dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36472
[Bug target/36473] New: Generate bit test (bt) instructions
According to Intel Technology Journal [1], page 270, bt instruction runs 20% faster on Core2 Duo than equivalent generic code. ---Qoute from p.270--- The bit test instruction bt was introduced in the i386 processor. In some implementations, including the Intel NetBurst® micro-architecture, the instruction has a high latency. The Intel Core micro-architecture executes bt in a single cycle, when the bit base operand is a register. Therefore, the Intel C++/Fortran compiler uses the bt instruction to implement a common bit test idiom when optimizing for the Intel Core micro-architecture. The optimized code runs about 20% faster than the generic version on an Intel Core 2 Duo processor. Both of these versions are shown below: C source code int x, n; ... if (x (1 n)) ... Generic code generation ; edx contains x, ecx contains n. mov eax, 1 shl eax, cl test edx, eax je taken Intel Core micro-architecture code generation ; edx contains x, eax contains n. bt edx, eax jae taken ---/Quote--- I have a patch in testing that implements suggested optimization for TARGET_USE_BT (including core2) targets. [1] Inside the Intel® 10.1 Compilers: New Threadizer and New Vectorizer for Intel® Core2 Processors, Intel Technology Journal, Vol. 11, Issue 4, November 15, 2007, http://download.intel.com/technology/itj/2007/v11i4/1-inside/1-Inside_the_Intel_Compilers.pdf -- Summary: Generate bit test (bt) instructions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC target triplet: x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36473
[Bug c++/36474] New: gcc takes forever to compile a certain file
Compiling VirtualBox with gcc version 4.3.1 the C++ compiler takes forever running at 100% when compiling the file VBoxManage.c. It compiles fine with -O0 but takes forever with -O1. I will attach the pre-processed file. This is a regression since some weeks, sorry, I cannot report the exact version of gcc 4.3 when it started to fail. Older gcc compilers work. $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.1 (Debian 4.3.1-1) -- Summary: gcc takes forever to compile a certain file Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fm3 at os dot inf dot tu-dresden dot de GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36474
[Bug c++/36474] gcc takes forever to compile a certain file
--- Comment #1 from fm3 at os dot inf dot tu-dresden dot de 2008-06-09 10:15 --- Created an attachment (id=15740) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15740action=view) VBoxManage.cpp (preprocessed with -E -dD and compressed) from current VirtualBox SVN. If you compile this file with g++ -c -o foo.o -O0 -fshort-wchar VBoxManage.cpp it will be compiled successfully. It you compile it with g++ -c -o foo.o -O1 -fshort-wchar VBoxManage.cpp (gcc 4.3.1) the g++ compiler will loop forever (aborted after 5 minutes). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36474
[Bug bootstrap/32272] make exit because build/genmodes.exe doesn't exist
--- Comment #8 from Ralf dot Wildenhues at gmx dot de 2008-06-09 11:02 --- (In reply to comment #7) I am currently using GCC4.2.1 and the same problem still exist as described. [...] build/genmodes -h tmp-modes.h /bin/sh: build/genmodes: No such file or directory make[3]: *** [s-modes-h] Error 127 [...] Please advise on how to solve the above problem. Or is it a known bug? Have you ever started configure and make within the source tree? As as consequence of that, if the directory $top_srcdir/host-$host_noncanonical exists, then that would lead to the above error when later building outside of the source tree (replace the variables $top_srcdir and $host_noncanonical with whatever fits your setup, e.g., ../gcc-4.2.1/host-i686-pc-linux-gnu). A solution would be to remove that directory, then remove the build tree and start afresh. -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32272
[Bug target/36473] Generate bit test (bt) instructions
--- Comment #1 from ubizjak at gmail dot com 2008-06-09 11:39 ---
Created an attachment (id=15741)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15741action=view)
Proposed patch
Following code:
--cut here--
void foo (void);
int test (int x, int n)
{
if (x (1 n))
foo ();
return 0;
}
--cut here--
compiles using -O2 to:
test:
subl$12, %esp
movl16(%esp), %eax
movl20(%esp), %ecx
sarl%cl, %eax
testb $1, %al
je .L2
callfoo
.L2:
xorl%eax, %eax
addl$12, %esp
ret
With attached patch, following code is produced:
test:
subl$12, %esp
movl20(%esp), %edx
movl16(%esp), %eax
btl %edx, %eax
jnc .L2
callfoo
.L2:
xorl%eax, %eax
addl$12, %esp
ret
Attached patch doesn't have TARGET_USE_BT insn predicates, and it generates bt
instructions by default. It was used to bootstrap gcc on i686-pc-linux-gnu,
where it converts 1800 shift-and-test sequences into eqivalent bt instruction.
The patch as is was bootstrapped and regression tested on x86_64-pc-linux-gnu
as well as i686-pc-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36473
[Bug target/36473] Generate bit test (bt) instructions
--- Comment #2 from ubizjak at gmail dot com 2008-06-09 11:41 --- Mine, the patch needs testcases. 2008-06-09 Uros Bizjak [EMAIL PROTECTED] * config/i386/predicates.md (bt_comparison_operator): New predicate. * config/i386/i386.md (*btdi_rex64): New instruction pattern. (*btsi): Ditto. (*jcc_btdi_rex64): New instruction and split pattern. (*jcc_btsi): Ditto. (*jcc_btsi_1): Ditto. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-09 11:41:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36473
[Bug c/36455] gcc 3.4.6 evaluates wrong size for dynamic size arrays (hence binaries compiled with it can yield wrong results or even segfault)
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-09 12:03 --- Fixed. Please re-open if you happen to reproduce this with a still maintained version. -- 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=36455
[Bug c++/36474] gcc takes forever to compile a certain file
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-09 12:22 --- Seems to be stuck processing int handleModifyVM(int, char**, ComPtrIVirtualBox, ComStrongRef, ComPtrISession, ComStrongRef) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||compile-time-hog, memory-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36474
[Bug c++/36474] GCC takes forever to compile a certain file
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-09 12:58 --- Confirmed. -fno-inline fixes it, but not -fno-tree-fre or -fno-tree-dominator-opts. --param max-fields-for-field-sensitive=0 fixes it (disabling SFTs and field-sensitive PTA) as well. -- 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 |2008-06-09 12:58:01 date|| Summary|gcc takes forever to compile|GCC takes forever to compile |a certain file |a certain file http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36474
[Bug c++/36474] GCC takes forever to compile a certain file
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-09 13:01 --- Created an attachment (id=15742) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15742action=view) unincluded testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36474
[Bug c++/36474] GCC takes forever to compile a certain file
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-06-09 13:02 --- We can fix -O1 for 4.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-06-09 12:58:01 |2008-06-09 13:02:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36474
[Bug tree-optimization/36474] [4.3 Regression] GCC takes forever to compile a certain file
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |tree-optimization GCC build triplet|i386-pc-linux-gnu | GCC host triplet|i386-pc-linux-gnu | GCC target triplet|i386-pc-linux-gnu |i?86-*-* Known to fail||4.3.1 Known to work||4.2.4 4.4.0 Summary|GCC takes forever to compile|[4.3 Regression] GCC takes |a certain file |forever to compile a certain ||file Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36474
[Bug c/36470] sizeof UTF-32 is 2 on AVR
--- Comment #1 from kris dot van dot hees at oracle dot com 2008-06-09 13:25 --- It sound like AVR will need a different specification for CHAR32_TYPE given that the default in c-common.c (unsigned int) won't work. Which would go in the appropriate file in gcc/config/avr, similar to how WCHAR_TYPE is defined. That still won't solve the hardcoded specification of the typedef in the test, but that is going to be addressed Real Soon Now in an upcoming patch to provide a macro (by the compiler) for the underlying types that are used for char16_t and char32_t, which will then be used in the tests to get rid of the hardcoded underlying type in the typedefs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36470
[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze
--- Comment #6 from jakub at gcc dot gnu dot org 2008-06-09 13:33 --- --param df-double-queue-threshold-factor=0 helps, at -O1 with it the testcase compiled under 45seconds (with standard trunk checking). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug c++/33255] A warning for unused typedefs?
--- Comment #12 from paolo dot carlini at oracle dot com 2008-06-09 13:36 --- Hi Gaby, just a pointer, this is the enhancement PR I was talking about... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
[Bug libgomp/36475] New: [gomp] register keyword in openmp handled for-loop fails
Hi,
Using the register keyword in a for loop which is handled by OpenMP fails to
compile.
Testcase below
g++ -v
Using built-in specs.
Target: x86_64-manbo-linux-gnu
Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib
--with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info
--enable-checking=release
--enable-languages=c,c++,ada,fortran,objc,obj-c++,java
--host=x86_64-manbo-linux-gnu --with-cpu=generic --with-system-zlib
--enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo
--disable-libjava-multilib --enable-ssp --disable-libssp
Thread model: posix
gcc version 4.2.3 (4.2.3-6mnb1)
= test code =
#include omp.h
int main() {
#pragma omp parallel for
for (register int i = 0; i 2; ++i) {
}
return 0;
}
== compilation output
g++ -fopenmp register.c
register.c: In function int main():
register.c:5: error: expected primary-expression before register
register.c:5: error: expected `;' before register
register.c:5: error: expected primary-expression before register
register.c:5: error: expected `;' before register
register.c:5: error: expected primary-expression before register
register.c:5: error: expected `)' before register
register.c:5: error: expected iteration declaration or initialization
register.c:5: error: i was not declared in this scope
register.c:5: error: expected `;' before ) token
--
Summary: [gomp] register keyword in openmp handled for-loop fails
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Klaas dot Vantournhout at UGent dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36475
[Bug fortran/36476] New: Fortran CHARACTER array triggers ICE
The following code triggers an ICE even with gfortran 4.3.1: = bash$ gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.3.1/configure --with-pkgversion='DLR MF/AP UPAS 2008-06-09' [EMAIL PROTECTED] --prefix=/local/upas/inst-devel --enable-languages=c,c++,fortran --with-gmp-include=/local/upas/compile/gmp-4.2.2 --with-gmp-lib=/local/upas/compile/gmp-4.2.2/.libs --with-mpfr-include=/local/upas/compile/mpfr-2.3.1 --with-mpfr-lib=/local/upas/compile/mpfr-2.3.1/.libs Thread model: posix gcc version 4.3.1 (DLR MF/AP UPAS 2008-06-09) bash$ cat funny.F SUBROUTINE FUNNY_STRINGS character*256 STRING CHARACTER (len=*) MY_STRING(1:3) PARAMETER ( MY_STRING = (/ A , B, C /) ) STRING = MY_STRING(1) RETURN END bash$ gfortran -c funny.F funny.F: In function funny_strings: funny.F:1: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1031 = I suspect this is valid code, but at the end this is not the point as an ICE should not happen here. Maybe it's related to bug id 36322, as an array is also used there, but the line number in gfc_get_symbol_decl is different, so I suspect not. This ICE is also triggered with gfortran 4.3.0 and 4.1.2. -- Summary: Fortran CHARACTER array triggers ICE Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: walter dot zimmer at dlr dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36476
[Bug c++/33255] A warning for unused typedefs?
--- Comment #13 from gdr at cs dot tamu dot edu 2008-06-09 14:06 --- Subject: Re: A warning for unused typedefs? paolo dot carlini at oracle dot com [EMAIL PROTECTED] writes: | Hi Gaby, just a pointer, this is the enhancement PR I was talking about... Many thanks, Paolo. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
--- Comment #16 from hjl dot tools at gmail dot com 2008-06-09 14:16
---
(In reply to comment #9)
I suspect that if you remove the setting in site.exp you will break the
following scenario:
1. User puts libraries/headers in $pefix/{lib,include}
I am not convinced it is the right thing to do. What
are those libraries/headers? Are they from gcc? If yes,
you don't need to do it. If not, can you use --sysroot
to handle non-gcc libraries/headers?
2. User builds GCC with corresponding --prefix option
3. User runs make check
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug c/36468] [LTO] ICE in force_decl_die, at dwarf2out.c:13976
--- Comment #2 from aldot at gcc dot gnu dot org 2008-06-09 16:09 ---
Smaller testcase:
extern int dummy(long int *);
void build_range_exp(void)
{
long int cmp_buf[6] = { L'\0', L'\0', L'\0', L'\0', L'\0', L'\0' };
if (dummy(cmp_buf)) {
;
}
}
using a smaller cmp_buf (e.g. 5) makes it compile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36468
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #17 from bugzilla-gcc at thewrittenword dot com 2008-06-09 16:23 --- This bug is fixed in opensolaris: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6685125 Fixed in revision 6388: http://cvs.opensolaris.org/source/search?q=defs=refs=path=hist=6388project=%2Fonnv We have filed case #65952072 with Sun to get this backported to Solaris 10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug c++/36478] New: [4.3/4.4 regression] warning not emitted when code expanded from macro
This is a copy of a bug report from Red Hat's bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=449191
The bug is that with mapped locations, the code in check_empty_body
does not notice that the while() from the macro expansion violates the
rule. This is because of the hack we needed to get decent error messages
with mapped locations -- tokens resulting from a macro expansion are all
given the location of the start of the expansion.
Steps to Reproduce:
1. compile example program:
cat warn2.cc
int
main(int, char**)
{
#define XXX while(0);
XXX ;
while (0);
}
g++ -W -Werror -c warn2.cc
Actual results:
cc1plus: warnings being treated as errors
warn2.cc: In function int main(int, char**):
warn2.cc:6: error: suggest a space before ; or explicit braces around empty
body in while statement
Expected results:
warn2.cc: In function int main(int, char**):
warn2.cc:5: warning: suggest a space before ; or explicit braces around empty
body in while statement
warn2.cc:6: warning: suggest a space before ; or explicit braces around empty
body in while statement
--
Summary: [4.3/4.4 regression] warning not emitted when code
expanded from macro
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36478
[Bug fortran/36476] ICE: len=* CHARACTER array with separate PARAMETER statement
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-09 16:40 --- CONFIRM. The failing assert is: gcc_assert (!sym-value); Work around: Use the following syntax CHARACTER (len=*), PARAMETER :: MY_STRING(1:3) = (/ A , B, C /) or explicitly give the length of the character length: CHARACTER (len=1) MY_STRING(1:3) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2008-06-09 16:40:32 date|| Summary|Fortran CHARACTER array |ICE: len=* CHARACTER array |triggers ICE|with separate PARAMETER ||statement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36476
[Bug preprocessor/36479] New: Short buffer in libcpp
[EMAIL PROTECTED] prev-gcc]$ cat foo.ii
# 1 /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/g++.dg/pch/pch.C
# 1 built-in
# 1 command-line
# 1 /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/g++.dg/pch/pch.C
int main()
{
return 0;
}
[EMAIL PROTECTED] prev-gcc]$ valgrind --tool=memcheck ./cc1plus -fpreprocessed
foo.ii
-quiet -dumpbase foo.ii -m32 -mtune=generic -auxbase pch -O2 -version -o foo.s
==6304== Memcheck, a memory error detector.
==6304== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==6304== Using LibVEX rev 1804, a library for dynamic binary translation.
==6304== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==6304== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==6304== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==6304== For more details, rerun with: -v
==6304==
GNU C++ (GCC) version 4.4.0 20080609 (experimental) [trunk revision 136589]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20080609 (experimental) [trunk revision
136589], GMP version 4.2.2, MPFR version 2.3.0-p4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9e36edea0acfb287d81f6630c10d1047
==6304== Invalid read of size 1
==6304==at 0x4A07B24: strlen (mc_replace_strmem.c:242)
==6304==by 0x693EB2: output_file_directive (toplev.c:680)
==6304==by 0x7AE7E8: x86_file_start (i386.c:23343)
==6304==by 0x694DA4: toplev_main (toplev.c:1343)
==6304==by 0x39D3C1E329: (below main) (in /lib64/libc-2.8.so)
==6304== Address 0x4cb7d01 is 0 bytes after a block of size 65 alloc'd
==6304==at 0x4A074D1: realloc (vg_replace_malloc.c:429)
==6304==by 0xA0313C: xrealloc (xmalloc.c:179)
==6304==by 0x9D22AC: cpp_interpret_string (charset.c:1392)
==6304==by 0x9D2860: cpp_interpret_string_notranslate (charset.c:1416)
==6304==by 0x9D624A: do_linemarker (directives.c:956)
==6304==by 0x9D4BB4: _cpp_handle_directive (directives.c:483)
==6304==by 0x9DCE6E: cpp_read_main_file (init.c:536)
==6304==by 0x4D9947: c_common_post_options (c-opts.c:1174)
==6304==by 0x694309: toplev_main (toplev.c:1660)
==6304==by 0x39D3C1E329: (below main) (in /lib64/libc-2.8.so)
==6304==
==6304== Invalid read of size 1
==6304==at 0x693114: output_quoted_string (toplev.c:652)
==6304==by 0x693F03: output_file_directive (toplev.c:695)
==6304==by 0x7AE7E8: x86_file_start (i386.c:23343)
==6304==by 0x694DA4: toplev_main (toplev.c:1343)
==6304==by 0x39D3C1E329: (below main) (in /lib64/libc-2.8.so)
==6304== Address 0x4cb7d01 is 0 bytes after a block of size 65 alloc'd
==6304==at 0x4A074D1: realloc (vg_replace_malloc.c:429)
==6304==by 0xA0313C: xrealloc (xmalloc.c:179)
==6304==by 0x9D22AC: cpp_interpret_string (charset.c:1392)
==6304==by 0x9D2860: cpp_interpret_string_notranslate (charset.c:1416)
==6304==by 0x9D624A: do_linemarker (directives.c:956)
==6304==by 0x9D4BB4: _cpp_handle_directive (directives.c:483)
==6304==by 0x9DCE6E: cpp_read_main_file (init.c:536)
==6304==by 0x4D9947: c_common_post_options (c-opts.c:1174)
==6304==by 0x694309: toplev_main (toplev.c:1660)
==6304==by 0x39D3C1E329: (below main) (in /lib64/libc-2.8.so)
==6304==
==6304== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 1)
==6304== malloc/free: in use at exit: 448,374 bytes in 1,606 blocks.
==6304== malloc/free: 4,000 allocs, 2,394 frees, 2,176,191 bytes allocated.
==6304== For counts of detected errors, rerun with: -v
==6304== searching for pointers to 1,606 not-freed blocks.
==6304== checked 3,757,576 bytes.
==6304==
==6304== LEAK SUMMARY:
==6304==definitely lost: 8,832 bytes in 30 blocks.
==6304== possibly lost: 0 bytes in 0 blocks.
==6304==still reachable: 439,542 bytes in 1,576 blocks.
==6304== suppressed: 0 bytes in 0 blocks.
==6304== Rerun with --leak-check=full to see details of leaked memory.
[EMAIL PROTECTED] prev-gcc]$
--
Summary: Short buffer in libcpp
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36479
[Bug target/36450] [IRA] ICE in insert_restore with GET_MODE_ALIGNMENT mem
--- Comment #2 from aldot at gcc dot gnu dot org 2008-06-09 17:08 --- Vladimir, Is the testcase ok as is or do you need it reduced? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
[Bug preprocessor/36479] Short buffer in libcpp
--- Comment #1 from hjl dot tools at gmail dot com 2008-06-09 17:12 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00491.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||tromey at redhat dot com URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||06/msg00491.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36479
[Bug target/36450] [IRA] ICE in insert_restore with GET_MODE_ALIGNMENT mem
--- Comment #3 from vmakarov at redhat dot com 2008-06-09 17:22 --- The test is ok. Thanks. The problem is very simple. The assertion causing abort is simply wrong. I reproduced the same bug for the old register allocator. I just used wetstone for this. The assertion is wrong because alignment can not be bigger the preferred stack boundary (please see function.c::assign_stack_slot). It is a very old code. Instead of gcc_assert (GET_MODE_ALIGNMENT (GET_MODE (mem) = MEM_ALIGN (mem)) in caller_save.c::insert_save/insert_restore, the assertion should be gcc_assert (MIN (PREFERRED_STACK_BOUNDARY, GET_MODE_ALIGNMENT (GET_MODE (mem)) = MEM_ALIGN (mem)) I'll submit the patch to the branch today or tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
[Bug bootstrap/33781] [4.3/4.4 Regression] Arg list too long building libgcc.a
--- Comment #19 from Ralf dot Wildenhues at gmx dot de 2008-06-09 18:41 --- Created an attachment (id=15743) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15743action=view) patch to build libraries piecewise This patch assumes that libgcc_eh.a is the only one of the three libraries whose list of objects may be empty. If that assumption is false, then the other *-objects need to be defaulted as well (but in that case the original rules had a race condition, not guarding against eh_dummy.[co] being created concurrently). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug fortran/36379] preprocessing preprocessed output: invalid reads
--- Comment #6 from hjl dot tools at gmail dot com 2008-06-09 20:00 --- *** This bug has been marked as a duplicate of 36479 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379
[Bug preprocessor/36479] Short buffer in libcpp
--- Comment #2 from hjl dot tools at gmail dot com 2008-06-09 20:00 --- *** Bug 36379 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36479
[Bug preprocessor/36479] Short buffer in libcpp
--- Comment #3 from hjl dot tools at gmail dot com 2008-06-09 20:02 --- An updated patch is at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00513.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2008- |patches/2008- |06/msg00491.html|06/msg00513.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36479
[Bug preprocessor/36479] Short buffer in libcpp
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-06-09 20:09 --- H.J., this is c++, correct? For the fortran side of the problem, i.e. PR36379, I found that + cpp_option-char_precision = TYPE_PRECISION (char_type_node); should be added (comment #5). Could you check if this by any chance is missing on the c++ side of things as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36479
[Bug preprocessor/36479] Short buffer in libcpp
--- Comment #5 from hjl dot tools at gmail dot com 2008-06-09 20:20 --- This may be introduced by http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01235.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||kris dot van dot hees at ||oracle dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36479
[Bug preprocessor/36479] Short buffer in libcpp
--- Comment #6 from hjl dot tools at gmail dot com 2008-06-09 21:11 --- The updated patch is at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00523.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2008- |patches/2008- |06/msg00513.html|06/msg00523.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36479
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #17 from mark at codesourcery dot com 2008-06-09 21:16 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
--- Comment #16 from hjl dot tools at gmail dot com 2008-06-09 14:16
---
(In reply to comment #9)
I suspect that if you remove the setting in site.exp you will break the
following scenario:
1. User puts libraries/headers in $pefix/{lib,include}
I am not convinced it is the right thing to do. What
are those libraries/headers? Are they from gcc? If yes,
you don't need to do it. If not, can you use --sysroot
to handle non-gcc libraries/headers?
In general, no, these are not from GCC. They're probably from your C
library -- which might not be GLIBC or Newlib, of course. And, they
probably include your installed assembler and linker -- which not be
from GNU binutils, of course.
I don't know if --sysroot might be a solution. Historically, I believe
the scenario I put forth has worked, so you are going to break people's
test methodology. Maybe there is some solution that involves changing
the compiler flags used in site.exp (like by adding --sysroot, or -B
options, or something) so that you don't need to set GCC_EXEC_PREFIX.
But, I think that's going to be complicated. That's why I think the
right thing to do is to set up HOSTCC to be robust. Like having the
command to run default to:
unset GCC_EXEC_PREFIX gcc
rather than just:
gcc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug target/36480] New: stack-protector causes bad ARM PIC code generated
The ARM back-end avoids marking a function as needing PIC in
require_pic_register(). The code there checks if the current IR-type is
IR_GIMPLE or not. The logic does not work when both -fPIC and
-fstack-protector are given. The stack protector prologue is generated very
early in RTL expansion when the IR-type is still IR_GIMPLE. Hence, the current
code ends up using a PIC regiser never gets initialized properly.
---
extern int sprintf (char *, const char*, ...);
void
test (void)
{
char buf[10];
sprintf(buf, );
}
---
compiled using top-of-trunk on 6/9/2008
../install/bin/arm-elf-gcc -O2 -S -fdump-rtl-expand -fpic -fstack-protector
bug.c
Note that vreg 133 is used in insn 4 but never assigned a value.
;;
;; Full RTL generated for this function:
;;
(note 1 0 7 NOTE_INSN_DELETED)
(note 7 1 10 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 10 7 11 2 bug.c:7 (set (reg:SI 139)
(unspec:SI [
(const:SI (minus:SI (const (symbol_ref:SI
(_GLOBAL_OFFSET_TABLE_)))
(const:SI (plus:SI (unspec:SI [
(const_int 0 [0x0])
] 21)
(const_int 8 [0x8])
] 3)) -1 (nil))
(insn 11 10 12 2 bug.c:7 (set (reg:SI 139)
(unspec:SI [
(plus:SI (reg:SI 139)
(const (plus:SI (pc)
(const_int 8 [0x8]
(const_int 0 [0x0])
] 4)) -1 (nil))
(insn 12 11 2 2 bug.c:7 (use (reg:SI 139)) -1 (nil))
(note 2 12 3 2 NOTE_INSN_FUNCTION_BEG)
(insn 3 2 4 2 bug.c:5 (set (reg:SI 135)
(unspec:SI [
(symbol_ref:SI (__stack_chk_guard) [flags 0x40] var_decl
0xf7ec6f78 __stack_chk_guard)
] 3)) -1 (nil))
(insn 4 3 5 2 bug.c:5 (set (reg/f:SI 134)
(mem/u/c:SI (plus:SI (reg:SI 133)
(reg:SI 135)) [0 S4 A32])) -1 (expr_list:REG_EQUAL
(symbol_ref:SI (__stack_chk_guard) [flags 0x40] var_decl 0xf7ec6f78
__stack_chk_guard)
(nil)))
--
Summary: stack-protector causes bad ARM PIC code generated
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougkwan at google dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36480
[Bug middle-end/36447] [4.4 Regression] simplify_subreg ICE with right shift more than length type AVR
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2008-06-09 22:39 --- Subject: Bug 36447 Author: hutchinsonandy Date: Mon Jun 9 22:38:34 2008 New Revision: 136602 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136602 Log: PR middle-end/36447 * simplify-rtx.c (simplify_subreg): Add check for shift count greater than size. Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36447
[Bug testsuite/36285] gcc.dg/compat/struct-by-value-xxx improper test for AVR target
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2008-06-09 22:49 --- Subject: Bug 36285 Author: hutchinsonandy Date: Mon Jun 9 22:48:37 2008 New Revision: 136604 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136604 Log: PR testsuite/36285 * gcc.dg/compat/struct-return-10_y.c: Remove test_va. * gcc.dg/compat/vector-defs.h: Add check for availability of 8 byte double. * gcc.dg/compat/struct-layout-1_test.h: Change bitfield to match integer size. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/compat/struct-layout-1_test.h trunk/gcc/testsuite/gcc.dg/compat/struct-return-10_y.c trunk/gcc/testsuite/gcc.dg/compat/vector-defs.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36285
[Bug c/36481] New: gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
I'm trying to compile gcc 4.3.1 on a Laptop running Solaris Express Community Edition Build 89. [EMAIL PROTECTED]:[~/build] $ cat /etc/release Solaris Express Community Edition snv_89 X86 Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 06 May 2008 After configuring with these options (plenty of others tried) $ ../gcc-4.3.1/configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,fortran LD_LIBRARY_PATH=/usr/local/lib --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpfr-lib=/usr/local/lib --with-mpfr-include=/usr/local/include --with-gmp-include=/usr/local/include --with-gmp-lib=/usr/local/lib gcc spends 15 minutes or so compiling, then bombs out with: checking for i386-pc-solaris2.11-lipo... lipo checking for i386-pc-solaris2.11-nm... /export/home/drkirkby/build/./gcc/nm checking for i386-pc-solaris2.11-ranlib... ranlib checking for i386-pc-solaris2.11-strip... strip checking whether ln -s works... yes checking for i386-pc-solaris2.11-gcc... /export/home/drkirkby/build/./gcc/xgcc -B/export/home/drkirkby/build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[2]: *** [configure-stage1-target-libgcc] Error 1 gmake[2]: Leaving directory `/export/home/drkirkby/build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/ex A search on the web for the configure: error: cannot compute suffix of object files: cannot compile suggests setting LD_LIBRARY_PATH, as above. That does not work. I've also tried set LD_LIBRARY_PATH=/usr/local/lib export LD_LIBRARY_PATH but that does not work either. The log file: ./i386-pc-solaris2.11/libgcc/config.log (see end of message) shows the linker can't seem to find the library libmpfr.so.1. But that does exists. I've tried every option to configure that might tell the linker where to find this library: --with-mpfr=/usr/local --with-mpfr-lib=/usr/local/lib --with-mpfr-include=/usr/local/include but it does not work. In contrast, I can easily use that library if I compile with cc or gcc. Neither of these present any error message. [EMAIL PROTECTED]:[~] $ cc -L/usr/local/lib -lmpfr f.c [EMAIL PROTECTED]:[~] $ gcc -L/usr/local/lib -lmpfr f.c so the library is ok. Here's the log file. Any idea why the building of gcc 4.3.1 is failing? Target: i386-pc-solaris2.11 Configured with: ../gcc-4.3.1/configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,fortran LD_LIBRARY_PATH=/usr/local/lib --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpfr-lib=/usr/local/lib --with-mpfr-include=/usr/local/include --with-gmp-include=/usr/local/include --with-gmp-lib=/usr/local/lib Thread model: posix gcc version 4.3.1 (GCC) configure:2374: $? = 0 configure:2376: /export/home/drkirkby/build/./gcc/xgcc -B/export/home/drkirkby/build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -V /dev/null 5 xgcc: '-V' must come at the start of the command line configure:2379: $? = 1 configure:2398: /export/home/drkirkby/build/./gcc/xgcc -B/export/home/drkirkby/build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -o conftest -g -fkeep-inline-functions conftest.c 5 ld.so.1: cc1: fatal: libmpfr.so.1: open failed: No such file or directory xgcc: Internal error: Killed (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. configure:2401: $? = 1 configure:2567: checking for suffix of object files configure:2588: /export/home/drkirkby/build/./gcc/xgcc -B/export/home/drkirkby/build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -c -g -fkeep-inline-functions conftest.c 5 ld.so.1: cc1: fatal: libmpfr.so.1: open failed: No such file or directory xgcc: Internal error: Killed (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. configure:2591: $? = 1 configure: failed program was: Someone suggested I set CONFIG_SHELL to /bin/bash. That did not help. Also tried LDFLAGS='-L/usr/local/lib -R/usr/local/lib' but again did not help. -- Summary: gcc fails to build on Solaris x86 - it forgets the locations of libmpfr Product: gcc
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #18 from hjl dot tools at gmail dot com 2008-06-09 23:58
---
(In reply to comment #17)
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
--- Comment #16 from hjl dot tools at gmail dot com 2008-06-09 14:16
---
(In reply to comment #9)
I suspect that if you remove the setting in site.exp you will break the
following scenario:
1. User puts libraries/headers in $pefix/{lib,include}
I am not convinced it is the right thing to do. What
are those libraries/headers? Are they from gcc? If yes,
you don't need to do it. If not, can you use --sysroot
to handle non-gcc libraries/headers?
In general, no, these are not from GCC. They're probably from your C
library -- which might not be GLIBC or Newlib, of course. And, they
probably include your installed assembler and linker -- which not be
from GNU binutils, of course.
They sound to me the ideal usage for --sysroot. They aren't from
gcc and they don't change from one gcc version to another one.
You can use one --sysroot for gcc 4.1, 4.2, 4.3, 4.4, ...
--syroot supports libraries and headers. Does it support
assembler and linker?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #19 from mark at codesourcery dot com 2008-06-10 00:38 --- Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc hjl dot tools at gmail dot com wrote: They sound to me the ideal usage for --sysroot. They aren't from gcc and they don't change from one gcc version to another one. You can use one --sysroot for gcc 4.1, 4.2, 4.3, 4.4, ... --syroot supports libraries and headers. Does it support assembler and linker? Not as far as I know; --sysroot is about the target, not the host. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #20 from hjl dot tools at gmail dot com 2008-06-10 01:45 --- (In reply to comment #19) Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc hjl dot tools at gmail dot com wrote: They sound to me the ideal usage for --sysroot. They aren't from gcc and they don't change from one gcc version to another one. You can use one --sysroot for gcc 4.1, 4.2, 4.3, 4.4, ... --syroot supports libraries and headers. Does it support assembler and linker? Not as far as I know; --sysroot is about the target, not the host. So setting GCC_EXEC_PREFIX is to support make check using non-system assembler and linker with gcc for a target which probably isn't a GNU target/OS. Am I correct? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug c/36470] sizeof UTF-32 is 2 on AVR
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2008-06-10 03:21 --- Fixing the testcase is easy, That is how i found problem. Two wrongs make a right! It is not a priority but it seems like the suggestions is right way to fix. I'll mark as XFAIL sometime soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36470
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #21 from mark at codesourcery dot com 2008-06-10 05:02 --- Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc hjl dot tools at gmail dot com wrote: --syroot supports libraries and headers. Does it support assembler and linker? Not as far as I know; --sysroot is about the target, not the host. So setting GCC_EXEC_PREFIX is to support make check using non-system assembler and linker with gcc for a target which probably isn't a GNU target/OS. Am I correct? Or which *is* a GNU target/OS, but isn't using an in-tree build of all the components -- like, for example, if you already have good versions of the cross tools around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #22 from hjl dot tools at gmail dot com 2008-06-10 05:49 --- (In reply to comment #21) Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc hjl dot tools at gmail dot com wrote: --syroot supports libraries and headers. Does it support assembler and linker? Not as far as I know; --sysroot is about the target, not the host. So setting GCC_EXEC_PREFIX is to support make check using non-system assembler and linker with gcc for a target which probably isn't a GNU target/OS. Am I correct? Or which *is* a GNU target/OS, but isn't using an in-tree build of all the components -- like, for example, if you already have good versions of the cross tools around. I have done that all the time. I just combine a known good gcc source tree with a known good binutils source tree. The main problem is many times the common directories, like include, libiberty and top level files, aren't compatible between gcc and binutils. My solutions are 1. Use PATH for build/testing if I can't use combined tree. Or 2. Patch the common directories/files so that they are compatible between gcc and binutils. I thought it was my problem. I believe such changes belong to vendor branches, not gcc trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
