27;s patches so correct in fixing this big regression
which I am surprised they find so much opposition. I kindly ask you to
reconsider your position.
Giovanni Bajo
-O2.
Also, I would like to see detailed reports of where the compilation time goes,
after the patch. I'm sure we can go blaming other optimizers (probably some of
the new ones) for the compile time regression.
Giovanni Bajo
tuations where it hurts still).
That is *exactly* what -pedantic is meant to be. If it does not, patches are
welcome.
Giovanni Bajo
ople *should* expect trouble while upgrading to 3.4,
or 4.0. I would be *really* surprised to hear a notransition from 2.95 to 4.0
which does not require any modification (for non-trivial codebases of course).
Giovanni Bajo
post the patch as an unified diff, and attach it to the mail rather than
copying within it.
Giovanni Bajo
ich
I'm CC:ing) is the owner of that page.
Niall, are you planning to get the site back up and running soon? If not, can
we get a copy of gccvisibility.html so that we can extract the text and host it
locally?
Thanks
Giovanni Bajo
was
posted last December with mainline in Stage 3 (and got almost no comments), so
if the patch is approved, it could be added to 4.0 too (given absolutely zero
risk).
Giovanni Bajo
+ FE needs to fold
constant expressions (in the ISO C++ sense of 'constant expressions)? For
instance, we need to fold "1+1" into "2" much before gimplification. Should
a part of fold() be extracted and duplicated in the C++ frontend?
--
Giovanni Bajo
you talking of? I know for a fact that the extension itself has always
worked for basic rvalue usage, with basic types. Instead, I would not be
surprised if some more complex usage of it used to be (or still is) broken,
like weird lvalue contexts, usage in templates, operator overloading or
similar.
--
Giovanni Bajo
, and both shows a rather complex
situation which includes pointer tricks. My statement that basic usage of
the extension has always worked still holds.
--
Giovanni Bajo
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> IMO, if these are C++-only, it's relatively easy to deprecate these
> extension -- but I'd like to hear from Jason and Nathan, and also the
> user community before we do that. Of all the extensions we've had, this
> one really hasn't been that problemati
es. It avoided me to write casts
which are otherwise necessary. I don't think I will have to explain you the
domain of the problem, why that single variable was float or int, and so on.
My statement is that std::min() is *not* an exact replacement for I would like to see those extensions deprecated and go with no return.
I would like to propose them for standardization. It is just too bad I don't
have time to prepare the papers.
--
Giovanni Bajo
the purpose of assessing the purpoted
> usefulness in real codes. Arguments are easily made with xyz examples.
Are you disputing the usefulness of promotion rules with operators? If you
agree that promotion is useful, I cannot see why it should not be for
min/max operators.
--
Giovanni Bajo
ement that min() and max() are not exact replacements still stands.
We'll disagree, as happens.
Since there is no exact replacements (especially for the min/max assignment
operators), and the extensions are definitely not so troublesome, I would
like them to stay.
--
Giovanni Bajo
'll remove
the link.
I would like to still get hold of the information that used to be present at
that page because they were in fact very useful.
--
Giovanni Bajo
have the time nor the willing of pushing a patch for
weeks just for this. I believe we should either be more liberal with the
contents of our website, or get more reviewers. For instance, we could think
of a policy where a www patch can be applied after 48hrs if nobody says
otherwise).
--
Giovanni Bajo
cp=1&.intl=us
OK, done. Link: http://gcc.gnu.org/wiki/Visibility.
Can someone patch changes.html and restore the link in the documentation
that was deleted a few days ago?
--
Giovanni Bajo
ew, rather than the fact that the Wiki syntax is partially
lighter than HTML. The 48-hrs rule I propose seems sensible to me. The worst
thing that can happen is that something incorrect goes live on the site, and
it'll eventually get fixed when someone reads the patch a few days later.
--
Giovanni Bajo
d have been committed immediatly and been refined
over time. In fact, I should find a couple of hours to add it to the Wiki.
--
Giovanni Bajo
Michael Cieslinski <[EMAIL PROTECTED]> wrote:
> I formatted the infomation from Giovanni Bajo's patch and put it in the
> Wiki: http://gcc.gnu.org/wiki/HowToPrepareATestcase
Many thanks!
--
Giovanni Bajo
C++. Anyone using that feature? Or know anyone
> who is.
Last time this was discussed on gcc@, there was an agreement that since we
have to support trampolines for Ada & co., we can as well keep the extension
in C, which allows easier testcases, reductions (as most developers do not
understand Ada) and let the feature be tested even within gcc.dg.
--
Giovanni Bajo
software is unfortunate. I agree with Mark when he
says that a naked abort should be used only after useful information has
already been printed to the user. In fact, we are in the middle of a conversion
of the whole GCC codebase from abort() to assert() (even if our abort() is a
fancy_abort() in disguise!).
Giovanni Bajo
Topi Maenpaa <[EMAIL PROTECTED]> wrote:
> In short, anything inherited from the base class can be used as
> expected, except the assignment operator. What's the deal? I'm doing
> this on Mandrake
> 10.1, gcc 3.4.1, if that matters.
This is what the standard says.
Giovanni Bajo
Maybe a NEWS item is called for, I dunno.
It will be in NEWS, since RTH already updated
http://gcc.gnu.org/gcc-4.0/changes.html. I hope newlib will be promptly fixed.
Giovanni Bajo
rmore,
> calling A::test directly from main rather than through the
> template function works fine.
This is correct, because if "test2" is not a template function name anymore,
then 'a' is not a dependent name, and the 'template' keyword is not needed to
disambiguate the parser.
Giovanni Bajo
John Vickers <[EMAIL PROTECTED]> wrote:
> I can have another go without the "--disable-checking" if that's
> likely to help. Anything else you'd like in the bug report ?
Please submit the smallest preprocessed source you can machine-generate which
shows the bug.
Thanks!
Giovanni Bajo
er with Ulrich, maybe?).
What is your plan for this branch? Is there more code refactoring/rewriting
planned, or are you just going to give it a wider testing and fix fallout bugs,
in preparation for a merge?
Giovanni Bajo
void *lb[] = { &&l1, &&l2, &&l3 };
int x = 0;
goto *lb[dest];
l1:
x += 1;
l2:
x += 1;
l3:
x += 1;
return x;
}
I would not design a backend so that such a feature is deemed to be impossible
to support.
Giovanni Bajo
:34: internal compiler error: in schedule_insns, at
sched-rgn.c:2549
>
> who can tell me why?
> why can it bring compiler error?
Any compiler error, *whichever* source file you use, is a bug of GCC. Would
you please submit this as a proper bugreport in Bugzilla? Read the
instructions at http://gcc.gnu.org/bugs.html.
Thanks
--
Giovanni Bajo
t bootstrap time means the IA-64 bootstrap
> should now succeed. This testcase will still be broken, but now it
> will only be a make check failure instead of a make bootstrap failure.
Typo, you meant PR 20694.
Giovanni Bajo
be
templates only?). Are you positive this attribute declaration *does* have an
effect at all in 3.4?
--
Giovanni Bajo
I suggest you file a bugreport in Bugzilla, and
mark it as ABI breaking. It should get fixed before 4.0 gets out.
--
Giovanni Bajo
:
http://gcc.gnu.org/ml/gcc/2005-04/msg00139.html
I hope he'll open a PR soon, but you probably want to consider this for 4.0.
Giovanni Bajo
pen a PR soon, but you probably want to consider this
>>> for 4.0.
>>
>>
>> Note it also effects all targets too by shown by my testcase.
>
> Please put this into a PR.
This is now PR 20763. I took the liberty of CC'ing you in it.
--
Giovanni Bajo
like WRITEONCE_EXPR which is a MODIFY_EXPR with a READONLY on its lhs, and
which is supposed by the frontends when initialing such variables.
Giovanni Bajo
mention it (and news.html
as well). Would you please prepare a patch about this?
--
Giovanni Bajo
ated by #pragma weak alias=target. This is because it's meaningless to
define an alias to an undefined symbol. On Solaris, the native assembler would
have caught this error, but GNU as does not.
Giovanni Bajo
Hello Gaby,
do you still confirm the release date which was last reported here:
http://gcc.gnu.org/ml/gcc/2005-01/msg01253.html
that is, will GCC 3.3.6 released on April, 30th? And will it be the last
release of the GCC 3.3 series?
Thanks,
Giovanni Bajo
> an expert in that area and the patch even was rather short, but I do
> not see it in CVS, so I just committed it.
I either forgot about it or waited for an approval. Either way, thank you for
taking care of this!
Giovanni Bajo
t to sound rude, but your posts seem more like trolling
to me. I am *ready* to admit that GCC4 is much slower than GCC3 or GCC2, but I
would like to do this in front of real measurable data, not just random
complaints and told legends. Thus, I am really awaiting your preprocessed
testcases which prove
or stuff like that.
Please, provide preprocessed sources and we *will* analyze them. Just file a
bugreport in Bugzilla, it took 10 minutes of your time.
Giovanni Bajo
#x27;s
not 1% or something like that.
There are many posts on gcc@ that show this, I can dig them up in the archive
for you if you want, but I'm sure you can use google as well as I do. Two of
them are very recente (see Karel Gardas' post on this thread, and the recent
benchmark posted by Rene Rebe).
Giovanni Bajo
d. This also helped building up a stereotype of
the average NetBSD developer being "just a GCC whine troll".
I am sure this is *far* from true, but I would love to see NetBSD developers
*collaborating* with us, especially since what we are asking (filing bug
reports with preprocessed sources) cannot take more than 1-2 hours of their
time.
Giovanni Bajo
ted as NetBSD maintainer... you can always drop me a
> note directly when this sort of thing happens.
Thanks! Are you then going to file in Bugzilla some preprocessed sources that
show the 2.95 -> 3.3 slowdown experimented by NetBSD folks?
Giovanni Bajo
actually fetch from memory?
> Hint, 3.3 fetched.
I agree it should fetch. Did you try -fno-strict-aliasing? Open a bugreport,
I'd say.
Giovanni Bajo
Kenneth P.. Massey wrote:
> The code below runs significantly slower when compiled in 64 bit with
> 3.4.3 than
> it does in 3.3.4, and both are significantly slower than a 32 bit
> compile.
Thanks for the report. Would you please open a bugreport in Bugzilla?
--
Giovanni Bajo
le and
linkable, and the resulting binary should run for a while doing computations.
With this kind of help, we can analyze the regression and see why it's slower
with 4.0.0.
Giovanni Bajo
picked the
> numsort benchmark which had a serious regression:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
Many, many thanks!
Giovanni Bajo
ould
you please take care of that? It is sufficient to provide a single
preprocessed source which shows the code size increase in compilation. GCC4
still needs some tuning for -Os.
Thanks!
--
Giovanni Bajo
c2 test.o
GCC 4.1.0 CVS 20050323
textdata bss dec hex filename
280 0 0 280 118 test.o
So it's a 44% increase. Definitely worth a bugreport in Bugzilla!
--
Giovanni Bajo
ode base is audited and __attribute__((upcast)) added wherever appropriate.
- For the Java/Fortran/Ada frontend, probably TBAA can be on by default at -Ox,
but I dunno.
I'm positive that for C++ there would be zero need for manual decoration in,
say, a whole OS distribution (Qt, KDE, Boost, and whatnot) if we use
"-ftree-tbaa -fpod-upcast".
Giovanni Bajo
etter than 3.3, after we disable -ftree-sra. I guess SRA
should be tuned (disabled?) for -Os.
Please, do file a bugreport.
--
Giovanni Bajo
be able to make up for turning off SRA, i'm
> guessing, at least as far as propagating constants and DCE is
> concerned.
>
> You could test this by seeing if -fno-tree-sra -fno-tree-salias
> produces
> an increased code size over the above.
Not really: with -fno-tree-salias I get exactly the same result (224 bytes).
Giovanni Bajo
tic programmer from getting to
>> them anyway, but that's always the case.
>
> Ooh, I like this one for enum machine_mode.
I think this is an ODR failure for C++ and I suspect program-at-a-time would
flag it with an error. So even this solution to hide enum constants (a
legitimate design request) does not appear to be C++ compatible to me.
--
Giovanni Bajo
Mark,
is it OK to remove the link "Last-Minute Requests for 4.0.0" from the Wiki
main page? The page is obviously unneded there. If you want, we can keep the
link somewhere else (like collected in a page "obsolete misc pages").
--
Giovanni Bajo
x27;s not GCC's fault).
> [2] GCC could implement a better error message.
This is a bug, too. You can file a PR in Bugzilla explictly asking for a more
informative error message.
Giovanni Bajo
323 because the C/C++
standards do not tell us to do better than this. If you have higher
expectations about floating point and C/C++, you should file a bugreport
against the C/C++ standards.
Really, we can't make everybody happy. The best we can do is to adhere the
international well-known ISO/ANSI standards.
Giovanni Bajo
applies for a vect_int test, vect-dv-2.c. I assume also vect_int
tests require SSE2 capability and thus should call check_vect()?
Thanks,
Giovanni Bajo
t the sensible thing to do is to use
check_vect there as well.
For an example of the failures, see for instance:
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00553.html (which is
Diego's tester).
--
Giovanni Bajo
can easily provide a patch to
make the few missing testcases call check_vect(), as the rest of the
testsuite does. This would shut down the bogus regressions, while a more
correct solution is being developed. Would such a patch be ok?
--
Giovanni Bajo
o file papers for copyright assignment to the FSF, which is a
prerequisite for accepting any patch.
Giovanni Bajo
warning (OPT_Wmissing_braces, "missing braces around initializer");
What is the difference between [1], [2], [3]?
Thanks,
--
Giovanni Bajo
ng is
> warranted is sufficiently complex, *also* checking the variable is
> considered an optimization:
OK, thanks!
--
Giovanni Bajo
DJ Delorie <[EMAIL PROTECTED]> wrote:
>> So, I assume this patch is wrong in this regard:
>> http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00392.html
>
> Yes, it's wrong in that way.
Gaby, can you please fix it then?
--
Giovanni Bajo
ng() also for another reason: we want to
be able to optionally print which flag can be used to disable each warning,
so warning() has to be smarter than it used to be.
--
Giovanni Bajo
break strict-aliasing rules
../../../gcc/libmudflap/mf-runtime.c:339: warning: dereferencing type-punned
pointer will break strict-aliasing rules
../../../gcc/libmudflap/mf-runtime.c:342: warning: dereferencing type-punned
pointer will break strict-aliasing rules
The code is accessing a variable of enum type through an unsigned pointer.
Giovanni Bajo
ions. Yet here's a quote from an earlier message by
> Giovanni Bajo.
> [...]
First of all, I would consider polite to CC: me on the mail if you quote and
debate my statements.
> The ISO Standard doesn't prevent GCC from being *better* than
> specified, does it? Are we somehow
this testcase. It
reads:
2005-05-17 Jeff Law <...>
* g++.dg/tree-ssa/pr18414.C: New test.
* gcc.dg/tree-ssa/pr18414.C: New test.
while the correct PR number is "14814". Would you please also fix this?
Thanks,
Giovanni Bajo
Richard Henderson <[EMAIL PROTECTED]> wrote:
> This needs to use a VIEW_CONVERT_EXPR, at minimum.
What about a compound literal instead?
Giovanni Bajo
it, so an objection in a comment does
not make the bug invalid per se.
--
Giovanni Bajo
Richard Henderson <[EMAIL PROTECTED]> wrote:
>>> This needs to use a VIEW_CONVERT_EXPR, at minimum.
>>
>> What about a compound literal instead?
>
> I suppose. Why?
Nothing specifically. I just believe it is a cleaner way to transform the
argument into an agg
: vector VEC(tinfo_s,base) index domain error, in
get_tinfo_decl at cp/rtti.c:373
Would you please check and possibly fix this?
Thanks,
Giovanni Bajo
Feng Wang <[EMAIL PROTECTED]> wrote:
> I want to write a testcase. The compiler gives two separated warnings on
one
> statement. How to write this with Dejagnu?
http://gcc.gnu.org/wiki/HowToPrepareATestcase
--
Giovanni Bajo
alled "make all-stageN", and there is also "make
> all-stageN-gcc" to rebuild gcc only.
It would help also if you add to the wiki explanation of what exactly all
these options do. Especially bubblestrap vs quickstrap vs restrap.
Thanks!
--
Giovanni Bajo
, etc.). Maybe we should think if we want to use the Wiki as our rapid
documentation prototyping: people could write documentation there for
review, be refined by others, and eventually converted to real TeX
documentation.
--
Giovanni Bajo
t into texinfo
with our commands. It would handle the boring part of the conversion.
Giovanni Bajo
rations within templates, correct semantic for old-style access
declarations vs using declarations, etc.), plus of course the usual bag of
bugs.
I am not aware of any official list though.
Giovanni Bajo
mem is just an optimization option
which does not affect the semantic of the program in any way. If we remove
it, people would need to just drop it from their Makefiles. There is no
source code adjustment required (which would justify the deprecation cycle).
Or convert it to a noop as Bernd suggested.
--
Giovanni Bajo
some verification could be done, eg, at gimplification
time, rather than waiting for latent bugs in optimizers to produce wrong
code?
--
Giovanni Bajo
been some opposition in the past about allowing conditions in
asserts to be used as hints to the optimizers. In fact, I would like to know
if there is a current statement of purpose about this. That is, would there
be strong oppositions to patches doing this?
--
Giovanni Bajo
gt; return 2;
> }
Agreed, but my point is whether we can do that when NDEBUG is defined.
--
Giovanni Bajo
ttribute would be needed in the first place for
gcc_unreachable() in our own sources. Right now we expand it to gcc_assert(0),
but we could do much better with a special attribute.
Giovanni Bajo
find a way to avoid generating e.g. function calls or
similar things, and get information from the most basic conditions.
Giovanni Bajo
ned in the file
cp/pt.c. The instantiation happens in the function tsubst_copy_and_build.
You can place a breakpoint there and see what happens within GDB.
--
Giovanni Bajo
hat explains what needs to be
> sent, but doesn't contain a word about *where* to send. That's not a
> flame, just a silly user's troubles.
I see you already have an account. Login is [EMAIL PROTECTED] Try
logging in with the password you provided. Otherwise, I can reset the
password for you.
--
Giovanni Bajo
rictly a GCC question, but
mainly a C++ question, your program is likely invalid and you do not know
why. So probably the best forum to ask is some newsgroup like
comp.lang.c++.moderated.
--
Giovanni Bajo
status of Stage 2. As things
stand now, Stage 2 ends tomorrow.
Giovanni Bajo
; no wrong
code will be generated. This ain't code. In many common cases, the
documentation will be useful effectively immediatly, and
typos/subtleties/formatting can be refined by others over time.
--
Giovanni Bajo
nd all changes to gcc-patches to
> assist in review?
I strongly support this (and was going to suggest this myself). I'd rather
it be another list though, say wiki-patches or doc-patches, because of the
amount of traffic that is going to be generated (think of all those small
typo fixes, or spam reverts).
--
Giovanni Bajo
the contributors.
Thanks.
--
Giovanni Bajo
s are created?
I believe the simple way is faster for you to continue with you work. The
proper fix does not look easy at all.
--
Giovanni Bajo
al-case hacks:
http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00550.html
http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00630.html
--
Giovanni Bajo
Michael Gatford <[EMAIL PROTECTED]> wrote:
> std::map::const_iterator functionIterator =
> quickfindtag.find(funcname);
It's missing a typename keyword here:
typename std::map::const_iterator functionIterator =
See: http://gcc.gnu.org/gcc-3.4/changes.html, C++ sect
code to escape special characters, so to write
something like:
@54 string_cst type: @61 strg: "wrong
type:\n\0\0\xaf\x03\x03foo\"bar" lngt: 19
This would not need a different special option.
--
Giovanni Bajo
e is *very* specific of GCC inners, and
it can dramatically changes between releases. OK, maybe not the syntax, but
the semantic. I wouldn't care of the syntax at that point.
--
Giovanni Bajo
managed by a parent process that monitors and manages it's
> execution - reporting crashes and restarting it if necessary.
Looks like a bug hidden in your code. Several things you could try:
- valgrind
- GCC 4.0 with -fmudflap
- GCC 4.1 CVS with -fstack-protect
--
Giovanni Bajo
sizes be smaller (at least a little) with the -O3 switch? Maybe
> there's a loop unrolled to make it faster, resulting in a larger
> codebase?
Or inlining, or many other things. If you care about size, use -Os.
--
Giovanni Bajo
description; also one should be closed as duplicate of
the other, instead of simply marked as "fixed".
Giovanni Bajo
/wiki/Visibility).
IMHO, it's unreasonable to break the C++ ABI for 1 second of warm time
startup.
--
Giovanni Bajo
should
be clearly stated.
Giovanni Bajo
1 - 100 of 212 matches
Mail list logo
