Hello Joseph
On 01.04.09, you wrote:
I add this file some time ago to Amiga OS 68k target, and build compiler, in
config.log files during compiler build, it seem detect right, are there
still defines in config.gcc need and other defines ?
configure:3626: $? = 0
configure:3629: test -s
Hello Dear GCC Developers,
I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example, the
same way as libffi is integrated within gcc source tree. It seems to
me that LLVM solves many goals that are already complete
And no this is not a 1st April joke :-)
Thanks,
Kirill
2009/4/1 Kirill Kononenko kirill.konone...@gmail.com:
Hello Dear GCC Developers,
I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example, the
same way as
Kirill Kononenko wrote:
I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example, the
same way as libffi is integrated within gcc source tree. It seems to
me that LLVM solves many goals that are already complete and
More useful in implementation of Just-In-Time compilation in Virtual
Machine runtimes. For example, for Microsoft Common Intermediate
Language (.NET).
Thanks,
Kirill
2009/4/1 Andrew Haley a...@redhat.com:
Kirill Kononenko wrote:
I would like to ask your opinion about possibility for
2009/4/1 Andrew Haley a...@redhat.com:
Kirill Kononenko wrote:
I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example, the
same way as libffi is integrated within gcc source tree. It seems to
me that LLVM solves
2009/4/1 Andrew Haley a...@redhat.com:
Kirill Kononenko wrote:
I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example, the
same way as libffi is integrated within gcc source tree. It seems to
me that LLVM solves
Kirill Kononenko wrote:
2009/4/1 Andrew Haley a...@redhat.com:
Kirill Kononenko wrote:
I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example, the
same way as libffi is integrated within gcc source tree. It seems
Kirill Kononenko wrote:
2009/4/1 Andrew Haley:
Kirill Kononenko wrote:
I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example, the
same way as libffi is integrated within gcc source tree. It seems to
me that
Basile STARYNKEVITCH wrote:
The second issue (which perhaps Kirill did not thought of) would be to
accelerate some internal optimisations of GCC by using JIT-code
generation techniques within the compiler itself. There are several
occasions within GCC where complex internal processing
Kirill Kononenko wrote (citing me Basile)
The second issue (which perhaps Kirill did not thought of) would be to
accelerate some internal optimisations of GCC by using JIT-code generation
techniques within the compiler itself. There are several occasions within
GCC where complex internal
2009/4/1 Dave Korn dave.korn.cyg...@googlemail.com:
Kirill Kononenko wrote:
2009/4/1 Andrew Haley:
Kirill Kononenko wrote:
I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example, the
same way as libffi is
The second issue (which perhaps Kirill did not thought of) would be to
accelerate some internal optimisations of GCC by using JIT-code
generation techniques within the compiler itself. There are several
occasions within GCC where complex internal processing happens, and one
could imagine to
However, I see several interesting issues raised here:
the first is to [re-]use GCC for just in time compilation, for instance to
JIT-compile CLI or JVM bytecode into machine code, or even C or some
specialized gimple-like representation into machine code, or CLISP into
machine code, all
Andrew Haley wrote:
Useful for what? I think you have to tell us how this will improve the
experience of gcc users .
Kirill Kononenko wrote:
More useful in implementation of Just-In-Time compilation in Virtual
Machine runtimes. For example, for Microsoft Common Intermediate
2009/4/1 Andrew Haley a...@redhat.com:
Kirill Kononenko wrote:
2009/4/1 Andrew Haley a...@redhat.com:
Kirill Kononenko wrote:
I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example, the
same way as libffi is
2009/4/1 Basile STARYNKEVITCH bas...@starynkevitch.net:
The second issue (which perhaps Kirill did not thought of) would be to
accelerate some internal optimisations of GCC by using JIT-code
generation
techniques within the compiler itself. There are several occasions within
GCC where
On Tue, 31 Mar 2009, DJ Delorie wrote:
I expect most of the OSes listed do; the types should still be entered
into GCC (so the Fortran front end can know them, for example), and
Well, I'm not a big fan of duplicating information, but if that's what
you want to do, here it is. Enjoy.
Kirill Kononenko wrote:
LLVM is an overkill for JIT compilation. I think the tasks which LLVM
solves are already solved within GCC transformations, or can be
integrated very easily with libJIT. LibJIT is also much easier in
usage, for ordinary developers. So what I see here, LLVM is rather a
On Wed, 1 Apr 2009, Bernd Roesch wrote:
Hello Joseph
On 01.04.09, you wrote:
I add this file some time ago to Amiga OS 68k target, and build compiler, in
config.log files during compiler build, it seem detect right, are there
still defines in config.gcc need and other defines ?
Yes, the
Joseph S. Myers wrote:
I'm hoping the maintainers of OS support in GCC, or other people set up to
test on each OS, will put the types in an appropriate tm.h header and test
that the c99-stdint-*.c tests pass. Adding the information myself without
testing is very much a last resort.
2009/4/1 Dave Korn dave.korn.cyg...@googlemail.com:
LLVM is an overkill for JIT compilation. I think the tasks which LLVM
solves are already solved within GCC transformations, or can be
integrated very easily with libJIT. LibJIT is also much easier in
usage, for ordinary developers. So what I
Hello!
I have encountered a problem with a private RISC target, where invalid
reload is generated when paradoxical registers are involved.
In a lreg pass, I have a sequence of instructions:
(insn 112 182 114 2 t.c:22 (set (mem/s/j/c:SI (plus:SI (reg/f:SI 35 frame)
(const_int -20
Is that an April fool's joke?
The new license allows Java, but it does not allow linking with
code that has no dependency on the Runtime Library whatsoever
(because it is not considered 'Independent Modules'), and it does not
allow linking with code that has been written in assembly language
(it
Dave Korn wrote:
Kirill and Andrew wrote:
April Fool's joke
not your area of expertise
Maybe it would be for the best if you two started over, before this turns
sour.
I'm out of here already! All I can say is that I hope my boss never finds
out that virtual machines and JITs are not
Kirill and Andrew wrote:
April Fool's joke
not your area of expertise
Maybe it would be for the best if you two started over, before this turns
sour.
I'm out of here already! All I can say is that I hope my boss never finds
out that virtual machines and JITs are not my area of
On Wed, Apr 1, 2009 at 3:18 PM, Joern Rennecke joe...@arc.com wrote:
Is that an April fool's joke?
The new license allows Java, but it does not allow linking with
code that has no dependency on the Runtime Library whatsoever
(because it is not considered 'Independent Modules'), and it does
I suggest you first find out more what is exactly reloaded and where
the inheritance occurs - inheritance can be done by choose_reload_regs
or later in emit_reload_insns and its subfunctions.
I.e. set a breakpoint on find_reloads and make it conditional on
insn-u.fld[0].rt_int == 121 replace
,
On Wed, Apr 01, 2009 at 03:30:25PM +0200, Richard Guenther wrote:
On Wed, Apr 1, 2009 at 3:18 PM, Joern Rennecke joe...@arc.com wrote:
Is that an April fool's joke?
The new license allows Java, but it does not allow linking with
code that has no dependency on the Runtime Library
Sorry to cross-post here because I have started this discussion on gcc-help
but since we are trying to interest people about seh exceptions it might be
better
to do it here.
I first asked how to take some instructions and generate a function with
them,
so I wanted to know if start_function was the
Richard Guenther wrote:
What I do find strange is the restriction to explicitly Java VM bytecode
(not CIL or others).
I think I understand that one. Way back in time, when gcj was contributed
by Cygnus, the FSF had to be convinced that Java VM bytecode couldn't be
used to allow, e.g., an
Joern,
The FSF and SFLC believes that your concerns best can be addressed in the FAQ.
David
On Wed, Apr 1, 2009 at 9:18 AM, Joern Rennecke joe...@arc.com wrote:
Is that an April fool's joke?
The new license allows Java, but it does not allow linking with
code that has no dependency on the
Joern Rennecke joe...@arc.com writes:
On Wed, Apr 01, 2009 at 03:30:25PM +0200, Richard Guenther wrote:
On Wed, Apr 1, 2009 at 3:18 PM, Joern Rennecke joe...@arc.com wrote:
Is that an April fool's joke?
The new license allows Java, but it does not allow linking with
code that has no
Vincent R. foru...@smartmobili.com writes:
Now the question is can we declare a function with an eh region and will it
construct prologue and epilogue ?
The instructions are already in a function. Why do you need a separate
prologue and epilogue for them?
Maybe I am missing the point here.
Hi,
to keep everybody updated what is happening in the GRAPHITE branch, I
would like to post the notes of our weekly phone call.
Attendees: Razya, Li, Konrad, Jan, Tobi, David, Sebastian, Christophe
Discussed topics:
* Data dependencies: Tobias committed a patch filling the access
On Wed, Apr 1, 2009 at 8:14 AM, Kirill Kononenko
kirill.konone...@gmail.com wrote:
My explanations seem to have also failed to explain you.
Unfortunately, one really needs have some back group with both
Just-In-Time compilers,Virtual Machines, and Common Intermediate
Language to understand
On Wed, 01 Apr 2009 07:54:20 -0700, Ian Lance Taylor i...@google.com
wrote:
Vincent R. foru...@smartmobili.com writes:
Now the question is can we declare a function with an eh region and will
it
construct prologue and epilogue ?
The instructions are already in a function. Why do you need
My explanations seem to have also failed to explain you.
Unfortunately, one really needs have some back group with both
Just-In-Time compilers,Virtual Machines, and Common Intermediate
Language to understand this area. I understand that it is not your
area of expertise, so it is not an issue
My explanations seem to have also failed to explain you.
Unfortunately, one really needs have some back group with both
Just-In-Time compilers,Virtual Machines, and Common Intermediate
Language to understand this area. I understand that it is not your
area of expertise, so it is not an issue
Vincent R. foru...@smartmobili.com writes:
Yes I think I don't explain things very clearly, so what is important to
know is that the __except keyword
can be passed instructions(case 1) or directly a function(case 2).
I see that but I don't see why it matters.
in the case 1) ie if you
On Apr 1, 2009, at 5:09 AM, Dave Korn wrote:
It seems to
me that LLVM solves many goals that are already complete and solved
in
GCC. So I think libJIT potentially is more useful for GCC and
software
developers.
but you don't say what libjit would be more useful than, or how this
overlap
I've merged mainline into plugins in preparation for a
plugins-mainline merge in the next few days. I will start preparing
separate patches to simplify review.
Bootstrapped and tested on x86_64.
Diego.
It seems to
me that LLVM solves many goals that are already complete and solved in
GCC. So I think libJIT potentially is more useful for GCC and software
developers.
but you don't say what libjit would be more useful than, or how this
overlap
between solved goals between gcc and llvm
2009/4/1 Kirill Kononenko kirill.konone...@gmail.com:
This is what Chris Lattner wrote a couple of years ago. Now I see an
exactly contradiction:
Please, could you pinpoint side-by-side the two sentences that
contradict each other and later give links to (or quote) the context?
I am having
On Wed, Apr 01, 2009 at 06:54:55PM +0200, Manuel López-Ibáñez wrote:
2009/4/1 Kirill Kononenko kirill.konone...@gmail.com:
This is what Chris Lattner wrote a couple of years ago. Now I see an
exactly contradiction:
Please, could you pinpoint side-by-side the two sentences that
The other day there was a request for a compile error if you do:
int foo(void) { }
and the answer was the standard says that this is legal -- after all,
you can say 'foo();' so the return value isn't used and it doesn't
matter that it's missing.
That makes sense.
So how about:
int foo
Hello All,
[I don't know if this discussion belongs to gcc@ or gcc-patches@ so I'm
sending it on gcc@ since I don't propose or discuss any code yet]
My understanding was that most plugins people are aware that somehow
some plugins would need to have static GTY-ed roots for the GGC
On Wed, Apr 1, 2009 at 5:33 AM, Kirill Kononenko
kirill.konone...@gmail.com wrote:
Hello Dear GCC Developers,
I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example, the
same way as libffi is integrated within
2009/4/1 Daniel Berlin dber...@dberlin.org:
On Wed, Apr 1, 2009 at 5:33 AM, Kirill Kononenko
kirill.konone...@gmail.com wrote:
Hello Dear GCC Developers,
I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example,
On Wed, Apr 01, 2009 at 10:18:32AM -0700, Paul Koning wrote:
The other day there was a request for a compile error if you do:
int foo(void) { }
and the answer was the standard says that this is legal -- after all,
you can say 'foo();' so the return value isn't used and it doesn't
On Wed, 01 Apr 2009 08:56:49 -0700, Ian Lance Taylor i...@google.com
wrote:
Vincent R. foru...@smartmobili.com writes:
Yes I think I don't explain things very clearly, so what is important to
know is that the __except keyword
can be passed instructions(case 1) or directly a function(case 2).
Vincent R. foru...@smartmobili.com writes:
gcc will do the right thing if you put statements in an exception
region.
Hum how gcc can do that kind of things, is it some kind of voodoo ?
__except is not implemented yet and is more than a language construct
because it's an
OS thing.
So
On Wed, Apr 1, 2009 at 7:22 PM, Basile STARYNKEVITCH
bas...@starynkevitch.net wrote:
Hello All,
[I don't know if this discussion belongs to gcc@ or gcc-patches@ so I'm
sending it on gcc@ since I don't propose or discuss any code yet]
My understanding was that most plugins people are aware
On Wed, Apr 1, 2009 at 12:19, Diego Novillo dnovi...@google.com wrote:
I've merged mainline into plugins in preparation for a
plugins-mainline merge in the next few days. I will start preparing
separate patches to simplify review.
A clarification. I don't intend to do the actual merge into
Richard Guenther wrote:
Plugins shouldn't keep permanent references to GCed memory. At least
that would make it unnecessary to do what you suggest.
I strongly disagree with that, and I simply do not understand your
position. In my perception, plugins are essentially loaded (dlopen-ed)
Thanks to everyone who tested the prerelease snashot of MPC. The
maintainers have now released mpc-0.6 which incorporates hopefully
everyone's feedback and testing results.
http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-April/000176.html
The MPC developers have made a concerted effort
Hi,
My name is Mallik and I work for Sun. I need a favor from you. I need
to cross compile our product to work on x86 Atom Processor on CentOS.
Could you please point me to the link where I can download the gcc
binaries. I downloaded the source from ix86/gcc-4_4-branch but facing
some
Please, let collect together all useful ideas and concrete thoughts? I
am sure many people already have thought about which JITing support
GCC users need. I also do have my thoughts about this research topic
but I would like also to have useful feedback from people who also
understand this
On Sun, Mar 29, 2009 at 4:46 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Sun, 29 Mar 2009, Steven Bosscher wrote:
On Mon, Mar 23, 2009 at 7:28 PM, Steve Ellcey s...@cup.hp.com wrote:
I think
depreciating Itanium1 tuning for 4.4 and removing it in 4.5 is
reasonable. Code
Joe == Joe Buck joe.b...@synopsys.com writes:
Joe On Wed, Apr 01, 2009 at 10:18:32AM -0700, Paul Koning wrote:
The other day there was a request for a compile error if you do:
int foo(void) { }
and the answer was the standard says that this is legal -- after
all, you can say
On Wed, Apr 1, 2009 at 8:42 PM, Kaveh R. Ghazi gh...@caip.rutgers.edu wrote:
Thanks to everyone who tested the prerelease snashot of MPC. The
maintainers have now released mpc-0.6 which incorporates hopefully
everyone's feedback and testing results.
From: Richard Guenther richard.guent...@gmail.com
I get 1 failure on linux-{i586,x86_64,ppc,ppc64,ia64,s390,s390x}
platforms:
inp_str.c:131: MPC assertion failed: n == nread
/bin/sh: line 4: 2347 Aborted (core dumped) ${dir}$tst
FAIL: tio_str
Richard.
Thanks for the
On Wed, Apr 1, 2009 at 10:36 PM, Kaveh R. Ghazi gh...@caip.rutgers.edu wrote:
From: Richard Guenther richard.guent...@gmail.com
I get 1 failure on linux-{i586,x86_64,ppc,ppc64,ia64,s390,s390x}
platforms:
inp_str.c:131: MPC assertion failed: n == nread
/bin/sh: line 4: 2347 Aborted
Basile STARYNKEVITCH wrote:
Richard Guenther wrote:
Plugins shouldn't keep permanent references to GCed memory. At least
that would make it unnecessary to do what you suggest.
I strongly disagree with that, and I simply do not understand your
position. In my perception, plugins are
From: Richard Guenther richard.guent...@gmail.com
I tested on openSUSE Factory which currently has gcc 4.3.3, gmp 4.2.3,
mpfr 2.4.1 and some pre-2.10 glibc.
I tried with vanilla mpfr-2.4.1 and gmp-4.2.3, and mpc still passed all it's
tests on gcc14. Would it be fair to suspect something in
On Wed, Apr 1, 2009 at 11:03 PM, Kaveh R. Ghazi gh...@caip.rutgers.edu wrote:
From: Richard Guenther richard.guent...@gmail.com
I tested on openSUSE Factory which currently has gcc 4.3.3, gmp 4.2.3,
mpfr 2.4.1 and some pre-2.10 glibc.
I tried with vanilla mpfr-2.4.1 and gmp-4.2.3, and mpc
On Wed, 2009-04-01 at 23:21 +0200, Richard Guenther wrote:
On Wed, Apr 1, 2009 at 11:03 PM, Kaveh R. Ghazi gh...@caip.rutgers.edu
wrote:
From: Richard Guenther richard.guent...@gmail.com
I tested on openSUSE Factory which currently has gcc 4.3.3, gmp 4.2.3,
mpfr 2.4.1 and some pre-2.10
And if garbage collection is avoidable in GCC, given the strong opposition it
has, all the GTY gengtype stuff would have been removed by now. The mere
fact it is staying here is in my opinion very significant. If GC was not
relevant in GCC, GGC GTY would have gone long time ago. They
On Thu, Apr 2, 2009 at 12:48 AM, Joern Rennecke joe...@arc.com wrote:
And if garbage collection is avoidable in GCC, given the
strong opposition it has, all the GTY gengtype stuff would
have been removed by now.
This looks like a rather uninformed opinion...
The mere fact it is staying
From: Janis Johnson janis...@us.ibm.com
Same behavior with openSUSE 11.1 (glibc 2.9, gcc 4.3.2, gmp 4.2.3, mpfr
2.3.2).
Note that I build with -D_FORTIFY_SOURCE=2 -fstack-protector.
I get the failure Richard mentioned when I use -D_FORTIFY_SOURCE=2
-fstack-protector but no failures without
On Wed, Apr 01, 2009 at 06:48:17AM -0700, Joern Rennecke wrote:
Say you have module A, B, C and D. A is the main program and uses B, C
and D. B uses the runtime library, and is therefore an independent module.
Thus, you are allowed to link B with the runtime library. An argument
could be
On Wed, 1 Apr 2009, Kaveh R. Ghazi wrote:
Ah, that helps. I was able to reproduce the failure using just
-D_FORTIFY_SOURCE=2. However when I used both -D_FORTIFY_SOURCE=2 *and*
-fstack-protector the error went away again.
I'm using gcc-4.1.2 if that matters, perhaps there's a bug in
Hello All
Joern Rennecke wrote:
As long as you only need to GTY known types, you can avoid having extra GTY
roots by having all plugins share one GTY root in the plugin infrastructure;
this root can point to a list to which each plugin can add at will.
If you want new types, it gets ugly,
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-01 07:06 ---
Subject: Bug 39591
Author: jakub
Date: Wed Apr 1 07:06:12 2009
New Revision: 145391
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145391
Log:
PR other/39591
* omp-low.c (remove_exit_barrier):
--- Comment #1 from jakub at gcc dot gnu dot org 2009-04-01 06:55 ---
Subject: Bug 39591
Author: jakub
Date: Wed Apr 1 06:54:52 2009
New Revision: 145390
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145390
Log:
PR other/39591
* omp-low.c (remove_exit_barrier):
g++ -c foo.cpp -m32 -O2
foo.cpp: In member function 'AbcIval1d
AbcCone::GetLinearParamIval(AbcSurfType*) const':
foo.cpp:81: internal compiler error: in emit_swap_insn, at reg-stack.c:827
NOTES:
(1) g++ -c foo.cpp -m32 -O1 works
(2) g++ -c foo.cpp -m64 -O2 works
--- Comment #1 from mario-baumann at web dot de 2009-04-01 07:58 ---
Created an attachment (id=17574)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17574action=view)
bzipped foo.cpp file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39607
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-01 08:02 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
during testing 4.4 snapshot i get an compilation error on boost-1.38.0
codebase.
% x86_64-gnu-linux-g++ t.ii -std=gnu++0x -c
t.ii: In member function 'size_t boost::dynamic_bitsetBlock,
Allocator::count() const':
t.ii:30558: error: 'mode' cannot appear in a constant-expression
t.ii:30558: error:
--- Comment #1 from pluto at agmk dot net 2009-04-01 08:04 ---
Created an attachment (id=17575)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17575action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39608
--- Comment #6 from jakub at gcc dot gnu dot org 2009-04-01 08:18 ---
*** This bug has been marked as a duplicate of 37731 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-01 09:00 ---
__gnu_cxx::__verbose_terminate_handler hasn't been called then,
doesn't the mingw runtime override __cxxabiv1::__terminate_handler
or the unwinding on mingw not call std::terminate at all?
--
jakub at gcc dot gnu
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-04-01 09:08 ---
Committed to 4.4 at revision 145395 and to 4.5 at revision 145395.
Didn't committed it to 4.3.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-01 09:13 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-01 09:24 ---
Sure (assuming the weirdo message after it is M$ abort verbiage).
The question is if the reporter sees it as well and if not, why.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39530
--- Comment #5 from shadow2531 at gmail dot com 2009-04-01 09:30 ---
(In reply to comment #3)
terminate called after throwing an instance of 'std::runtime_error'
what(): ouch
Yes, this is the part that's missing for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39530
--- Comment #10 from paolo dot carlini at oracle dot com 2009-04-01 09:49
---
To be honest, I don't like such tentative fixes. We are adding even more code
for essentially the same kind of work. There must be a better way to deal with
the issue.
--
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-04-01 10:44 ---
(In reply to comment #5)
(In reply to comment #3)
terminate called after throwing an instance of 'std::runtime_error'
what(): ouch
Yes, this is the part that's missing for me.
Well, as far as I verified
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-04-01 09:18 ---
(In reply to comment #2)
__gnu_cxx::__verbose_terminate_handler hasn't been called then,
doesn't the mingw runtime override __cxxabiv1::__terminate_handler
or the unwinding on mingw not call std::terminate at all?
--- Comment #2 from matz at gcc dot gnu dot org 2009-04-01 11:45 ---
The old stack slot sharing problem. stack slot sharing really wants to
look at scopes to determine if stack variables can share the same space or
not (stack variables, not registers, those are all top-level). But
--- Comment #7 from shadow2531 at gmail dot com 2009-04-01 12:15 ---
(In reply to comment #6)
(In reply to comment #5)
(In reply to comment #3)
terminate called after throwing an instance of 'std::runtime_error'
what(): ouch
Yes, this is the part that's missing for me.
--- Comment #8 from dominiq at lps dot ens dot fr 2009-04-01 12:50 ---
On powerpc-apple-darwin9 the code in comment #3 compiles with -m64 -O3, but ICE
with the change in comment #6 with:
pr39595_db.f90: In function 'foo':
pr39595_db.f90:3: internal compiler error: vector VEC(tree,base)
--- Comment #3 from ramu dot konaparthi at gmail dot com 2009-04-01 13:18
---
I am able to built shared objects. But, while building the executable binary
using the shared objects. I see the error hidden symbol `__gcov_init' in
--- Comment #15 from dominiq at lps dot ens dot fr 2009-04-01 13:25 ---
On *-darwin* we have
FAIL: gcc.dg/c99-stdint-1.c (test for excess errors)
FAIL: gcc.dg/c99-stdint-2.c (test for excess errors)
FAIL: gcc.dg/c99-stdint-5.c (test for excess errors)
FAIL: gcc.dg/c99-stdint-6.c (test
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-01 13:32 ---
Subject: Bug 37772
Author: jakub
Date: Wed Apr 1 13:32:22 2009
New Revision: 145401
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145401
Log:
PR c/37772
* c-parser.c (c_parser_asm_statement):
Problem:
g++ fail to build execuable by linking .so files built with options -Wall
-fprofile-arcs -ftest-coverage
I am able to built shared objects with g++ using options -Wall -fprofile-arcs
-ftest-coverage. But, while building the executable binary
by linkng the shared objects, I see the error
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-01 13:45 ---
Subject: Bug 37772
Author: jakub
Date: Wed Apr 1 13:45:14 2009
New Revision: 145402
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145402
Log:
PR c/37772
* c-parser.c (c_parser_asm_statement):
--- Comment #5 from jakub at gcc dot gnu dot org 2009-04-01 13:50 ---
Fixed on the 4.4 branch and on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-01 14:00 ---
Even for live range analysis of the vars that must go into stack the block info
needs to be used, otherwise once address of a stack var escapes, you'd have to
assume it is live almost till the end of the function (at
--- Comment #4 from matz at gcc dot gnu dot org 2009-04-01 14:05 ---
Yes, that's my thought too. Fixing the BLOCK_VARS when references to
variables show up in a block where they weren't before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
1 - 100 of 146 matches
Mail list logo
