Re: Error saying cannot compute suffix while building compiler gcc-4.3.2
On 26 March 2010 07:54, Vaibhav Shrimali vaibhav.shrim...@gmail.com wrote: Hello, I made some changes in the compiler gcc-4.3.2 and am currently trying to build the compiler. There are no compilation error in the source code. I followed the steps specified at : http://gcc.gnu.org/install/index.html while configuring i used the command: r...@vebs-pc:/home/vebs/gcc/gcc# export SUF=-4.3 r...@vebs-pc:/home/vebs/gcc/gcc# /home/vebs/gcc/gcc-4.3.2/configure --program-suffix=$SUF r...@vebs-pc:/home/vebs/gcc/gcc# make -f Makefile it exits and gives the following output.. whose last few lines are: ** checking for i686-pc-linux-gnu-gcc... /home/vebs/gcc/gcc/./gcc/xgcc -B/home/vebs/gcc/gcc/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 make[2]: Leaving directory `/home/vebs/gcc/gcc' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/vebs/gcc/gcc' make: *** [all] Error 2 ** As the configure output says: See `config.log' for more details. Your existing compiler is not working correctly, see config.log for more details of what is failing. There is no need to crosspost this to gcc and gcc-patches, please follow up on gcc-help. Jonathan
bug linear loop transforms
Im writing to you regarding a possible bug in linear loop transfor.
The bug can be reproduce by compiling the attached c file with gcc.4.5.0
(20100204, 20100325) on x86 machine.
The compiler flags that reproduce the error are:
-O2 -fno-inline -fno-tree-ch -ftree-loop-linear
If the compiler is run with:
-O2 -fno-inline -fno-tree-ch -fno-tree-loop-linear
then the produced code is correct.
#include stdio.h
int test (int n, int *a)
{
int i, j;
for (i = 0; i n; i++)
{
for (j = 0; j n; j++)
{
a[j] = i + n;
}
}
if (a[0] != 31 || i + n - 1 != 31)
printf(incorrect %d %d \n, a[0], i+n-1);
return 0;
}
int main (void)
{
int a[16];
test (16, a);
return 0;
}
Re: bug linear loop transforms
[gcc-bugs@ removed from Cc:] On Mon, 29 Mar 2010, Alex Turjan wrote: Im writing to you regarding a possible bug in linear loop transfor. The bug can be reproduce by compiling the attached c file with gcc.4.5.0 (20100204, 20100325) on x86 machine. The compiler flags that reproduce the error are: -O2 -fno-inline -fno-tree-ch -ftree-loop-linear If the compiler is run with: -O2 -fno-inline -fno-tree-ch -fno-tree-loop-linear then the produced code is correct. Instead of writing to a mailing list, please file a bug in GCC Bugzilla, as described in http://gcc.gnu.org/bugs/ . Posting bug reports to gcc-bugs@ does not register them in the bugzilla, and thus is not recommended. Thanks. Alexander Monakov
Is gcc-bugs archive down?
Hi, Many comments for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43560 are missing from gcc-bugs archive: http://gcc.gnu.org/ml/gcc-bugs/2010-03/ Is there a problem with gcc-bugs archive? -- H.J.
Re: Ask for suggestions on init_caller_save
On 03/23/10 21:30, Jie Zhang wrote: I'm fixing a bug. It's caused by uninitialized caller save pass data. One function in the test case uses the optimize attribute with O2 option. So even with -O0 in command line, GCC calls caller save pass for that function. The problem is init_caller_save is called in backend_inti_target if flag_caller_saves is set. Apparently, in this case, flag_caller_saves is not set when came to backend_inti_target. I think there are several ways to fix this bug, but I don't know which way should/can I go: 1. Always call init_caller_save in backend_inti_target. But it seems a waste for most cases if -O0. 2. Call init_caller_save in IRA main function. But by this way it will be called multiple times unless we create a flag to remember if it has been called or not. Maybe we can reuse test_reg or test_mem. If they are NULL_TREE, just call init_caller_save. 3. Call init_caller_save in handle_optimize_attribute. If flag_caller_saves is not set before parse_optimize_options but set after, call init_caller_save. Considering there might be multiple functions using optimize attribute, we also need a flag to remember if init_caller_save has been called or not. 4. There are only three global function in caller-save.c: init_save_areas, setup_save_areas, and save_call_clobbered_regs. We can just add a check in the beginning of those functions. If the data has not been initialized, just init_caller_save first. Any suggestions? I'd suggest #2 with a status flag indicating whether or not caller-saves has been initialized.That should be low enough overhead to not be a problem. Jeff
Peculiar XPASS of gcc.dg/guality/inline-params.c
Hi, I have run the testcase with the early inliner disabled and noticed that gcc.dg/guality/inline-params.c XPASSes with early inlining and XFAILs without it. The reason for the (expected) failure is that IPA-CP removes a parameter which is constant (but also unused?). I reckon this is the reason for the xfail mark and so I guess that early inlining should be disabled in the particular testcase, am I right? Thanks, Martin
gmp 5.0.1 and gcc 4.5?
I've not seen any discussion of testing gcc trunk against the newer gmp 5.0 or 5.0.1 releases. Has anyone done significant testing with the newer gmp releases and are there any long term plans for bumping the required gmp (assuming that any of the new features or fixes are useful for gcc)? Thanks in advance for any comments. I planning a gcc45 fink package once gcc 4.5.0 is released and was considering whether it made sense to try to depend on the newer gmp. Jack
Re: gmp 5.0.1 and gcc 4.5?
On Mon, 29 Mar 2010, Jack Howarth wrote: I've not seen any discussion of testing gcc trunk against the newer gmp 5.0 or 5.0.1 releases. Has anyone done significant testing with the newer gmp releases and are there any long term plans for bumping the required gmp (assuming that any of the new features or fixes are useful for gcc)? Thanks in advance for GMP is mainly used via MPFR. Thus, I'd expect the required version to be bumped if a new MPFR version was required that in turn required newer GMP, but otherwise there would be little use to a bump. New MPFR would be required if needed for folding some function of use to GCC to fold (erfc_scaled has been mentioned as one it would be useful to the Fortran front end to have MPFR support for, for example, but SVN MPFR doesn't yet support it; if it gains support, that might justify a future increase in the required MPFR version). -- Joseph S. Myers jos...@codesourcery.com
Optimizing floating point *(2^c) and /(2^c)
I've recently written a program where taking the average of 2 floating
point numbers was a real bottleneck. I've looked into the assembly
generated by gcc -O3 and apparently gcc treats multiplication and
division by a hard-coded 2 like any other multiplication with a
constant. I think, however, that *(2^c) and /(2^c) for floating
points, where the c is known at compile-time, should be able to be
optimized with the following pseudo-code:
e = exponent bits of the number
if (e c e (0b111...11)-c) {
e += c or e -= c
} else {
do regular multiplication
}
Even further optimizations may be possible, such as bitshifting the
significand when e=0. However, that would require checking for a lot
of special cases and require so many conditional jumps that it's most
likely not going to be any faster.
I'm not skilled enough with assembly to write this myself and test if
this actually performs faster than how it's implemented now. Its
performance will most likely also depend on the processor
architecture, and I could only test this code on one machine.
Therefore I ask to those who are familiar with gcc's optimization
routines to give this 2 seconds of thought, as this is probably rather
easy to implement and many programs could benefit from this.
Greets,
Jeroen
Re: Ask for suggestions on init_caller_save
On 03/30/2010 12:11 AM, Jeff Law wrote: On 03/23/10 21:30, Jie Zhang wrote: I'm fixing a bug. It's caused by uninitialized caller save pass data. One function in the test case uses the optimize attribute with O2 option. So even with -O0 in command line, GCC calls caller save pass for that function. The problem is init_caller_save is called in backend_inti_target if flag_caller_saves is set. Apparently, in this case, flag_caller_saves is not set when came to backend_inti_target. I think there are several ways to fix this bug, but I don't know which way should/can I go: 1. Always call init_caller_save in backend_inti_target. But it seems a waste for most cases if -O0. 2. Call init_caller_save in IRA main function. But by this way it will be called multiple times unless we create a flag to remember if it has been called or not. Maybe we can reuse test_reg or test_mem. If they are NULL_TREE, just call init_caller_save. 3. Call init_caller_save in handle_optimize_attribute. If flag_caller_saves is not set before parse_optimize_options but set after, call init_caller_save. Considering there might be multiple functions using optimize attribute, we also need a flag to remember if init_caller_save has been called or not. 4. There are only three global function in caller-save.c: init_save_areas, setup_save_areas, and save_call_clobbered_regs. We can just add a check in the beginning of those functions. If the data has not been initialized, just init_caller_save first. Any suggestions? I'd suggest #2 with a status flag indicating whether or not caller-saves has been initialized. That should be low enough overhead to not be a problem. Thanks. I will send a patch to gcc-patches and CC you. -- Jie Zhang CodeSourcery (650) 331-3385 x735
Re: Optimizing floating point *(2^c) and /(2^c)
On Mar 29, 2010, at 13:19, Jeroen Van Der Bossche wrote:
've recently written a program where taking the average of 2 floating
point numbers was a real bottleneck. I've looked into the assembly
generated by gcc -O3 and apparently gcc treats multiplication and
division by a hard-coded 2 like any other multiplication with a
constant. I think, however, that *(2^c) and /(2^c) for floating
points, where the c is known at compile-time, should be able to be
optimized with the following pseudo-code:
e = exponent bits of the number
if (e c e (0b111...11)-c) {
e += c or e -= c
} else {
do regular multiplication
}
Even further optimizations may be possible, such as bitshifting the
significand when e=0. However, that would require checking for a lot
of special cases and require so many conditional jumps that it's most
likely not going to be any faster.
I'm not skilled enough with assembly to write this myself and test if
this actually performs faster than how it's implemented now. Its
performance will most likely also depend on the processor
architecture, and I could only test this code on one machine.
Therefore I ask to those who are familiar with gcc's optimization
routines to give this 2 seconds of thought, as this is probably rather
easy to implement and many programs could benefit from this.
For any optimization suggestions, you should start with showing some real,
compilable, code with a performance problem that you think the compiler could
address. Please include details about compilation options, GCC versions and
target hardware, as well as observed performance numbers. How do you see that
averaging two floating point numbers is a bottleneck? This should only be a
single addition and multiplication, and will execute in a nanosecond or so on a
moderately modern system.
Your particular suggestion is flawed. Floating-point multiplication is very
fast on most targets. It is hard to see how on any target with floating-point
hardware, manual mucking with the representation can be a win. In particular,
your sketch doesn't at all address underflow and overflow. Likely a complete
implementation would be many times slower than a floating-point multiply.
-Geert
Re: Optimizing floating point *(2^c) and /(2^c)
On 3/29/2010 10:51 AM, Geert Bosch wrote:
On Mar 29, 2010, at 13:19, Jeroen Van Der Bossche wrote:
've recently written a program where taking the average of 2 floating
point numbers was a real bottleneck. I've looked into the assembly
generated by gcc -O3 and apparently gcc treats multiplication and
division by a hard-coded 2 like any other multiplication with a
constant. I think, however, that *(2^c) and /(2^c) for floating
points, where the c is known at compile-time, should be able to be
optimized with the following pseudo-code:
e = exponent bits of the number
if (e c e (0b111...11)-c) {
e += c or e -= c
} else {
do regular multiplication
}
Even further optimizations may be possible, such as bitshifting the
significand when e=0. However, that would require checking for a lot
of special cases and require so many conditional jumps that it's most
likely not going to be any faster.
I'm not skilled enough with assembly to write this myself and test if
this actually performs faster than how it's implemented now. Its
performance will most likely also depend on the processor
architecture, and I could only test this code on one machine.
Therefore I ask to those who are familiar with gcc's optimization
routines to give this 2 seconds of thought, as this is probably rather
easy to implement and many programs could benefit from this.
For any optimization suggestions, you should start with showing some real,
compilable, code with a performance problem that you think the compiler could
address. Please include details about compilation options, GCC versions and
target hardware, as well as observed performance numbers. How do you see that
averaging two floating point numbers is a bottleneck? This should only be a
single addition and multiplication, and will execute in a nanosecond or so on a
moderately modern system.
Your particular suggestion is flawed. Floating-point multiplication is very
fast on most targets. It is hard to see how on any target with floating-point
hardware, manual mucking with the representation can be a win. In particular,
your sketch doesn't at all address underflow and overflow. Likely a complete
implementation would be many times slower than a floating-point multiply.
-Geert
gcc used to have the ability to replace division by a power of 2 by an
fscale instruction, for appropriate targets (maybe still does). Such
targets have nearly disappeared from everyday usage. What remains is
the possibility of replacing the division by constant power of 2 by
multiplication, but it's generally considered the programmer should have
done that in the beginning. icc has such an facility, but it's subject
to -fp-model=fast (equivalent to gcc -ffast-math -fno-cx-limited-range),
even though it's a totally safe conversion.
As Geert indicated, it's almost inconceivable that a correct
implementation which takes care of exceptions could match the floating
point hardware performance, even for a case which starts with operands
in memory (but you mention the case following an addition).
--
Tim Prince
Re: Peculiar XPASS of gcc.dg/guality/inline-params.c
Hi, I have run the testcase with the early inliner disabled and noticed that gcc.dg/guality/inline-params.c XPASSes with early inlining and XFAILs without it. The reason for the (expected) failure is that IPA-CP removes a parameter which is constant (but also unused?). I reckon this is the reason for the xfail mark and so I guess that early inlining should be disabled in the particular testcase, am I right? Well, I guess we should be able to maintain debug info with IPA-CP changes (only case where debugging info is difficult to maintain IMO is the case of unused argument removal that is explicitely disabled here). So I guess in a way this is correct XFAIL... Honza Thanks, Martin
bug linear loop transforms
Im writing to you regarding a possible bug in linear loop transfor.
The bug can be reproduce by compiling the attached c file with gcc.4.5.0
(20100204, 20100325) on x86 machine.
The compiler flags that reproduce the error are:
-O2 -fno-inline -fno-tree-ch -ftree-loop-linear
If the compiler is run with:
-O2 -fno-inline -fno-tree-ch -fno-tree-loop-linear
then the produced code is correct.
#include stdio.h
int test (int n, int *a)
{
int i, j;
for (i = 0; i n; i++)
{
for (j = 0; j n; j++)
{
a[j] = i + n;
}
}
if (a[0] != 31 || i + n - 1 != 31)
printf(incorrect %d %d \n, a[0], i+n-1);
return 0;
}
int main (void)
{
int a[16];
test (16, a);
return 0;
}
[Bug web/43573] testing bugzilla mail reporting
--- Comment #2 from cgf at gcc dot gnu dot org 2010-03-29 18:00 --- Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43573
[Bug web/43573] testing bugzilla mail reporting
--- Comment #3 from cgf at gcc dot gnu dot org 2010-03-29 18:02 --- Need to remember to restart everything that uses spamassassin after an update to spamassassin. -- cgf at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43573
[Bug lto/43577] New: gcc.dg/lto/20081115_?.c fails without early inlining
If you compile the testcase consisting of files testsuite/gcc.dg/lto/20081115_[012].c with disabled early inlining (-fno-early-inlining), the execution will abort. The testcase is full of extern inline functions so probably the correct ones get picked by early inliner but wrong ones by the IPA inliner. -- Summary: gcc.dg/lto/20081115_?.c fails without early inlining Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jamborm at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43577
[Bug lto/43577] gcc.dg/lto/20081115_?.c fails without early inlining
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-29 18:29 --- * passes.c (init_optimization_passes): Schedule pass_rebuild_cgraph_edges and pass_early_inline outside of pass_all_early_optimizations. Document reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43577
[Bug lto/43577] gcc.dg/lto/20081115_?.c fails without early inlining
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-29 18:29 --- Yes this testcase is testing early inlining :). -- 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=43577
[Bug lto/43577] gcc.dg/lto/20081115_?.c fails without early inlining
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-29 18:28 --- Well the testcase is really bogus without early inline turned on. It is testing early inlining as far as I can tell. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43577
[Bug c/43580] New: ICE segfault compiling libgcc2.c
Compiles at -O0. Fails at -O1 and higher. $ gcc --version gcc (GCC) 4.5.0 20100328 (experimental) [trunk revision 157785] This should also be /users/joel/test-gcc/b-gcc1-arm/./gcc/xgcc -B/users/joel/test-gcc/b-gcc1-arm/./gcc/ -nostdinc -B/users/joel/test-gcc/b-gcc1-arm/arm-rtems4.10/newlib/ -isystem /users/joel/test-gcc/b-gcc1-arm/arm-rtems4.10/newlib/targ-include -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/arm-rtems4.10/bin/ -B/users/joel/test-gcc/install-svn/arm-rtems4.10/lib/ -isystem /users/joel/test-gcc/install-svn/arm-rtems4.10/include -isystem /users/joel/test-gcc/install-svn/arm-rtems4.10/sys-include-g -O2 -mhard-float -O2 -I/users/joel/test-gcc/gcc-svn/gcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -Wno-missing-prototypes -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/users/joel/test-gcc/gcc-svn/libgcc -I/users/joel/test-gcc/gcc-svn/libgcc/. -I/users/joel/test-gcc/gcc-svn/libgcc/../gcc -I/users/joel/test-gcc/gcc-svn/libgcc/../include -DHAVE_CC_TLS -o _mulsc3.o -MT _mulsc3.o -MD -MP -MF _mulsc3.dep -DL_mulsc3 -c /users/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcc2.c \ /users/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcc2.c: In function '__mulsc3': /users/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcc2.c:1889:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE segfault compiling libgcc2.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: arm-rtems4.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
[Bug target/43580] ICE segfault compiling libgcc2.c
--- Comment #1 from joel at gcc dot gnu dot org 2010-03-29 18:44 --- Created an attachment (id=20252) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20252action=view) Preprocessed libgcc2.c source Definitely compiles with 4.4.3 not with head -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build, ice-on-valid-code Summary|ICE segfault compiling |[4.5 Regression] ICE |libgcc2.c |segfault compiling libgcc2.c Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c
--- Comment #2 from joel at gcc dot gnu dot org 2010-03-29 18:45 --- Could someone try this with arm-eabi/elf? That would impact the priority of this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
[Bug c++/43581] New: exception handling broken across shared libaries
This looks like a recent regression, it didn't fail sometime early February, if
I remember correctly. Test somewhat reduced from a libtool testsuite test.
CXX=g++
cat lib.h \EOF
#include exception
#include string
class libexc : public std::exception {
public:
libexc (std::string str) : message (str) { }
~libexc () throw () { }
virtual const char *what () const throw ()
{
return message.c_str ();
}
private:
std::string message;
};
int libfoo () throw (libexc);
EOF
cat lib.cpp \EOF
#include iostream
#include lib.h
int libbar (void) throw (libexc)
{
throw libexc (exception in library);
}
int libfoo (void) throw (libexc)
{
try {
libbar ();
}
catch (libexc e) {
std::cerr caught inside lib: e.what () '\n';
throw libexc (exception from library);
}
return 0;
}
EOF
cat main.cpp \EOF
#include lib.h
int exceptions_in_lib (void)
{
try {
libfoo ();
}
catch (libexc e) {
return 0;
}
return 1;
}
int main (void)
{
if (exceptions_in_lib ())
return 1;
return 0;
}
EOF
$CXX -O2 -c main.cpp
$CXX -O2 -c lib.cpp -fPIC -DPIC
$CXX -fPIC -DPIC -shared lib.o -O2 -Wl,-soname -Wl,liba.so.1 -o liba.so.1
ln -sf liba.so.1 liba.so
$CXX -O2 -o main main.o -L. -la
LD_LIBRARY_PATH=`pwd` ./main
leads to:
caught inside lib: exception in library
terminate called after throwing an instance of 'libexc'
what(): exception from library
./script: line 73: 24698 Aborted (core dumped)
LD_LIBRARY_PATH=`pwd` ./main
Happens with
$ gcc -v
Using built-in specs.
COLLECT_GCC=/opt/bin/gcc
COLLECT_LTO_WRAPPER=/opt/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure -C --enable-maintainer-mode --prefix=/opt
LDFLAGS_FOR_TARGET=-Wl,--as-needed --with-boot-ldflags=-Wl,--as-needed
--with-stage1-ldflags=-Wl,--as-needed --enable-lto --without-cloog
--without-ppl --enable-languages=c,c++,fortran,java,lto,objc,obj-c++
--enable-gold LD=/opt/bin/ld LD_FOR_TARGET=/opt/bin/ld
Thread model: posix
gcc version 4.5.0 20100329 (experimental) (GCC)
where ld is
$ /opt/bin/ld -v
GNU gold (GNU Binutils 2.20.51.20100319) 1.9
as well as
$ gcc -v
Using built-in specs.
COLLECT_GCC=/opt/bin/gcc
COLLECT_LTO_WRAPPER=/opt/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure -C --enable-maintainer-mode --prefix=/opt
LDFLAGS_FOR_TARGET=-Wl,--as-needed --with-boot-ldflags=-Wl,--as-needed
--with-stage1-ldflags=-Wl,--as-needed --enable-lto --without-cloog
--without-ppl --enable-languages=c,c++,fortran,java,lto,objc,obj-c++
Thread model: posix
gcc version 4.5.0 20100329 (experimental) (GCC)
--
Summary: exception handling broken across shared libaries
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code, EH
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwild at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43581
[Bug other/43581] [4.5 Regression] exception handling broken across shared libaries
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |other Summary|exception handling broken |[4.5 Regression] exception |across shared libaries |handling broken across ||shared libaries Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43581
[Bug bootstrap/43583] New: [4.5 Regression] value computed not used in parallel.c:121:4
Bootstrap fails with revision 157799 on trunk: /bin/sh ./libtool --tag=CC --mode=compile /home/ig25/Gcc/trunk-bin/./gcc/xgcc -B/home/ig25/Gcc/trunk-bin/./gcc/ -B/home/ig25/x86_64-unknown-linux-gnu/bin/ -B/home/ig25/x86_64-unknown-linux-gnu/lib/ -isystem /home/ig25/x86_64-unknown-linux-gnu/include -isystem /home/ig25/x86_64-unknown-linux-gnu/sys-include-DHAVE_CONFIG_H -I. -I../../../../trunk/libgomp -I../../../../trunk/libgomp/config/linux/x86 -I../../../../trunk/libgomp/config/linux -I../../../../trunk/libgomp/config/posix -I../../../../trunk/libgomp -Wall -Werror -ftls-model=initial-exec -march=i486 -mtune=i686 -Wc,-pthread -g -O2 -m32 -MT parallel.lo -MD -MP -MF .deps/parallel.Tpo -c -o parallel.lo ../../../../trunk/libgomp/parallel.c libtool: compile: /home/ig25/Gcc/trunk-bin/./gcc/xgcc -B/home/ig25/Gcc/trunk-bin/./gcc/ -B/home/ig25/x86_64-unknown-linux-gnu/bin/ -B/home/ig25/x86_64-unknown-linux-gnu/lib/ -isystem /home/ig25/x86_64-unknown-linux-gnu/include -isystem /home/ig25/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../../trunk/libgomp -I../../../../trunk/libgomp/config/linux/x86 -I../../../../trunk/libgomp/config/linux -I../../../../trunk/libgomp/config/posix -I../../../../trunk/libgomp -Wall -Werror -ftls-model=initial-exec -march=i486 -pthread -mtune=i686 -g -O2 -m32 -MT parallel.lo -MD -MP -MF .deps/parallel.Tpo -c ../../../../trunk/libgomp/parallel.c -fPIC -DPIC -o .libs/parallel.o cc1: warnings being treated as errors ../../../../trunk/libgomp/parallel.c: In function 'GOMP_parallel_end': ../../../../trunk/libgomp/parallel.c:121:4: error: value computed is not used make[9]: *** [parallel.lo] Error 1 make[9]: Leaving directory `/home/ig25/Gcc/trunk-bin/x86_64-unknown-linux-gnu/32/libgomp' make[8]: *** [all-recursive] Error 1 make[8]: Leaving directory `/home/ig25/Gcc/trunk-bin/x86_64-unknown-linux-gnu/32/libgomp' make[7]: *** [all] Error 2 make[7]: Leaving directory `/home/ig25/Gcc/trunk-bin/x86_64-unknown-linux-gnu/32/libgomp' make[6]: *** [multi-do] Error 1 make[6]: Leaving directory `/home/ig25/Gcc/trunk-bin/x86_64-unknown-linux-gnu/libgomp' make[5]: *** [all-multi] Error 2 make[5]: Leaving directory `/home/ig25/Gcc/trunk-bin/x86_64-unknown-linux-gnu/libgomp' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/ig25/Gcc/trunk-bin/x86_64-unknown-linux-gnu/libgomp' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/ig25/Gcc/trunk-bin/x86_64-unknown-linux-gnu/libgomp' make[2]: *** [all-stage1-target-libgomp] Error 2 make[2]: Leaving directory `/home/ig25/Gcc/trunk-bin' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/ig25/Gcc/trunk-bin' make: *** [all] Error 2 configure command was ../trunk/configure --prefix=$HOME --enable-languages=all,ada --with-mpc=/usr/local -- Summary: [4.5 Regression] value computed not used in parallel.c:121:4 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug bootstrap/43584] New: [regression] h8300-rtems fails to build
Looking at the failure log, this looks like the new cross-compiler is being used to compile a native part of gcc. make[3]: Entering directory `/users/joel/test-gcc/b-gcc1-h8300/gcc' /users/joel/test-gcc/b-gcc1-h8300/./gcc/xgcc -B/users/joel/test-gcc/b-gcc1-h8300/./gcc/ -nostdinc -B/users/joel/test-gcc/b-gcc1-h8300/h8300-rtems4.10/newlib/ -isystem /users/joel/test-gcc/b-gcc1-h8300/h8300-rtems4.10/newlib/targ-include -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/h8300-rtems4.10/bin/ -B/users/joel/test-gcc/install-svn/h8300-rtems4.10/lib/ -isystem /users/joel/test-gcc/install-svn/h8300-rtems4.10/include -isystem /users/joel/test-gcc/install-svn/h8300-rtems4.10/sys-include-c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I/users/joel/test-gcc/gcc-svn/gcc -I/users/joel/test-gcc/gcc-svn/gcc/. -I/users/joel/test-gcc/gcc-svn/gcc/../include -I/users/joel/test-gcc/gcc-svn/gcc/../libcpp/include -I/users/joel/test-gcc/gcc-svn/gcc/../libdecnumber -I/users/joel/test-gcc/gcc-svn/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/include/libelf \ /users/joel/test-gcc/gcc-svn/gcc/config/h8300/h8300.c -o h8300.o In file included from /users/joel/test-gcc/gcc-svn/gcc/config/h8300/h8300.c:25:0: /users/joel/test-gcc/gcc-svn/gcc/system.h:199:22: fatal error: strings.h: No such file or directory compilation terminated. make[3]: *** [h8300.o] Error 1 -- Summary: [regression] h8300-rtems fails to build Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: h8300-rtems4.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43584
[Bug bootstrap/43584] [regression] h8300-rtems fails to build
--- Comment #1 from joel at gcc dot gnu dot org 2010-03-29 18:52 --- Cross source is gcc (GCC) 4.5.0 20100328 (experimental) [trunk revision 157785] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43584
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-03-29 18:54 --- Created an attachment (id=20253) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20253action=view) config.log in the libgomp directory -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #2 from tkoenig at gcc dot gnu dot org 2010-03-29 18:57 --- Trying to get this onto the regression radar.. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.0 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #3 from tkoenig at gcc dot gnu dot org 2010-03-29 18:58 --- ... which of course works better if I get the Known to work and Known to fail fields correct. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.4.0 |4.5.0 Known to work|4.5.0 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug c++/43586] New: Missing strstream.h file in Include directory
I am not seeing strstream.h file in Include directory.Instead of this i am seeing strstream in include directory because of this my old code is giving errors while compliation Here are the list of files which i am able to see. [/usr] find . -name strstream ./include/c++/3.4.6/backward/strstream ./include/c++/4.1.1/backward/strstream Please suggest me what can be done -- Summary: Missing strstream.h file in Include directory Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: skalyan_g at yahoo dot co dot in GCC build triplet: Red Hat Linux Enterprise 5.4 GCC host triplet: Red Hat Linux Enterprise 5.4 GCC target triplet: Red Hat Linux Enterprise 5.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43586
[Bug c++/43586] Missing strstream.h file in Include directory
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-29 20:26 --- First off your find will only find files named exactly strstream. And second strstream.h never existed and is not part of the C++ standard (strstream is not either). You should use stringstream instead. -- 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=43586
[Bug c/43587] New: New test failures
On Linux/ia32, revision 157801 gave: FAIL: gcc.dg/cpp/include6.c (test for excess errors) FAIL: gcc.dg/raw-string-1.c (test for excess errors) FAIL: gcc.dg/raw-string-2.c (test for excess errors) FAIL: gcc.dg/raw-string-5.c (test for excess errors) FAIL: gcc.dg/raw-string-6.c (test for errors, line 4) FAIL: gcc.dg/raw-string-6.c (test for errors, line 4) FAIL: gcc.dg/raw-string-6.c (test for excess errors) FAIL: gcc.dg/raw-string-7.c (test for excess errors) -- Summary: New test failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c 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=43587
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-29 20:27 --- I don't see why h8300.c is being built. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Keywords||build Summary|host files being used during|[4.5 Regression] host files |cross compilation |being used during cross ||compilation Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug bootstrap/43584] [regression] h8300-rtems fails to build
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-29 20:27 --- *** This bug has been marked as a duplicate of 43531 *** *** This bug has been marked as a duplicate of 43531 *** -- 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=43584
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-29 20:27 --- *** Bug 43584 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||joel at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-29 20:34 --- __sync_fetch_and_add (gomp_remaining_threads_count, 1UL - team-nthreads); This should not cause a warning to happen. Can you provide the preprocessed source? This works for me with: LAST_UPDATED: Fri Mar 26 18:56:25 UTC 2010 (revision 157759) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build, diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug other/43581] [4.5 Regression] exception handling broken across shared libaries
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-29 20:43 --- This works for me with: gcc version 4.5.0 20100326 (experimental) [trunk revision 157759] (GCC) GNU ld (GNU Binutils for Debian) 2.18.0.20080103 GNU C Library stable release version 2.7, by Roland McGrath et al. I tried with both 4.5's libstdc++ and with the default 4.3's. Can you remove from the configure part --as-needed ? Since that is the major difference between my build and yours. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added 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=43581
[Bug middle-end/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1
--- Comment #24 from eric dot cabret at gmail dot com 2010-03-29 20:44 --- I checked on my Ubuntu 64bit Lucid Lynx system that generates bad binary : 1) binutils (2.20.1-3ubuntu1) is installed 2) binutils-gold (2.20-0ubuntu2) is NOT installed (In reply to comment #23) only seen with gold (2.20.1). gold from the trunk does work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43556
[Bug c++/29131] [DR 225] Bad name lookup for templates due to fundamental types namespace for ADL.
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-03-29 20:53 --- *** Bug 43506 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29131
[Bug c++/43506] name lookup fails in function template
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-29 20:53 --- Yes we are inconsistent with how foundational types work with argument dependent namelookup but it is still the same issue. *** This bug has been marked as a duplicate of 29131 *** -- 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=43506
[Bug c/43587] New test failures
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-29 20:57:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43587
[Bug c/43587] New test failures
--- Comment #1 from jason at gcc dot gnu dot org 2010-03-29 20:57 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43587
[Bug middle-end/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1
--- Comment #25 from eric dot cabret at gmail dot com 2010-03-29 21:48 --- I've reported this problem to Ubuntu at this following URL : https://bugs.launchpad.net/ubuntu/+bug/551245 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43556
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #5 from tkoenig at gcc dot gnu dot org 2010-03-29 22:01 --- Created an attachment (id=20254) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20254action=view) Preprocessed source This is from ~/Gcc/trunk-bin/x86_64-unknown-linux-gnu/32/libgomp the 32 bit subdirectory -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #6 from tkoenig at gcc dot gnu dot org 2010-03-29 22:06 --- Created an attachment (id=20255) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20255action=view) Preprocessed source where the problem occurs for the first time team.c also shows the problem, this is just the source corresponding to the original error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug bootstrap/43583] [4.5 Regression] value computed not used in parallel.c:121:4
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-29 22:17 --- I just was about to bootstrap with [trunk revision 157804]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43583
[Bug target/43588] New: ICE in copy_to_mode_reg, at explow.c:635
ICE happens with 4.3, 4.4 and 4.5. ICE doesn't happen with eabi target.
$ ./xgcc -v
Using built-in specs.
Target: arm-unknown-linux-gnu
Configured with: ../configure --target=arm-unknown-linux-gnu
--prefix=/home/ryan/xtools/arm-unknown-linux-gnu
--with-headers=/home/ryan/xtools/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include
--with-local-prefix=/home/ryan/xtools/arm-unknown-linux-gnu/arm-unknown-linux-gnu
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c++ --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.5.0 20100329 (experimental) [trunk revision 157802] (GCC)
$ cat ~/ice.i
typedef unsigned int _GCC_ATTR_ALIGN_u16t __attribute__((__mode__(__HI__)));
typedef _GCC_ATTR_ALIGN_u16t _Uint16t __attribute__((__aligned__(8)));
typedef _Uint16t uint16_t;
typedef __builtin_neon_uhi uint16x4_t __attribute__ ((__vector_size__ (8)));
__extension__ static __inline uint16x4_t __attribute__ ((__always_inline__))
vdup_n_u16 (uint16_t __a) {
return (uint16x4_t)__builtin_neon_vdup_nv4hi ((__builtin_neon_hi) __a);
}
void test() {
uint16x4_t vec_test = vdup_n_u16(0);
}
$ ./xgcc -B. -mfpu=neon -mfloat-abi=softfp ~/ice.i -c
/home/ryan/ice.i: In function 'test':
/home/ryan/ice.i:6:50: internal compiler error: in copy_to_mode_reg, at
explow.c:635
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE in copy_to_mode_reg, at explow.c:635
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43588
[Bug target/43458] c99_classification_macros_c.cc fails on hppa*-*-hpux*
--- Comment #2 from danglin at gcc dot gnu dot org 2010-03-29 23:51 --- Subject: Bug 43458 Author: danglin Date: Mon Mar 29 23:51:05 2010 New Revision: 157806 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157806 Log: PR target/43458 * testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc: Xfail hppa*-*-hpux*. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43458
[Bug c++/43509] [4.5 regression] [C++0x] ICE in constructor_name_p, at cp/name-lookup.c:1809
--- Comment #4 from jason at gcc dot gnu dot org 2010-03-30 00:14 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43509
[Bug middle-end/41150] segmentation fault after using __attribute__((optimize()))
--- Comment #8 from ictlpeng at gmail dot com 2010-03-30 02:09 --- (In reply to comment #7) bug2-susan.i still exists on gcc 4.4 branch head. So reopen it. Yes, It was true that bug1-susan.i was a duplicate of PR 43562, we used the same way like you suggestion 1 to fix it temporarily. And I think your second try provided a better solution. Thank you! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41150
[Bug middle-end/41150] segmentation fault after using __attribute__((optimize()))
--- Comment #9 from ictlpeng at gmail dot com 2010-03-30 02:14 --- (In reply to comment #4) bug2-susan.i does not crash ICE on GCC SVN trunk now. Do you mean bug2-susan.i does not exist on GCC 4.5? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41150
[Bug middle-end/41150] segmentation fault after using __attribute__((optimize()))
--- Comment #10 from jiez at gcc dot gnu dot org 2010-03-30 02:41 --- (In reply to comment #9) (In reply to comment #4) bug2-susan.i does not crash ICE on GCC SVN trunk now. Do you mean bug2-susan.i does not exist on GCC 4.5? I don't see it on latest GCC 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41150
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #3 from corsepiu at gcc dot gnu dot org 2010-03-30 03:09 --- AFAICT, this bug affects all *-rtems* targets, if not _all_ targets, i.e. building target files uses host includes during bootstrap. But for some reasons I don't (yet) know, it only causes a breakdown for building some targets. So far I've encountered breakdowns for h8300-rtems* and the m32l-rtems* and know verified that building sparc-rtems* uses host-includes for building target-files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #4 from corsepiu at gcc dot gnu dot org 2010-03-30 03:22 --- ... and the m32l-rtems* ... Typo, this should have been ... m32r-rtems*... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file
--- Comment #29 from jvdelisle at gcc dot gnu dot org 2010-03-30 03:22 --- Subject: Bug 43265 Author: jvdelisle Date: Tue Mar 30 03:22:28 2010 New Revision: 157810 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157810 Log: 2010-03-29 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/43265 * io/transfer.c (next_record_r): Only call hit_eof for specific conditions when an EOF is encountered. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43265
[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2010-03-30 03:25 --- Subject: Bug 43265 Author: jvdelisle Date: Tue Mar 30 03:25:04 2010 New Revision: 157811 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157811 Log: 2010-03-29 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/43265 * gfortran.dg/read_eof_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/read_eof_8.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43265
[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file
--- Comment #31 from jvdelisle at gcc dot gnu dot org 2010-03-30 03:54 --- Subject: Bug 43265 Author: jvdelisle Date: Tue Mar 30 03:54:36 2010 New Revision: 157812 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157812 Log: 2010-03-29 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/43265 * io/transfer.c (next_record_r): Only call hit_eof for specific conditions when an EOF is encountered. Modified: branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43265
[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file
--- Comment #32 from jvdelisle at gcc dot gnu dot org 2010-03-30 03:56 --- Subject: Bug 43265 Author: jvdelisle Date: Tue Mar 30 03:56:08 2010 New Revision: 157813 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157813 Log: 2010-03-29 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/43265 * gfortran.dg/read_eof_8.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/read_eof_8.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43265
[Bug middle-end/43574] [4.5 Regression] Revision 157795 failed gcc.dg/lto/20090914-1 c_lto_20090914-1_0.o
--- Comment #2 from jiez at gcc dot gnu dot org 2010-03-30 03:56 --- I'm testing a patch. -- jiez at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jiez at gcc dot gnu dot org |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43574
[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file
--- Comment #33 from jvdelisle at gcc dot gnu dot org 2010-03-30 03:57 --- Closing one more time. Fixed on trunk and 4.4 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43265
[Bug middle-end/43589] New: segmentation fault after using __attribute__((optimize()))
A segmentation fault(ipa-cp.c ipcp_lattice_changed (old_lat=0x7bf46080, new_lat=0x0)) comes up if we: declare function Mibench automotive_susan_e susan.c:susan_edges() with __attribute__((optimize(3))) declare function Mibench automotive_susan_e susan.c:susan_edges_small() with __attribute__((optimize(1))) declare function Mibench automotive_susan_e susan.c:susan_corners_quick() with __attribute__((optimize(3))) complete command line and compiler output : $~/ici/install/bin/gcc -lm -O3 -c susan.c susan.c:2122: internal compiler error: Segmentation fault System type: Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../../../gcc-ici/branches/gcc-4.4.0-ici-2.0-adapt/configure --prefix=/home/lpeng/ici/install --with-mpfr=/home/common/tools/mpfr-2.4.1 --with-gmp=/home/common/tools/gmp-4.3.1 --with-ppl=/home/common/tools/ppl-0.10.2 --with-cloog=/home/common/tools/cloog --enable-languages=c,fortran Thread model: posix Release: gcc version 4.4.0 (GCC) -- Summary: segmentation fault after using __attribute__((optimize())) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ictlpeng at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43589
[Bug middle-end/43589] segmentation fault after using __attribute__((optimize()))
--- Comment #1 from ictlpeng at gmail dot com 2010-03-30 04:03 --- Created an attachment (id=20256) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20256action=view) Test case susan.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43589
[Bug other/43562] GCC ICE on optimize attribute
--- Comment #7 from jiez at gcc dot gnu dot org 2010-03-30 04:06 --- A new patch is here: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01375.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43562
[Bug target/43590] New: ICE in spill_failure, at reload1.c:2158
$ cat ~/ice2.i
typedef unsigned int _GCC_ATTR_ALIGN_u64t __attribute__((__mode__(__DI__)));
typedef _GCC_ATTR_ALIGN_u64t _Uint64t __attribute__((__aligned__(8)));
typedef unsigned int _GCC_ATTR_ALIGN_u8t __attribute__((__mode__(__QI__)));
typedef _GCC_ATTR_ALIGN_u8t _Uint8t __attribute__((__aligned__(1)));
typedef _Uint8t uint8_t;
typedef _Uint64t uint64_t;
typedef __builtin_neon_udi uint64x1_t;
typedef struct uint64x1x4_t { uint64x1_t val[4]; } uint64x1x4_t;
__extension__ static __inline uint64x1x4_t __attribute__ ((__always_inline__))
vld4_u64 (const uint64_t * __a) {
union { uint64x1x4_t __i; __builtin_neon_oi __o; } __rv;
__rv.__o = __builtin_neon_vld4v8hi ((const __builtin_neon_hi *) __a);
return __rv.__i;
}
void test( uint8_t * dst, uint8_t * src, unsigned nbytes) {
uint64x1x4_t tmp;
while (nbytes = 32) {
tmp = vld4_u64((uint64_t *)src);
vst4_u64((uint64_t *)dst, tmp);
}
}
$ ./xgcc -v
Using built-in specs.
Target: arm-unknown-linux-gnueabi
Configured with: ../configure --target=arm-unknown-linux-gnueabi
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi
--with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
--enable-languages=c,c++ --disable-multilib --with-float=soft
--disable-sjlj-exceptions --enable-__cxa_atexit
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspac
Thread model: posix
gcc version 4.5.0 20100329 (experimental) [trunk revision 157802] (GCC)
$ ./xgcc -B. ~/ice2.i -O3 -mfpu=neon -mfloat-abi=softfp -c
/home/ryan/ice2.i: In function 'test':
/home/ryan/ice2.i:22:1: error: unable to find a register to spill in class
'GENERAL_REGS'
/home/ryan/ice2.i:22:1: error: this is the insn:
(insn 96 10 12 3 /home/ryan/ice2.i:12 (set (reg:XI 136 [ D.3641 ])
(const_int 0 [0x0])) 732 {*neon_movxi} (expr_list:REG_EQUAL (const_int
0 [0x0])
(nil)))
/home/ryan/ice2.i:22:1: internal compiler error: in spill_failure, at
reload1.c:2158
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
On the 4.3 branch (4.3.5 20100330 (prerelease)), the same testcase has causes a
different ICE:
$ ./xgcc -B. ~/ice2.i -O3 -mfpu=neon -mfloat-abi=softfp -c
/home/ryan/ice2.i: In function 'test':
/home/ryan/ice2.i:22: internal compiler error: in record_store, at dse.c:1360
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE in spill_failure, at reload1.c:2158
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
