Re: Boehm-gc performance data
On 23/06/06, Laurynas Biveinis [EMAIL PROTECTED] wrote: I'm still waiting for the testsuite to complete (it's been running just for about 24 hours so far). In the meanwhile I'd like to discuss the first performance results, which I've put on the Wiki: First number is GCC with Boehm's GC and the number in parentheses is GCC with page collector. combine.c: top mem usage: 52180k (13915k). GC execution time 0.66 (0.61) 4% (4%). User running time: 0m16 (0m14). How are you collecting top mem usage? Thanks, -- Paulo Jorge Matos - pocm at sat inesc-id pt Web: http://sat.inesc-id.pt/~pocm Computer and Software Engineering INESC-ID - SAT Group
Re: unable to detect exception model
On Jun 24, 2006, at 6:58 AM, Andrew Pinski wrote: I can reproduce this, something is miscompiling cc1plus. If I revert: 2006-06-23 Richard Guenther [EMAIL PROTECTED] * ggc-page.c (init_ggc): Do not round up the extra_order_size_table sizes to MAX_ALIGNMENT. Fix the size_lookup table to honour alignment requests instead. Add verification code. Add struct tree_function_decl and struct tree_binfo size to extra_order_size_table. Add missing element to size_lookup table. Bootstrap works. Thanks, Andrew Pinski
Re: unable to detect exception model
On Sun, 25 Jun 2006, Andrew Pinski wrote:
On Jun 24, 2006, at 6:58 AM, Andrew Pinski wrote:
I can reproduce this, something is miscompiling cc1plus.
If I revert:
2006-06-23 Richard Guenther [EMAIL PROTECTED]
* ggc-page.c (init_ggc): Do not round up the extra_order_size_table
sizes to MAX_ALIGNMENT. Fix the size_lookup table to honour
alignment requests instead. Add verification code.
Add struct tree_function_decl and struct tree_binfo size to
extra_order_size_table. Add missing element to size_lookup
table.
Bootstrap works.
How does size_loopup look like? And object_size_table? Does
Index: ggc-page.c
===
--- ggc-page.c (revision 114974)
+++ ggc-page.c (working copy)
@@ -1574,8 +1574,9 @@ init_ggc (void)
/* Verify we got everything right with respect to alignment requests.
*/
for (order = 1; order 512; ++order)
-gcc_assert (ffs (OBJECT_SIZE (size_lookup [order]))
- = ffs (order | MAX_ALIGNMENT));
+gcc_assert ((ffs (OBJECT_SIZE (size_lookup [order]))
+= ffs (order | MAX_ALIGNMENT))
+order = OBJECT_SIZE (size_lookup [order]));
G.depth_in_use = 0;
G.depth_max = 10;
pass? What is MAX_ALIGNMENT on ppc-darwin? It's defined as
struct max_alignment {
char c;
union {
HOST_WIDEST_INT i;
long double d;
} u;
};
/* The biggest alignment required. */
#define MAX_ALIGNMENT (offsetof (struct max_alignment, u))
I would guess this exposes a latent GC problem, do you have a testcase
or a .o file that is miscompiled? Does it reproduce with different
gc --parms? Does ppc-darwin use the USING_MMAP variant?
It would be nice if you can track down this some more, as I do not
have access to ppc-darwin.
Richard.
--
Richard Guenther [EMAIL PROTECTED]
Novell / SUSE Labs
Re: unable to detect exception model
On Sun, Jun 25, 2006 at 07:59:14PM +0200, Richard Guenther wrote:
pass? What is MAX_ALIGNMENT on ppc-darwin? It's defined as
struct max_alignment {
char c;
union {
HOST_WIDEST_INT i;
long double d;
} u;
};
/* The biggest alignment required. */
#define MAX_ALIGNMENT (offsetof (struct max_alignment, u))
I learned while working on the zone collector that there is at least
one platform where this doesn't work, because long double had an
alignment of eight on its own and four as a structure field. It might
have been powerpc-darwin.
--
Daniel Jacobowitz
CodeSourcery
Re: unable to detect exception model
On Jun 25, 2006, at 11:12 AM, Daniel Jacobowitz wrote:
I learned while working on the zone collector that there is at least
one platform where this doesn't work, because long double had an
alignment of eight on its own and four as a structure field. It might
have been powerpc-darwin.
Maybe the struct should be rewritten like:
struct max_alignment {
char c;
union {
long double d;
HOST_WIDEST_INT i;
} u;
};
To make sure the long double was first which is usually the cures the
whole struct
alignment issues.
I will see if this fixes the issue but after I finish watching Dr. Who.
Thanks,
Andrew Pinski
Re: Boehm-gc performance data
2006/6/25, Paulo J. Matos [EMAIL PROTECTED]: combine.c: top mem usage: 52180k (13915k). GC execution time 0.66 (0.61) 4% (4%). User running time: 0m16 (0m14). How are you collecting top mem usage? Sorry, that's not the top mem usage, but rather peak GC allocated bytes. Determining them is easy from -Q output. -- Laurynas
Re: unable to detect exception model
On Sun, Jun 25, 2006 at 11:19:45AM -0700, Andrew Pinski wrote:
Maybe the struct should be rewritten like:
struct max_alignment {
char c;
union {
long double d;
HOST_WIDEST_INT i;
} u;
};
To make sure the long double was first which is usually the cures the
whole struct
alignment issues.
It's a union. If that makes a difference the platform ABI is
hopelessly broken.
Anyway, I'm thinking of MAX_FIELD_ALIGNMENT or something like that.
--
Daniel Jacobowitz
CodeSourcery
Re: unable to detect exception model
On 6/25/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Sun, Jun 25, 2006 at 07:59:14PM +0200, Richard Guenther wrote:
pass? What is MAX_ALIGNMENT on ppc-darwin? It's defined as
struct max_alignment {
char c;
union {
HOST_WIDEST_INT i;
long double d;
} u;
};
/* The biggest alignment required. */
#define MAX_ALIGNMENT (offsetof (struct max_alignment, u))
I learned while working on the zone collector that there is at least
one platform where this doesn't work, because long double had an
alignment of eight on its own and four as a structure field. It might
have been powerpc-darwin.
Though that particular part of ggc-page is the same before and after
the patch. Of course we may now get MAX_ALIGNMENT alignment
where we got MAX_ALIGNMENT*2 before.
Richard.
Re: unable to detect exception model
It would be nice if you can track down this some more, as I do not have access to ppc-darwin. And to SPARC/Solaris 32-bit? :-) /opt/build/eric/gcc/./gcc/xgcc -B/opt/build/eric/gcc/./gcc/ -B/opt/build/eric/local/gcc/sparc-sun-solaris2.7/bin/ -B/opt/build/eric/local/gcc/sparc-sun-solaris2.7/lib/ -isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.7/include -isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.7/sys-include -O2 -g -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I/home/eric/svn/gcc/gcc -I/home/eric/svn/gcc/gcc/. -I/home/eric/svn/gcc/gcc/../include -I./../intl -I/home/eric/svn/gcc/gcc/../libcpp/include -I/opt/build/eric/local/include -I/opt/build/eric/local/include -I/home/eric/svn/gcc/gcc/../libdecnumber -I../libdecnumber \ -c /home/eric/svn/gcc/gcc/config/sparc/gmon-sol2.c -o gmon.o /home/eric/svn/gcc/gcc/config/sparc/gmon-sol2.c:1: internal compiler error: BusError Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. gmake[3]: *** [gmon.o] Error 1 gmake[3]: Leaving directory `/opt/build/eric/gcc/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/opt/build/eric/gcc' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc' gmake: *** [all] Error 2 Reverting your patch makes it go away too. I'll try and look into it tomorrow. -- Eric Botcazou
Re: unable to detect exception model
On 6/25/06, Eric Botcazou [EMAIL PROTECTED] wrote: It would be nice if you can track down this some more, as I do not have access to ppc-darwin. And to SPARC/Solaris 32-bit? :-) No ;) But I verified that i386-apple-darwin still works. Also ppc-aix still works. /opt/build/eric/gcc/./gcc/xgcc -B/opt/build/eric/gcc/./gcc/ -B/opt/build/eric/local/gcc/sparc-sun-solaris2.7/bin/ -B/opt/build/eric/local/gcc/sparc-sun-solaris2.7/lib/ -isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.7/include -isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.7/sys-include -O2 -g -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I/home/eric/svn/gcc/gcc -I/home/eric/svn/gcc/gcc/. -I/home/eric/svn/gcc/gcc/../include -I./../intl -I/home/eric/svn/gcc/gcc/../libcpp/include -I/opt/build/eric/local/include -I/opt/build/eric/local/include -I/home/eric/svn/gcc/gcc/../libdecnumber -I../libdecnumber \ -c /home/eric/svn/gcc/gcc/config/sparc/gmon-sol2.c -o gmon.o /home/eric/svn/gcc/gcc/config/sparc/gmon-sol2.c:1: internal compiler error: BusError Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. gmake[3]: *** [gmon.o] Error 1 gmake[3]: Leaving directory `/opt/build/eric/gcc/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/opt/build/eric/gcc' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc' gmake: *** [all] Error 2 Reverting your patch makes it go away too. I'll try and look into it tomorrow. At least this one looks easier to look at. Is SPARC/Solaris a strict alignment target? Richard.
Re: unable to detect exception model
On Sun, 25 Jun 2006, Eric Botcazou wrote:
At least this one looks easier to look at. Is SPARC/Solaris a
strict alignment target?
Yes, all SPARC targets are.
So, something obviously wrong with
struct max_alignment {
char c;
union {
HOST_WIDEST_INT i;
long double d;
} u;
};
/* The biggest alignment required. */
#define MAX_ALIGNMENT (offsetof (struct max_alignment, u))
for SPARC 32bit?
Richard.
--
Richard Guenther [EMAIL PROTECTED]
Novell / SUSE Labs
Re: unable to detect exception model
So, something obviously wrong with
struct max_alignment {
char c;
union {
HOST_WIDEST_INT i;
long double d;
} u;
};
/* The biggest alignment required. */
#define MAX_ALIGNMENT (offsetof (struct max_alignment, u))
for SPARC 32bit?
I don't think so, the ABI says 8 in both cases.
Note that bootstrap doesn't fail on SPARC/Solaris 2.[56] and (presumably)
SPARC/Linux, which have HOST_WIDE_INT == 32, whereas SPARC/Solaris 7+ have
HOST_WIDE_INT == 64. All are 32-bit compilers.
Bootstrap doesn't fail on SPARC64/Solaris 7+ either, for which the ABI says 16
for the alignment in both cases. They are 64-bit compilers.
--
Eric Botcazou
RE: RFC: __cxa_atexit for mingw32
From: Ranjit Mathew Sent: Sunday, June 25, 2006 1:28 PM Danny Smith wrote: Adding a real __cxa_atexit to mingw runtime is of course also possible, but I thought I'd attempt the easy options first. When you say runtime, do you mean libstdc++ or something like libmingwex.a in mingw-runtime? If you mean the former, you can add this in for GCC 4.2 and work on a real __cxa_atexit() for GCC 4.3, if you want. A real __cxa_atexit solution needs to be integrated into the mingw-runtime. The initialization and finalization of the at-exit tables needs to be handled by mainCRTStartup/DllMainCRTStartup and the C runtime functions _onexit, atexit and possibly dllonexit need to rewritten as wrappers around cxa_atexit. As it turns out, that is fairly simple: eg., the version of __cxa_atexit and friends that is in the STLPort library translate to mingw quite easily with a few minor tweaks to accomodate the win32 API. And integrating atexit/_onexit into cxa_atexit is facilitated by the fact that the msvcrt versions of these functions are exported only as _imp__ prefixed indirect references, so that we can avoid getting mixed up with MS version of these functions.I have tested all that with a basic single-threaded implementation and no problems. But that won't happen before 4.2 is released. I don't know how difficult it will be to convince other mingw developers that this idea is a good thing: replace an ISO standard-conformant and perfectly adequate atexit function already supplied by OS vendor with a new version, perhaps with some licensing strings attached. I expect the fake cxa_atexit hack I illustrated earlier would meet less resistance, and that is why I considered it the easier option. Me? The __cxa_atexit behaviour is documented. AFAICT, the msvcrt-specific behaviour of the atexit and dllonexit functions is not, and was 'discovered' by a lot of trial and error. So, today, I'd prefer to implement a real __cxa_atexit and point users to the ABI specs. Thanks for replying to this thread, Ranjit. We'll see if any other mingw developers read this list. Danny Thanks, Ranjit.
How can I remove articles posted under my name?
Hello, As the title says, how can I remove articles posted under my name Alexander Verhaeghe or e-mailaddress alexanderverhaeghe at yahoo dot com When I do a search in http://gcc.gnu.org/lists.html I get 8 results which I would like to have removed, espcially when they popup in the searchengines. My next mail will be a list of e-mailaddresses that don't work! Regards, Alexander Verhaeghe __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: How can I remove articles posted under my name?
On Sun, 25 Jun 2006, Alexander Verhaeghe wrote: As the title says, how can I remove articles posted under my name Alexander Verhaeghe or e-mailaddress alexanderverhaeghe at yahoo dot com You can't. And by shot-gunning your request to [EMAIL PROTECTED], [EMAIL PROTECTED], gcc@gcc.gnu.org, [EMAIL PROTECTED] (which probably was ment to read gnu.org), [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] you certainly aren't doing yourself a favor and, by the way, just generated another couple of hits in the archives. Plus, even if we removed the message posted by you, there still would me those where others responded and quoted from your original message, and we definitely do not want to touch those. Obviously, you have not bothered to read the footer we carefully put on every single page at http://gcc.gnu.org, have you? Gerald
Re: How can I remove articles posted under my name?
On 6/26/06, Alexander Verhaeghe [EMAIL PROTECTED] wrote: As the title says, how can I remove articles posted under my name Alexander Verhaeghe or e-mailaddress alexanderverhaeghe at yahoo dot com You can not. And it would not be very useful either, because all the lists you sent mail to are archived in a lot more places than just gcc.gnu.org. Sorry. Gr. Steven
Re: Boehm-gc performance data
On 25/06/06, Laurynas Biveinis [EMAIL PROTECTED] wrote: 2006/6/25, Paulo J. Matos [EMAIL PROTECTED]: combine.c: top mem usage: 52180k (13915k). GC execution time 0.66 (0.61) 4% (4%). User running time: 0m16 (0m14). How are you collecting top mem usage? Sorry, that's not the top mem usage, but rather peak GC allocated bytes. Determining them is easy from -Q output. Ah, ok! -- Laurynas -- Paulo Jorge Matos - pocm at sat inesc-id pt Web: http://sat.inesc-id.pt/~pocm Computer and Software Engineering INESC-ID - SAT Group
Re: How can I remove articles posted under my name?
[ cutting down the CC list ] Alexander Verhaeghe [EMAIL PROTECTED] wrote on Mon, 26 Jun 2006: As the title says, how can I remove articles posted under my name Alexander Verhaeghe or e-mailaddress alexanderverhaeghe at yahoo dot com When I do a search in http://gcc.gnu.org/lists.html I get 8 results which I would like to have removed, espcially when they popup in the searchengines. You've just added another 2 to that list. Had you not misspelled gnu.org once that would have been three. Needless to say that these 2 will be reproduced on several other list archives, including gmane.org which you found before. Please stop spamming the lists with requests to be removed from the list archives hosted on gcc.gnu.org and other, unrelated sites. As other people have pointed out to you, this is not going to happen (reg. my previous answers, I might add that I wasn't aware that there's a policy in place against this, but it makes a lot of sense), and the lists themselves are the wrong place to ask for this. If you don't want your address published, this originally happened a year ago, when you originally posted to the list and only turning back time can revert this fact. If you don't want unfavorably looking posts appearing in a google search of your name, you've not done yourself a favor with today's series of posts. Sorry, - Tobi This message was sent using IMP, the Internet Messaging Program.
Free as in Freedom
Free as in Freedom in http://www.gnu.org/home.html#ContactInfo You're not even able to remove a couple of messages, so how free am I now? [EMAIL PROTECTED] wanted $300 for removal! How free am I now? You should be ashamed of yourselves! Not only privacy is not respected, [EMAIL PROTECTED] also threatened that more hits would be generated in the archives, [EMAIL PROTECTED] shouldn't do that, it's against privacy in case you didn't realize! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Question concerning shared libraries in non-standard locations
I have a situation (on Linux or Solaris, at least), in which I install versions of GCC in non-standard directories (specifically, directories not owned operated by root). With such an installation, when a GCC link finds a definition of an external reference in a shared library that is part of the .../lib subdirectory used by this installation, it treats the shared library as if it were also installed in one of the standard locations known to the dynamic linker, and does NOT store the path to the directory in which that library is found. The result is that to run the linked executable, one must either 1. Add this non-standard directory to one's LD_LIBRARY_PATH, or 2. Remember to include the appropriate -W,l-R option or whatever in and every compilation. For C programs, this is seldom an issue, although it can be if one uses -shared-libgcc. It's more problematic with G++, where a simple Hello World program that uses iostream requires this special treatment. Of course, I could just install everything in a standard location, but I keep several versions of GCC around, so that is not the best solution. Besides which, as a DEFAULT behavior, this strikes me as odd---linking against a standard shared library that the compiler (in principle) KNOWS will likely be unavailable or incompatible at execution. Of course, it's easy to come up with cases where you really want to make sure that the runtime link is satisfied from some standard location, so the current behavior has to be supported, but isn't it a little odd as a default? Comments and instructions as to how to configure my local GCC builds to do what I want by default (which in this case means recording the path to the non-standard library in the executables) welcome. Thanks. Paul Hilfinger
Re: Free as in Freedom
On Sun, 2006-06-25 16:44:22 -0700, Alexander Verhaeghe [EMAIL PROTECTED] wrote: Not only privacy is not respected, [EMAIL PROTECTED] also threatened that more hits would be generated in the archives, [EMAIL PROTECTED] shouldn't do that, it's against privacy in case you didn't realize! This is the internet. It's where people work together and share data. If you want to do that in private, use a VPN. If you want to be in private, just don't post emails to publically archived mailing lists. That's not hard, but it's too late right now. You've done that mistake and you cannot turn back time. So please shut up now. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: Free as in Freedom
Quote Jan-Benedict Glaw So please shut up now. Quite friendly I must say, it's the german way I suppose of handling things? To Jan-Benedict Glaw I WON'T SHUT UP because of Free as in Freedom! --- Jan-Benedict Glaw [EMAIL PROTECTED] wrote: On Sun, 2006-06-25 16:44:22 -0700, Alexander Verhaeghe [EMAIL PROTECTED] wrote: Not only privacy is not respected, [EMAIL PROTECTED] also threatened that more hits would be generated in the archives, [EMAIL PROTECTED] shouldn't do that, it's against privacy in case you didn't realize! This is the internet. It's where people work together and share data. If you want to do that in private, use a VPN. If you want to be in private, just don't post emails to publically archived mailing lists. That's not hard, but it's too late right now. You've done that mistake and you cannot turn back time. So please shut up now. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: RFC: __cxa_atexit for mingw32
Danny Smith wrote: is a good thing: replace an ISO standard-conformant and perfectly adequate atexit function already supplied by OS vendor with a new version, perhaps with some licensing strings attached. I expect the fake cxa_atexit hack I illustrated earlier would meet less resistance, and that is why I considered it the easier option. This change would be contained in crt?.o dllcrt?.o, no? So that would mean it would get statically linked, with no additional runtime dependency. Assuming it was licensed the same way as the rest of the existing CRT startup code, I don't see how anyone could complain. It would give us proper __cxa_atexit support for essentially free. Brian
Re: Free as in Freedom
Always threatening, you're even worse than Microsoft... Once again Free as in Freedom, how dare you to use this? Please don't forget to mention that you want to rip me off $300! --- Robert Dewar [EMAIL PROTECTED] wrote: Alexander Verhaeghe wrote: Quote Jan-Benedict Glaw So please shut up now. Quite friendly I must say, it's the german way I suppose of handling things? To Jan-Benedict Glaw I WON'T SHUT UP because of Free as in Freedom! If I googled on your name and found this sort of absurd post, I would form conclusions right away. People will see these quotes for ever, they are not going away, they will follow you everywhere, is this what you want? Do you not understand that it is technically impossible to remove those posts, there are thousands of copies of this all over the net. By posting to this list, you gave consent to this massing reproduction of what you wrote, and it cannot be undone. Free as in freedom does not allow you to insist on other people removing your messages, and the idea that it violates privacy rules to refuse is absurd. On the contrary the operation of freedom here is that anyone anywhere has the ability and right to copy your posts, and thousands of people have already taken advantage of this permission that you gave by posting in the first place. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Free as in Freedom
On Sun, Jun 25, 2006 at 05:02:41PM -0700, Alexander Verhaeghe wrote: Quote Jan-Benedict Glaw So please shut up now. Quite friendly I must say, it's the german way I suppose of handling things? To Jan-Benedict Glaw I WON'T SHUT UP because of Free as in Freedom! However, you have been told quite clearly what the site policy is. None of the mailing lists at gcc.gnu.org are intended to be rant lists so you really do have to stop sending this type of email since it is off-topic for every list that you are using. If you can't stop yourself, then steps will be taken to block you from sending email here.
Re: Free as in Freedom
On Sun, 2006-06-25 17:02:41 -0700, Alexander Verhaeghe [EMAIL PROTECTED] wrote: To Jan-Benedict Glaw I WON'T SHUT UP because of Free as in Freedom! Ah, so your understanding of Freedom reads like: Okay guys, I've sent out some rude emails insulting you a bit about your fortran stuff and all. I've put that into publically archived mailing lists and I just ignored the fact of publically archived. Well, it seems to fuck up by bio and because of me being lame, please waste your time to search the archives for my name and drop them all, maybe even including replys etc. My reading of Freedom is more like: Heya, your mailing list archive sux because you cannot easily find a people's attitude there. I've taken all the HTML stuff and made it useful. With a single click, you can now find out if a person is only a lame guy not reading sources or documentation, yelling about it's inabilities and not doing any community work. See the difference? Freedom, as we see it, is the right to participate, not the right to let others work for you. But you'll learn that the other day. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: Free as in Freedom
On Sun, Jun 25, 2006 at 05:16:37PM -0700, Alexander Verhaeghe wrote: Always threatening, you're even worse than Microsoft... Once again Free as in Freedom, how dare you to use this? Please don't forget to mention that you want to rip me off $300! Alexander the email you requested removed at this link http://blog.gmane.org/gmane.comp.gcc.fortran/day=20050926# was written by me. You have no right to ask for my post to be removed. In viewing the above link, you will find On Sun, Sep 25, 2005 at 04:21:19PM -0700, Alexander Verhaeghe wrote: There is no email address at that link. It is however interesting to read your posts to Lahey and Microsoft forums. I suspect your recent spat of postings here has earned you many killfile entries. -- Steve
Re: Free as in Freedom
It is of course not a threat to point out that anything you post here will be permanently associated with your name for ever, and that there is no way to undo this. This is just a statement of fact. There is always a way of undoing things, it's simply a matter if you want to do so or not, and in this case clearly not. I don't see any reason why this conversation will be listed by just mailing a couple e-mailaddresses which I contacted before numerous times and no one responded for the simple reason they don't want to. Just delete all e-mailaddresses and state clearly that once posted it can not be undone. I'm almost sure that your practices are against the laws of privacy. Tomorrow I will check this out, as a matter of fact I already did. You have no right to publish things without permission. If all this crap is ever to be published, no one will believe, gnu.org is simply making itself ridiculous by publishing this. I just got another mail from Christopher Faylor, which threatens to block me from sending mail, why not, once again so much freedom... There isn't even freedom of speech here. Do I continue until I'm blocked? --- Robert Dewar [EMAIL PROTECTED] wrote: I did not mean my message at all as a threat, but just as some helpful advice. Note that it was sent only to you, not to the list. It is normally not a good idea to post such private messages to a public list without permission (and may indeed violate copyright, though that's not clear). For sure it is a violation of netiquette, so you add that to your record here. I respond to the list here just to make it clear that I did not post the message to the list. It is of course not a threat to point out that anything you post here will be permanently associated with your name for ever, and that there is no way to undo this. This is just a statement of fact. In our modern day and age, people will often google a name to find out more about someone, and when they do that, all your old posts will appear. Again, that's not a threat, just a statement of a fact that should be clear to anyone posting on any list. Alexander Verhaeghe wrote: Go ahead threatening people, it's all what you accomplished so far! You say Are you really sure, I don't even have the chance to say yes or no, so much freedom! That e-mail of $300 I will keep just in case... --- Robert Dewar [EMAIL PROTECTED] wrote: Are you really sure you want the below message to be permanently associated with your name, it is now .. and this association can never be removed. I think you should think before posting any more messages that will follow you around. Alexander Verhaeghe wrote: Free as in Freedom in http://www.gnu.org/home.html#ContactInfo You're not even able to remove a couple of messages, so how free am I now? [EMAIL PROTECTED] wanted $300 for removal! How free am I now? You should be ashamed of yourselves! Not only privacy is not respected, [EMAIL PROTECTED] also threatened that more hits would be generated in the archives, [EMAIL PROTECTED] shouldn't do that, it's against privacy in case you didn't realize! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Free as in Freedom
Please tell me where I can read this spat of postings so that I can evaluate them. I guess I have to change emailaddress (not difficult) and name (more difficult) after this stuff. I never typed so much in a short time! --- Steve Kargl [EMAIL PROTECTED] wrote: On Sun, Jun 25, 2006 at 05:16:37PM -0700, Alexander Verhaeghe wrote: Always threatening, you're even worse than Microsoft... Once again Free as in Freedom, how dare you to use this? Please don't forget to mention that you want to rip me off $300! Alexander the email you requested removed at this link http://blog.gmane.org/gmane.comp.gcc.fortran/day=20050926# was written by me. You have no right to ask for my post to be removed. In viewing the above link, you will find On Sun, Sep 25, 2005 at 04:21:19PM -0700, Alexander Verhaeghe wrote: There is no email address at that link. It is however interesting to read your posts to Lahey and Microsoft forums. I suspect your recent spat of postings here has earned you many killfile entries. -- Steve __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Free as in Freedom
Alexander Verhaeghe wrote: Always threatening, you're even worse than Microsoft... Once again Free as in Freedom, how dare you to use this? Please don't forget to mention that you want to rip me off $300! First of all, again you are quoting my private messages. Second, the $300 has nothing to do with me, though I see no objection to people charging for work you ask them to do on your behalf. Third, can't you get it through your head that no threats are involved here, just some very basic statements of facts. You seem to be unaware of these facts as was clear from your initial post. This is certainly off-topic noise but on the other hand perhaps it is instructive to any others following this list who may be sharing the same misconceptions as Alexander. Anyway, I am killing this thread now, and apologies to anyone annoyed by these messages. In both the last two cases, I made the mistake of sending private advice to Alexander, clearly something that is not helpful in this situation. --- Robert Dewar [EMAIL PROTECTED] wrote: Alexander Verhaeghe wrote: Quote Jan-Benedict Glaw So please shut up now. Quite friendly I must say, it's the german way I suppose of handling things? To Jan-Benedict Glaw I WON'T SHUT UP because of Free as in Freedom! If I googled on your name and found this sort of absurd post, I would form conclusions right away. People will see these quotes for ever, they are not going away, they will follow you everywhere, is this what you want? Do you not understand that it is technically impossible to remove those posts, there are thousands of copies of this all over the net. By posting to this list, you gave consent to this massing reproduction of what you wrote, and it cannot be undone. Free as in freedom does not allow you to insist on other people removing your messages, and the idea that it violates privacy rules to refuse is absurd. On the contrary the operation of freedom here is that anyone anywhere has the ability and right to copy your posts, and thousands of people have already taken advantage of this permission that you gave by posting in the first place. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Free as in Freedom
On Sun, Jun 25, 2006 at 05:43:41PM -0700, Alexander Verhaeghe wrote: Please tell me where I can read this spat of postings so that I can evaluate them. I guess I have to change emailaddress (not difficult) and name (more difficult) after this stuff. I never typed so much in a short time! Well, to start with you can go to http://gcc.gnu.org/ml/fortran/2006-06/ Look for post by Alexander Verhaeghe. These posts will soon be mirrored. Your google hits are going up. -- Steve
ADMINISTRIVIA about Re: Free as in Freedom
I thought I should point out that this thread has hit the too many recipients spam blocking rule at gcc.gnu.org so there are a number of messages from various people (but mostly from Alexander) which are not making it to the mailing list. cgf
Re: unable to detect exception model
On 6/25/06, Eric Botcazou [EMAIL PROTECTED] wrote:
So, something obviously wrong with
struct max_alignment {
char c;
union {
HOST_WIDEST_INT i;
long double d;
} u;
};
/* The biggest alignment required. */
#define MAX_ALIGNMENT (offsetof (struct max_alignment, u))
for SPARC 32bit?
I don't think so, the ABI says 8 in both cases.
Note that bootstrap doesn't fail on SPARC/Solaris 2.[56] and (presumably)
SPARC/Linux, which have HOST_WIDE_INT == 32, whereas SPARC/Solaris 7+ have
HOST_WIDE_INT == 64. All are 32-bit compilers.
Bootstrap doesn't fail on SPARC64/Solaris 7+ either, for which the ABI says 16
for the alignment in both cases. They are 64-bit compilers.
SPARC psABI3.0 (32bit version) defines long double as 8 byte aligned.
SCD4.2, 64bit version, defines long double as 16 byte aligned with some caveat
(which essentially says long double can be 8-byte aligned in some cases
- fortran common block case - but the compiler should assume
16-byte unless it can prove otherwise).
On 32bit ABI, there's also a possiblity of doubles being only 4-byte aligned
when a double is passed on the stack.
I don't know enough about gcc's gc to know whether the above can trip it over,
but the memory allocation (malloc and the likes) shouldn't be a
problem as long as
it returns 8-byte aligned block on 32bit and 16-byte aligned on 64bit.
--
#pragma ident Seongbae Park, compiler, http://seongbae.blogspot.com;
Re: Question concerning shared libraries in non-standard locations
On Sun, Jun 25, 2006 at 07:47:52PM -0400, Paul Hilfinger wrote:
I have a situation (on Linux or Solaris, at least), in which I
install versions of GCC in non-standard directories (specifically,
directories not owned operated by root). With such an
installation, when a GCC link finds a definition of an external
reference in a shared library that is part of the .../lib
subdirectory used by this installation, it treats the shared library
as if it were also installed in one of the standard locations known
to the dynamic linker, and does NOT store the path to the directory
in which that library is found. The result is that to run the
linked executable, one must either
So you simply want the RPATH entry in the executable created by gcc
-o foo foo.c to contain an entry to locate libgcc.so and
libstdc++.so?
You can modify the specs file to _automatically_ add the -R/-Wl,-rpath
when linking. Below is a possible patch for the GCC 4.0.2 specs file
to accomplish it for Solaris. Linux is handled in a similar way.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
--- specs.orig Sun Jun 25 23:30:01 2006
+++ specs Fri Oct 21 00:05:58 2005
@@ -173,6 +173,12 @@
*link_arch:
%{m32:%(link_arch32)} %{m64:%(link_arch64)}
%{!m32:%{!m64:%(link_arch_default)}}
+*rpath:
+-R[gcc library path]
+
+*rpath64:
+-R[gcc library path]/sparcv9
+
*link_command:
-%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %{pie:} %X %{o*}
%{A} %{d} %{e*} %{m} %{N} %{n} %{r}%{s} %{t} %{u*} %{x} %{z} %{Z}
%{!A:%{!nostdlib:%{!nostartfiles:%S}}}%{static:} %{L*} %(mfwrap)
%(link_libgcc) %o %(mflib)%{fprofile-arcs|fprofile-generate:-lgcov}
%{!nostdlib:%{!nodefaultlibs:%(link_gcc_c_sequence)}}
%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}
+%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %{pie:} %X %{o*}
%{A} %{d} %{e*} %{m} %{N} %{n} %{r}%{s} %{t} %{u*} %{x} %{z} %{Z}
%{!A:%{!nostdlib:%{!nostartfiles:%S}}}%{static:} %{L*} %(mfwrap)
%(link_libgcc) %o %(mflib)%{fprofile-arcs|fprofile-generate:-lgcov}
%{!nostdlib:%{!nodefaultlibs:%{!m64:%(rpath)} %{m64:%(rpath64)}
%(link_gcc_c_sequence)}}%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}
[Bug middle-end/28160] New: Bogus size of array 'foo' is too large error with -mms-bitfields
Several g++ tests in tmpdir-g++.dg-struct-layout-1 fail during
the compilation with the error message like
error: size of array 'foo' is too large
with -mms-bitfields. A reduced testcase is
typedef long int along __attribute__((aligned (32)));
struct S
{
unsigned char a;
along d:130;
int e:66;
} A[1];
It looks the ms-bitfield code in stor-layout.c doesn't take
the bit field with excessive size into account and it makes
the negative remaining_in_alignment which causes the above
error.
--
Summary: Bogus size of array 'foo' is too large error with -
mms-bitfields
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28160
[Bug middle-end/28161] New: Wrong bit field layout with -mms-bitfields
Several g++ tests in tmpdir-g++.dg-struct-layout-1 fail with
the execution error. A reduced testcase is
extern C void abort (void);
struct S
{
long long d:23;
int e:32;
int f:32;
} a;
int main (void)
{
a.e = -3;
a.f = 1;
if (a.e != -3)
abort ();
return 0;
}
which shows that the current compiler allocates a.e and a.f in
an overlapped manner with -mms-bitfields. With that option,
the 4.1 compiler allocates a field in the first 8-byte for a.d,
the next 4-byte for a.e and the another 4-byte for a.f, but 4.2
allocates 23-bit for a.d, the next 32-bit for a.e and the last
32-bit for a.f in the same 8-byte.
--
Summary: Wrong bit field layout with -mms-bitfields
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28161
[Bug target/28150] ICE in reload_cse_simplify_operands, at postreload.c:394
--- Comment #3 from pluto at agmk dot net 2006-06-25 08:47 --- (In reply to comment #2) How did you configure GCC becase having TFmode there sounds like you configured to have 128bit long double to be default. $ gcc -v Reading specs from /usr/lib/gcc/ppc-pld-linux/4.1.2/specs Target: ppc-pld-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --libdir=/usr/lib --libexecdir=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --x-libraries=/usr/lib --enable-shared --enable-threads=posix --enable-languages=c,c++,fortran,objc,obj-c++,ada,java --enable-c99 --enable-long-long --disable-multilib --enable-nls --disable-werror --with-gnu-as --with-gnu-ld --with-demangler-in-ld --with-system-zlib --with-slibdir=/lib --without-system-libunwind --enable-cmath --with-long-double-128 --enable-secureplt --with-gxx-include-dir=/usr/include/c++/4.1.2 --disable-libstdcxx-pch --enable-__cxa_atexit --enable-libstdcxx-allocator=new --with-qt4dir=/usr/lib/qt4 --disable-libjava-multilib --enable-libgcj --enable-libgcj-multifile --enable-libgcj-database --enable-gtk-cairo --enable-java-awt=qt,gtk,xlib --enable-jni --enable-xmlj --enable-alsa --enable-dssi ppc-pld-linux Thread model: posix gcc version 4.1.2 20060623 (prerelease) (PLD-Linux) glibc-2.4, kernel-2.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28150
[Bug c/28162] New: ice on valid code
I just tried to compile the attached source code with compiler flag -O3. GNU C compiler version 4.2 snapshot 20060624 said [EMAIL PROTECTED]:~/gnu/42-20060617/bugs ~/gnu/42-20060624/results/bin/gcc -O3 bug18.c bug18.c: In function 'Speech_Encode_Frame_init': bug18.c:24528: warning: passing argument 1 of 'Speech_Encode_Frame_exit' from incompatible pointer type bug18.c: In function 'ol_ltp': bug18.c:19118: internal compiler error: in set_value_range, at tree-vrp.c:157 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED]:~/gnu/42-20060624/bugs Preprocessed source code attached. Flag -O3 required. -- Summary: ice on valid code Product: gcc Version: 4.2.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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28162
[Bug c/28162] ice on valid code
--- Comment #1 from dcb314 at hotmail dot com 2006-06-25 09:28 --- Created an attachment (id=11744) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11744action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28162
[Bug c/28162] ice on valid code
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-25 10:01 --- min is not less than max: (gdb) call debug_tree (min) integer_cst 0xa78f57b0 type integer_type 0xa7bf42e0 unsigned int constant invariant 4294966724 (gdb) call debug_tree (max) integer_cst 0xa7be2498 type integer_type 0xa7bf433c long int constant invariant 2147483647 but worse, their types don't match. (I guess the former wants to be casted to int) #1 0x086124ff in set_value_range (vr=0xaff5a110, t=VR_RANGE, min=0xa78f57b0, max=0xa7be2498, equiv=0x8a30dd8) at /home/richard/src/trunk/gcc/tree-vrp.c:157 #2 0x08617d92 in adjust_range_with_scev (vr=0xaff5a110, loop=0x89f3980, stmt=0xa7966774, var=0xa700a1e0) at /home/richard/src/trunk/gcc/tree-vrp.c:2090 #3 0x0861e035 in vrp_visit_assignment (stmt=0xa7966774, output_p=0xaff5a278) at /home/richard/src/trunk/gcc/tree-vrp.c:3457 #4 0x0861f9a0 in vrp_visit_stmt (stmt=0xa7966774, taken_edge_p=0xaff5a27c, output_p=0xaff5a278) at /home/richard/src/trunk/gcc/tree-vrp.c:3850 (gdb) call debug_generic_expr (stmt) D.23941_257 = p_max1D.23874_118 * 0fffc mult_expr 0xa7966798 type integer_type 0xa7bf42e0 unsigned int public unsigned SI size integer_cst 0xa7be23f0 constant invariant 32 unit size integer_cst 0xa7be2180 constant invariant 4 align 32 symtab 0 alias set -1 precision 32 min integer_cst 0xa7be2468 0 max integer_cst 0xa7be2450 4294967295 pointer_to_this pointer_type 0xa7c94e60 arg 0 ssa_name 0xa7566e40 type integer_type 0xa7a5bcf0 Word32 sizes-gimplified public SI size integer_cst 0xa7be23f0 32 unit size integer_cst 0xa7be2180 4 align 32 symtab 0 alias set -1 precision 32 min integer_cst 0xa7be2480 -2147483648 max integer_cst 0xa7be2498 2147483647 pointer_to_this pointer_type 0xa7a60678 var var_decl 0xa7897898 p_max1 def_stmt modify_expr 0xa794fbf4 version 118 arg 1 integer_cst 0xa79a1be8 type integer_type 0xa7bf42e0 unsigned int constant invariant 4294967292 type mismatch in the MULT_EXPR (signed vs. unsigned). ol_ltpD.6288:: ;; basic block 10, loop depth 1, count 0 ;; prev block 17, next block 11 ;; pred: 67 (true,exec) ;; succ: 11 (true) 12 (false) L24:; p_max1_118 = ASSERT_EXPR p_max1_13, p_max1_13 19; D.23941_257 = p_max1_118 * 0fffc; D.23942_258 = (Float32 *) D.23941_257; D.23943_259 = D.23942_258 + corr[143]; ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28162
[Bug tree-optimization/28162] ICE in set_value_range, at tree-vrp.c:157
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-06-25 10:30 ---
Reduced testcase, still needs -O3 (and checking enabled):
void Lag_max_wght(float corr[], long wght_flg)
{
float t0, max;
const float *ww;
long i;
if ( wght_flg 0 ) {
for ( i = 143; i = 20; i-- ) {
t0 = corr[ - i] * *ww--;
if ( t0 = max )
max = t0;
}
}
}
--
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 |2006-06-25 10:30:15
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28162
[Bug tree-optimization/27937] [4.2 Regression] Ada bootstrap failure on Solaris 10/x86
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-06-25 10:58 --- Is there a testcase for this bug that can be examined on more common host/target systems? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27937
[Bug c++/28051] [4.0/4.1/4.2 regression] ICE on invalid conversion operator
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-06-25 11:07 --- Subject: Bug 28051 Author: lmillward Date: Sun Jun 25 11:07:05 2006 New Revision: 114985 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114985 Log: PR c++/28051 * mangle.c (mangle_conv_op_name_for_type): Check for invalid types. *name-lookup.c (push_class_level_binding): Robustify. (do_class_using_decl): Return early if name is error_mark_node. Added: trunk/gcc/testsuite/g++.dg/template/using13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28051
[Bug c++/28051] [4.0/4.1 regression] ICE on invalid conversion operator
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-06-25 11:07 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE on |on invalid conversion |invalid conversion operator |operator| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28051
[Bug c++/28054] [4.2 regression] ICE with friend declaration of invalid bitfield
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-06-25 11:28 --- Subject: Bug 28054 Author: lmillward Date: Sun Jun 25 11:28:01 2006 New Revision: 114986 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114986 Log: PR c++/28054 * decl2.c (grokbitfield): Remove check for grokdeclarator returning NULL_TREE, instead check for error_mark_node to indicate failure. * decl.c (grokdeclarator): Adjust block comment. * g++.dg/other/incomplete3.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/incomplete3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28054
[Bug c++/28054] [4.2 regression] ICE with friend declaration of invalid bitfield
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-06-25 11:28 --- Fixed. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28054
[Bug tree-optimization/28162] ICE in set_value_range, at tree-vrp.c:157
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-06-25 12:02 ---
.003.original is already wrong:
t0 = *((float *) (i * 0fffc) + corr) * (float) *ww-- ;
we ask fold to fold (unsigned)-i * 4U
which continues to ask fold to fold i * -4U (buggy already), which is from
case MULT_EXPR:
/* (-A) * (-B) - A * B */
if (TREE_CODE (arg0) == NEGATE_EXPR negate_expr_p (arg1))
return fold_build2 (MULT_EXPR, type,
TREE_OPERAND (arg0, 0),
negate_expr (arg1));
it should use fold_convert () on the args. The following fixes it:
Index: fold-const.c
===
--- fold-const.c(revision 114974)
+++ fold-const.c(working copy)
@@ -8866,12 +8866,12 @@ fold_binary (enum tree_code code, tree t
/* (-A) * (-B) - A * B */
if (TREE_CODE (arg0) == NEGATE_EXPR negate_expr_p (arg1))
return fold_build2 (MULT_EXPR, type,
- TREE_OPERAND (arg0, 0),
- negate_expr (arg1));
+ fold_convert (type, TREE_OPERAND (arg0, 0)),
+ fold_convert (type, negate_expr (arg1)));
if (TREE_CODE (arg1) == NEGATE_EXPR negate_expr_p (arg0))
return fold_build2 (MULT_EXPR, type,
- negate_expr (arg0),
- TREE_OPERAND (arg1, 0));
+ fold_convert (type, negate_expr (arg0)),
+ fold_convert (type, TREE_OPERAND (arg1, 0)));
if (! FLOAT_TYPE_P (type))
{
(obvious, but has to wait until after the summit.)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2006-06-25 10:30:15 |2006-06-25 12:02:00
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28162
[Bug fortran/28163] New: Calling libgfortran's copy_string is inefficient
Currently, string assignments are done via calls to _gfortran_copy_string,
which is a simple wrapper around memmove/memset:
void
copy_string (GFC_INTEGER_4 destlen, char * dest,
GFC_INTEGER_4 srclen, const char * src)
{
if (srclen = destlen)
{
/* This will truncate if too long. */
memmove (dest, src, destlen);
}
else
{
memmove (dest, src, srclen);
/* Pad with spaces. */
memset (dest[srclen], ' ', destlen - srclen);
}
}
With this implementation, AERMOD (from polyhedron benchmark) spends most of its
time in calls to memmove/memset. If the above code is directly emitted by the
front-end, I measure on i686-linux a 27% improvement in execution time with the
following options:
gfortran -march=pentium4 -ffast-math -funroll-loops -O3 aermod.f90
--
Summary: Calling libgfortran's copy_string is inefficient
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28163
[Bug fortran/28163] Calling libgfortran's copy_string is inefficient
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-06-25 12:31 --- Created an attachment (id=11746) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11746action=view) Patch described in the bug report -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28163
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #17 from whaley at cs dot utsa dot edu 2006-06-25 13:17 --- OK, thanks for the reply. I will assume gcc 4 won't be fixed in the near future. My guess is this will make icc an easier compiler for users, which I kind of hate, which is why I worked as much as I did on this report . . . I hope you will consider adding the mmbench4s.tar.gz attachment above (the one that runs both single and double precision) to the gcc regression tests. Notice that it caught this problem between 3 and 4, as well as a similar fp performance drop between gcc 2 and 3 (bugzilla 4991). The kernel here is typical of those used in ATLAS, which is used by hundreds of thousands of people worldwide. I believe these kernels are also typical of pretty much any register blocked fp code, so having them in the regression tests may help other open source fp packages (eg, fftw, etc) as well. Notice that closed-source alternatives that ship binaries do not face this challenge, so that having the compiler drop between releases gives them an advantage, and can drive HPC users (where performance dictates everything) to proprietary solutions. Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug c++/28164] New: g++ core when init a struct
using ACE 5.4.1
command line:g++ -I/usr/local/ACE_wrappers test.cpp
gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)
source:
#include ace/INET_Addr.h
struct ERR
{
ACE_INET_Addr err[10][2]; /// right: int err[10][2]; or ACE_INET_Addr [10];
};
ERR temp = {0};
int main()
{
return 0;
}
--
Summary: g++ core when init a struct
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tiramisu dot xc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28164
[Bug c++/28164] g++ core when init a struct
--- Comment #1 from tiramisu dot xc at gmail dot com 2006-06-25 13:38 --- Created an attachment (id=11747) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11747action=view) /tmp/cciuGwmP.out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28164
[Bug fortran/27554] Strange assembler produced
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-25 15:11 --- Subject: Bug 27554 Author: pault Date: Sun Jun 25 15:11:02 2006 New Revision: 114987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114987 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/elemental_result_1.f90 trunk/gcc/testsuite/gfortran.dg/forall_4.f90 trunk/gcc/testsuite/gfortran.dg/forall_5.f90 trunk/gcc/testsuite/gfortran.dg/impure_actual_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f trunk/gcc/testsuite/gfortran.dg/select_7.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27554
[Bug fortran/25056] non-PURE function should not be a valid argument
--- Comment #3 from pault at gcc dot gnu dot org 2006-06-25 15:11 --- Subject: Bug 25056 Author: pault Date: Sun Jun 25 15:11:02 2006 New Revision: 114987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114987 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/elemental_result_1.f90 trunk/gcc/testsuite/gfortran.dg/forall_4.f90 trunk/gcc/testsuite/gfortran.dg/forall_5.f90 trunk/gcc/testsuite/gfortran.dg/impure_actual_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f trunk/gcc/testsuite/gfortran.dg/select_7.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25056
[Bug fortran/20874] elemental function ought to be scalar
--- Comment #5 from pault at gcc dot gnu dot org 2006-06-25 15:11 --- Subject: Bug 20874 Author: pault Date: Sun Jun 25 15:11:02 2006 New Revision: 114987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114987 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/elemental_result_1.f90 trunk/gcc/testsuite/gfortran.dg/forall_4.f90 trunk/gcc/testsuite/gfortran.dg/forall_5.f90 trunk/gcc/testsuite/gfortran.dg/impure_actual_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f trunk/gcc/testsuite/gfortran.dg/select_7.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20874
[Bug fortran/25073] CASEs overlap
--- Comment #10 from pault at gcc dot gnu dot org 2006-06-25 15:11 --- Subject: Bug 25073 Author: pault Date: Sun Jun 25 15:11:02 2006 New Revision: 114987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114987 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/elemental_result_1.f90 trunk/gcc/testsuite/gfortran.dg/forall_4.f90 trunk/gcc/testsuite/gfortran.dg/forall_5.f90 trunk/gcc/testsuite/gfortran.dg/impure_actual_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f trunk/gcc/testsuite/gfortran.dg/select_7.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25073
[Bug fortran/20867] statement function args not given implicit type early enough
--- Comment #3 from pault at gcc dot gnu dot org 2006-06-25 15:11 --- Subject: Bug 20867 Author: pault Date: Sun Jun 25 15:11:02 2006 New Revision: 114987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114987 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/elemental_result_1.f90 trunk/gcc/testsuite/gfortran.dg/forall_4.f90 trunk/gcc/testsuite/gfortran.dg/forall_5.f90 trunk/gcc/testsuite/gfortran.dg/impure_actual_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f trunk/gcc/testsuite/gfortran.dg/select_7.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20867
[Bug fortran/28119] forall_stmt ; stmt gives an internal error
--- Comment #2 from pault at gcc dot gnu dot org 2006-06-25 15:11 --- Subject: Bug 28119 Author: pault Date: Sun Jun 25 15:11:02 2006 New Revision: 114987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114987 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/elemental_result_1.f90 trunk/gcc/testsuite/gfortran.dg/forall_4.f90 trunk/gcc/testsuite/gfortran.dg/forall_5.f90 trunk/gcc/testsuite/gfortran.dg/impure_actual_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f trunk/gcc/testsuite/gfortran.dg/select_7.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28119
[Bug fortran/22038] Forall with mask broken
--- Comment #9 from pault at gcc dot gnu dot org 2006-06-25 15:11 --- Subject: Bug 22038 Author: pault Date: Sun Jun 25 15:11:02 2006 New Revision: 114987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114987 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/elemental_result_1.f90 trunk/gcc/testsuite/gfortran.dg/forall_4.f90 trunk/gcc/testsuite/gfortran.dg/forall_5.f90 trunk/gcc/testsuite/gfortran.dg/impure_actual_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f trunk/gcc/testsuite/gfortran.dg/select_7.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22038
[Bug fortran/25072] non PURE function used in For-All
--- Comment #8 from pault at gcc dot gnu dot org 2006-06-25 15:11 --- Subject: Bug 25072 Author: pault Date: Sun Jun 25 15:11:02 2006 New Revision: 114987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114987 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/elemental_result_1.f90 trunk/gcc/testsuite/gfortran.dg/forall_4.f90 trunk/gcc/testsuite/gfortran.dg/forall_5.f90 trunk/gcc/testsuite/gfortran.dg/impure_actual_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f trunk/gcc/testsuite/gfortran.dg/select_7.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25072
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #21 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-25 15:32 --- Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops I looked at the documentation for lshiftrt, but it doesn't say whether the shift amount range handled by the PA insn for variable shifts is ok or not. On the otherhand, there's no obvious reason why we should need to support logical right shifts larger than 31 bits and I have to wonder why the generated code does this. I looked at this a bit more and I believe that this behavior is normal when SHIFT_COUNT_TRUNCATED is defined. The test doesn't fail with -fno-unroll-loops-all-loops. It appears to me that this is a loop unrolling rather than a loop invariant bug, although I must admit it's not clear where things actually go wrong because of the complexity of this operation. I modified the testcase a bit to make debugging easier. I've attached the modified testcase and the dumps from loop2_unroll, loop2_done, web and cse2. The initialization of count in the block after code_label 21 definitely appears wrong after cse2. I've also attached the final assembly code for reference. Dave --- Comment #22 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-25 15:32 --- Created an attachment (id=11748) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11748action=view) --- Comment #23 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-25 15:32 --- Created an attachment (id=11749) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11749action=view) --- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-25 15:32 --- Created an attachment (id=11750) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11750action=view) --- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-25 15:32 --- Created an attachment (id=11751) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11751action=view) --- Comment #26 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-25 15:32 --- Created an attachment (id=11752) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11752action=view) --- Comment #27 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-25 15:32 --- Created an attachment (id=11753) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11753action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug tree-optimization/28162] [4.2 Regression] ICE in set_value_range, at tree-vrp.c:157
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|ICE in set_value_range, at |[4.2 Regression] ICE in |tree-vrp.c:157 |set_value_range, at tree- ||vrp.c:157 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28162
[Bug c++/27821] [4.0/4.1 regression] ICE with invalid ptr-to-member
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-06-25 17:00 --- Subject: Bug 27821 Author: lmillward Date: Sun Jun 25 17:00:43 2006 New Revision: 114988 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114988 Log: PR c++/27821 * decl.c (grokdeclarator): Return error_mark_node on invalid uses of the scope resolution operator. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/error22.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27821
[Bug c++/27821] [4.0/4.1 regression] ICE with invalid ptr-to-member
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-06-25 17:05 --- Subject: Bug 27821 Author: lmillward Date: Sun Jun 25 17:05:22 2006 New Revision: 114989 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114989 Log: PR c++/27821 * decl.c (grokdeclarator): Return error_mark_node on invalid uses of the scope resolution operator. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/error22.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27821
[Bug c++/27821] [4.0/4.1 regression] ICE with invalid ptr-to-member
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-06-25 17:06 --- Fixed in 4.1.2 and 4.0.4. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27821
[Bug middle-end/28151] [4.1/4.2 Regression] ICE with complex math
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-06-25 17:16 --- Subject: Bug 28151 Author: ebotcazou Date: Sun Jun 25 17:16:25 2006 New Revision: 114992 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114992 Log: PR middle-end/28151 * fold-const.c (const_binop): Be prepared for self returning zero. Simplify code handling complex values. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20060625-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug middle-end/28151] [4.1/4.2 Regression] ICE with complex math
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-06-25 17:18 --- Subject: Bug 28151 Author: ebotcazou Date: Sun Jun 25 17:18:00 2006 New Revision: 114993 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114993 Log: PR middle-end/28151 * fold-const.c (const_binop): Be prepared for self returning zero. Simplify code handling complex values. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/20060625-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/fold-const.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug middle-end/28151] [4.1/4.2 Regression] ICE with complex math
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-06-25 17:19 --- Fixed everywhere. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug fortran/25056] non-PURE function should not be a valid argument
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-25 18:08 --- Subject: Bug 25056 Author: pault Date: Sun Jun 25 18:08:13 2006 New Revision: 114994 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114994 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_result_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/impure_actual_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/select_7.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/match.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25056
[Bug fortran/20874] elemental function ought to be scalar
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-25 18:08 --- Subject: Bug 20874 Author: pault Date: Sun Jun 25 18:08:13 2006 New Revision: 114994 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114994 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_result_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/impure_actual_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/select_7.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/match.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20874
[Bug fortran/27554] Strange assembler produced
--- Comment #5 from pault at gcc dot gnu dot org 2006-06-25 18:08 --- Subject: Bug 27554 Author: pault Date: Sun Jun 25 18:08:13 2006 New Revision: 114994 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114994 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_result_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/impure_actual_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/select_7.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/match.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27554
[Bug fortran/20867] statement function args not given implicit type early enough
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-25 18:08 --- Subject: Bug 20867 Author: pault Date: Sun Jun 25 18:08:13 2006 New Revision: 114994 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114994 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_result_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/impure_actual_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/select_7.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/match.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20867
[Bug fortran/25073] CASEs overlap
--- Comment #11 from pault at gcc dot gnu dot org 2006-06-25 18:08 --- Subject: Bug 25073 Author: pault Date: Sun Jun 25 18:08:13 2006 New Revision: 114994 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114994 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_result_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/impure_actual_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/select_7.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/match.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25073
[Bug fortran/28119] forall_stmt ; stmt gives an internal error
--- Comment #3 from pault at gcc dot gnu dot org 2006-06-25 18:08 --- Subject: Bug 28119 Author: pault Date: Sun Jun 25 18:08:13 2006 New Revision: 114994 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114994 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_result_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/impure_actual_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/select_7.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/match.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28119
[Bug fortran/22038] Forall with mask broken
--- Comment #10 from pault at gcc dot gnu dot org 2006-06-25 18:08 --- Subject: Bug 22038 Author: pault Date: Sun Jun 25 18:08:13 2006 New Revision: 114994 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114994 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_result_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/impure_actual_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/select_7.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/match.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22038
[Bug fortran/25072] non PURE function used in For-All
--- Comment #9 from pault at gcc dot gnu dot org 2006-06-25 18:08 --- Subject: Bug 25072 Author: pault Date: Sun Jun 25 18:08:13 2006 New Revision: 114994 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114994 Log: 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/25056 * interface.c (compare_actual_formal): Signal an error if the formal argument is a pure procedure and the actual is not pure. PR fortran/27554 * resolve.c (resolve_actual_arglist): If the type of procedure passed as an actual argument is not already declared, see if it is an intrinsic. PR fortran/25073 * resolve.c (resolve_select): Use bits 1 and 2 of a new int to keep track of the appearance of constant logical case expressions. Signal an error is either value appears more than once. PR fortran/20874 * resolve.c (resolve_fl_procedure): Signal an error if an elemental function is not scalar valued. PR fortran/20867 * match.c (recursive_stmt_fcn): Perform implicit typing of variables. PR fortran/22038 * match.c (match_forall_iterator): Mark new variables as FL_UNKNOWN if the match fails. PR fortran/28119 * match.c (gfc_match_forall): Remove extraneous call to gfc_match_eos. PR fortran/25072 * resolve.c (resolve_code, resolve_function): Rework forall_flag scheme so that it is set and has a value of 2, when the code-expr (ie. the forall mask) is resolved. This is used to change block to mask in the non-PURE error message. 2006-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/20867 * gfortran.dg/stfunc_3.f90: New test. PR fortran/25056 * gfortran.dg/impure_actual_1.f90: New test. PR fortran/20874 * gfortran.dg/elemental_result_1.f90: New test. PR fortran/25073 * gfortran.dg/select_7.f90: New test. PR fortran/27554 * intrinsic_actual_1.f: New test. PR fortran/22038 PR fortran/28119 * gfortran.dg/forall_4.f90: New test. PR fortran/25072 * gfortran.dg/forall_5.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_result_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/impure_actual_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_1.f branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/select_7.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/stfunc_3.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/match.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25072
[Bug fortran/25056] non-PURE function should not be a valid argument
--- Comment #5 from pault at gcc dot gnu dot org 2006-06-25 18:09 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25056
[Bug fortran/20867] statement function args not given implicit type early enough
--- Comment #5 from pault at gcc dot gnu dot org 2006-06-25 18:10 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20867
[Bug fortran/20874] elemental function ought to be scalar
--- Comment #7 from pault at gcc dot gnu dot org 2006-06-25 18:11 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20874
[Bug fortran/25073] CASEs overlap
--- Comment #12 from pault at gcc dot gnu dot org 2006-06-25 18:11 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25073
[Bug fortran/27554] Strange assembler produced
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-25 18:12 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27554
[Bug fortran/22038] Forall with mask broken
--- Comment #11 from pault at gcc dot gnu dot org 2006-06-25 18:12 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22038
[Bug fortran/28119] forall_stmt ; stmt gives an internal error
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-25 18:13 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28119
[Bug fortran/25072] non PURE function used in For-All
--- Comment #10 from pault at gcc dot gnu dot org 2006-06-25 18:13 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25072
[Bug c++/28164] g++ core when init a struct
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-25 19:55 --- Fixed in 4.0.0 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||ice-on-valid-code Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28164
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #18 from rguenth at gcc dot gnu dot org 2006-06-25 20:05 --- Unfortunately we don't have infrastructure for performance regression tests. Btw. did you check what happens if you do not unroll the innermost loop manually but let -funroll-loops do it? For me the performance is the same (but I may have screwed up removing the unrolling). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug middle-end/27950] [4.2 regression] undefined reference when compiling valgrind 3.2.0
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-25 23:05:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27950
[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function
--- Comment #14 from roger at eyesopen dot com 2006-06-26 00:24 --- The problem appears to be that DECL_COMPLEX_GIMPLE_REG_P is not getting set on the declarations correctly. The VAR_DECLs that are operands to the additions don't have DECL_COMPLEX_GIMPLE_REG_P set, so fail the is_gimple_val check in verify_stmts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #19 from whaley at cs dot utsa dot edu 2006-06-26 00:55 --- Thanks for the info. I'm sorry to hear that no performance regression tests are done, but I guess it kind of explains why these problems reoccur :) As to not unrolling, the fully unrolled case is almost always commandingly better whenever I've looked at it. After your note, I just tried on my P4, using ATLAS's P4 kernel, and I get (ku is inner loop unrolling, and nb=40, so 40 is fully unrolled): GCC 4 ku=1 : 1.65Gflop GCC 4 ku=40 : 1.84Gflop Gcc 3 ku=1 : 1.90Gflop Gcc 3 ku=40: 2.19Gflop This is throwing the -funroll-loops flag. BTW, gcc 4 w/o the -funroll-loops (ku=1) is indeed slower, at roughly 1.54 . . . Anyway, I've never found the performance of gcc ku=1 competitive with ku=fully unrolled on any machine. Even in assembly, I have to fully unroll the inner loop to get near peak on all intel machines. On the Opteron, you can get within 5% or so with a rolled loop in assembly, but I've not gotten a C code to do that.I think the gcc unrolling probably defaults to something like 4 or 8 (guess from performance, not verified): unrolling all the way (the loop is over a compile-time constant) is the way to go . . . When you said competitive, did you mean that gcc 4 ku=1 was competitive with gcc 4 ku=40 or gcc 3 ku=1? If the latter, I find it hard to believe unless you use SSE for gcc 4 and something unexpected happens. Even so, if you are using SSE try it with the single precision kernel, where SSE cannot compete with the x87 unit (even the broken one in gcc 4). Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug preprocessor/28165] New: _Pragma GCC system_header broken
In a main translation unit, this: #pragma GCC system_header results in this warning: warning: #pragma system_header ignored outside include file However, this doesn't: _Pragma (GCC system_header) In fact, this causes GCC to emit a line marker switching the main translation unit to look like a system header. -Chris -- Summary: _Pragma GCC system_header broken Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28165
[Bug c/28166] New: internal compiler error when -finstrument-functions on an inline function.
Internal compiler error when compiling an inline static function with -finstrument-functions and -finline-functions, even if the function has the no_instrument_function attribute. No error occurs if inlining is turned off or an addressable version of the function is provided with -fkeep-inline-functions -- Summary: internal compiler error when -finstrument-functions on an inline function. Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: murdo at catapult dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28166
[Bug c/28166] internal compiler error when -finstrument-functions on an inline function.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-26 02:42 --- This was fixed in 4.0.0 and this is also a dup of bug 16780. *** This bug has been marked as a duplicate of 16780 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28166
[Bug c/16780] [3.4 regression] ICE with -finstrument-functions -funit-at-a-time -finline -finline-functions
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-06-26 02:42 --- *** Bug 28166 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||murdo at catapult dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16780
[Bug c/28166] internal compiler error when -finstrument-functions on an inline function.
--- Comment #2 from murdo at catapult dot com 2006-06-26 02:43 --- Created an attachment (id=11754) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11754action=view) Minimum failing case plus gcc version, command, output and .i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28166
