Re: legitimate parallel make check?
IainS develo...@sandoe-acoustics.co.uk writes: that's really neat indeed - I should have spotted the potential looking at the code in contrib ... although the site.exp is hardwired in btest.sh at present ; I guess one might be able to use .dejagnurc - just need to check on the order that the files are processed. Far easier: just set the DEJAGNU environment variable to the absolute path to the size.exp file. runtest knows about that. hmm. I see that the make check would work using that neat method above... ... however, 1/ I want a different language list than the default... 2/ also some other different configure options... I've got some local patches for btest-gcc.sh which allow just that (e.g. support for Ada testing), which I'll submit once I'm reasonably confident they are general enough. but mainly 3/ ... As I read it - btest.sh strips everything but the testname from the PASSES and FAILS files. (the awk lines that print $2 for a match of /FAIL: / etc.) This means (e.g.) that if a test passes at m32 and fails at m64 I think it will appear in both PASSES and FAILS.. ... this seems destined to result in confusion... You can still use make mail-report.log in the build subdir to get the complete summary; besides, there's still contrib/dg-cmp-results.sh (which I haven't checked out yet). Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: legitimate parallel make check?
On 10 Mar 2010, at 09:12, Rainer Orth wrote: IainS develo...@sandoe-acoustics.co.uk writes: that's really neat indeed - I should have spotted the potential looking at the code in contrib ... although the site.exp is hardwired in btest.sh at present ; I guess one might be able to use .dejagnurc - just need to check on the order that the files are processed. Far easier: just set the DEJAGNU environment variable to the absolute path to the size.exp file. runtest knows about that. the DEJAGNU env. var is set in btest.sh hmm. I see that the make check would work using that neat method above... ... however, 1/ I want a different language list than the default... 2/ also some other different configure options... I've got some local patches for btest-gcc.sh which allow just that (e.g. support for Ada testing), which I'll submit once I'm reasonably confident they are general enough. OK - (but I'm happy that my local mods for this are also working). but mainly 3/ ... As I read it - btest.sh strips everything but the testname from the PASSES and FAILS files. (the awk lines that print $2 for a match of /FAIL: / etc.) This means (e.g.) that if a test passes at m32 and fails at m64 I think it will appear in both PASSES and FAILS.. ... this seems destined to result in confusion... You can still use make mail-report.log in the build subdir to get the complete summary; besides, there's still contrib/dg-cmp-results.sh (which I haven't checked out yet). contrib/compare_tests is good (I was thinking to merge the capability of that with the capability of btest.sh) meetings today... so until later I can't find a hardware fault -- but I'm exploring a hunch about a FBKAC Iain
Re: legitimate parallel make check?
On 10 Mar 2010, at 09:22, IainS wrote: Far easier: just set the DEJAGNU environment variable to the absolute path to the size.exp file. runtest knows about that. the DEJAGNU env. var is set in btest.sh my mistake. duh - that's what comes of working with code that was forked a long time ago .. .. it isn't set in the current version.. Iain
Re: legitimate parallel make check?
IainS develo...@sandoe-acoustics.co.uk writes: Far easier: just set the DEJAGNU environment variable to the absolute path to the size.exp file. runtest knows about that. the DEJAGNU env. var is set in btest.sh It's not: $ grep DEJAGNU contrib/regression/btest-gcc.sh # DEJAGNU: should point to a site.exp suitable for testing I've got some local patches for btest-gcc.sh which allow just that (e.g. support for Ada testing), which I'll submit once I'm reasonably confident they are general enough. OK - (but I'm happy that my local mods for this are also working). Without doubt, but why should everyone trying to use this have to reinvent the wheel? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Use the wctype builtins functions
On 03/06/2010 12:03 AM, Joseph S. Myers wrote: On Fri, 5 Mar 2010, Ian Lance Taylor wrote: Dave Korn dave.korn.cyg...@googlemail.com writes: I think you'll probably have to use plain old iswalpha. Looking at opts.c, I'm guessing you're trying to extend the help string format to allow unicode? Note that it may be OK to use iswalpha strictly on command line options, but using it anywhere else gets you into a set of issues around -finput-charset and -fexec-charset. The present issue is help text, as produced by gettext (which produces output in the locale's LC_CTYPE, calling iconv internally as needed). See my discussion at http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01074.html of the issues with line breaking given a string of multibyte characters, whose display width may also vary. I don't know if there's an existing free software implementation of UAX#14 (Unicode Line Breaking Algorithm) suitable for use in GCC; that would be the very heavyweight approach. I also don't know if that algorithm would actually work well for the peculiarities of option help strings, not having studied the details of it. Hence the suggestion that the existing algorithm in opts.c could be reworked to check for L'-', L'/', L' ' and use iswalpha. Thank you all to that replied. I finally include wctype.h on intl.c and use isw* strictly to handle the wide-character help string. The updated patch for the issue that Joseph mentioned is at http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00364.html. Any advices will be appreciated. Thanks Pearly
Re: Incorrect casting?
2010/3/9 Marcin Baczyński marb...@gmail.com:
Hi,
the following piece of code produces different output on svn trunk and
gcc-4_4-branch:
#include stdio.h
int main()
{
struct { unsigned bar:1; } foo;
foo.bar = 0x1;
printf(%08x\n, (unsigned char)(foo.bar * 0xfe));
printf(%08x\n, (unsigned char)(foo.bar * 0xff));
return 0;
}
monst...@yggdrasil /data/tmp $ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --enable-stage1-languages-c
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.4 20100309 (prerelease) (GCC)
monst...@yggdrasil /data/tmp $ ./a.out
00fe
0001
monst...@yggdrasil /data/tmp $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --enable-stage1-languages-c
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100309 (experimental) (GCC)
monst...@yggdrasil /data/tmp $ ./a.out
00fe
00ff
Is there something illegal in this code or is it a bug somewhere?
Probably something that was fixed for 4.5 but not backported to 4.4.
The 4.4 C frontend produces for the 2nd printf:
printf ((const char * restrict) %08x\n, (int) -foo.bar);
while 4.5 does
printf ((const char * restrict) %08x\n, (int) -(unsigned char) foo.bar);
I'm not sure where this difference comes from (and I can't convince
myself that this is a real fix). Please file a bugreport.
Btw, 4.3 produced
printf ((const char * restrict) (char *) %08x\n, (int) (unsigned
char) ((int) foo.bar * 255));
and the same runtime result as 4.5.
Thanks,
Richard.
Thanks,
Marcin
Compiling OpenCV 2.0 on Solaris 10 with GCC 4.4.3
Hello,
I'm having some problem with compiling OpenCV code on Solaris SPARC with GCC
4.4.3, I don't know whether it is an OpenCV bug (I have posted on their mailing
list too) or a gcc bug. I was hoping someone may be able to shed some light on
the error and provide some ideas on what I could look at to try and resolve it.
Basically I'm getting the following error:
[ 54%] Building CXX object src/cxcore/CMakeFiles/cxcore.dir/cxmatmul.o
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:673: error: expected ',' or '...'
before numeric constant
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp: In function 'void cv::gemm(const
cv::Mat, const cv::Mat)':
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:682: error: conversion from 'int' to
'cv::Mat' is ambiguous
/tmp/OpenCV-2.0.0/include/opencv/cxcore.hpp:732: note: candidates are:
cv::Mat::Mat(const IplImage*, bool) near match
/tmp/OpenCV-2.0.0/include/opencv/cxmat.hpp:194: note:
cv::Mat::Mat(const CvMat*, bool) near match
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:683: error: request for member 'data'
in '32', which is of non-class type 'int'
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:683: error: 'beta' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:683: error: lvalue required as unary
'' operand
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:689: error: 'flags' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:715: error: 'flags' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:718: error: 'flags' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:718: error: 'D' was not declared in
this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:725: error: 'D' was not declared in
this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:727: error: 'flags' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:752: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:769: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:784: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:804: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:821: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:845: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:879: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:896: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:911: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:931: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:948: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:972: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:1028: error: 'flags' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:1102: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:1102: error: 'flags' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:1106: error: 'flags' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:1233: error: 'alpha' was not declared
in this scope
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:1240: error: 'alpha' was not declared
in this scope
make[2]: *** [src/cxcore/CMakeFiles/cxcore.dir/cxmatmul.o] Error 1
make[1]: *** [src/cxcore/CMakeFiles/cxcore.dir/all] Error 2
make: *** [all] Error 2
The first syntax error the compiler complains about I think is the main problem:
/tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:673: error: expected ',' or '...'
before numeric constant
However, when I look at the line of code it's complaining about I can see
absolutely nothing wrong with it:
...
664 static void GEMMStore_64fc( const Complexd* c_data, size_t c_step,
665const Complexd* d_buf, size_t d_buf_step,
666Complexd* d_data, size_t d_step, Size d_size,
667double alpha, double beta, int flags )
668 {
669 GEMMStore(c_data, c_step, d_buf, d_buf_step, d_data, d_step,
d_size, alpha, beta, flags);
670 }
671
672
673 void gemm( const Mat _A, const Mat _B double alpha,
674 const Mat _C, double beta, Mat D, int flags )
675 {
676 const int block_lin_size = 128;
677 const int block_size = block_lin_size * block_lin_size;
678
679 static double zero[] = {0,0,0,0};
680 static float zerof[] = {0,0,0,0};
...
What could possibly be causing this error??
Environment configuration
=
SunOS ignatius 5.10 Generic_142900-03 sun4u sparc SUNW,Sun-Fire-V440
GCC 4.4.3
GNU Make 3.80
Re: Compiling OpenCV 2.0 on Solaris 10 with GCC 4.4.3
On Wed, Mar 10, 2010 at 01:30:36PM +, Nick Fielding wrote: The first syntax error the compiler complains about I think is the main problem: /tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:673: error: expected ',' or '...' before numeric constant However, when I look at the line of code it's complaining about I can see absolutely nothing wrong with it: ... 673 void gemm( const Mat _A, const Mat _B double alpha, ^ Looks like a missing comma. -Nathan
Advancing SP on a call
We have a problem with arguments passing in memory. The caller puts the arguments in memory relative to the sp: add sp, 4 // allocate space for the argument. stack grows up store r1, (sp-4) // store the argument on the stack call xxx// call the function. In xxx the result code looks like: load (sp-4), r1 // load the argument from the stack. The problem is that the 'call' instruction pushes the return address to the stack and increments the sp by 4 so when the callee tries to access the memory it does not get to the correct location. How can I tell GCC that that the callee should load from the original offset + 4? Thanks.
ICE with nontype template parameter
Hi,
this code
---
template typename _T
struct A
{
template int _N, int _M
struct B;
template int _N
struct B_N, _T::m
{
static void f();
};
};
struct C
{
static const int m = 4;
};
void m()
{
AC::B1, 4::f();
}
--
causes the following ICE as of 4.2
[g++ 4.4]
test.cc: In function ‘void m()’:
test.cc:22: internal compiler error: in unify, at cp/pt.c:14081
g++ 4.1 yields this error, instead
[g++ 4.1]
test.cc: In function ‘void m()’:
test.cc:22: error: incomplete type ‘AC::B1, 4’ used in nested name specifier
This code seems fine to me (and so seems to intel, xlc++ and comeau online) so
I assume it is some issue in g++.
Is this a known bug or I should fill a PR?
(It seems that GCC's bugzilla has some issues at the moment of writing this
message)
Kind regards,
--
Roger Ferrer Ibáñez - roger.fer...@bsc.es
Re: Advancing SP on a call
On 03/10/2010 09:02 AM, Frank Isamov wrote: How can I tell GCC that that the callee should load from the original offset + 4? You'll want to set FIRST_PARM_OFFSET and INCOMING_FRAME_SP_OFFSET. r~
Re: legitimate parallel make check?
FWIW; the bus errors were consistently coming from expect in a strcpy [about 100 tcl levels down] the actual fault was a corrupted dejagnu installation - it's not clear how that happened - nothing present in syslogs to indicate disk problems. a clean install of dejagnu appears to have cleared the problem. On 10 Mar 2010, at 09:47, Rainer Orth wrote: IainS develo...@sandoe-acoustics.co.uk writes: I've got some local patches for btest-gcc.sh which allow just that (e.g. support for Ada testing), which I'll submit once I'm reasonably confident they are general enough. OK - (but I'm happy that my local mods for this are also working). Without doubt, but why should everyone trying to use this have to reinvent the wheel? indeed, I have every intention of sharing my changes too (at least those that are of any merit). thanks for the help, and apologies that it was noise in the end... Iain
test listarch
Hi - This is a test for gcc.gnu.org's listarch for this mailing list, which has interrupted. - FChE
Does gengtyped gt-*.h depends upon the configuration of the compiler?
Hello All,
Sylvestre Ledru is very nicely trying to package MELT as a packaged
debian plugin for GCC 4.5 - MELT can be compiled either as an entire GCC
branch, or as a GCC 4.5 -i.e. trunk- plugin.
However, we seems to have found some difficult issue. As Diego added
into the documentation:
http://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins
Plugins needing to use gengtype require a GCC build directory for the
same version of GCC that they will be linked against.
The MELT plugin uses PLUGIN_REGISTER_GGC_ROOTS et PLUGIN_GGC_MARKING
So it needs to run gengtype to generate the GGC roots table specific to
MELT. MELT also have its own GTY-ed struct in melt-runtime.h some
GTY-ed roots in melt-runtime.c
MELT only need gengtype to generate its gt-melt-runtime.h but I have no
idea if that file depends upon the configuration (and notably the target
for which GCC is built). The GTY-ed data of MELT does not depend (IMHO)
upon the configuration directly (in the sense that there is no #ifdef
around GTY-ed struct), but of course it points to data like Gimple or
Tree which I imagine depend upon the configuration of GCC (notably
--enable-check but perhaps also the target ...)
In other words, would a gt-melt-runtime.h generated on
Debian/Linux/AMD64 would be ok for a Debian/Linux/x86 or
Debian/Linux/ARM? I blindly guess that probably not, but I am not sure.
Apparently, the constraint that gengtype requires availability of both
the source the build trees of the GCC for which the plugin is built is
quite unnatural (but of course I understand why it is needed) and could
be perhaps incompatible with the way many Linux distributions (including
Debian) are naturally packaging GCC.
Comments are welcome.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: ICE with nontype template parameter
On Wed, Mar 10, 2010 at 07:04:20PM +0100, Roger Ferrer Ibáñez wrote: Is this a known bug or I should fill a PR? I see that you have just filed a PR for this at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43327 Thanks. Dodji
constant hoisting out of loops
I am porting gcc 4.3.2 to my own micro-controller.
For below piece of code, the instruction clr.w a15 obviously doesn't
belong to the inner loop. Compiler should be smart enough to move it
to the beginning of the function.
How I can hoist the constant out of loops?
Maybe the costs functions have to be changed, but I don't know how.
Thanks.
C code:
void memzero_aligned(uint* ptr, uint size)
{
uint ptr_end = (uint)ptr + size;
while ((uint)ptr ptr_end)
{
*ptr++ = 0;
}
}
Disassembly code:
_memzero_aligned:
0: bc ab 90 add.w a9 a10 a11;
3: f4 0e 0bbra 0xe; #branch unconditionally, no delay slot
6: bd f4clr.w a15; #clear to zero
8: 80 af 00std.w a10 0x0 a15;
b: 90 aa 04 add.w a10 a10 0x4;
e: b8 a9 06 cmp.w a10 a9;
11: f4 08 f5brc 0x6;
14: f8 00ret;
--
-Qifei Fan
http://freshtime.org
Re: Does gengtyped gt-*.h depends upon the configuration of the compiler?
Basile Starynkevitch wrote:
In other words, would a gt-melt-runtime.h generated on
Debian/Linux/AMD64 would be ok for a Debian/Linux/x86 or
Debian/Linux/ARM? I blindly guess that probably not, but I am not sure.
Apparently, the constraint that gengtype requires availability of both
the source the build trees of the GCC for which the plugin is built is
quite unnatural (but of course I understand why it is needed) and could
be perhaps incompatible with the way many Linux distributions (including
Debian) are naturally packaging GCC.
I also have sent to the Debian GCC team an email
http://lists.debian.org/debian-gcc/2010/03/msg00047.html describing my
views and issues.
Perhaps should I send the same emails to both gcc@ debian-gcc@ ? Is it
appropriate?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
[Bug java/42143] [4.3/4.4/4.5 Regression] gcj creates dummy variables
--- Comment #4 from michele at focuseek dot com 2010-03-10 08:05 --- Yesterday I filed the suspiciously similar bug 42143 with a really simple test case that fails on gcc 4.4.3 and used to work with gcc 4.2.2. As I wrote in the description for that bug I suspect it's actually a duplicate of this bug but I can't confirm it easily as I don't have binutils sources at hand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143
[Bug debug/43290] ICE in dwarf2out_frame_debug_expr
--- Comment #18 from jakub at gcc dot gnu dot org 2010-03-10 08:07 --- Created an attachment (id=20073) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20073action=view) gcc45-pr43290.patch Updated patch. This one includes testcases, and also fixes for -O+, when optimizing we really shouldn't be replacing random registers that once happened to be vDRAP or DRAP somewhere with DW_OP_fbreg and there is no point tracking it at all - after all when optimizing combiner or some other optimization pass will very likely remove the vDRAP = DRAP insn anyway. For -O1+ var-tracking is supposed to do the right job finding where the variable lives. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #20072|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43290
[Bug java/42143] [4.3/4.4/4.5 Regression] gcj creates dummy variables
--- Comment #5 from michele at focuseek dot com 2010-03-10 08:09 --- (In reply to comment #4) [...] suspiciously similar bug 42143 [...] I meant bug 43302... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143
[Bug java/43302] [Regression] gcc creates dummy resources in object files
--- Comment #2 from michele at focuseek dot com 2010-03-10 08:30 --- Experimenting with -save-temps I noticed that the .dummy resource is in the .jar generated by ecj which seems to point to it as the main suspect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43302
[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)
--- Comment #10 from pault at gcc dot gnu dot org 2010-03-10 09:29 --- In preparing a testcase, I foolishly decided to check the original for correct execution. The following gives the wrong result: module m1 type :: t1 contains procedure :: sizeof end type contains integer function sizeof(a) class(t1) :: a sizeof = 1 end function sizeof end module module m2 use m1 type, extends(t1) :: t2 contains procedure :: sizeof = sizeof2 end type contains integer function sizeof2(a) class(t2) :: a sizeof2 = 2 end function end module module m3 use m2 type :: t3 class(t1), pointer :: a contains procedure :: sizeof = sizeof3 end type contains integer function sizeof3(a) class(t3) :: a sizeof3 = a%a%sizeof() end function end module use m1 use m2 use m3 class(t1), pointer :: a, ptr type(t1), target :: x type(t2), target :: y type(t3) :: z a = x print *, a%sizeof() a = y print *, a%sizeof() z%a = x print *, z%sizeof(), z%a%sizeof() z%a = y print *, z%sizeof(), z%a%sizeof() end gives 1 2 1 1 2 1 The last line should read 2 2 of course. The logic in calling resolve_class_compcall is wrong. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43291
[Bug c++/43315] Variadic Templates affects the overload resolution rank
--- Comment #2 from redi at gcc dot gnu dot org 2010-03-10 10:14 --- In the latest draft (n3035) [temp.deduct.type] 14.9.2.5 paragraph 22 has an example of a case where a non-variadic template is more specialized than variadic templates. I'm not entirely sure if that's relevant though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43315
[Bug tree-optimization/43317] [4.5 Regression] ICE: Segmentation fault with -fipa-struct-reorg -g
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43317
[Bug c++/43313] ICE with non-POD and covariant return thunks
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-10 10:49 --- Works for me on x86_64 and i?86 with various GCC versions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43313
[Bug target/32951] missed memcpy - movdqa optimization.
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-10 10:52 --- (In reply to comment #7) current 4.4.x generates 'movdqa (%rdi), %xmm0' in both cases. 4.2 branch is closed, 4.3 is near to close. can we close this bug as fixed? GCC 4.4 creates movdqu (%rdi), %xmm0 for load_2 for me, so no (same as 4.5). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.3 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32951
[Bug target/32951] missed memcpy - movdqa optimization.
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-03-10 10:54 --- Actually it does with the fixed aligned attribute. Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.4.3 4.5.0 | Known to work||4.4.3 4.5.0 Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32951
[Bug target/43311] missed 'movw' optimization.
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-10 10:55 --- Confirmed. -- 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 |2010-03-10 10:55:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43311
[Bug middle-end/42859] [4.5 regression] ICE in verify_flow_info
--- Comment #10 from abel at gcc dot gnu dot org 2010-03-10 11:09 --- Subject: Bug 42859 Author: abel Date: Wed Mar 10 11:08:48 2010 New Revision: 157337 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157337 Log: PR middle-end/42859 * tree-eh.c: Include pointer-set.h. (lower_eh_dispatch): Filter out duplicate case labels and remove the unneeded edge when the label is unused. Return true when some edges are removed. (execute_lower_eh_dispatch): When any lowering resulted in removing an edge, also delete unreachable blocks. * g++.dg/eh/pr42859.C: New test. Added: trunk/gcc/testsuite/g++.dg/eh/pr42859.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-eh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
[Bug middle-end/42859] [4.5 regression] ICE in verify_flow_info
--- Comment #11 from abel at gcc dot gnu dot org 2010-03-10 11:09 --- Fixed. -- abel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
[Bug c/43319] Lack of documentation on asm extension
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-03-10 11:17 --- Machine-independent templates are described in gccint.info, in the Output Templates and Operand Substitution section. Online documentation is here: http://gcc.gnu.org/onlinedocs/gccint/Output-Template.html. See also: http://gcc.gnu.org/viewcvs/trunk/gcc/final.c?revision=157325view=markup#l3194. But it seems that x86-specific templates are not documented; see description of them in the sources: http://gcc.gnu.org/viewcvs/trunk/gcc/config/i386/i386.c?revision=157325view=markup#l11384. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43319
[Bug fortran/43320] New: [4.5 Regression] 200.sixtrack fails setup
--- Running 200.sixtrack ref base default-linux default Commands to run: -u /gcc/spec/cpu2000/benchspec/CFP2000/200.sixtrack/run/0003 -i inp.in -o inp.out -e inp.err ../0003/sixtrack_base.default-linux Specinvoke: /gcc/spec/cpu2000/bin/specinvoke -d /gcc/spec/cpu2000/benchspec/CFP2000/200.sixtrack/run/0003 -e speccmds.err -o speccmds.out -f speccmds.cmd user 0 finished @ Wed Mar 10 02:39:46 2010. Total elapsed time: 0.416101 comparing files in '/gcc/spec/cpu2000/benchspec/CFP2000/200.sixtrack/run/0003' comparing 'inp.out' with cw='', abstol='0.0005', reltol='0.0005',obiwan='',skiptol='' Specinvoke: /gcc/spec/cpu2000/bin/specinvoke -E -d /gcc/spec/cpu2000/benchspec/CFP2000/200.sixtrack/run/0003 -c 1 -e compare.err -o compare.out -f compare.cmd *** Miscompare of inp.out, see /gcc/spec/cpu2000/benchspec/CFP2000/200.sixtrack/run/0003/inp.out.mis 1904: From file fort.8 : 0 values read in. ^ 1905: --- +ERROR DETECTED+ ^ 1906:*** RING PARAMETERS *** ^ 1907: SINGLE ELEMENTS: RUN TERMINATED ABNORMALLY !!! ^ 1910:NO NAME TYP 1/RHO STRENGTH LENGTH X-POS X-RMSZ-PO Z-RMS PROBLEM READING EXTERNAL MISALIGNMENTS ^ 'inp.out' short -- Summary: [4.5 Regression] 200.sixtrack fails setup Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: x86-64-*-*, ia64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-10 12:35 --- Last known good rev. 157294, first known bad rev. 157328 (x86_64). Last known good rev. 157304, first known bad rev. 157331 (ia64). Points at: Index: libgfortran/ChangeLog === --- libgfortran/ChangeLog (revision 157304) +++ libgfortran/ChangeLog (revision 157328) @@ -1,3 +1,14 @@ +2010-03-09 Jerry DeLisle jvdeli...@gcc.gnu.org + + PR libfortran/43265 + * io/read.c: Include fbuf.h and unix.h to enable lower level I/O for + read_x. (read_x): Replace the use of read_sf with equivalent lower level + I/O, eliminating unneeded code and handling EOF and EOR conditions. + * io/io.h: Revise prototype for read_sf. + * io/transfer.c (read_sf): Delete no_error parameter and all uses of it. + (read_block_form): Likewise. + (next_record_r): Delete wrong code call to hit_eof. + -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org Component|fortran |libfortran Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup
--- Comment #2 from burnus at gcc dot gnu dot org 2010-03-10 12:40 --- Richard, how new is this regression? That is: Which check-ins could have causes this? Assuming that CPU SPEC is run every day, I assume that it is the patch for PR 43265; namely commit http://gcc.gnu.org/viewcvs?root=gccview=revrev=157310 Can you confirm this? If so, it must be some issue related to reading a file. Thus, the line of the input file which fails and the corresponding format of the READ statement are of interest. Paul, I think you are the only gfortraner, which has access to SPEC CPU 2000. Can you have a look? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file
--- Comment #15 from burnus at gcc dot gnu dot org 2010-03-10 12:42 --- This patch causes a regression in SPEC CPU 2000 (200.sixtrack), see PR 43320. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43265
[Bug tree-optimization/43236] -ftree-loop-distribution produces wrong code in reload1.c:delete_output_reload(), bootstrap fails
--- Comment #9 from amonakov at gcc dot gnu dot org 2010-03-10 12:54 --- Subject: Bug 43236 Author: amonakov Date: Wed Mar 10 12:53:51 2010 New Revision: 157339 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157339 Log: PR tree-optimization/43236 * tree-loop-distribution.c (generate_memset_zero): Fix off-by-one error in calculation of base address in reverse iteration case. (generate_builtin): Take number of latch executions if the statement is in the latch. * gcc.c-torture/execute/pr43236.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr43236.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-loop-distribution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43236
[Bug tree-optimization/43236] -ftree-loop-distribution produces wrong code in reload1.c:delete_output_reload(), bootstrap fails
--- Comment #10 from amonakov at gcc dot gnu dot org 2010-03-10 12:57 --- Both issues are fixed with above commit. -- amonakov at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43236
[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup
--- Comment #3 from paul dot richard dot thomas at gmail dot com 2010-03-10 13:20 --- Subject: Re: [4.5 Regression] 200.sixtrack fails setup Dear All, Paul, I think you are the only gfortraner, which has access to SPEC CPU 2000. Can you have a look? I am still recuperating from the operation in the UK. I do not have SPEC on the laptop that I have with me. I´ll be back in Barcelona on Sunday night, however, and could look at it sometime next week. Sorry Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup
-- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-10 14:01:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
[Bug tree-optimization/43236] -ftree-loop-distribution produces wrong code in reload1.c:delete_output_reload(), bootstrap fails
--- Comment #11 from sezeroz at gmail dot com 2010-03-10 14:17 --- The testcase fails with 4.4 with -Ox -ftree-loop-distribution and the patch does not apply to 4.4. Will there be a gcc-4.4 backport of this? -- sezeroz at gmail dot com changed: What|Removed |Added CC||sezeroz at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43236
[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-10 14:31 --- The SixTrack souce code can be found at http://lhc-collimation-project.web.cern.ch/lhc-collimation-project/code-tracking.htm Namely: http://lhc-collimation-project.web.cern.ch/lhc-collimation-project/SixPack.zip Regarding 1904: From file fort.8 : 0 values read in. That matches the file: sixve.f: open(8,file='fort.8',form='formatted',status='unknown') And I see two reads for sixve.f (in subroutine daten): read(8,10020,end=1581) read(8,10020,end=1550,iostat=ierro) ch which seemingly uses: 10020 format(a80) which looks harmless. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup
--- Comment #5 from burnus at gcc dot gnu dot org 2010-03-10 14:39 --- Reproduce using: 1. Grab SixTrack.zip (see comment 4) 2. Change in track.f, line 4411 in (i,1x,... the i into an i0 3. Grab the input file http://lhc-collimation-project.web.cern.ch/lhc-collimation-project/InjPack.zip and unzip in the same directory 4. Compile by running: gfortran *.f a) Run with the trunk's libgfortran. The result will be: Multipole errors read in from external file [...] +ERROR DETECTED+ RUN TERMINATED ABNORMALLY !!! b) Run with an older libgfortran, e.g. the one from GCC 4.4. Result is [...] Multipole errors read in from external file From file fort.16 : 0 values read in. Alignment errors read in from external file From file fort.8 : 0 values read in. [...] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
[Bug rtl-optimization/43286] Missed related value optimization in cse.c
--- Comment #3 from ramana at gcc dot gnu dot org 2010-03-10 14:49 --- Confirmed but do we expect this to be done in CSE . IIUC, shouldn't this be a part of fwprop handling addresses rather than doing this in CSE ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-10 14:49:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43286
[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup
--- Comment #6 from burnus at gcc dot gnu dot org 2010-03-10 14:52 --- Reduced test case: Reading from a completely empty line should produce an EOF status. As soon as there is a \n or or 0, ifort, NAG f95 and gfortran 4.3/4.5 also succeed (i.e. have no EOF error.) That's kind of the opposite to the remaining problem of PR 43265, where reading from an incomplete but non-empty line produces an error while it shouldn't. open(8,status='scratch',form='formatted') ! Create empty file read(8,'(a80)', end=123) ! Reading from an empty file should be an error stop 'error' 123 continue end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
[Bug c++/43321] New: [c++0x] ICE on valid auto
I hope it's a valid auto. the code works if I write int instead of auto.
It might be related to Bug 43281
internal compiler error: in type_unification_real, at cp/pt.c:13486
template typename T
void shuffle(const T first, const T last)
{
auto w = *first;
}
int main()
{
int b[5];
shuffle(b[0],b[4]);
}
g++-4.5 -v
Using built-in specs.
COLLECT_GCC=g++-4.5
COLLECT_LTO_WRAPPER=/home/rakadam/streamplusplus/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --program-suffix=-4.5
--prefix=/home/rakadam/streamplusplus/src/third_party/gcc-trunk/build_gcc/../../../../local
--enable-lto --disable-bootstrap --enable-gold
Thread model: posix
gcc version 4.5.0 20100306 (experimental) (GCC)
--
Summary: [c++0x] ICE on valid auto
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam dot rak at streamnovation dot com
GCC build triplet: x86_64-unknown-linux
GCC host triplet: x86_64-unknown-linux
GCC target triplet: x86_64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43321
[Bug fortran/43322] New: compiling under Matlab with gfortran
Mac gcc -v Using built-in specs. Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5646) (dot 1) --- Under Matlab 7.9.0.529 (R2009b) mex -v prueba.f - mexopts.sh sourced from directory (DIR = $HOME/.matlab/$REL_VERSION) FILE = /Users/balbin/.matlab/R2009b/mexopts.sh -MATLAB= /Applications/MATLAB_R2009b.app -CC= gcc-4.0 -CC flags: CFLAGS = -fno-common -no-cpp-precomp -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -fexceptions CDEBUGFLAGS= -g COPTIMFLAGS= -O2 -DNDEBUG CLIBS = -L/Applications/MATLAB_R2009b.app/bin/maci64 -lmx -lmex -lmat -lstdc++ arguments = -DMX_COMPAT_32 -CXX = g++-4.0 -CXX flags: CXXFLAGS = -fno-common -no-cpp-precomp -fexceptions -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 CXXDEBUGFLAGS = -g CXXOPTIMFLAGS = -O2 -DNDEBUG CXXLIBS= -L/Applications/MATLAB_R2009b.app/bin/maci64 -lmx -lmex -lmat -lstdc++ arguments = -DMX_COMPAT_32 -FC= gfortran -FC flags: FFLAGS = -fexceptions -m64 -fbackslash FDEBUGFLAGS= -g FOPTIMFLAGS= -O FLIBS = -L/Applications/MATLAB_R2009b.app/bin/maci64 -lmx -lmex -lmat -L/usr/local/lib/gcc/x86_64-apple-darwin10.2.0/4.5.0/../../.. -lgfortran -L/usr/local/lib/gcc/x86_64-apple-darwin10.2.0/4.5.0 -lgfortranbegin arguments = -DMX_COMPAT_32 -LD= gcc-4.0 -Link flags: LDFLAGS= -Wl,-twolevel_namespace -undefined error -arch x86_64 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -bundle -Wl,-exported_symbols_list,/Applications/MATLAB_R2009b.app/extern/lib/maci64/fexport.map LDDEBUGFLAGS = -g LDOPTIMFLAGS = -O LDEXTENSION= .mexmaci64 arguments = -LDCXX = -Link flags: LDCXXFLAGS = LDCXXDEBUGFLAGS= LDCXXOPTIMFLAGS= LDCXXEXTENSION = arguments = - gfortran -c -I/Applications/MATLAB_R2009b.app/extern/include -I/Applications/MATLAB_R2009b.app/simulink/include -fexceptions -m64 -fbackslash -DMX_COMPAT_32 -O prueba.f dyld: Library not loaded: /usr/local/lib/libmpfr.1.dylib Referenced from: /usr/local/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/f951 Reason: Incompatible library version: f951 requires version 4.0.0 or later, but libmpfr.1.dylib provides version 3.0.0 gfortran: Internal error: Trace/BPT trap (program f951) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. mex: compile of ' prueba.f' failed. ??? Error using == mex at 221 Unable to complete successfully. -- under darwin it works: Mac gfortran -v prueba.f Driving: gfortran -mmacosx-version-min=10.6.2 -v prueba.f -lgfortran -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/lto-wrapper Target: x86_64-apple-darwin10.2.0 Configured with: /Developer/instaladores/gcc/configure --enable-languages=c,fortran Thread model: posix gcc version 4.5.0 20100309 (experimental) (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-shared-libgcc' '-mtune=generic' /usr/local/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/f951 prueba.f -ffixed-form -fPIC -quiet -dumpbase prueba.f -mmacosx-version-min=10.6.2 -mtune=generic -auxbase prueba -version -fintrinsic-modules-path /usr/local/lib/gcc/x86_64-apple-darwin10.2.0/4.5.0/finclude -o /var/folders/vo/vocAT36r2RWNJU+1YwQ30TM/-Tmp-//ccQKwi14.s GNU Fortran (GCC) version 4.5.0 20100309 (experimental) (x86_64-apple-darwin10.2.0) compiled by GNU C version 4.5.0 20100309 (experimental), GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.5.0 20100309 (experimental) (x86_64-apple-darwin10.2.0) compiled by GNU C version 4.5.0 20100309 (experimental), GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
[Bug middle-end/43323] New: Wrong code with bitfields and type casting.
When compiled with gcc 4.4.[34] The following code prints fe 01, while it
should fe ff. Current svn trunk produces correct results.
No flags needed to reproduce.
extern int printf(const char * __restrict, ...);
int main()
{
struct { unsigned bar:1; } foo;
foo.bar = 0x1;
printf(%02x\n, (unsigned char)(foo.bar * 0xfe));
printf(%02x\n, (unsigned char)(foo.bar * 0xff));
return 0;
}
gcc -v:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --enable-stage1-languages-c
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.4 20100309 (prerelease) (GCC)
--
Summary: Wrong code with bitfields and type casting.
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marbacz at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43323
[Bug c/43288] [4.5 Regression] ICE in function_and_variable_visibility, at ipa.c:415
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-03-10 15:40 --- Patch posted -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-03-08 11:58:39 |2010-03-10 15:40:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43288
[Bug c++/43321] [c++0x] ICE on valid auto
--- Comment #1 from jason at gcc dot gnu dot org 2010-03-10 15:43 --- Yes, that's valid. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-10 15:43:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43321
[Bug fortran/43322] compiling under Matlab with gfortran
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-03-10 15:52 --- dyld: Library not loaded: /usr/local/lib/libmpfr.1.dylib Referenced from: /usr/local/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/f951 Reason: Incompatible library version: f951 requires version 4.0.0 or later, but libmpfr.1.dylib provides version 3.0.0 And what's so difficult about this? Update mpfr and go?! Besides, you seem to mix 3 versions, 4.0, 4.2.1 and 4.5.0 - get yourself sorted. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43322
[Bug middle-end/43323] [4.4 Regression] Wrong code with bitfields and type casting.
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-10 15:55 ---
Confirmed.
extern void abort (void);
int main()
{
struct { unsigned bar:1; } foo;
foo.bar = 0x1;
if ((unsigned char)(foo.bar * 0xfe) != 0xfeu)
abort ();
if ((unsigned char)(foo.bar * 0xff) != 0xffu)
abort ();
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Known to fail||4.4.0 4.4.3
Known to work||4.3.4 4.5.0
Last reconfirmed|-00-00 00:00:00 |2010-03-10 15:55:16
date||
Summary|Wrong code with bitfields |[4.4 Regression] Wrong code
|and type casting. |with bitfields and type
||casting.
Target Milestone|--- |4.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43323
[Bug fortran/43310] -pedantic errors on valid code involving PARAMETERs initialized to intrinsic function result
--- Comment #6 from giese025 at umn dot edu 2010-03-10 16:07 --- (In reply to comment #5) (In reply to comment #4) Not all valid FORTRAN 95 programs will compile properly when using this option. If you want to ensure compliance with one of the FORTRAN standards, please see the -std= option. The problem is that your program does not conform to the Fortran 95 standard. It compiles without error nor warning with gfortran -std=f95 -Wall bar.f90 I'm not trying to sound argumentative here but you can't have it both ways... so are you saying that this is really a problem with -std, as opposed to -pedantic? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310
[Bug target/42427] [4.5 Regression] invalid assembly code for 301.apsi for -fnon-call-exceptions
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-10 16:19 --- Downgrading to P2. Target maintainers think this is not a serious bug and are happy with not fixing it for 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42427
[Bug rtl-optimization/40761] [4.4/4.5 Regression] IRA memory hog for insanely nested loops
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
[Bug rtl-optimization/43286] Missed related value optimization in cse.c
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-10 16:21 --- Another arm_arm_address_cost problem, dup of something I'm not even going to try to find. Until ARM or an ARM maintainer cares (or Google folks stop filing and start fixing bugs), we don't need more reports of the same problem -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43286
[Bug c++/41786] [4.4/4.5 regression] misparsing an object declaration - parameter may not have variably modified type
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.3 Known to work||4.3.4 Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41786
[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-10 16:26 --- dsymutil bug -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
[Bug middle-end/43255] [4.5 Regression] ICE in extract_range_from_assert, at tree-vrp.c:1423
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-10 16:26 --- Mine anyway. -- 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 Priority|P3 |P1 Last reconfirmed|2010-03-04 16:14:14 |2010-03-10 16:26:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43255
[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43265
[Bug tree-optimization/43280] [4.5 Regression] gcc4.5 -m32 -O2: misoptimizes sha256!
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
[Bug c/43288] [4.5 Regression] ICE in function_and_variable_visibility, at ipa.c:415
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43288
[Bug middle-end/43300] [4.5 Regression] ICE: in emit_move_insn, at expr.c:3432
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43300
[Bug fortran/43303] [4.4/4.5 Regression] ICE with C_ASSOCIATED
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43303
[Bug target/43305] [4.4/4.5 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-10 16:31 --- Even though this is Fortran being able to build run SPEC is release critical. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
[Bug tree-optimization/43280] [4.5 Regression] gcc4.5 -m32 -O2: misoptimizes sha256!
--- Comment #5 from krebbel at gcc dot gnu dot org 2010-03-10 16:31 --- Created an attachment (id=20074) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20074action=view) Experimental patch This patch fixes the problem for me. Testsuites are still running. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
[Bug tree-optimization/43306] [4.5 Regression] ICE: in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:713 with -O1 -fstrict-overflow -fgraphite-identity
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to work||4.4.3 Priority|P3 |P1 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43306
[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43291
[Bug bootstrap/43287] [4.5 Regression] Bootstrap fails at stage 1 on powerpc-apple-darwin9
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-03-10 16:33 --- Fixed (I assume). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43287
[Bug testsuite/40050] plugin tests don't work with multilib
--- Comment #5 from doko at gcc dot gnu dot org 2010-03-10 16:34 --- Subject: Bug 40050 Author: doko Date: Wed Mar 10 16:32:56 2010 New Revision: 157345 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157345 Log: Use the host compiler instead of the target compiler to build plugins in the testsuite. (Ported from mainline patches r147197 and r147208.) 2009-05-06 H.J. Lu hongjiu...@intel.com PR testsuite/40050 * lib/plugin-support.exp (plugin-test-execute): Use HOSTCC to build plugin. 2009-05-06 Diego Novillo dnovi...@google.com * lib/plugin-support.exp: Do not prefix $GMPINC with -I. Modified: branches/gcc-4_4-plugins/gcc/testsuite/ChangeLog.plugins branches/gcc-4_4-plugins/gcc/testsuite/lib/plugin-support.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40050
[Bug middle-end/43204] [4.4/4.5 Regression] generates larger code for a particular testcase
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|GCC 4.4 / 4.5 generates |[4.4/4.5 Regression] |larger code for a particular|generates larger code for a |testcase|particular testcase Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43204
[Bug tree-optimization/43141] [4.5 Regression] Wrong debug information with IPA-SRA
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-03-10 16:36 --- Created an attachment (id=20075) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20075action=view) Potential (preliminary) fix After much tinkering I have came up with this patch do create an ABSTRACT_ORIGIN for functions affected by IPA-SRA. The formal parameter x is in debug info as shown by dwarfdump. The C and C++ testsuites have shown no regressions and the full bootstrap I am running at the moment is already in stage 3. However, this patch certainly does cut some corners so if you think it is unsuitable, please let me know, the sooner the better. Otherwise, if all goes well I'll add the missing comments, changelog, dependencies and stuff and will submit the patch for trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43141
[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty
--- Comment #23 from paolo dot carlini at oracle dot com 2010-03-10 16:36 --- At the end of a further discussion today, apparently there is a strong consensus to add additional signatures returning void, Boost-style. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug c++/41185] [4.4/4.5 regression] size of array ... has non-integral type ...
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P2 Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41185
[Bug fortran/43310] -pedantic errors on valid code involving PARAMETERs initialized to intrinsic function result
--- Comment #7 from kargl at gcc dot gnu dot org 2010-03-10 17:17 --- (In reply to comment #6) (In reply to comment #5) (In reply to comment #4) Not all valid FORTRAN 95 programs will compile properly when using this option. If you want to ensure compliance with one of the FORTRAN standards, please see the -std= option. The problem is that your program does not conform to the Fortran 95 standard. It compiles without error nor warning with gfortran -std=f95 -Wall bar.f90 I'm not trying to sound argumentative here but you can't have it both ways... so are you saying that this is really a problem with -std, as opposed to -pedantic? The issue is with -pedantic. It doesn't do what one may think it does. When one uses -pedantic, it will strictly enforce a range of [-huge():huge()] on integer types. Without -pedantic, the range is [-huge()-1:huge()]. There are issues with either choice of range. You found one with NOT(1). Another issue is with IABS() and the most negative integer value. If you're trying to enforce standard conformance use -std=f95. -pedantic has too much baggage from times before gfortran was in the tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43310
[Bug tree-optimization/43280] [4.5 Regression] gcc4.5 -m32 -O2: misoptimizes sha256!
--- Comment #6 from hjl dot tools at gmail dot com 2010-03-10 17:50 ---
(In reply to comment #5)
Created an attachment (id=20074)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20074action=view) [edit]
Experimental patch
This patch fixes the problem for me. Testsuites are still running.
Why does the new testcase have
+/* { dg-require-effective-target lp64 } */
when the failure is shown with -m32 on x86-64?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
[Bug debug/36728] [stack]: gdb doesn't work with stack alignment
--- Comment #13 from jakub at gcc dot gnu dot org 2010-03-10 18:17 --- Subject: Bug 36728 Author: jakub Date: Wed Mar 10 18:17:10 2010 New Revision: 157363 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157363 Log: PR debug/43290 * reg-notes.def (REG_CFA_SET_VDRAP): New note. * dwarf2out.c (dwarf2out_frame_debug_expr): Remove rule 20 - setting of fde-vdrap_reg. (dwarf2out_frame_debug): Handle REG_CFA_SET_VDRAP note. (based_loc_descr): Only express drap or vdrap regno based expressions using DW_OP_fbreg when not optimizing. * config/i386/i386.c (ix86_get_drap_rtx): When not optimizing, make the vDRAP = DRAP assignment RTX_FRAME_RELATED_P and add REG_CFA_SET_VDRAP note. PR debug/36728 * gcc.dg/guality/pr36728-1.c: New test. * gcc.dg/guality/pr36728-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/guality/pr36728-1.c trunk/gcc/testsuite/gcc.dg/guality/pr36728-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/dwarf2out.c trunk/gcc/reg-notes.def trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36728
[Bug debug/43290] ICE in dwarf2out_frame_debug_expr
--- Comment #19 from jakub at gcc dot gnu dot org 2010-03-10 18:17 --- Subject: Bug 43290 Author: jakub Date: Wed Mar 10 18:17:10 2010 New Revision: 157363 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157363 Log: PR debug/43290 * reg-notes.def (REG_CFA_SET_VDRAP): New note. * dwarf2out.c (dwarf2out_frame_debug_expr): Remove rule 20 - setting of fde-vdrap_reg. (dwarf2out_frame_debug): Handle REG_CFA_SET_VDRAP note. (based_loc_descr): Only express drap or vdrap regno based expressions using DW_OP_fbreg when not optimizing. * config/i386/i386.c (ix86_get_drap_rtx): When not optimizing, make the vDRAP = DRAP assignment RTX_FRAME_RELATED_P and add REG_CFA_SET_VDRAP note. PR debug/36728 * gcc.dg/guality/pr36728-1.c: New test. * gcc.dg/guality/pr36728-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/guality/pr36728-1.c trunk/gcc/testsuite/gcc.dg/guality/pr36728-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/dwarf2out.c trunk/gcc/reg-notes.def trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43290
[Bug c++/43324] New: core dump on throw
$uname -a
SunOS sigvmec2 5.11 snv_111b i86pc i386 i86xpv Solaris
$g++ -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../configure CC=gcc --prefix=/usr/local2
--build=i386-pc-solaris2.11 --with-gnu-as --with-as=/usr/local/bin/as
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-gmp=/usr/local
--with-mpfr=/usr/local --enable-languages=c,c++,fortran --enable-shared
Thread model: posix
gcc version 4.4.3 (GCC)
Source code:
#include iostream
using namespace std;
int main() {
cout hello world! endl;
try {
throw exception;
} catch ( ... ) {
cout catched exception endl ;
}
return 0;
}
If I compile this with:
g++ -m64 test.c -o test
and run ./test, I get
hello world!
terminate called after throwing an instance of 'char const*'
Abort (core dumped)
With gcc 4.3.3 it works without a problem.
Best,
Lutz
--
Summary: core dump on throw
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lwestermann at gams dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43324
[Bug c++/43324] core dump on throw
--- Comment #1 from lwestermann at gams dot com 2010-03-10 18:24 --- Created an attachment (id=20076) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20076action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43324
[Bug target/43249] unsigned int arg with no prototype gets full 64-bit reg
--- Comment #1 from janis at gcc dot gnu dot org 2010-03-10 18:35 --- GCC 3.4 also has this bug. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||bergner at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43249
[Bug fortran/43303] [4.4/4.5 Regression] ICE with C_ASSOCIATED
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-10 18:57 --- Subject: Bug 43303 Author: burnus Date: Wed Mar 10 18:56:46 2010 New Revision: 157364 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157364 Log: 2010-03-10 Tobias Burnus bur...@net-b.de PR fortran/43303 * symbol.c (get_iso_c_sym): Set sym-result. 2010-03-10 Tobias Burnus bur...@net-b.de PR fortran/43303 * gfortran.dg/c_assoc_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/c_assoc_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43303
[Bug debug/43325] New: C++ external inner reference does not override outer scope
namespace S
{
int f ()
{
int i = 42;
{
extern int i;
return i;
}
}
}
generates DWARF:
# Grossly simplified.
12d: Abbrev Number: 2 (DW_TAG_namespace)
2e DW_AT_name: S
236: Abbrev Number: 3 (DW_TAG_subprogram)
37 DW_AT_external: 1
38 DW_AT_name: f
3c DW_AT_MIPS_linkage_name: (indirect string, offset: 0x49): _ZN1S1fEv
61 DW_AT_low_pc : 0x0
69 DW_AT_high_pc : 0x13
71 DW_AT_frame_base : 0x0 (location list)
375: Abbrev Number: 7 (DW_TAG_lexical_block)
76 DW_AT_low_pc : 0x4
7e DW_AT_high_pc : 0x11
486: Abbrev Number: 8 (DW_TAG_variable)
87 DW_AT_name: i
8f DW_AT_location: 2 byte block: 91 6c (DW_OP_fbreg: -20)
492: Abbrev Number: 9 (DW_TAG_lexical_block)
93 DW_AT_low_pc : 0xb
9b DW_AT_high_pc : 0x11
245: Abbrev Number: 4 (DW_TAG_variable)
46 DW_AT_name: i
4a DW_AT_MIPS_linkage_name: (indirect string, offset: 0x40): _ZN1S1iE
52 DW_AT_external: 1
53 DW_AT_declaration : 1
But the last DIE should have been 545 being in inner DW_TAG_lexical_block
so that debugger would display external variable S::i in the inner block.
(I have inlined the DW_AT_specification reference in the dump above.)
Similar case in C works OK:
int
f (void)
{
int i = 42;
{
extern int i;
return i;
}
}
--
Summary: C++ external inner reference does not override outer
scope
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43325
[Bug c/43288] [4.5 Regression] ICE in function_and_variable_visibility, at ipa.c:415
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-03-10 19:33 --- Subject: Bug 43288 Author: hubicka Date: Wed Mar 10 19:33:37 2010 New Revision: 157366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157366 Log: PR c/43288 * ipa.c (function_and_variable_visibility) Normalize COMMON bits. * varasm.c (get_variable_section): Don't do that here... (make_decl_rtl): ... and here. (do_assemble_alias): Produce decl RTL. (assemble_alias): Likewise. * gcc.dg/compile/pr43288.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr43288.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa.c trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43288
[Bug c/43288] [4.5 Regression] ICE in function_and_variable_visibility, at ipa.c:415
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-03-10 19:36 --- Fixed. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43288
[Bug middle-end/40815] redundant neg instruction caused by loop-invariant
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2010-03-10 19:39
---
Created an attachment (id=20077)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20077action=view)
Proposed patch
Richard,
Thank you for the great pointers how to fix this bug. Here is the proposed
patch to fix it, I am now testing it on both x86_64 and ARM.
One thing I am not sure about in this patch is whether I am forgetting a check
before swapping the operands (to optimize `-a + b' into `b - a') -- is any
check needed for {PLUS, MINUS}_EXPR in this case?
Thank you.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40815
[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-03-10 19:44 --- I will get on this tonight. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-03-10 14:01:39 |2010-03-10 19:44:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
[Bug middle-end/43323] [4.4 Regression] Wrong code with bitfields and type casting.
--- Comment #2 from hjl dot tools at gmail dot com 2010-03-10 20:05 --- It is fixed on trunk on revision 148631: http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00613.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||nemet at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43323
[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-03-10 20:21 --- I am fairly sure its the hit_eof I removed from next_record_r in transfer.c. When I get to my work machine I will fix either by reverting or otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
[Bug middle-end/41290] [4.5 regression] ICE: edge points to wrong declaration
--- Comment #18 from foom at fuhm dot net 2010-03-10 20:32 --- Sorry for the extreme delay in responding. I can confirm that applying that patch on top of: gcc-4.5 (Debian 4.5-20100227-1) 4.5.0 20100227 (experimental) [trunk revision 157109] *does* make my issue go away, and my program compile correctly without requiring the -fno-ipa-cp argument. Thank you. Should this report be reopened for that patch to be applied? I don't have the reopen option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290
[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)
--- Comment #11 from janus at gcc dot gnu dot org 2010-03-10 20:46 --- (In reply to comment #6) If all appears to be well with the regtest and I do not hear back from you, I will commit the patch to trunk tonight. The patch clobbers dynamic_dispatch_4.f03. Hm, funny. For me the patch from comment #5 survives a full regtest. Ok to commit from my side. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43291
[Bug middle-end/43204] [4.4/4.5 Regression] generates larger code for a particular testcase
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-10 20:54 --- This is tracer duplicating the basic block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43204
[Bug middle-end/43204] [4.4/4.5 Regression] generates larger code for a particular testcase
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-10 20:54 --- And really at -O3 you can expect bigger code in general. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43204
[Bug middle-end/43204] [4.4/4.5 Regression] generates larger code for a particular testcase
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-10 20:56 --- Actually this is PPRE at -O3 so this is expected. -- 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=43204
[Bug fortran/43326] New: [OOP] dynamic dispatch with CLASS components
Spin-off from PR 43291 comment #10 ... The following gives the wrong result: module m1 type :: t1 contains procedure :: sizeof end type contains integer function sizeof(a) class(t1) :: a sizeof = 1 end function sizeof end module module m2 use m1 type, extends(t1) :: t2 contains procedure :: sizeof = sizeof2 end type contains integer function sizeof2(a) class(t2) :: a sizeof2 = 2 end function end module module m3 use m2 type :: t3 class(t1), pointer :: a contains procedure :: sizeof = sizeof3 end type contains integer function sizeof3(a) class(t3) :: a sizeof3 = a%a%sizeof() end function end module use m1 use m2 use m3 class(t1), pointer :: a, ptr type(t1), target :: x type(t2), target :: y type(t3) :: z a = x print *, a%sizeof() a = y print *, a%sizeof() z%a = x print *, z%sizeof(), z%a%sizeof() z%a = y print *, z%sizeof(), z%a%sizeof() end gives 1 2 1 1 2 1 The last line should read 2 2 of course. -- Summary: [OOP] dynamic dispatch with CLASS components Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)
--- Comment #12 from janus at gcc dot gnu dot org 2010-03-10 21:04 --- (In reply to comment #10) In preparing a testcase, I foolishly decided to check the original for correct execution. The following gives the wrong result: I guess this is worth a separate PR. It's PR43326 now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43291
[Bug testsuite/38163] gcc.dg/tree-ssa/loop-3.c failure at -m64 on i686-apple-darwin9
--- Comment #5 from ghazi at gcc dot gnu dot org 2010-03-10 21:15 --- Subject: Bug 38163 Author: ghazi Date: Wed Mar 10 21:15:16 2010 New Revision: 157370 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157370 Log: Backport: 2008-12-12 Uros Bizjak ubiz...@gmail.com PR testsuite/38163 * gcc.dg/tree-ssa/loop-3.c: Compile only on nonpic x86 targets. Remove dg-skip-if directive. Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/tree-ssa/loop-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38163
[Bug fortran/43326] [OOP] dynamic dispatch with CLASS components
--- Comment #1 from janus at gcc dot gnu dot org 2010-03-10 22:06 ---
Here is a simple-minded patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 157366)
+++ gcc/fortran/resolve.c (working copy)
@@ -,6 +,8 @@
gfc_resolve_expr (gfc_expr *e)
{
gfc_try t;
+ gfc_typespec ts;
+ gfc_ref *ref = NULL;
if (e == NULL)
return SUCCESS;
@@ -5584,7 +5586,14 @@
break;
case EXPR_COMPCALL:
- if (e-symtree e-symtree-n.sym-ts.type == BT_CLASS)
+ if (e-symtree)
+ ts = e-symtree-n.sym-ts;
+ for (ref = e-ref; ref; ref = ref-next)
+ {
+ if (ref-type == REF_COMPONENT)
+ ts = ref-u.c.component-ts;
+ }
+ if (ts.type == BT_CLASS)
t = resolve_class_compcall (e);
else
t = resolve_compcall (e, true);
This fixes the test case. Haven't tested for regressions yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
[Bug c++/43327] New: ICE in unifiy.c
The following code
---
template typename _T
struct A
{
template int _N, int _M
struct B;
template int _N
struct B_N, _T::m
{
static void f();
};
};
struct C
{
static const int m = 4;
};
void m()
{
AC::B1, 4::f();
}
--
causes the following ICE as of 4.2
[g++ 4.4]
test.cc: In function âvoid m()â:
test.cc:22: internal compiler error: in unify, at cp/pt.c:14081
g++ 4.1 yields this error, instead
[g++ 4.1]
test.cc: In function âvoid m()â:
test.cc:22: error: incomplete type âAC::B1, 4â used in nested name
specifier
This code seems fine to me (and so seems to intel, xlc++ and comeau online) so
I assume it is some issue in g++.
--
Summary: ICE in unifiy.c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roger dot ferrer at bsc dot es
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43327
[Bug c++/43315] Variadic Templates affects the overload resolution rank
--- Comment #3 from boostcpp at gmail dot com 2010-03-10 22:30 --- I'm not sure about this. Maybe gcc is right. Even though it take zero parameter, it's still there. I don't know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43315
