Fellow GCC developers,
Does GCC make any effort to collapse control-flow that is guaranteed to
have undefined behavior? Such an optimization would improve performance
of Proc_2 from Dhrystone:
typedef int One_Fifty;
typedef enum{Ident_1, Ident_2, Ident_3, Ident_4, Ident_5}
On Wed, Oct 7, 2009 at 8:53 AM, Charles J. Tabony
tabon...@austin.rr.com wrote:
Fellow GCC developers,
Does GCC make any effort to collapse control-flow that is guaranteed to
have undefined behavior? Such an optimization would improve performance
of Proc_2 from Dhrystone:
typedef int
Apologies if you receive multiple copies of this call.
CALL FOR PAPERS
2nd Workshop on
GCC Research Opportunities
Hi,
today I'm seeing an ABI check failure in mainline, x86_64-linux, 11
incompatible symbols: my preliminary analysis shows that the problem is
the recurring one, simple, but annoying: some small functions are not
inlined anymore, thus inadvertently exported (with an old version
number, because
On Wed, Oct 7, 2009 at 12:24 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
today I'm seeing an ABI check failure in mainline, x86_64-linux, 11
incompatible symbols: my preliminary analysis shows that the problem is
the recurring one, simple, but annoying: some small functions are not
Richard Guenther wrote:
Yes.
Thanks ;) I'm going to tighten the patterns asap, cannot hurt. For the
record, on testresults there are no big traces of this issue, this is
puzzling, no idea why some people do not reproduce my problems...
Paolo.
2
_ZNKSt8ios_base6getlocEv
std::ios_base::getloc() const
version status: incompatible
GLIBCXX_3.4
type: function
status: added
Are there very recent inlining changes?
Yes.
This might be patch I commited today morning. It would help if you
could just send me testcase showing
Hi Honza,
2
_ZNKSt8ios_base6getlocEv
std::ios_base::getloc() const
version status: incompatible
GLIBCXX_3.4
type: function
status: added
Are there very recent inlining changes?
Yes.
This might be patch I commited today morning. It would help if you
could just send me
Anyway, as regards *which* specific functions are not inlined, I would
say all the functions which break the ABI test as newly exported symbols
should be checked, like the above, 'std::ios_base::getloc() const'. I'm
attaching below a complete list, from my libstdc++.log, but I would
guess
On Wed, Oct 7, 2009 at 2:33 PM, Jan Hubicka hubi...@ucw.cz wrote:
Anyway, as regards *which* specific functions are not inlined, I would
say all the functions which break the ABI test as newly exported symbols
should be checked, like the above, 'std::ios_base::getloc() const'. I'm
attaching
I am pleased to announce that the GCC Steering Committee has
appointed Diego Novillo, Rafael Avila de Espindola, and Richard Guenther
as LTO Reviewers, and Rafael Avila de Espindola and Cary Coutant as
LTO Plugin Reviewers.
Thanks to everyone for their hard work bringing LTO to
David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Diego Novillo, Rafael Avila de Espindola, and Richard Guenther
as LTO Reviewers, and Rafael Avila de Espindola and Cary Coutant as
LTO Plugin Reviewers.
Sorry, but what exactly are LTO plugins?
On Wed, Oct 7, 2009 at 09:55, Basile STARYNKEVITCH
bas...@starynkevitch.net wrote:
Are LTO plugins fondamentally different from others, non LTO plugins?
Yes, it should be probably be named 'linker' plugins. It's a plugin
for gold to allow extraction of individual .o files out of static
Btw, that new comdat behavior is very well reasonable. In
whole-program mode it should be the old one though.
It is another effect of the patch that in whole-program we bring all
comdat functions static except for those having address taken (so the
address must be same from all modules)
I was
Diego Novillo wrote:
On Wed, Oct 7, 2009 at 09:55, Basile STARYNKEVITCH
bas...@starynkevitch.net wrote:
Are LTO plugins fondamentally different from others, non LTO plugins?
Yes, it should be probably be named 'linker' plugins. It's a plugin
for gold to allow extraction of individual .o
On Wed, 7 Oct 2009, David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Diego Novillo, Rafael Avila de Espindola, and Richard Guenther
as LTO Reviewers, and Rafael Avila de Espindola and Cary Coutant as
LTO Plugin Reviewers.
Thanks to
On Wed, Oct 7, 2009 at 10:10, Basile STARYNKEVITCH
bas...@starynkevitch.net wrote:
Then I would imagine it requires a copyright transfer to FSF different of
the one covering GCC development. The legal document covering my
contribution cites specifically GCC (not binutils).
Getting that
Diego Novillo dnovi...@google.com writes:
On Wed, Oct 7, 2009 at 09:55, Basile STARYNKEVITCH
bas...@starynkevitch.net wrote:
Are LTO plugins fondamentally different from others, non LTO plugins?
Yes, it should be probably be named 'linker' plugins. It's a plugin
for gold to allow
On Wed, Oct 7, 2009 at 10:12, Ian Lance Taylor i...@google.com wrote:
Diego Novillo dnovi...@google.com writes:
On Wed, Oct 7, 2009 at 09:55, Basile STARYNKEVITCH
bas...@starynkevitch.net wrote:
Are LTO plugins fondamentally different from others, non LTO plugins?
Yes, it should be
Jan Hubicka wrote:
So things seems to work now plus minus as expected. I.e. LTO builds
seems similar to combined builds and whole-programs improves code size
quite noticeably.
Runtime results for gzip are pretty much unchanged, but that is
expected. I am quite curoius about full SPEC run.
Diego Novillo wrote:
On Wed, Oct 7, 2009 at 10:10, Basile STARYNKEVITCH
bas...@starynkevitch.net wrote:
Then I would imagine it requires a copyright transfer to FSF different of
the one covering GCC development. The legal document covering my
contribution cites specifically GCC (not binutils).
On Wed, Oct 7, 2009 at 10:29, Basile STARYNKEVITCH
bas...@starynkevitch.net wrote:
I suppose LTO plugins means plugin dlopen-ed in lto-plugin/lto-symtab.c
No, it does not mean that. As I said already, these are plugins for
gold, the linker. It is gold the one that uses it.
Diego.
On Wed, Oct 07, 2009 at 04:29:29PM +0200, Basile STARYNKEVITCH wrote:
I suppose LTO plugins means plugin dlopen-ed in lto-plugin/lto-symtab.c
It sounds to me like this confusion comes from LTO plugins. Isn't
it just LTO plugin? That is, a specific plugin?
--
Daniel Jacobowitz
CodeSourcery
I try to analyse this code:
--
int foo (int N)
{
int ftab[257];
int i, j;
for (i = 0; i N - 7488645; i++)
j = ftab [i];
return j;
}
--
The number of iterations I get is:
On Wed, Oct 7, 2009 at 4:25 PM, Vladimir Makarov vmaka...@redhat.com wrote:
Jan Hubicka wrote:
So things seems to work now plus minus as expected. I.e. LTO builds
seems similar to combined builds and whole-programs improves code size
quite noticeably.
Runtime results for gzip are pretty
On Wed, Oct 7, 2009 at 10:34, Daniel Jacobowitz d...@false.org wrote:
On Wed, Oct 07, 2009 at 04:29:29PM +0200, Basile STARYNKEVITCH wrote:
I suppose LTO plugins means plugin dlopen-ed in lto-plugin/lto-symtab.c
It sounds to me like this confusion comes from LTO plugins. Isn't
it just LTO
On Wed, Oct 7, 2009 at 4:37 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
I try to analyse this code:
--
int foo (int N)
{
int ftab[257];
int i, j;
for (i = 0; i N - 7488645; i++)
j = ftab [i];
return j;
}
Diego Novillo dnovi...@google.com writes:
On Wed, Oct 7, 2009 at 10:34, Daniel Jacobowitz d...@false.org wrote:
On Wed, Oct 07, 2009 at 04:29:29PM +0200, Basile STARYNKEVITCH wrote:
I suppose LTO plugins means plugin dlopen-ed in lto-plugin/lto-symtab.c
It sounds to me like this confusion
It sounds to me like this confusion comes from LTO plugins. Isn't
it just LTO plugin? That is, a specific plugin?
There is one GCC plugin. LLVM has another one. The fully qualified
name is probably something like gold plugin for gcc lto.
--
Daniel Jacobowitz
CodeSourcery
Cheers,
--
On Wed, 2009-10-07 at 16:42 +0200, Richard Guenther wrote:
On Wed, Oct 7, 2009 at 4:37 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
I try to analyse this code:
--
int foo (int N)
{
int ftab[257];
int i, j;
for (i = 0;
On Wed, Oct 7, 2009 at 5:16 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
On Wed, 2009-10-07 at 16:42 +0200, Richard Guenther wrote:
On Wed, Oct 7, 2009 at 4:37 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
I try to analyse this code:
On Wed, 2009-10-07 at 17:23 +0200, Richard Guenther wrote:
On Wed, Oct 7, 2009 at 5:16 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
On Wed, 2009-10-07 at 16:42 +0200, Richard Guenther wrote:
On Wed, Oct 7, 2009 at 4:37 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
I try to
On Wed, Oct 7, 2009 at 5:35 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
On Wed, 2009-10-07 at 17:23 +0200, Richard Guenther wrote:
On Wed, Oct 7, 2009 at 5:16 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
On Wed, 2009-10-07 at 16:42 +0200, Richard Guenther wrote:
On Wed, Oct
Hi,
thanks for the report! It is actually more promising than I've
expected. A while ago I did similar tests with whole-program and
--combine and we didn't get very consistent with performance (I saw also
code size reductions). I guess geomaverage will go down for specint
after
On Wed, 2009-10-07 at 18:30 +0200, Tobias Grosser wrote:
On Wed, 2009-10-07 at 17:44 +0200, Richard Guenther wrote:
On Wed, Oct 7, 2009 at 5:35 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
On Wed, 2009-10-07 at 17:23 +0200, Richard Guenther wrote:
On Wed, Oct 7, 2009 at 5:16 PM,
On Wed, Oct 7, 2009 at 7:21 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
On Wed, 2009-10-07 at 18:30 +0200, Tobias Grosser wrote:
On Wed, 2009-10-07 at 17:44 +0200, Richard Guenther wrote:
On Wed, Oct 7, 2009 at 5:35 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
On Wed,
Hi there,
I am new here, so I wish to take a second to introduce myself and what
I am working on, then ultimately why I am posting on this list. Also I
will apologise if this is the wrong place to post this query. If this
is so, perhaps you could point me in the right direction.
I have just
While constructing a patch to resolve PR41313 on darwin, I noticed an oddity.
The problem in PR41313 is due to hot/cold partitioning not being understood by
darwin_emit_unwind_label() such that duplicate .eh symbols can be created. This
can be fixed by restoring the previous behavior for
Interestingly, on darwin, it appears that the trigger for the generation
of the duplicate .eh symbols is not -freorder-blocks-and-partition but the
additional use of -fprofile-use -D_PROFILE_USE. When I drop the profiling
from gcc.dg/tree-prof/bb-reorg.c and gcc.dg/tree-prof/pr34999.c, they
Edd Barrett vex...@gmail.com writes:
I would be really interested to know how GCC:
* Decides whether or not to embed tables in the data segment of the binary.
* Selects the comparisons in the above tree.
The relevant code is expand_case and friends in gcc/stmt.c. Where a
jump table should
--- Comment #2 from aoliva at gcc dot gnu dot org 2009-10-07 07:23 ---
Thanks for the bug report, confirmed, looking into it.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #3 from jakub at gcc dot gnu dot org 2009-10-07 07:37 ---
Created an attachment (id=18733)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18733action=view)
gcc45-pr41445.patch
Updated patch that actually passed bootstrap. Unfortunately it regresses many
gcc.dg/cpp/
--- Comment #5 from burnus at gcc dot gnu dot org 2009-10-07 08:02 ---
More from the thread.
Richard Maine wrote:
The Note appears to have been removed from f2003, but see
F95 Note 5.6. Apparently it was the interface body case I was recalling
rather than the module procedure
--- Comment #2 from burnus at gcc dot gnu dot org 2009-10-07 08:09 ---
Actually, according to a note (cf. PR 41603 comment 5) the interface actually
could be valid - as long it is not used.
While invoking the function directly is properly rejected, e.g. the following
c =
The following is properly rejected but the error message is bogus:
Error: Character-valued internal function 'assumed_len' at (1) must not be
assumed length
I tried to find an internal function, but all I see is a module procedure. (For
internal functions, assumed-length result values are also
--- Comment #4 from jakub at gcc dot gnu dot org 2009-10-07 08:19 ---
Created an attachment (id=18734)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18734action=view)
gcc45-pr41445.patch
An updated patch that actually fixes all cpp.exp regressions except 2 matches
in spacing1.c,
--- Comment #10 from burnus at gcc dot gnu dot org 2009-10-07 08:20 ---
(In reply to comment #8)
Created an attachment (id=18732)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18732action=view) [edit]
Potential patch to fix pr40737
Here is a patch from Adhemerval Zanella from
--- Comment #1 from chris dot smith at st dot com 2009-10-07 08:33 ---
Did anyone ever find a solution to this? I'm seeing exactly the same effect
with gcc 4.3.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38766
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-07 08:46 ---
The code is not valid, you need to change the line with the error to:
dbLeft.template detectFileChange3();
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
In the following testcase:
inline int f(int *a)
{
return *a;
}
main()
{
int b=1;
return f(b);
}
We ought to be able to track that value of b is 1. However we do not:
main ()
{
bb 2:
# DEBUG a = b
return 1;
}
--
Summary: Variables promoted to Gimple registers by aliasing
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-07 09:29 ---
Huh? You just cited the errors you got. Use -pedantic if you want to be
warned about $ in identifiers.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-10-07 09:33 ---
Raphael, can you look into this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from zhnmju123 at gmx dot de 2009-10-07 09:33 ---
Thanks for the fast reply! I had tried compilation with VC++ 2008 and there it
worked, so I thought it would be valid.
Maybe a more expressive error message could help. In this shortened example the
error message is ...
--- Comment #4 from dominiq at lps dot ens dot fr 2009-10-07 09:45 ---
The fix in revision 152513 has been regtested without regression. Closing as
fixed.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #3 from redi at gcc dot gnu dot org 2009-10-07 09:48 ---
(In reply to comment #2)
Thanks for the fast reply! I had tried compilation with VC++ 2008 and there it
worked, so I thought it would be valid.
You should be wary of using VC++ to determine if code is valid, it's
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-07 09:50 ---
I am looking into this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Seen with a lot of GNUstep applications:
gcc AppController.m -c \
-MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1
-DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -g -Wall -DDEBUG
-fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE -Wno-import -O2
--- Comment #1 from doko at ubuntu dot com 2009-10-07 09:52 ---
Created an attachment (id=18735)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18735action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41617
--- Comment #2 from doko at ubuntu dot com 2009-10-07 09:53 ---
Created an attachment (id=18736)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18736action=view)
assembler file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41617
--- Comment #3 from doko at ubuntu dot com 2009-10-07 09:53 ---
Created an attachment (id=18737)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18737action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41617
--- Comment #4 from doko at ubuntu dot com 2009-10-07 09:54 ---
Created an attachment (id=18738)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18738action=view)
assembler file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41617
--- Comment #4 from chris dot hhodges at gmail dot com 2009-10-07 10:23
---
(In reply to comment #3)
Please let us know if you fix this and/or you are still stuck.
Yes. I've got this fixed now!
gcc now fully compiled.
Many thanks for the pointer to the __gmp_get_memory_functions
--- Comment #1 from domob at gcc dot gnu dot org 2009-10-07 10:32 ---
Confirmed, I'll investigate what we can do here (and look at similar cases).
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rob1weld at aol dot com 2009-10-07 11:21 ---
(In reply to comment #1)
Yes GPU libraries would be nice but this needs a lot of work to begin with.
First you have to support the GPUs. This also amounts to doubling the
support.
If you really want them, since
--- Comment #1 from hubicka at ucw dot cz 2009-10-07 11:26 ---
Subject: Re: New: Variables promoted to Gimple registers by aliasing are not
getting debug statements.
We ought to be able to track that value of b is 1. However we do not:
main ()
{
bb 2:
# DEBUG a = b
Note that
--- Comment #4 from zhnmju123 at gmx dot de 2009-10-07 12:30 ---
This seems to be the member template analogon to cases where typename is
needed for nested types. Thanks for the detailed explanation!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41614
The following invalid program is currently accepted:
type t1
integer :: comp
class(t1),pointer :: cc
end type
class(t1) :: x! invalid: must be dummy, allocatable or pointer
x%comp = 3
print *,x%comp
end
Removing the line which defines the class pointer component 'cc' causes
--- Comment #5 from jakub at gcc dot gnu dot org 2009-10-07 12:57 ---
This doesn't even compile, you forgot NXConstStr.h stuff.
When it is added, it compiles just fine, at least on x86_64-linux and
i686-linux, no assembler errors.
--
While doing a bunch of experiments with randomly constructed sets of
optimization flags, I ran into the following compilation error while trying to
build SPEC CPU2000's 252.eon:
internal compiler error: in insert_save, at caller-save.c:1122
The problem occurs during compilation of various of the
--- Comment #1 from kenneth dot hoste at elis dot ugent dot be 2009-10-07
13:13 ---
Created an attachment (id=18739)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18739action=view)
reduced testcase for this bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41619
On Linux/i686, revision 152526 failed to bootstrap:
[...@gnu-29 libjava]$ /export/gnu/import/svn/gcc-test/bld/./gcc/xgcc
-shared-libgcc -B/export/gnu/import/svn/gcc-test/bld/./gcc -nostdinc++
-L/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libstdc++-v3/src
--- Comment #34 from jakub at gcc dot gnu dot org 2009-10-07 13:35 ---
Linker bug, so closing. Workaround also exists, use a non-buggy linker, or use
non-obsolete crt files.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2009-10-07 13:35 ---
It may be caused by revision 152520:
http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00169.htm
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hudson at comp dot ufla dot br 2009-10-07 13:47 ---
Ok, but this isn't a warning, it's an *error*. Concordant to specification
ANSI, it's not acceptable. Even -pedantic option must to give an error, no?
Anyway, thanks by reply!
--
--- Comment #3 from jakub at gcc dot gnu dot org 2009-10-07 13:58 ---
You are looking for -pedantic-errors I guess.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41610
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet||i686-pc-linux-gnu
Target Milestone|---
--- Comment #2 from domob at gcc dot gnu dot org 2009-10-07 14:04 ---
At least now this can be considered fully implemented, I think.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from domob at gcc dot gnu dot org 2009-10-07 14:09 ---
This is still happening with current gfortran trunk, though the ICE is now in
[/tmp]# gfortran-dev test.f90
test.f90: In function 'myfortran_error':
test.f90:8:0: internal compiler error: in fold_convert_loc, at
--- Comment #1 from domob at gcc dot gnu dot org 2009-10-07 14:10 ---
I'll try to find some better formulation for the manual.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from domob at gcc dot gnu dot org 2009-10-07 14:12 ---
As another note, I already did the mistake of indexing a string as str(n)
instead of str(n:n) for single characters multiple times; and IIRC there's not
much useful a diagnostic in any case, so maybe I can improve
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-07 14:57 ---
It's mostly
a) target specific builtin types and decls that do not get fixed up
b) LTO (or rather generic) builtin functions and types not get fixed up
c) the tree.c local canonical type machinery that isn't
seen with builds from the 4.4 branch, compiler configured biarch, defaulting to
32bit; these testcase don't fail when the testsuite is run with -m64. Not seen
on trunk 20090803.
gcc is configured with: --with-pkgversion='Debian 4.4.1-5'
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2009-10-07
15:09 ---
Subject: Re: [4.5 Regression] Internal error compiling fortran/intrinsic.c
I see this has -g and this sounds like PR41343 where cc1 is killed because
the
compiler runs out of VM . Could you try the
--- Comment #6 from doko at ubuntu dot com 2009-10-07 15:15 ---
Created an attachment (id=18740)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18740action=view)
preprocessed source
regenerated with objc/NXConstStr.h included.
--
doko at ubuntu dot com changed:
What
The following program:
#include string
#include unordered_set
int main()
{
std::unordered_setstd::string set;
std::string key(foo);
for (int i=0; i1000; ++i) {
set.count(key);
}
return 0;
}
(if compiled without optimizations) makes 1000 calls to the std::string copy
--- Comment #1 from jbytheway at gmail dot com 2009-10-07 15:45 ---
Created an attachment (id=18741)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18741action=view)
Patch providing proof-of-concept implementation
I attach a patch implementing this change on svn HEAD. It doesn't
--- Comment #2 from redi at gcc dot gnu dot org 2009-10-07 16:07 ---
(In reply to comment #1)
but I am fairly sure I've done the wrong thing to the linker script
(gnu.ver); I don't really understand the linker script, so it was rather
monkey-see-monkey-do.
I think the commented out
--- Comment #4 from hudson at comp dot ufla dot br 2009-10-07 16:23 ---
Oh, yeah! I'm sorry!
I'll take care in the next time...
Thanks a lot!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41610
--- Comment #3 from paolo dot carlini at oracle dot com 2009-10-07 16:42
---
Nope. This library follows the ISO Standards ad TRs, and both the current CD
and TR1 mandates by value. I can try to raise the issue in Santa Cruz by
certainly we can't just change the implementation like
--- Comment #4 from paolo dot carlini at oracle dot com 2009-10-07 16:51
---
Two very general comments: 1- Certainly, you can't change old exports like
this, you can only *add* exports at later version numbers; 2- If you mean to
contribute more to the library (that would be great!) I
--- Comment #9 from bkoz at gcc dot gnu dot org 2009-10-07 16:56 ---
Beyond caret diagnostics there is also range info for the diagnostic location.
See:
http://clang.llvm.org/diagnostics.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #10 from manu at gcc dot gnu dot org 2009-10-07 17:06 ---
(In reply to comment #9)
Beyond caret diagnostics there is also range info for the diagnostic location.
See the patch and thread at
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00459.html
and the requested patch:
--- Comment #15 from vmakarov at gcc dot gnu dot org 2009-10-07 17:18
---
Subject: Bug 22072
Author: vmakarov
Date: Wed Oct 7 17:18:38 2009
New Revision: 152533
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152533
Log:
2009-10-07 Vladimir Makarov vmaka...@redhat.com
--- Comment #2 from jason at gcc dot gnu dot org 2009-10-07 17:54 ---
Yep, reverting that patch fixes libjava build. The patch incorrectly makes us
emit the abstract pre-cloning constructor.
--
jason at gcc dot gnu dot org changed:
What|Removed
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #10 from davek at gcc dot gnu dot org 2009-10-07 17:55 ---
(In reply to comment #9)
Fixed at revision 152511.
My tests (r.152512) have now run far enough to confirm that all the new FAILs
are fixed. Thanks Danny!
--
davek at gcc dot gnu dot org changed:
--- Comment #2 from domob at gcc dot gnu dot org 2009-10-07 18:13 ---
Subject: Bug 41615
Author: domob
Date: Wed Oct 7 18:13:28 2009
New Revision: 152534
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152534
Log:
2009-10-07 Daniel Kraft d...@domob.eu
PR fortran/41615
--- Comment #3 from domob at gcc dot gnu dot org 2009-10-07 18:15 ---
Fixed on trunk, now the message really prints module procedure for module
procedures.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 150 matches
Mail list logo
