Re: [C++0x]: non-public defaulted copy c-tor
2009/11/26 Piotr Wyderski:
Clean, simple and GCC used to happily accept that.
Only with the experimental C++0x mode, which is a moving target and
you shouldn't really complain if it changes.
But now it is illegal because of 3 draft violations:
Base() shall be public, but is not
~Base() shall be public, but is not
~Base() shall not be virtual, but it is
IMHO this severely cripples defaulted functions,
making them almost useless -- the set of allowed
cases is too narrow. Is there any chance to fix the DR?
It's under discussion, but relax, notice it says If it is explicitly
defaulted on its first declaration,
Have you tried:
class Base {
protected:
Base();
virtual ~Base();
};
inline Base::Base() = default;
inline Base::~Base() = default;
This still lets you use defaulted functions, but the base is not
trivially copyable. (I haven't tested this with GCC, but I believe it
should work.)
Re: [C++0x]: non-public defaulted copy c-tor
2009/11/26 Jonathan Wakely: This still lets you use defaulted functions, but the base is not trivially copyable. Oops, I meant the base is not a trivial class ... but then it can't be anyway as you have a virtual function.
Re: WTF?
On 11/26/2009 12:20 AM, Alexandre Oliva wrote: sed -i 's,[ \t]*$,,' probably won't work, if there are all-blanks lines being left alone in the patch (so the rx will match the patch markers too), but something slightly more elaborate preserving a fixed number of leading blanks dependng on the patch type (context or unified) should: Actually an empty line is considered by patch(1) the same way as a line containing only a space (or two spaces for context diffs), because there are many mailers that strip trailing whitespace. Paolo
Re: [C++0x]: non-public defaulted copy c-tor
Jonathan Wakely wrote:
It's under discussion
That's certainly a good news. Anyway, I'll wait
with porting my framework to the newest GCC,
until this issue is settled, as:
a) = default works as I expect on gcc 4.5-20090604
and maybe it will still do in the future;
b) gcc 4.5-20091119 reports so many ICEs it is almost
useless;
c) it seems to have problems with overload resolution.
I wanted lambdas, but it can wait -- the top of my
wish list, i.e. constructor inheritance/delegation is
not implemented yet anyway.
but relax, notice it says If it is explicitly
defaulted on its first declaration,
[...]
inline Base::Base() = default;
inline Base::~Base() = default;
Of course, I tried that and it works to some
extent, as on 20090604 defaulted virtual
destructors are not DLL-exported for some
reasons, but their {} counterparts are).
The point is that the only reason to have
defaulted functions is to provide comprehensive
syntax for obvious things. However:
inline Base::Base() {};
inline Base::~Base() {};
is even shorter than the defaulted version, not to mention:
class Base {
protected:
Base() {};
virtual ~Base() {};
};
which is the reason I dare to say the crippled version is useless.
What is the point of doing simple things in a complex way?
Best regards
Piotr Wyderski
Re: WTF?
On Thu, Nov 26, 2009 at 9:56 AM, Paolo Bonzini bonz...@gnu.org wrote: On 11/26/2009 12:20 AM, Alexandre Oliva wrote: sed -i 's,[ \t]*$,,' probably won't work, if there are all-blanks lines being left alone in the patch (so the rx will match the patch markers too), but something slightly more elaborate preserving a fixed number of leading blanks dependng on the patch type (context or unified) should: Actually an empty line is considered by patch(1) the same way as a line containing only a space (or two spaces for context diffs), because there are many mailers that strip trailing whitespace. Does svn rely on patch for merging and can it be taught to use -l? Richard.
Re: WTF?
Richard Guenther richard.guent...@gmail.com writes: Does svn rely on patch for merging No, it uses an internal diff3 algorithm. You can make it use an external diff3 program via the command line or the config file. and can it be taught to use -l? The internal diff/merge will ignore whitespace if you use -x -w. -- Philip
Re: WTF?
On 2009-11-25 17:49:39 +0100, Richard Guenther wrote: On Wed, 25 Nov 2009, Richard Kenner wrote: Why the latter? I agree with the problems this can cause, but if they can't be fixed by removing it from the database, why revert it? All things being equal, trailing blanks in fact aren't a good idea. Because it makes branch merging a nightmare and all patches people keep are hosed and won't apply anymore. Except if patches come from some web page (e.g. mailing-list archives) where trailing spaces are stripped out. In that case, patches will magically apply without any problem, whereas before the change they wouldn't. :) I've had such problems in the past with other projects, where I was told to apply some patch only available on the web, but it wouldn't apply since the source had trailing whitespace and the patch didn't (because some tool not specifically written to handle patches stripped such whitespace). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: WTF?
On 2009-11-26 10:12:39 +1100, Ben Elliston wrote: On Wed, 2009-11-25 at 15:17 -0500, Kaveh R. GHAZI wrote: Finally, we have a process for reverting a patch. If anyone wants to revert some part, it needs to be followed. Otherwise *that* would be breaking the rules... Won't reverting the patch just attribute all of the lines to the username of the reverter? Probably not if this is done with svn cp from the previous revision (and the patch won't appear in the log anymore). But I don't know the side effects of such a svn cp on merges and so on. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: WTF?
Hi, On Wed, 25 Nov 2009, Richard Kenner wrote: In my mind it's very simple: trailing whitespace poses exactly _no_ problem (except of being against the coding standard), It's against the coding standards for a very good reason, which is that it makes patching harder because you have lines that compare differently but look identical. Wow I like this creative twisting of arguments. So in order to not make patching harder in theory you make patching harder in practice?! Brilliant. So removing them, while making some patches harder to apply, makes others easier into the future. Except if you produce patches by hand this change doesn't make the slightest thing easier in the future. patch and diff will consume and generate applyable .diff files no matter if the material did or didn't contain trailing white space as long as this isn't changed between producing and applying the patch, hence future patch processing is not affected in any way. I also didn't want to know how to make patch work around this commit by loosening it's apply algorithm, neither did I want to know how to mold the patches I have into a form that now applies again. The point is That I Don't Want To Work Around useless unapproved mass changes. I'm also surprised by the hair splitting and bike shedding if the patch was or wasn't obvious. To any reasonable person it must be clear that due to the ripple effect it has it is not obvious and hence has to be reverted already just out of policy reasons. Then we perhaps can discuss further about the merits of the change, and then, after reaching agreement, commit it again; but only then. I'll note that conveniently nobody of the supporters of this change answered Richards question about the positive effects of the change and the seeming absence of real GCC bugs so that we can waste our time on this type of thing. Ciao, Michael.
Re: trivial trailing whitespace issue
Hi, On Wed, 25 Nov 2009, Basile STARYNKEVITCH wrote: 1. What to do in the immediate term with the repo. I've got no strong opinions here. I do understand most of the opinions, but I would rather prefer that we don't revert the trailing whitespace patch. I definitely can live with them, and they probably cleaned up a bit the code. How, for goodness sake, can pure trailing whitespace changes, which by necessity you can't even _see_ in an editor (except if you activate modes that explicitely show them e.g. in different color) clean up code? Have you looked at the patch or fallout from it? If not, why do you speak in favor of it? Ciao, Michael.
Re: WTF?
On 11/25/09 16:51, Lu, Hongjiu wrote: Sorry for that. I did send an email and though it was an obvious fix. I guess the patch may be too big, 400K with bz2. Did you get a reject message? If so, that should have caused you to stop and think a little... Jeff
Re: WTF?
Michael Matz wrote: I Don't Want To Work Around useless unapproved mass changes. Hey, nor do I. (In fact, I don't even like having to work around useful approved mass changes, merging is always dull and tedious work. But I think of it as just something that goes with the territory.) To any reasonable person it must be clear I'm a reasonable person. It is not clear to me. the seeming absence of real GCC bugs so that we can waste our time on this type of thing. Actually, I made a quick judgement call when Richard G. first posted about this, and decided that the quickest and most efficient thing I could possibly do to deal with this problem using the least effort and wasting the least time would be to just not care and simply get on with my work. If this thread goes on much longer, there will presumably come a crossover point at which it would have been more worth your while too cheers, DaveK
Re: trivial trailing whitespace issue
Michael Matz wrote:
Hi,
On Wed, 25 Nov 2009, Basile STARYNKEVITCH wrote:
1. What to do in the immediate term with the repo. I've got no strong
opinions here.
I do understand most of the opinions, but I would rather prefer that we
don't revert the trailing whitespace patch. I definitely can live with
them, and they probably cleaned up a bit the code.
How, for goodness sake, can pure trailing whitespace changes, which by
necessity you can't even _see_ in an editor (except if you activate modes
that explicitely show them e.g. in different color) clean up code? Have
you looked at the patch or fallout from it? If not, why do you speak in
favor of it?
I was speaking in favor of the patch because it apparently make the GCC code
more conformant to GCC coding styles.
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: trivial trailing whitespace issue
On 11/26/2009 08:18 AM, Michael Matz wrote: How, for goodness sake, can pure trailing whitespace changes, which by necessity you can't even _see_ in an editor (except if you activate modes that explicitely show them e.g. in different color) clean up code? Have you looked at the patch or fallout from it? If not, why do you speak in favor of it? I'm an outside observer with professional ties to SCM. This issue is similar in scope to TAB vs SPACE for indenting. Whether you can see it or not is not indicative of whether it has downstream effects or not. Generally, whitespace on the end of lines is bad, and cleanup eventually becomes necessary. It is bad because people will accidentally change lines without realizing them, and these changed lines show up in patches and annotations. This goes both ways - a lot of people browse code in vi, and accidentally add space to the end of lines they don't even intend to change. Or, maybe their editor automatically strips whitespace at end of line when they re-indent. Who knows? Same happens with TAB changed to SPACE or back and forth. Once these start to accumulate - they create downstream consequences that multiply. You can't see it, but every program that the file passes through *does* see them. Is cleanup in bulk the right approach? You either clean up over time or you do it in bulk. In my own projects, some of the designers I worked with had horrible habits in this regard. Every second line would have whitespace on the end. The longer it is left, the worse the effect. As software architect for our project, I notified the team I was doing a cleanup, and did it in bulk. Due to the notification, everything went smooth. It sounds like the idea should have been proposed and accepted. Everybody would have been ready for it, and nobody would be upset. Oh well. It's been entertaining. gcc@gcc.gnu.org is normally pretty dull to read... :-) Cheers, mark -- Mark Mielkem...@mielke.cc
gcc-4.5-20091126 is now available
Snapshot gcc-4.5-20091126 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20091126/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 154692 You'll find: gcc-4.5-20091126.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20091126.tar.bz2 C front end and core compiler gcc-ada-4.5-20091126.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20091126.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20091126.tar.bz2 C++ front end and runtime gcc-java-4.5-20091126.tar.bz2 Java front end and runtime gcc-objc-4.5-20091126.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20091126.tar.bz2The GCC testsuite Diffs from 4.5-20091119 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: WTF?
Did you get a reject message? If so, that should have caused you to stop and think a little... I sent: Date: Wed, 25 Nov 2009 02:53:21 -0800 From: H.J. Lu hongjiu...@intel.com To: gcc-patc...@gcc.gnu.org Subject: PATCH: Remove trailing white spaces User-Agent: Mutt/1.5.19 (2009-01-05) Hi, I am checking in this patch to remove trailing white spaces. I didn't get any reject. But apparently it never showed up. H.J.
Re: No .got section in ELF
The rsult is also same, you go too far. Code I want to show a fact in Linux, when a process load a library into memory, such as 0x1000 foo.so 0x1000 ELF header .text section .data section .bss section ... Here data in 0x1000 and its follower have an *exact* map to foo.so in disk, you need review my code, so which can bring an optimization is offsetof(C - A) is const. Further, everything in data/bss section has a fixed offset to text section. 2009/11/26 Alexandre Oliva aol...@redhat.com: On Nov 26, 2009, yunfeng zhang zyf.zer...@gmail.com wrote: The result is the same But the code isn't. See how, with hidden, we use the fixed offset. Now remove the hidden attribute, define g also in the main program, and see what it prints. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: No .got section in ELF
yunfeng zhang wrote: have an *exact* map to foo.so in disk This is where your misunderstanding arises. Just as 5+3 can add up to the same result as 4+4, so you cannot ignore that the final mapped addresses you are seeing add up to the same result via different routes. Compile your sources using --save-temps, and look at the differences in the generated assembly files. By looking only at the final results, you are losing information about how those results are arrived at. cheers, DaveK
Re: No .got section in ELF
You can run a.out several times 24a5e0, 24941c 1115e0, 11041c c785e0, c7741c 8c35e0, 8c241c ... Now open f.map g = 0x15e0, foo = 0x41c is it 5 + 3 = 4 + 4? 2009/11/27 Dave Korn dave.korn.cyg...@googlemail.com: yunfeng zhang wrote: have an *exact* map to foo.so in disk This is where your misunderstanding arises. Just as 5+3 can add up to the same result as 4+4, so you cannot ignore that the final mapped addresses you are seeing add up to the same result via different routes. Compile your sources using --save-temps, and look at the differences in the generated assembly files. By looking only at the final results, you are losing information about how those results are arrived at. cheers, DaveK
Re: No .got section in ELF
yunfeng zhang wrote: a.out f.map is it 5 + 3 = 4 + 4? If you refuse to look at the source code that gcc generates, you will never know what the difference is. I cannot make that decision for you. cheers, DaveK
Re: No .got section in ELF
Yunfeng Zhang, please try this example. elf.tar.gz Description: GNU Zip compressed data
Re: No .got section in ELF
On 11/26/2009 02:04 PM, yunfeng zhang wrote:
The result is the same
#includestdio.h
extern int g __attribute__((visibility(hidden)));
int g;
int foo(int a, int b)
{
g = a + b;
printf(%x, %x,g, foo);
return g;
}
load and call `foo' in the library, an outputting (with vdso) is
cc15bc, cc03fc
and open f.map
0x15bc, 0x3fc
It shows Linux simply maps the library to memory *using* library segment layout.
Using e.cc to call it
#includeexception
#includetypeinfo
#includecstddef
#includedlfcn.h
#includestdio.h
int main(void)
{
void* handle = dlopen(./f.so, RTLD_NOW);
typedef int (*gso)(int, int);
gso f;
*(void**) (f) = dlsym(handle, foo);
f(1, 2);
return 0;
}
You got the bad test case. Please try the following:
$ cat f.c
#include stdio.h
int g;
int foo(int a, int b)
{
g = a + b;
printf(g = 0x%x, foo = 0x%x\n, g, foo);
return g;
}
$ cat e.c
int g;
extern int foo(int a, int b);
int main(void)
{
foo(1, 2);
return 0;
}
$ gcc -shared -fPIC -Wl,-soname,./libf.so,-Map,f.map -o libf.so f.c
$ gcc -o e e.c -ldl -L. -lf
$ ./e
g = 0x600a30, foo = 0x294a2614
Then comment out the int g; in e.c. and do the same steps as above:
$ ./e
g = 0x58294948, foo = 0x58094614
You can see that C-A is *not* a constant. Your premise is wrong.
Jie
Re: No .got section in ELF
Sorry! I've made a mistake! But using LD_PRELOAD to force to reposition a variable/function from a module is violating software engineer. And the more important is, as the result, all user *all* pay the bill for this even they make sure they don't need the feature, such as, glibc itself.
[Bug objc++/42156] [4.5 Regression] Hundreds of objc++ testsuite regressions
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-26 09:31 --- Caused by http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01059.html aka r154354. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug objc++/42156] [4.5 Regression] Hundreds of objc++ testsuite regressions
--- Comment #5 from jakub at gcc dot gnu dot org 2009-11-26 09:42 --- The problem seems to be the new set_underlying_type call called from build_self_reference. Apparently the objc-act.c expects that type variants at that point are only created for some other purpose (don't know objc, so have no idea for what), and that they have TYPE_OBJC_INFO allocated, which is not the case for these self reference variants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug objc++/42156] [4.5 Regression] Hundreds of objc++ testsuite regressions
--- Comment #6 from jakub at gcc dot gnu dot org 2009-11-26 09:47 --- Created an attachment (id=19152) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19152action=view) gcc45-pr42156.patch Untested patch. I'm not familiary with ObjC/ObjC++, so have no idea whether it is the right fix or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug c/42179] Incorrect optimization (-O2) yields wrong code (regression)
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-26 09:56 ---
Aliasing rules are indeed broken because you access a union of anonymous type
through a pointer to a union of type ieee_double_extract.
I think you want
union { union ieee_double_extract d; unsigned long long i; } x;
x.d.d = 0.0 / 0.0;
printf (d = %g [%llx]\n, x.d.d, x.d.i);
printf (exp = %x\n, (unsigned int) x.d.s.exp);
return 0;
or even simplified.
--
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=42179
[Bug c/42179] Incorrect optimization (-O2) yields wrong code (regression)
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-11-26 11:02 --- note that there are no warnings A warning is issued with -Wstrict-aliasing=1 or -Wstrict-aliasing=2, but no warning with -Wstrict-aliasing=3 (or -Wall). I see there are already a few bug reports about this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42179
[Bug c/42179] Incorrect optimization (-O2) yields wrong code (regression)
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-26 11:25 --- Correct. We can either produce possibly lots of false positives or not warn. Warning in the cases where we can prove your code is wrong would be pointless as in that case we'd better take measures to not miscompile it (and we then can do so as we were able to detect the situation). With 4.4 one alias warning machinery did exactly this (warn but then not miscompile - but then it didn't warn in cases where it _did_ miscompile). It's generally impossible to please all folks here ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42179
[Bug libstdc++/42182] New: memory errors using valarrays
The valarray mask_array implementation creates out of bound memory accesses when the number of the True bits is smaller that the size of array, although this is perfect legal. This produce valgrin error at best, sometime segfaults, or infinite loops. To reproduce, compile the attached test: g++ -O0 va0.cxx gnx2439$ valgrind ./a.out==1547== Memcheck, a memory error detector ==1547== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==1547== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==1547== Command: ./a.out ==1547== ==1547== Invalid read of size 1 ==1547==at 0x80489D1: void std::__valarray_copyint(std::_Arrayint, unsigned int, std::_Arrayint, std::_Arraybool) (in /home/bruel/tmp/a.out) ==1547==by 0x804889A: std::mask_arrayint::operator=(std::valarrayint const) const (in /home/bruel/tmp/a.out) ==1547==by 0x80485C9: main (in /home/bruel/tmp/a.out) ==1547== Address 0x4129061 is 0 bytes after a block of size 1 alloc'd ==1547==at 0x40061CC: operator new(unsigned int) (vg_replace_malloc.c:214) ==1547==by 0x8048644: std::__valarray_get_memory(unsigned int) (in /home/bruel/tmp/a.out) ==1547==by 0x80488E6: bool* restrict std::__valarray_get_storagebool(unsigned int) (in /home/bruel/tmp/a.out) ==1547==by 0x80486EE: std::valarraybool::valarray(bool const, unsigned int) (in /home/bruel/tmp/a.out) ==1547==by 0x804857B: main (in /home/bruel/tmp/a.out) ==1547== ==1547== Invalid write of size 4 ==1547==at 0x80489E3: void std::__valarray_copyint(std::_Arrayint, unsigned int, std::_Arrayint, std::_Arraybool) (in /home/bruel/tmp/a.out) ==1547==by 0x804889A: std::mask_arrayint::operator=(std::valarrayint const) const (in /home/bruel/tmp/a.out) ==1547==by 0x80485C9: main (in /home/bruel/tmp/a.out) ==1547== Address 0x4129108 is not stack'd, malloc'd or (recently) free'd ==1547== ==1547== ==1547== HEAP SUMMARY: ==1547== in use at exit: 0 bytes in 0 blocks ==1547== total heap usage: 3 allocs, 3 frees, 9 bytes allocated ==1547== ==1547== All heap blocks were freed -- no leaks are possible ==1547== ==1547== For counts of detected and suppressed errors, rerun with: -v ==1547== ERROR SUMMARY: 56 errors from 2 contexts (suppressed: 19 from 10) -- Summary: memory errors using valarrays Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christian dot bruel at st dot com 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=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #1 from christian dot bruel at st dot com 2009-11-26 11:32 --- Created an attachment (id=19153) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19153action=view) reduced case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #2 from christian dot bruel at st dot com 2009-11-26 11:35 --- Created an attachment (id=19154) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19154action=view) computed assignment test case compiled with g++ -O0 gnx2439$ valgrind ./a.out==1599== Memcheck, a memory error detector ==1599== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==1599== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==1599== Command: ./a.out ==1599== ==1599== Invalid read of size 1 ==1599==at 0x8048A0B: void std::_Array_augmented___plusint(std::_Arrayint, std::_Arraybool, std::_Arrayint, unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x80488D4: std::mask_arrayint::operator+=(std::valarrayint const) const (in /home/bruel/tmp/a.out) ==1599==by 0x80485E9: main (in /home/bruel/tmp/a.out) ==1599== Address 0x4129061 is 0 bytes after a block of size 1 alloc'd ==1599==at 0x40061CC: operator new(unsigned int) (vg_replace_malloc.c:214) ==1599==by 0x804867E: std::__valarray_get_memory(unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x8048920: bool* restrict std::__valarray_get_storagebool(unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x8048728: std::valarraybool::valarray(bool const, unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x804857B: main (in /home/bruel/tmp/a.out) ==1599== ==1599== Invalid read of size 4 ==1599==at 0x8048A18: void std::_Array_augmented___plusint(std::_Arrayint, std::_Arraybool, std::_Arrayint, unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x80488D4: std::mask_arrayint::operator+=(std::valarrayint const) const (in /home/bruel/tmp/a.out) ==1599==by 0x80485E9: main (in /home/bruel/tmp/a.out) ==1599== Address 0x4129108 is not stack'd, malloc'd or (recently) free'd ==1599== ==1599== Invalid write of size 4 ==1599==at 0x8048A24: void std::_Array_augmented___plusint(std::_Arrayint, std::_Arraybool, std::_Arrayint, unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x80488D4: std::mask_arrayint::operator+=(std::valarrayint const) const (in /home/bruel/tmp/a.out) ==1599==by 0x80485E9: main (in /home/bruel/tmp/a.out) ==1599== Address 0x4129108 is not stack'd, malloc'd or (recently) free'd -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-26 11:35 --- Hey, this is pointless, the issue is well known and Gaby is the reference person in this area. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #4 from christian dot bruel at st dot com 2009-11-26 11:38 --- Created an attachment (id=19155) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19155action=view) controversal testcase compile with -O0, Segfaults on x86 with gcc version 4.5.0 20091119 (experimental) [trunk revision 154332] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #5 from christian dot bruel at st dot com 2009-11-26 11:40 --- Created an attachment (id=19156) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19156action=view) Proposed patch 2009-11-23 Christian Bruel christian.br...@st.com * include/bits/mask_array.h (mask_array_Tp::operator=): Use _M_sz. (mask_array_Tp::operator _Op##): Likewise. * testsuite/26_numerics/valarray/mask_array.cc: New test. This patch makes the valarray_copy interates on the number of true elements rather than on the array size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #6 from christian dot bruel at st dot com 2009-11-26 12:08 --- (In reply to comment #3) Hey, this is pointless, the issue is well known and Gaby is the reference person in this area. no problem, if the issue is known it can be recorded for the reference, a link to Gaby authoritative answer http://gcc.gnu.org/ml/libstdc++/2009-11/msg00099.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #7 from paolo dot carlini at oracle dot com 2009-11-26 12:15 --- What I meant, exactly, is that if any issue is well known to the concerned people, there is no need for a Bugzilla, in particular an invalid one ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #8 from christian dot bruel at st dot com 2009-11-26 12:18 --- (In reply to comment #7) What I meant, exactly, is that if any issue is well known to the concerned people, there is no need for a Bugzilla, in particular an invalid one ;) Well I still need to be convinced that va0.cxx here is invalid : it is a 5 lines of simple conforming code that produces a segfault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #9 from paolo dot carlini at oracle dot com 2009-11-26 12:57 --- The point is that the code is not conforming. In any case, conforming or not, in the future please do not open Bugzilla for issues already known to the maintainers, thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-11-26 13:02 --- This is what I would call a very fundamental bug, at the soul of what fortran is suppose to do. I am looking at it but think it would go better with a team effort here. Anyone have any thoughts about it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-11-26 14:35 --- I think we need to gfc_walk_op_expr before we try to gfc_conv_array_transpose -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug tree-optimization/41905] [4.5 Regression] ICE with __attribute__((noreturn))
--- Comment #3 from matz at gcc dot gnu dot org 2009-11-26 14:50 --- I have a patch. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-11-06 09:32:52 |2009-11-26 14:50:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41905
[Bug c++/42183] New: internal compiler error: verify_stmts failed
Compiling of qt-x11-opensource-src-4.5.3/src/3rdparty/webkit/WebCore/rendering/RenderMenuList.cpp failed with the following compiler call g++ -c -fpreprocessed -m32 -O2 RenderMenuList.1.i RenderMenuList.1.i: In member function 'WebCore::RenderMenuList::controlClipRect(int, int) const': RenderMenuList.1.i:45546:9: error: address taken, but ADDRESSABLE bit not set retval RenderMenuList.1.i:1514:19: note: in statement # .MEM_119 = VDEF .MEM_117 WebCore::IntRect::intersect (retval, innerBox); RenderMenuList.1.i:45546:9: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: verify_stmts failed Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mario-baumann at web dot de GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
[Bug c++/42183] internal compiler error: verify_stmts failed
--- Comment #1 from mario-baumann at web dot de 2009-11-26 15:07 --- Created an attachment (id=19157) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19157action=view) preprocessed cpp file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
[Bug c++/42183] internal compiler error: verify_stmts failed
--- Comment #2 from mario-baumann at web dot de 2009-11-26 15:08 --- uname -a Linux yoda.intec.dom 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux rpm -qa glibc* | grep -e 'glibc-[0-9]' | sort -u glibc-2.5-42 g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/opt/gcc/4.5.0-20091126-svn154671/x86_64/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --with-cloog=/opt/gcc/svn/aux --with-gmp=/opt/gcc/svn/aux --with-mpc=/opt/gcc/svn/aux --with-mpfr=/opt/gcc/svn/aux --with-ppl=/opt/gcc/svn/aux --disable-nls --enable-languages=c,c++,fortran --prefix=/opt/gcc/4.5.0-20091126-svn154671/x86_64 Thread model: posix gcc version 4.5.0 20091126 (experimental) (GCC) ld -v GNU ld (GNU Binutils) 2.20.51.20091126 g++ -c -fpreprocessed -m32 -O2 RenderMenuList.1.i RenderMenuList.1.i: In member function 'WebCore::RenderMenuList::controlClipRect(int, int) const': RenderMenuList.1.i:45546:9: error: address taken, but ADDRESSABLE bit not set retval RenderMenuList.1.i:1514:19: note: in statement # .MEM_119 = VDEF .MEM_117 WebCore::IntRect::intersect (retval, innerBox); RenderMenuList.1.i:45546:9: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. NOTES: (1) g++ -c -fpreprocessed -m32 RenderMenuList.1.i works -- mario-baumann at web dot de changed: What|Removed |Added CC||mario-baumann at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
[Bug tree-optimization/42027] [4.5 Regression] Performance regression in convolution loop optimization
--- Comment #3 from nbenoit at tuxfamily dot org 2009-11-26 15:08 --- Using integer instead of double, the performance difference is even more noticeable : * with -O1 GCC 4.4.2 7475 ms GCC-trunk-r154672 9390 ms -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
[Bug tree-optimization/39806] incorrect pointer hashing in ipa-struct-reorg.c
--- Comment #3 from olga at il dot ibm dot com 2009-11-26 15:35 --- Potential patch (as Andew suggested). Please check for your platform. http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01467.html Thanks, Olga -- olga at il dot ibm dot com changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39806
[Bug c/42179] Incorrect optimization (-O2) yields wrong code (regression)
--- Comment #4 from vincent at vinc17 dot org 2009-11-26 15:53 --- (In reply to comment #1) Aliasing rules are indeed broken because you access a union of anonymous type through a pointer to a union of type ieee_double_extract. OK, the real code in MPFR is a double accessed through a pointer to a union of type ieee_double_extract, but I suppose this is the same problem. BTW, could my testcase be used to improve GCC's -Wstrict-aliasing=3 (i.e. to have fewer false negatives without introducing more false positives), or is it too difficult / not possible? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42179
[Bug tree-optimization/41905] [4.5 Regression] ICE with __attribute__((noreturn))
--- Comment #4 from matz at gcc dot gnu dot org 2009-11-26 15:58 --- Fixed in r154674. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41905
[Bug c++/10690] [DR 115] Even when used within typeid(), a template-id generating an overload set with only one function should silently decay to a pointer to function
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-26 16:00 --- Subject: Bug 10690 Author: jason Date: Thu Nov 26 15:59:52 2009 New Revision: 154675 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154675 Log: PR c++/10690 * rtti.c (get_tinfo_decl_dynamic): Call resolve_nondeduced_context. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/rtti.c trunk/gcc/testsuite/g++.dg/template/explicit-args2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10690
[Bug c++/10690] [DR 115] Even when used within typeid(), a template-id generating an overload set with only one function should silently decay to a pointer to function
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-26 16:04 --- Fixed for 4.5. -- 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=10690
[Bug c/42184] New: Same literal behaves differently as a double than as a long double
One would assume that the following program prints the same number four times,
but instead 1 0 1 0 is printed. I compiled it with options -std=c99 -lm.
#include stdio.h
#include math.h
#include stdlib.h
int main(void)
{
long double value1 = 1.6646342e21;
long double value2 = 1.6646342e21L;
long double value3 = strtod(1.6646342e21, NULL);
long double value4 = strtold(1.6646342e21, NULL);
long double divisor = 1.25L;
printf(%Lg %Lg %Lg %Lg\n,
fmodl(value1, divisor), fmodl(value2, divisor),
fmodl(value3, divisor), fmodl(value4, divisor));
return 1;
}
--
Summary: Same literal behaves differently as a double than as a
long double
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: warp at iki dot fi
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42184
[Bug c/42179] Incorrect optimization (-O2) yields wrong code (regression)
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-26 16:39 --- The frontend code should indeed be able to unconditionally warn for ((union ieee_double_extract *)(x.d))-s.exp because it can see both the underlying object and the access through the non-conflicting type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42179
[Bug c++/42183] internal compiler error: verify_stmts failed
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-26 16:41 --- reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
[Bug c++/41906] [4.5 Regression] ICE with catch(...) and -fpermissive
--- Comment #2 from matz at gcc dot gnu dot org 2009-11-26 16:51 --- I have a patch: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01474.html -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-11-05 15:58:18 |2009-11-26 16:51:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41906
[Bug middle-end/42185] New: [4.5 Regression] expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820
gfortran -c -fgraphite -O1 -ffast-math bug.f90 bug.f90: In function __powell_MOD_trsapp: bug.f90:4:0: internal compiler error: gimple check: expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. cat bug.f90 MODULE powell INTEGER, PARAMETER :: dp=8 CONTAINS SUBROUTINE trsapp (n,npt,xopt,xpt,gq,hq,pq,delta,step,d,g,hd,hs,crvmin) REAL(dp), DIMENSION(*), INTENT(INOUT):: step, d, g, hd, hs LOGICAL :: jump1, jump2 REAL(dp) :: alpha, angle, angtest, bstep, cf, cth, dd, delsq, dg, dhd, reduc, sg, sgk, shs, ss, sth, temp, tempa, tempb DO i=1,n dd=dd+d(i)**2 END DO mainloop : DO IF ( .NOT. jump2 ) THEN IF ( .NOT. jump1 ) THEN bstep=temp/(ds+SQRT(ds*ds+dd*temp)) IF (alpha bstep) THEN IF (ss delsq) CYCLE mainloop END IF IF (gg = 1.0e-4_dp*ggbeg) EXIT mainloop END IF END IF END DO mainloop END SUBROUTINE trsapp END MODULE powell details gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --disable-bootstrap --prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran --disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/ --with-libelf=/data03/vondele/libelf-0.8.12/build/ --enable-gold --enable-lto --enable-plugins Thread model: posix gcc version 4.5.0 20091126 (experimental) [trunk revision 154675] (GCC) -- Summary: [4.5 Regression] expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42185
[Bug middle-end/42181] -fgraphite-identity miscompiles or ICEs on air.f90
--- Comment #1 from jv244 at cam dot ac dot uk 2009-11-26 17:02 --- *** Bug 41051 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug middle-end/41051] -O1/-O2/-O3 -fgraphite-identity -floop-interchange miscompiles air.f90
--- Comment #2 from jv244 at cam dot ac dot uk 2009-11-26 17:02 --- *** This bug has been marked as a duplicate of 42181 *** -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41051
[Bug middle-end/42181] -fgraphite-identity miscompiles or ICEs on air.f90
--- Comment #2 from jv244 at cam dot ac dot uk 2009-11-26 17:04 --- the following is a testcase for the ICE (derived from CP2K bug crashes in the same place): cat bug.f90 MODULE powell INTEGER, PARAMETER :: dp=8 CONTAINS SUBROUTINE newuob (n,npt,x,rhobeg,rhoend,maxfun,xbase, xopt,xnew,xpt,fval,gq,hq,pq,bmat,zmat,ndim,d,vlag,w,opt) REAL(dp), DIMENSION(npt, *), INTENT(inout) :: xpt REAL(dp), DIMENSION(*), INTENT(inout):: fval, gq, hq, pq 120 IF (dsq = 1.0e-3_dp*xoptsq) THEN DO k=1,npt DO i=1,n gq(i)=gq(i)+temp*xpt(k,i) END DO END DO END IF END SUBROUTINE newuob END MODULE powell gfortran -fgraphite -O1 bug.f90 bug.f90: In function __powell_MOD_newuob: bug.f90:4:0: internal compiler error: in scan_tree_for_params, at graphite-sese-to-poly.c:853 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug middle-end/42181] [4.5 Regression] -fgraphite-identity miscompiles or ICEs on air.f90
--- Comment #3 from jv244 at cam dot ac dot uk 2009-11-26 17:05 --- the ice is absent in 4.4 but present in 4.5 trunk -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-26 17:05:43 date|| Summary|-fgraphite-identity |[4.5 Regression] -fgraphite- |miscompiles or ICEs on |identity miscompiles or ICEs |air.f90 |on air.f90 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug c++/42026] [DR 239] g++ violate [basic.lookup.argdep]
-- 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|NEW |ASSIGNED Last reconfirmed|2009-11-13 10:24:51 |2009-11-26 17:11:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42026
[Bug target/41077] [avr] excessive prologue/epilogue for interrupt handler
--- Comment #1 from hutchinsonandy at gcc dot gnu dot org 2009-11-26 17:12 --- R1 and R0 are used at assembler level outside of compiler scope. R1 is always expected to contain as a zero value - to avoid using a register to load this common value. R1 maybe used in assembler for other purposes - but must be restored to zero. R0 is used as a temporary - to get around awkward situation created by compiler like a = *a; Thus any ISR will always save these values - and clear r1. Gcc cannot see either r1 or r0 or otherwise track usage. While we may debate the merits of this approach. It has been this way from day one and will not change. :-( -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41077
[Bug c/42184] Same literal behaves differently as a double than as a long double
--- Comment #1 from kargl at gcc dot gnu dot org 2009-11-26 17:13 --- I think that you may be looking at a library issue and the conversion of a decimal string to binary. Add printf(%La\n%La\n%La\n%La\n, value1, value2, value3, value4); to your program yields REMOVE:kargl[209] ./z 0x1.68f5c2c528fa3p+70 0x1.68f5c2c528fa3p+70 0x1.68f5c2c528fa3p+70 0x1.68f5c2c528fa36p+70 1 1 1 0 on FreeBSD. If I replace 1.6646342e21 everywhere in your program with 0x1.68f5c2c528fa3p+70, I get the result you expect, ie., REMOVE:kargl[212] ./z 0x1.68f5c2c528fa3p+70 0x1.68f5c2c528fa3p+70 0x1.68f5c2c528fa3p+70 0x1.68f5c2c528fa3p+70 1 1 1 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42184
[Bug target/21080] Excecution test failure for avr for pr17377 test case.
--- Comment #6 from hutchinsonandy at gcc dot gnu dot org 2009-11-26 17:20 --- Fixed on 4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21078 -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21080
[Bug target/37081] [avr] FAIL: gcc.dg/pr36998.c
--- Comment #3 from hutchinsonandy at gcc dot gnu dot org 2009-11-26 17:25 --- Author: hutchinsonandy Date: Mon Nov 23 21:38:32 2009 New Revision: 154467 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154467 Log: * gcc.dg/pr36998.c: Frame pointer required for avr target. * gcc.dg/debug/pr41264-1.c: Use long if int size 16bit or smaller. * gcc.dg/pr39226.c: Use smaller bitfield if int size is 16bit. * gcc.dg/pr41340.c: Test requires long pointer target. * gcc.dg/profile-generate-3.c: Test requires profiling support. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/pr41264-1.c trunk/gcc/testsuite/gcc.dg/pr36998.c trunk/gcc/testsuite/gcc.dg/pr39226.c trunk/gcc/testsuite/gcc.dg/pr41340.c trunk/gcc/testsuite/gcc.dg/profile-generate-3.c -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37081
[Bug testsuite/38202] [avr] FAIL: gcc.dg/torture/pr37868.c
--- Comment #3 from hutchinsonandy at gcc dot gnu dot org 2009-11-26 17:29 --- Fixed 4.5 Author: hutchinsonandy Date: Mon Nov 23 22:21:21 2009 New Revision: 154474 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154474 Log: * gcc.dg/torture/pr37868.c: Use smaller bitfield for 16bit int targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr37868.c -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38202
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #10 from christian dot bruel at st dot com 2009-11-26 17:44 --- Paolo, I entered this defect for user reference, since the problem that originates the thread occurs in many public places such as testsuites (perenial Sec26/P26774) or class books (http://www.linux-kheops.com/doc/casteyde/cours_cpp-1.40.1/htm/x5866.htm#AEN6045) 14-21. Digging on the net, it's not difficult to find other instances of the same problem, All fail for the same reason: out of bound access from the mask array or exibit a valgrind error. FYU they pass with the proposed patch, I'm glad that it was not a bug with the library, and to have opened the discussion. just wanted to avoid future duplicate reports on the same problem an extra analysis. I didn't want to add extra burden to the maintainers of course, sorry if it was the case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-11-26 17:50 --- Removing the assert appears to fix this. Testing now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #11 from paolo dot carlini at oracle dot com 2009-11-26 18:00 --- Yes, but remember our policy in the future, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #12 from janus at gcc dot gnu dot org 2009-11-26 19:01 --- Subject: Bug 42048 Author: janus Date: Thu Nov 26 19:01:02 2009 New Revision: 154679 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154679 Log: 2009-11-26 Janus Weil ja...@gcc.gnu.org PR fortran/42048 PR fortran/42167 * gfortran.h (gfc_is_function_return_value): New prototype. * match.c (gfc_match_call): Use new function 'gfc_is_function_return_value'. * primary.c (gfc_is_function_return_value): New function to check if a symbol is the return value of an encompassing function. (match_actual_arg,gfc_match_rvalue,match_variable): Use new function 'gfc_is_function_return_value'. * resolve.c (resolve_common_blocks,resolve_actual_arglist): Ditto. 2009-11-26 Janus Weil ja...@gcc.gnu.org PR fortran/42048 PR fortran/42167 * gfortran.dg/select_type_10.f03: New test case. * gfortran.dg/typebound_call_11.f03: Extended test case. Added: trunk/gcc/testsuite/gfortran.dg/select_type_10.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/typebound_call_11.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug fortran/42167] [OOP] SELECT TYPE with function return value
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-26 19:01 --- Subject: Bug 42167 Author: janus Date: Thu Nov 26 19:01:02 2009 New Revision: 154679 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154679 Log: 2009-11-26 Janus Weil ja...@gcc.gnu.org PR fortran/42048 PR fortran/42167 * gfortran.h (gfc_is_function_return_value): New prototype. * match.c (gfc_match_call): Use new function 'gfc_is_function_return_value'. * primary.c (gfc_is_function_return_value): New function to check if a symbol is the return value of an encompassing function. (match_actual_arg,gfc_match_rvalue,match_variable): Use new function 'gfc_is_function_return_value'. * resolve.c (resolve_common_blocks,resolve_actual_arglist): Ditto. 2009-11-26 Janus Weil ja...@gcc.gnu.org PR fortran/42048 PR fortran/42167 * gfortran.dg/select_type_10.f03: New test case. * gfortran.dg/typebound_call_11.f03: Extended test case. Added: trunk/gcc/testsuite/gfortran.dg/select_type_10.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/typebound_call_11.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42167
[Bug fortran/42167] [OOP] SELECT TYPE with function return value
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-26 19:05 --- Fixed with r154679. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42167
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-11-26 19:05 --- Subject: Bug 41278 Author: jvdelisle Date: Thu Nov 26 19:05:37 2009 New Revision: 154680 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154680 Log: 2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41278 * trans-array.c (gfc_conv_array_transpose): Delete unnecessary assert. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug debug/42186] New: [4.5 Regression] internal compiler error: verify_ssa failed
gfortran -c -fgraphite-identity -g -O3 -ffast-math bug.f90 bug.f90: In function calerf: bug.f90:3:0: error: definition in block 11 does not dominate use in block 4 for SSA_NAME: xden_2 in statement: D.1562_21 = D.1561_20 + xden_2; bug.f90:3:0: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. cat bug.f90 MODULE erf_fn CONTAINS SUBROUTINE CALERF(ARG,RESULT,JINT) DIMENSION A(5),B(4),C(9),D(8),P(6),Q(5) IF (Y = THRESH) THEN DO I = 1, 3 XNUM = (XNUM + A(I)) * YSQ XDEN = (XDEN + B(I)) * YSQ END DO RESULT = X * (XNUM + A(4)) / (XDEN + B(4)) END IF END SUBROUTINE CALERF END MODULE erf_fn -- Summary: [4.5 Regression] internal compiler error: verify_ssa failed Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42186
[Bug debug/42186] [4.5 Regression] internal compiler error: verify_ssa failed
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42186
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-11-26 19:10 --- Subject: Bug 41278 Author: jvdelisle Date: Thu Nov 26 19:10:29 2009 New Revision: 154681 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154681 Log: 2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41278 * gfortran.dg/array_function_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_function_5.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug middle-end/42185] [4.5 Regression] expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820
--- Comment #1 from jv244 at cam dot ac dot uk 2009-11-26 19:11 --- pretty similar in this case gfortran -c -fgraphite-identity -g -O3 -ffast-math bug.f90 bug.f90 bug.f90: In function psi: bug.f90:4:0: internal compiler error: gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs_code, at gimple.h:1820 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. bug.f90: In function psi: bug.f90:4:0: internal compiler error: gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs_code, at gimple.h:1820 Please submit a full bug report, with preprocessed source if appropriate. cat bug.f90 MODULE beta_gamma_psi INTEGER, PARAMETER :: dp=KIND(0.0D0) CONTAINS FUNCTION psi(xx) RESULT(fn_val) REAL(dp) :: aug, den, dx0 = 1.461632144968362341262659542325721325e0_dp, p1(7) = (/ .895385022981970e-02_dp, .477762828042627e+01_dp, .142441585084029e+03_dp, .118645200713425e+04_dp, .363351846806499e+04_dp,.413810161269013e+04_dp, -.648157123766197e+00_dp /), piov4 = .785398163397448e0_dp, q1(6) = (/ .448452573429826e+02_dp, .520752771467162e+03_dp, .221000799247830e+04_dp, .364127349079381e+04_dp, .546117738103215e+02_dp, .88548522962e+01_dp /) DO i = 1, 5 den = (den + q1(i)) * x upper = (upper + p1(i+1)) * x END DO aug = upper / (den + q2(4)) - 0.5e0_dp / x + aug 350 fn_val = aug + LOG(x) END FUNCTION psi END MODULE beta_gamma_psi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42185
[Bug objc++/42156] [4.5 Regression] Hundreds of objc++ testsuite regressions
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-11-26 19:29 --- This patch on x86_64-apple-darwin10 returns the obj-c++ testsuite results back to their previous results of... === obj-c++ Summary === # of expected passes398 # of unexpected failures52 # of unexpected successes 3 # of expected failures 15 # of unresolved testcases 1 # of unsupported tests 1 so it seems to be working fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug c++/42187] New: ice when inlined_to pointer set for noninline callers
I just tried to compile package boswars-2.5 with the GNU C++ compiler version 4.5 snapshot 20091119 and the compiler said engine/guichan/widgets/textbox.cpp:595:1: error: inlined_to pointer set for noninline callers engine/guichan/widgets/textbox.cpp:595:1: error: multiple inline callers std::basic_string_CharT, _Traits, _Alloc::size_type std::basic_string_CharT, _Traits, _Alloc::_M_check(std::basic_string_CharT, _Traits, _Alloc::size_type, const char*) const [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar, std::basic_string_CharT, _Traits, _Alloc::size_type = long unsigned int]/423(-1) @0x7ff593464aa0 (inline copy in virtual bool gcn::TextBox::keyPress(const gcn::Key)/340) availability:available 5 time, 15 benefit 7 size, 6 benefit reachable body finalized inlinable called by: std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::insert(std::basic_string_CharT, _Traits, _Alloc::size_type, const std::basic_string_CharT, _Traits, _Alloc, std::basic_string_CharT, _Traits, _Alloc::size_type, std::basic_string_CharT, _Traits, _Alloc::size_type) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar, std::basic_string_CharT, _Traits, _Alloc::size_type = long unsigned int]/449 (1.00 per call) (can throw external) std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::insert(std::basic_string_CharT, _Traits, _Alloc::size_type, const std::basic_string_CharT, _Traits, _Alloc, std::basic_string_CharT, _Traits, _Alloc::size_type, std::basic_string_CharT, _Traits, _Alloc::size_type) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar, std::basic_string_CharT, _Traits, _Alloc::size_type = long unsigned int]/435 (0.00 per call) (inlined) (can throw external) calls: void std::__throw_out_of_range(const char*)/642 (can throw external) engine/guichan/widgets/textbox.cpp:595:1: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O2 required. -- Summary: ice when inlined_to pointer set for noninline callers Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42187
[Bug c++/42187] ice when inlined_to pointer set for noninline callers
--- Comment #1 from dcb314 at hotmail dot com 2009-11-26 20:05 --- Created an attachment (id=19158) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19158action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42187
[Bug c++/35112] [4.3/4.4/4.5 regression] ICE and broken diagnostic with ambiguous class name
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35112
[Bug c++/42026] [DR 239] g++ violate [basic.lookup.argdep]
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-26 20:58 --- Subject: Bug 42026 Author: jason Date: Thu Nov 26 20:58:47 2009 New Revision: 154686 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154686 Log: PR c++/42026, DR 239 * parser.c (cp_parser_postfix_expression): A local extern also prevents arg-dependent lookup. Added: trunk/gcc/testsuite/g++.dg/lookup/koenig8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42026
[Bug fortran/42188] New: F03:C612. The leftmost part-name shall be the name of a data object.
Follow-up to PR42048. Consider the following code: module grid_module implicit none type grid contains procedure :: new_grid procedure :: new_int end type contains subroutine new_grid(this) class(grid) :: this end subroutine integer function new_int(this) class(grid) :: this new_int = 42 end function end module module field_module use grid_module implicit none type field type(grid) :: mesh end type contains type(field) function new_field() end function subroutine test integer :: i type(grid) :: g g = new_field()%mesh call new_field()%mesh%new_grid() i = new_field()%mesh%new_int() end subroutine end module which is currently rejected with test.f90:41.3: g = new_field()%mesh 1 Error: Unclassifiable statement at (1) test.f90:42.19: call new_field()%mesh%new_grid() 1 Error: Syntax error in CALL statement at (1) test.f90:43.3: i = new_field()%mesh%new_int() 1 Error: Unclassifiable statement at (1) Rejecting it is fine, I think, but the error messages should be improved. ifort says error #6837: The leftmost part-ref in a data-ref can not be a function reference. The relevant parts from the standard are: R612 data-ref is part-ref [ % part-ref ] ... R613 part-ref is part-name [ ( section-subscript-list ) ] C612 (R612) The leftmost part-name shall be the name of a data object. 2.4.3.1 Data object A data object (often abbreviated to object) is a constant (4.1.2), a variable (6), or a subobject of a constant. -- Summary: F03:C612. The leftmost part-name shall be the name of a data object. Product: gcc Version: 4.5.0 Status: UNCONFIRMED 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=42188
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #13 from janus at gcc dot gnu dot org 2009-11-26 21:05 --- Comment #4 is fixed with r154679. For the issues in comment #6 to #10 I have opened PR42188, so this one can be closed. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug c++/42026] [DR 239] g++ violate [basic.lookup.argdep]
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-26 21:11 --- Fixed for 4.5. -- 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=42026
[Bug c/42184] Same literal behaves differently as a double than as a long double
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-11-26 21:11 --- Well FreeBSD has slightly different default x87 precision setting . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42184
[Bug c/42184] Same literal behaves differently as a double than as a long double
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-26 21:15 --- 1.6646342e21 will produce a double and then that is extended into long double. On the other hand 1.6646342e21L is a long double so it is parsed what you expect into a long double. 1 0 1 0 is the correct value for x87 (80bit long double). -- 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=42184
[Bug rtl-optimization/38582] excessive time in rename registers
--- Comment #5 from bernds at gcc dot gnu dot org 2009-11-26 21:35 --- Subject: Bug 38582 Author: bernds Date: Thu Nov 26 21:35:35 2009 New Revision: 154687 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154687 Log: PR rtl-opt/38582 * regrename.c (struct du_chain): Remove member earlyclobber. (scan_rtx_reg): Don't set it. Remove argument earlyclobber, all callers changed. (scan_rtx): Remove argument earlyclobber, all callers changed. (hide_operands, restore_operands, record_out_operands): New functions, broken out of build_def_use. (build_def_use): Call them as necessary. Modified: trunk/gcc/ChangeLog trunk/gcc/regrename.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38582
[Bug rtl-optimization/38582] excessive time in rename registers
--- Comment #6 from bernds at gcc dot gnu dot org 2009-11-26 21:41 --- Subject: Bug 38582 Author: bernds Date: Thu Nov 26 21:41:42 2009 New Revision: 154688 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154688 Log: PR rtl-opt/38582 * regrename.c (struct du_head): New members id, conflicts, hard_conflicts and cannot_rename. (enum scan_actions): Remove terminate_all_read and terminate_overlapping_read; add mark_all_read. (scan_actions_name): Likewise. (du_head_p): New typedef. Define a vector type for it. (id_to_chain): New static variable. (note_sets, clear_dead_regs): Delete functions. (free_chain_data): New function. (merge_overlapping_regs): Simply walk the conflicts bitmap. Remove argument B, all callers changed. (regrename_optimize): Allocate id_to_chain. Ignore chains that have the cannot_rename bit set. Update regno and nregs of a renamed chain. Call free_chain_data when done. (do_replace): Remove death notes when the renamed reg is set in the last insn; add them if not. (mark_conflict, note_sets_clobbers): New static function. (fail_current_block, current_id, open_chains_set, live_hard_regs): New static variables. (scan_rtx_reg): Keep track of conflicts between chains, and between chains and hard regs. Don't terminate chains when we find a read we can't handle, mark it unrenameable instead. For terminate_write, terminate chains that are written with an exact match or a superset of registers. Set fail_current_block if multi-word lifetimes are too complex to handle. (scan_rtx_address): Use mark_all_read instead of terminate_all_read. (build_def_use): Initialize current_id, live_chains and live_hard_regs; free memory for them when done. Rearrange the steps so that earlyclobbers are noted before reads are processed. Add new steps to keep track of hard register lifetimes outside insn operands. Modified: trunk/gcc/ChangeLog trunk/gcc/regrename.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38582
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #9 from burnus at gcc dot gnu dot org 2009-11-26 21:46 --- The following assert is wrong: gcc_assert (src_info-dimen == 2); (and has been removed in the comment patch of comment 7). I only want to link to an email which gives the reason why. http://gcc.gnu.org/ml/fortran/2009-11/msg00212.html -- burnus 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #27 from jvdelisle at gcc dot gnu dot org 2009-11-26 21:53 --- Subject: Bug 41807 Author: jvdelisle Date: Thu Nov 26 21:52:52 2009 New Revision: 154690 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154690 Log: 2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41807 * trans-const.c (gfc_conv_const): Set se-expr to a constant on error. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug fortran/42131] Weird translation of DO loops
--- Comment #13 from tkoenig at gcc dot gnu dot org 2009-11-26 21:56
---
Created an attachment (id=19159)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19159action=view)
patch that implements the multiplication idea
This generates
if (D.1339 0)
{
if (D.1338 D.1337)
{
goto L.2;
}
else
{
step_sign.2 = 1;
}
}
else
{
if (D.1338 D.1337)
{
goto L.2;
}
else
{
step_sign.2 = -1;
}
}
countm1.1 = (((character(kind=4)) D.1338 - (character(kind=4)) D.1337) *
(character(kind=4)) step_sign.2) / (character(kind=4)) (step_sign.2 * D.1339);
implementing the multiplication idea outlined above, and passes at
least do_3.F90.
Better?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Attachment #19104|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #28 from jvdelisle at gcc dot gnu dot org 2009-11-26 21:57 --- Subject: Bug 41807 Author: jvdelisle Date: Thu Nov 26 21:57:32 2009 New Revision: 154691 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154691 Log: 2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41807 Backport from mainline. * trans-const.c (gfc_conv_const): Fix typo in comment. Replace assert with error message if not constant. Set se-expr to a constant on error. * resolve.c (next_data_value): Delete check for constant. Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/resolve.c branches/gcc-4_4-branch/gcc/fortran/trans-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug fortran/42189] New: gfc_is_constant_expr has unacceptable side effects
Follow up to PR 41807 - based on the comment at http://gcc.gnu.org/ml/fortran/2009-11/msg00181.html cf. also http://gcc.gnu.org/ml/fortran/2009-11/msg00208.html it is both unacceptable and unanticipated that gfc_is_constant_expr have side effects like that. Should we, perhaps copy the expression within gfc_is_constant_expr, test that and free the new expression before exiting? and in http://gcc.gnu.org/ml/fortran/2009-11/msg00185.html I think we have some other bugs lurking here. For example, why could we simplify the original expr in get_array_index and not it's copy. gfc_copy_expr is missing something. The gfc_is_constant_expr issue is down in gfc_constant_ac. I think we may be trying to expand the constructors in more than one place, in gfc_constant_ac and somewhere else. -- Summary: gfc_is_constant_expr has unacceptable side effects 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: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42189
[Bug fortran/42131] Weird translation of DO loops
--- Comment #14 from kargl at gcc dot gnu dot org 2009-11-26 22:07 --- (In reply to comment #13) } countm1.1 = (((character(kind=4)) D.1338 - (character(kind=4)) D.1337) * (character(kind=4)) step_sign.2) / (character(kind=4)) (step_sign.2 * D.1339); implementing the multiplication idea outlined above, and passes at least do_3.F90. Better? Looks much better than the current situation. Is there a valid reason for the character(kind=4) casts? I would have thought that this should be a integer(kind=4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug ada/42190] New: instantiation incorrectly considered allocation for restrictions check
The following program pragma Restrictions (No_Local_Allocators); procedure Restrict_Bug is generic package Generic_Pkg is I : Integer; end Generic_Pkg; package Instance is new Generic_Pkg; begin null; end Restrict_Bug; creates the error message: gnatmake -v restrict_bug GNATMAKE 4.4.2 Copyright (C) 1995-2008, Free Software Foundation, Inc. restrict_bug.ali being checked ... - restrict_bug.ali missing. gcc -c restrict_bug.adb restrict_bug.adb:10:04: violation of restriction No_Local_Allocators at line 1 End of compilation gnatmake: restrict_bug.adb compilation error -- Summary: instantiation incorrectly considered allocation for restrictions check Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rolf dot ebert dot gcc at gmx dot de GCC host triplet: MinGW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42190
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-11-26 22:11 --- Just a note of appreciation to Chris for reporting this bug and providing a simple and extremely useful test case. When I get a moment, I will add Chris to the test case as recognition. Shall we backport this fix to 4.4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #29 from jvdelisle at gcc dot gnu dot org 2009-11-26 22:18 --- Subject: Bug 41807 Author: jvdelisle Date: Thu Nov 26 22:18:36 2009 New Revision: 154692 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154692 Log: 2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41807 * gfortran.dg/data_value_1.f90: Update test. * gfortran.dg/array_constructor_32.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/array_constructor_32.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/data_value_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2009-11-26 22:21 --- Fixed on trunk and 4.4. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #85 from howarth at nitro dot med dot uc dot edu 2009-11-26
22:35 ---
Created an attachment (id=19160)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19160action=view)
combined patch that fixes dsymutil asserts
Combined patches...
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01329.html
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01452.html
with hand merge of section...
@@ -15719,17 +15705,19 @@ add_location_or_const_value_attribute (d
a constant value. That way we are better to use
add_const_value_attribute
rather than expanding constant value equivalent. */
loc_list = lookup_decl_loc (decl);
- if (loc_list loc_list-first loc_list-first == loc_list-last)
+ if (loc_list loc_list-first loc_list-first == loc_list-last
+ loc_list-first-var_loc_note
+ NOTE_VAR_LOCATION (loc_list-first-var_loc_note)
+ NOTE_VAR_LOCATION_LOC (loc_list-first-var_loc_note))
{
enum var_init_status status;
struct var_loc_node *node;
node = loc_list-first;
status = NOTE_VAR_LOCATION_STATUS (node-var_loc_note);
- rtl = NOTE_VAR_LOCATION (node-var_loc_note);
- if (GET_CODE (rtl) == VAR_LOCATION
- GET_CODE (XEXP (rtl, 1)) != PARALLEL)
- rtl = XEXP (XEXP (rtl, 1), 0);
+ rtl = NOTE_VAR_LOCATION_LOC (node-var_loc_note);
+ if (GET_CODE (rtl) != PARALLEL)
+ rtl = XEXP (rtl, 0);
if ((CONSTANT_P (rtl) || GET_CODE (rtl) == CONST_STRING)
add_const_value_attribute (die, rtl))
return true;
against current gcc trunk. This patch eliminates all of the asserts in dsymutil
during a bootstrap of gcc trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
