givs
I have a short piece of code that I am using for tuning an application.
"-freduce-all-givs"
makes it run faster with some data types and slower with others. The
info page said you were interested in such results. I know very little
about this all.
The two conditions I am comparing that may be of interest to you are
(a) KITCHEN=-O3 -fexpensive-optimizations -ffast-math -fstrength-reduce
-frerun-cse-after-loop -frerun-loop-opt -fschedule-insns2
-fprefetch-loop-arrays -falign-loops -frename-registers
(b) GIVS=-freduce-all-givs $(KITCHEN)
Time in work units datatype - optimation . out
seconds per second
21.737 (459964)long-kitchensink.out
21.749 (459714)int-kitchensink.out
23.081 (433183)long-givs.out
24.445 (409002)short-givs.out
27.116 (368715)int-givs.out
33.834 (295506)double-kitchensink.out
34.500 (289802)double-givs.out
35.221 (283869)short-kitchensink.out
39.376 (253916)float-kitchensink.out
45.068 (221846)float-givs.out
51.890 (192681)int.1000.out
51.917 (192580)
int--fallow-single-precision.1000.out
51.919 (192575)int--O3.1000.out
62.984 (158742)
long--fallow-single-precision.1000.out
63.013 (158669)long.1000.out
63.018 (158656)long--O3.1000.out
65.054 (153691)
short--fallow-single-precision.1000.out
65.055 (153690)short--O3.1000.out
65.073 (153646)short.1000.out
70.367 (142087)double--O3.1000.out
70.384 (142053)
double--fallow-single-precision.1000.out
70.403 (142014)double.1000.out
72.452 (137997)float--O3.1000.out
72.490 (137926)float.1000.out
72.491 (137924)
float--fallow-single-precision.1000.out
include
#include
#define NUMBER float
#define DIM 540
#define INIT 5.0
#define FINGERCOUNT 2
/* typedef NUMBER int; */
NUMBER aaa[DIM];
NUMBER bbb[DIM];
NUMBER kkk[DIM];
NUMBER total = 0;
int main(int argc, char* argv[]){
int jj;
int j;
int v;
int tmp;
double fingers;
int fingersRT;
fingers = FINGERCOUNT;
fprintf(stderr,"<%s>\n", argv[1]);
if (argc == 2){
int rc;
rc = sscanf(argv[1],"%lf", &fingers);
fprintf(stderr,"rc=%d\n", rc);
}
fingersRT= sqrt(fingers);
fingers = fingersRT;
fingers = fingers * fingersRT;
printf(" fingersRT:%d fingers = %20.0f\n", fingersRT, fingers);
for(v=0; v < DIM; v++){
aaa[v] = 1 + (bbb[v] = (1 + (kkk[v] = 3)));
}
for(jj=0;jj Node 0
CPU0: Physical Processor ID: 0
CPU0: Processor Core ID: 0
CPU0: Initial APIC ID: 0
Using local APIC NMI watchdog using perfctr0
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0(2) -> Node 0
CPU0: Physical Processor ID: 0
CPU0: Processor Core ID: 0
CPU0: Initial APIC ID: 0
CPU0: Dual Core AMD Opteron(tm) Processor 870 HE stepping 02
per-CPU timeslice cutoff: 1023.93 usecs.
task migration cache decay timeout: 2 msecs.
Booting processor 1/1 rip 6000 rsp 1068d0d3f58
==
uname -a
Linux acc-1 2.6.9-22.EPsmp #2 SMP Thu Feb 9 15:22:50 CST 2006 x86_64 x86_64
x86_64 GNU/Linux
==
/Russell
Re: Wconversion versus Wcoercion
On 10 Jun 2006 20:07:02 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: I'll like to see a more precise definition of your understanding of "coercion" versus "conversion". Last time we dicussed this I was not quite clear about what you consider is "bad" what is not. I was under the impression you taught it was for "C" only, but you have to take into account that some warnings are shared with the C++ front-end and some of them really should be common to both front-ends. If your project is NOT about coercion in general, but those just related to function prototypes, you should be careful about the name of the option. Again, this assumes you tell us what you consider coercion and what you consider conversion. -- Gaby My project is about "risky" coercions in general: assignments, operators, prototypes. You can see some (and comment and propose) testcases in http://gcc.gnu.org/wiki/Wcoercion . I haven't thought how all this works when you include classes and objects and inheritance. However, this doesn't matter for this discussion because just taking into account the current code in trunk, there are several problems : 1) Following the documentation, currently Wconversion is used for two different and unrelated things (i) "Warn if a prototype causes a type conversion that is different from what would happen to the same argument in the absence of a prototype" and (ii) "warn if a negative integer constant expression is implicitly converted to an unsigned type". These two behaviours should be split. 2) Currently, Wconversion works very different for C and for C++. I have not seen anything in the manual explaining this, so I assume that it is undocumented behaviour. I think this is bad: C and C++ should be in sync and the current behaviour should be explained in the manual. 3) People using Wconversion to detect conversions that may be risky are frequently told that this is not the intended purpose. However, in g++, it currently works to some extent. People should not rely on this. We should either warn them somehow that this is wrong or we should fix Wconversion to do what they expect. However, fixing Wconversion would silently break things for those that rely on its original purpose. So, I propose a third option: c) Remove Wconversion and create two new options Wcoercion and Wprototypes-traditional. The reason is that both options (a) and (b) would silently break Wconversion for someone. And keeping Wconversion is not an option since it is currently broken and we need a way to warn people already using it in the wrong way. Also, keeping Wconversion raises the issue of what to do with the undocumented behaviour already implemented in g++. So the best option is just remove Wconversion and let people know that they should use one of the two new options. Of course this can be done in a very gradual way. For example, Wconversion may call the new options and issue a warning message. Cheers, Manuel.
Re: Wconversion versus Wcoercion
On 10/06/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: Here is my vote, have four options: -Wconversion the same as now. This is bad idea. Currently many people are relying in undocumented behaviour or the false perception that Wconversion detects risky conversions. If we keep Wconversion, they will keep using it wrongly. (I don't think most people will read Changelogs). -Wprototype-conversion turns on part of -Wconversion That is fine. Although, Wprototype-conversion seems like a conversion caused by the prototype and the warning actually is about conversions caused by a prototype that would be different in the absence of prototype. I think the name could be better. -Wcoercion the option you are dealing with That is fine. -Wconversion-signed the other part of the doc for -Wconversion I don't see the point on this. Wconversion-signed must be included in Wcoercion anyway. Now, one may argue if each functionality of Wcoercion should have its own option. If you think so, then Wcoercion-signed makes sense. Yet, we can argue about this later. Let's focus on what to do with Wconversion My new proposal: (c) make Wconversion obsolete. Cheers, Manuel.
gcc 4.1.1 Successful build - Cedric Arbogast
Hello, GCC 4.1.1 have successfully compiled on this system : ./config.guess: i686-pc-linux-gnu GCC_EXEC_PREFIX=/usr/local/gcc411; export GCC_EXEC_PREFIX; gcc -v : Using built-in specs. Target: i686-pc-linux-gnu Configured with: /usr/src/gcc-4.1.1/configure --prefix=/usr/local/gcc411 --enable-threads Thread model: posix gcc version 4.1.1 Linux distribution : Mandrake Linux release 9.0 (dolphin) for i586 Linux Kernel Version (personal build): 2.6.11-Zilog80 glibc version (personal build) : 2.3.2 Other info : Previous gcc version : 3.3 Fine work, regards, Cédric.
Re: Wconversion versus Wcoercion
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: | On 10/06/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: | > | > Here is my vote, have four options: | > -Wconversion the same as now. | | This is bad idea. Currently many people are relying in undocumented | behaviour or the false perception that Wconversion detects risky | conversions. If we keep Wconversion, they will keep using it wrongly. | (I don't think most people will read Changelogs). I don't believe we can just rename an existing option to another one just like that. First, I need to see a clear definition of "coercion", "conversion" and a clear statement why -Wconversion should disappear because of your project. [...] | My new proposal: (c) make Wconversion obsolete. I suggest you leave it, give a clear definition of "coercion". We will decide later whether it should be obselete or not. I'm unwilling to kill it or put it in a dust before seeing anything concrete about -Wcoercion. -- Gaby
Re: Wconversion versus Wcoercion
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: | On 10 Jun 2006 20:07:02 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: | > I'll like to see a more precise definition of your understanding of | > "coercion" versus "conversion". Last time we dicussed this I was not | > quite clear about what you consider is "bad" what is not. | > I was under the impression you taught it was for "C" only, but you | > have to take into account that some warnings are shared with the C++ | > front-end and some of them really should be common to both front-ends. | > | > If your project is NOT about coercion in general, but those just | > related to function prototypes, you should be careful about the name | > of the option. Again, this assumes you tell us what you consider | > coercion and what you consider conversion. | > | > -- Gaby | > | | My project is about "risky" coercions in general: assignments, | operators, prototypes. You can see some (and comment and propose) | testcases in http://gcc.gnu.org/wiki/Wcoercion . Thanks for maintaining a documentation about your current project. I hope by the time the project is completed the documentation becomes part of official GCC sources. People understand "conversion" because it is a term used in both C and C++ standards. You're introducing a second term (note : I did not say invented). You need to define it precisely so that people who have to give you feedback on work knows what you are talking about. Please do consider defining the term as you understand it and it guides your work. | I haven't thought how | all this works when you include classes and objects and inheritance. that is fine; once your have given clear definition and when you submit patches we will walk you through the implications. | However, this doesn't matter for this discussion because just taking | into account the current code in trunk, there are several problems : It does matter to know that they are implicit conversions that change values, and those are fine. It may be that in your definition, that is fine; but you have not told us precisely what it is. I'll like NOT to see a situation where you've spent months doing something that might be useful but we could not take it because you thought an aspect did not matter, when in fact it does. | 1) Following the documentation, currently Wconversion is used for two | different and unrelated things (i) "Warn if a prototype causes a type | conversion that is different from what would happen to the same | argument in the absence of a prototype" and (ii) "warn if a negative | integer constant expression is implicitly converted to an unsigned | type". These two behaviours should be split. Agrees. | 2) Currently, Wconversion works very different for C and for C++. I | have not seen anything in the manual explaining this, so I assume that | it is undocumented behaviour. I think this is bad: C and C++ should be | in sync and the current behaviour should be explained in the manual. if it is a documentation problem, the documentation should be strengthen instead of the option being removed. Note, "conversion" is a term well established in both C and C++ community. "coercion" is less used. And as a matter of fact, my understandings of terms are not the same. You need to nail it down. | 3) People using Wconversion to detect conversions that may be risky | are frequently told that this is not the intended purpose. However, in | g++, it currently works to some extent. People should not rely on | this. We should either warn them somehow that this is wrong or we | should fix Wconversion to do what they expect. However, fixing | Wconversion would silently break things for those that rely on its | original purpose. what kind of things that will be broken? If something is not documentation and we believe it is useful, we should document it. | So, I propose a third option: | | c) Remove Wconversion and create two new options Wcoercion and | Wprototypes-traditional. The reason is that both options (a) and (b) | would silently break Wconversion for someone. And keeping Wconversion | is not an option since it is currently broken and we need a way to Not just because you stated it is broken means it is. And even it is broken, please consider repair instead of removal. Please, do consider the above suggestions. -- Gaby
Re: Wconversion versus Wcoercion
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| My project is about "risky" coercions in general: assignments,
| operators, prototypes. You can see some (and comment and propose)
| testcases in http://gcc.gnu.org/wiki/Wcoercion .
void h2(void)
{
int i;
for(i=0; i < sizeof(double); i++);
}
when the ranges are known to imply no harm, it is irritating to get
the warning. It is conventional to use int a loop index.
Also don't include the warning option in the diagnostic message.
There is a separate machinery that shows which option control which
diagnostic.
-- Gaby
Re: [wwwdocs] Complete revamp of our web site
[ gcc-patches added, Reply-To: set ]
On Mon, 5 Jun 2006, DJ Delorie wrote:
> Sidebars should have some enclosing detail, such as a border or a
> shading, so set them off from the rest of the page. Don't rely on
> whitespace to do this job.
On this one, we follow the style of http://www.gnu.org. Looking into the
CSS there, I see that indeed they (and thus us) set a different background
color, alas that color is #fefefe which is white for all practical matters.
I guess this can be considered a bug, so I'll apply the patch below on
gcc.gnu.org in a minute and try to get a discussion with [EMAIL PROTECTED]
on this started. (Viewers of http://www.gnu.org/software/gcc/ will still
get the design in sync with the main page there, but http://gcc.gnu.org
will get the background.)
Okay?
> "Platforms" and "Testing" have bullets; no other item in that list
> does.
Addressed by several changes yesterday. Should be much more consistent
now.
Gerald
Index: gnu.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gnu.css,v
retrieving revision 1.1
diff -u -3 -p -r1.1 gnu.css
--- gnu.css 4 Jun 2006 23:24:17 - 1.1
+++ gnu.css 11 Jun 2006 16:23:46 -
@@ -73,12 +73,15 @@ a:hover {
font-weight: bold;
}
+/* gcc.gnu.org-local change: sync background-color with the copyright box
+ * instead of #fefefe which is basically white.
+ */
.td_con {
padding-top: 3px;
padding-left: 8px;
padding-bottom: 3px;
color : #303030;
- background-color : #fefefe;
+ background-color: #f2f2f9;
font-size: smaller;
}
Re: Wconversion versus Wcoercion
On 11 Jun 2006 10:31:07 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| My project is about "risky" coercions in general: assignments,
| operators, prototypes. You can see some (and comment and propose)
| testcases in http://gcc.gnu.org/wiki/Wcoercion .
void h2(void)
{
int i;
for(i=0; i < sizeof(double); i++);
}
when the ranges are known to imply no harm, it is irritating to get
the warning. It is conventional to use int a loop index.
Wsign-compare already emits a warning in this case. As far as I know,
there is no way in the front-end to know the ranges. The example,
perhaps should show be more evident:
for(i=-10; i < sizeof(double); i++);
This loop executes a total of 0 times. Yet, the previous testcase has
the benefit to show that currently we cannot know the ranges and we
should emit the warning.
Cheers,
Manuel.
Re: Wconversion versus Wcoercion
On 11 Jun 2006 10:14:02 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: Please, do consider the above suggestions. I will indeed and I am already thinking about them. Thanks for sharing your thoughts with me. I will try to make my following emails more clear on its definitions. Cheers, Manuel.
Missing -march=sempron -mtune=sempron -msse3 -m3dnow+?
Why is GCC-4.2.x missing -march=sempron -mtune=sempron -msse3 -m3dnow+? Why is GCC-4.2.x missing -march=k8 -mtune=athlonxp -mtune=athlon-xp -mtune=athlon_xp -msse3 -m3dnow+ -m32? Why is the table gcc/config/i386/i386.c:processor_alias_table[] small and unextendable? GCC want to say me bad news for powerful antiquities "Athlon-XP TBred", "Athlon-XP Barton", "Athlon64 Venice (939 pins and SSE3)" since 4 years and their performance match to the current processors. Obtenga su E-mail GRATUITO en http://www.clanomega.com ___ Get your own Web-based E-mail Service at http://www.zzn.com
Re: Missing -march=sempron -mtune=sempron -msse3 -m3dnow+?
On Jun 11, 2006, at 11:09 AM, Anny Blackyew wrote: Why is GCC-4.2.x missing -march=sempron -mtune=sempron -msse3 - m3dnow+? Well why don't you submit a patch to fix that? Why is GCC-4.2.x missing -march=k8 -mtune=athlonxp -mtune=athlon-xp -mtune=athlon_xp -msse3 -m3dnow+ -m32? Why don't you submit a patch to fix that Why is the table gcc/config/i386/i386.c:processor_alias_table[] small and unextendable? What do you mean by unextendable? I just tried to extend it and it worked. Maybe it is time for you to submit a patch or ask someone who you pay to submit a patch for these? Maybe you don't pay any one for GCC, well then you get what you paid for. -- Pinski
Re: Missing -march=sempron -mtune=sempron -msse3 -m3dnow+?
On Sun, 11 Jun 2006, Anny Blackyew wrote: > Why is GCC-4.2.x missing -march=sempron -mtune=sempron -msse3 -m3dnow+? As far as I can tell, tuning for Sempron doesn't make much sense since this is not one specific design, but at least two different ones (the Socket A variant and the Socket 754 variant). > Why is GCC-4.2.x missing -march=k8 -mtune=athlonxp -mtune=athlon-xp > -mtune=athlon_xp -msse3 -m3dnow+ -m32? I don't think we should have variants for all sorts of spellings such as athlonxp vs athlon-xp vs athlon_xp. And if you check our fine manual, you will see that we actually support such options. Gerald
Re: bootstrap broken on PPC-darwin and other targets without pkg-config (which is almost all)
On Sat, 10 Jun 2006, Andrew Haley wrote: >> See http://gcc.gnu.org/ml/gcc/2006-06/msg00120.html > I imagine that many people missed that announcement. I certainly did. > > Whilst I greatly appreciate Mark's GCC 4.2 Status Reports, I don't > always read them all. I try to keep the status part of our main page up-to-date with Mark's reports, but indeed this time I failed. Fixed thusly. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.566 diff -u -3 -p -r1.566 index.html --- index.html 11 Jun 2006 15:10:57 - 1.566 +++ index.html 11 Jun 2006 15:48:19 - @@ -70,7 +70,7 @@ mission statement. Status: Stage 3; http://gcc.gnu.org/ml/gcc/2006-06/msg00120.html";>2006-06-04 - (bugfixes and docu only). + (regression fixes and docu only). http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&; field0-0-0=noop&type0-0-0=noop&value0-0-0=">Serious
Re: Missing -march=sempron -mtune=sempron -msse3 -m3dnow+?
Andrew Pinski wrote: | | Why is the table gcc/config/i386/i386.c:processor_alias_table[] small and unextendable? | | | What do you mean by unextendable? I just tried to extend it and it worked. | Is it true? The truth is half. gcc$ for cpu in dothan sonoma sempron venice winchester palermo merom ; \ do grep -i -R $cpu . ; done | wc -l 0 gcc$ Obtenga su E-mail GRATUITO en http://www.clanomega.com ___ Get your own Web-based E-mail Service at http://www.zzn.com
Re: [wwwdocs] Complete revamp of our web site
[ gcc-patches added, Reply-To: set ]
On Mon, 5 Jun 2006, Andrew Pinski wrote:
> Also what about moving the News up to a noticeable spot since right now
> it is down in a corner so it looks out of place. In fact on my screen
> which is set to 1024x768, I have to scroll to get to the news.
I believe this also would have been the case for the original design?
But definitely something to address, yes!
> The release info should be at the same level as the news.
Agreed. Does that look better now?
Gerald
Rearrange the various sections on our main page. Use CSS instead of
and adjust formatting for and .
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.567
diff -u -3 -p -r1.567 index.html
--- index.html 11 Jun 2006 15:50:00 - 1.567
+++ index.html 11 Jun 2006 19:51:30 -
@@ -1,6 +1,10 @@
GCC, the GNU Compiler Collection
+
+ h2 { font-size: 1.2em; }
+ dd { margin-left:3ex; }
+
@@ -30,67 +34,17 @@ snapshots.
steering committee, guided by the
mission statement.
-
-
-Current release series:
- GCC 4.1.1
-
- Status:
- http://gcc.gnu.org/ml/gcc/2006-05/msg00345.html";>2006-05-15
- (regression fixes and docu only).
-
- http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.1&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&
;field0-0-0=noop&type0-0-0=noop&value0-0-0=">Serious
- regressions.
- http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.1&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-
0=">All
- regressions.
-
-
-Previous release series:
- GCC 4.0.3
-
- Status:
- http://gcc.gnu.org/ml/gcc/2006-03/msg00364.html";>2006-03-10
- (regression fixes and docu only).
-
- http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.0&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&;
field0-0-0=noop&type0-0-0=noop&value0-0-0=">Serious
- Regressions.
-
-
-Previous release series:
- GCC 3.4.6
-
- Status: the branch has been closed.
-
-
-Active development:
- GCC 4.2.0 (changes)
-
- Status: Stage 3;
- http://gcc.gnu.org/ml/gcc/2006-06/msg00120.html";>2006-06-04
- (regression fixes and docu only).
-
- http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emai
Re: Missing -march=sempron -mtune=sempron -msse3 -m3dnow+?
Gerald Pfeifer wrote:
| > Why is GCC-4.2.x missing -march=k8 -mtune=athlonxp -mtune=athlon-xp
| > -mtune=athlon_xp -msse3 -m3dnow+ -m32?
|
| I don't think we should have variants for all sorts of spellings
| such as athlonxp vs athlon-xp vs athlon_xp.
The big problem is that none of these work! It's due to many ocurrences of
athlon_* and athlon-* in the bash and m4 scripts (overall in "case") and
{.c,.h}.
athlon | athlon_*) in a location
athlon | athlon-*) in another location (but why?)
Other problem is the ambiguity of "athlon-xp-pc-linux-gnu" that
could not match with the regular expression *-*-linux-*.
It's contrary to the unambiguity of "i686-pc-linux-gnu", 3 minus signs
versus 4 minus signs.
Obtenga su E-mail GRATUITO en http://www.clanomega.com
___
Get your own Web-based E-mail Service at http://www.zzn.com
Generator programs can only be built with optimization enabled?
Typing "make" in $objdir/gcc (after a bootstrap) sometimes results in errors like: build/gencondmd.o: In function `VEC_rtx_heap_reserve': /net/sparrowhawk/scratch/mitchell/src/lto/gcc/rtl.h:195: undefined reference to `vec_heap_p_reserve' For an ordinary "make" the generator programs are built without optimization. But, rtl.h use DEF_VEC_*, the expansion of which includes inline functions. With optimization disabled, the compiler apparently emits the inline functions. The inline functions reference symbols (like vec_heap_p_reserve) that are not included in the build objects linked into the generator program. I'm using a version of mainline that's a few weeks old; is this something that has been recently fixed? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Generator programs can only be built with optimization enabled?
On Jun 11, 2006, at 1:20 PM, Mark Mitchell wrote: I'm using a version of mainline that's a few weeks old; is this something that has been recently fixed? Not really fixed, just hidden and the behavior of cgraph reverted to what it was in 4.1.0 but you can still reproduce the failure with -fkeep-inline-functions or compiling with Sun's CC (at default optimizations). See PR 18058 for how long this has been going on, there was a patch there but it sounds like it does not fix the full problem any more. Thanks, Andrew Pinski
Re: Generator programs can only be built with optimization enabled?
This is part of the new build infrastructure. One cannot simply go into $objdir/gcc and type "make". One either needs to use the appropriate incantation at the top-level build directory or go into $objdir/gcc and type "make CFLAGS='xxx'", where 'xxx' matches the optimization options for the current bootstrap phase. David
Re: Generator programs can only be built with optimization enabled?
Mark Mitchell <[EMAIL PROTECTED]> writes: | Typing "make" in $objdir/gcc (after a bootstrap) sometimes results in | errors like: | | build/gencondmd.o: In function `VEC_rtx_heap_reserve': | /net/sparrowhawk/scratch/mitchell/src/lto/gcc/rtl.h:195: undefined | reference to `vec_heap_p_reserve' | | For an ordinary "make" the generator programs are built without | optimization. But, rtl.h use DEF_VEC_*, the expansion of which includes | inline functions. With optimization disabled, the compiler apparently | emits the inline functions. The inline functions reference symbols | (like vec_heap_p_reserve) that are not included in the build objects | linked into the generator program. this must be a bug, not a feature. I think we already have PRs about it. -- Gaby
Re: Generator programs can only be built with optimization enabled?
David Edelsohn wrote: > This is part of the new build infrastructure. One cannot simply > go into $objdir/gcc and type "make". One either needs to use the > appropriate incantation at the top-level build directory or go into > $objdir/gcc and type "make CFLAGS='xxx'", where 'xxx' matches the > optimization options for the current bootstrap phase. That seems unfortunate, but so be it. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Generator programs can only be built with optimization enabled?
> Mark Mitchell writes: Mark> That seems unfortunate, but so be it. Yes it is very unfortunate and not very convenient for the way that most developers want to use the build infrastructure. There no longer is an equivalent to "make quickstrap". To rebuild only GCC, one can use "make all-stageN-gcc" at the top-level. David
Re: Where is the egg?
On Mon, 5 Jun 2006, Steven Bosscher wrote: > But is it really necessary to remove the egg too? Can we have > it back? Pleaeaeaeaese? :-) It's still there, just transformed into an Easter egg -- hidden in the bushes. ;-) Seriously, it did not really fit the design we inherited. I tried, and failed. Given your (and other) requests, I now have an idea that seems to work... On Mon, 5 Jun 2006, Stephan T. Lavavej wrote: > If y'all need a differently sized egg, I can generate one. (I was the one > who traced the old JPEG to make the clean PNG.) I've still got the high-res > master lying around. ...especially given Stephan's offer. Stephan, if you could provide an egg of about 60% the current size, and one of about 70% (so that we can play a bit), that would be great. Thanks! Gerald
Re: Thoughts on gcc maintainership and project merging
On Wed, 24 May 2006, Zdenek Dvorak wrote: >Proposal: Whenever a new pass or a major functionality is added to > gcc, a maintainer for it must be found. Preferably the > author, or in case he from some reason is not considered > suitable, some other person must be assigned. We can also enhance that: if you know about someone who should, in your opinion, be elevated to maintainer status for a specific part of GCC, or you think you are such a person, let a SC member of your choice know! (Yes, these then tend to take a while, but we try not to drop any balls. At least, in my TODO file I have some opens left... ;-) Gerald
Re: [wwwdocs] Complete revamp of our web site
On Mon, 5 Jun 2006, DJ Delorie wrote: > Right-side navigation bars are nonstandard. It should be moved to the > left side. Don't accept the search engine excuse; that's easily > fixable. Also, by fixing the search engine issue you punish Lynx > users; the navigation menu is now near (but not at) the end of the > text. Is your concern mainly Lynx users (and similar users)? It should be feasible to move the navigation bar to the beginning for these while still keeping it on the right side to be in sync with www.gnu.org. (Which technique would you recommend to address what you refer to as the "search engine" issue?) Gerald
Re: [wwwdocs] Complete revamp of our web site
Gerald Pfeifer wrote: > On Mon, 5 Jun 2006, DJ Delorie wrote: >> Right-side navigation bars are nonstandard. It should be moved to the >> left side. Don't accept the search engine excuse; that's easily >> fixable. Also, by fixing the search engine issue you punish Lynx >> users; the navigation menu is now near (but not at) the end of the >> text. > > Is your concern mainly Lynx users (and similar users)? It should be > feasible to move the navigation bar to the beginning for these while > still keeping it on the right side to be in sync with www.gnu.org. > > (Which technique would you recommend to address what you refer to as > the "search engine" issue?) I have to ask, why do people use lynx these days when links or elinks are much faster and better text mode browsers? I just have a very hard time thinking there are many lynx users these days. > > Gerald >
Re: [wwwdocs] Complete revamp of our web site
Daniel Berlin <[EMAIL PROTECTED]> writes: | > (Which technique would you recommend to address what you refer to as | > the "search engine" issue?) | | I have to ask, why do people use lynx these days when links or elinks | are much faster and better text mode browsers? some people don't run imperial machines; for some people, their experience with lynx and other browsers is that lynx tend to be more lightweight and much faster. | I just have a very hard time thinking there are many lynx users these days. depends on the corner of world you look at. -- Gaby
RE: Where is the egg?
[Gerald Pfeifer] > Stephan, if you could provide an egg of about 60% the current > size, and one of about 70% (so that we can play a bit), that > would be great. Of course, my dark lord. http://stl.nuwen.net/gcc50.png http://stl.nuwen.net/gcc55.png http://stl.nuwen.net/gcc60.png http://stl.nuwen.net/gcc65.png http://stl.nuwen.net/gcc70.png http://stl.nuwen.net/gcc75.png http://stl.nuwen.net/gcc80.png These are pngcrushed versions with linear dimensions between 50% and 80% of the 200-pixel-high original. Stephan T. Lavavej
Re: [wwwdocs] Complete revamp of our web site
> On this one, we follow the style of http://www.gnu.org. Looking > into the CSS there, I see that indeed they (and thus us) set a > different background color, alas that color is #fefefe which is > white for all practical matters. > > Okay? It addresses that issue, yes.
Re: [wwwdocs] Complete revamp of our web site
> Is your concern mainly Lynx users (and similar users)? It should be > feasible to move the navigation bar to the beginning for these while > still keeping it on the right side to be in sync with www.gnu.org. Lynx is an example of a non-GUI browser. All non-GUI browsers would suffer similarly. I don't think they should be moved to the top; that messes up search engines, but the usual alternate is to put a set of links at the *bottom* of the page, not in the middle. > (Which technique would you recommend to address what you refer to as > the "search engine" issue?) http://www.delorie.com/web/ses-hint.html
Re: [wwwdocs] Complete revamp of our web site
FWIW, I much prefer the navigation bar on the left no matter what browser I'm using. Dustin pgpRTYu9WRFhX.pgp Description: PGP signature
