Hi Vladimir,
Thanks for the feedback! Very interesting.
> Intel optimization compiler team (besides researchers) is much bigger than
>whole GCC community.
That's a surprise to me. I have to say that the GCC community has done amazing
work, as you came within factor 1.4 (gfortran) and 1.6 (g++
Daniel/Andrew
thanks so much. I was using gdb version 7.1. So it understood deferred
breakpoints but as long as I started gdb with something like ~/bin/gcc it never
stopped in my function.
As soon as I switched to running gdb on cc1, it worked!
Now i can work on debugging the seg-fault i'm causin
On Wed, Aug 11, 2010 at 03:52:17PM -0700, Jeff Saremi wrote:
> > Trying to use "break execute_x" command in
> > "add-symbol-file myplugin.so" but neither of them work. The
> > first one complains that "function not defined"
Did it ask you if you want to make the breakpoint pending? If it did,
On Wed, Aug 11, 2010 at 3:52 PM, Jeff Saremi wrote:
> Sending this to "gcc" since I got no help from sending it to "gcc-help"
Are you trying to debug gcc or cc1/cc1plus? If the former try running
with -v and seeing that cc1/cc1plus is involved and then debug
cc1/cc1plus instead.
Thanks,
Andrew
Sending this to "gcc" since I got no help from sending it to "gcc-help"
--- On Sun, 8/8/10, Jeff Saremi wrote:
> From: Jeff Saremi
> Subject: Debugging plugins with gdb
> To: gcc-h...@gcc.gnu.org
> Date: Sunday, August 8, 2010, 9:52 AM
> I'd like to step into my plugin to
> see if I can debug i
This is the beta release of binutils 2.20.51.0.11 for Linux, which is
based on binutils 2010 0810 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
Hi Richard,
> How about using an automatic converter to arrange for C++ code to
> call into the generated Fortran code instead? Create nice classes
> and wrappers and such, but in the end arrange for the Fortran code
> to be called to do the real work.
I found it very labor intensive to maintain
On 08/10/2010 09:51 PM, Ralf W. Grosse-Kunstleve wrote:
I wrote a Fortran to C++ conversion program that I used to convert selected
LAPACK sources. Comparing runtimes with different compilers I get:
absolute relative
ifort 11.1.0721.790s1.00
gfortran 4
On 08/11/2010 10:59 AM, Ralf W. Grosse-Kunstleve wrote:
> My original posting shows that gfortran and g++ don't do as good
> a job as ifort in generating efficient machine code. Note that the
> loss going from gfortran to g++ isn't as bad as going from ifort to
> gfortran. This gives me hope that t
Hi Tim,
> Do you mean you are adding an additional level of functions and hoping
> for efficient in-lining?
Note that my questions arise in the context of automatic code generation:
http://cci.lbl.gov/fable
Please compare e.g. the original LAPACK code with the generated C++ code
to see why th
On 08/11/2010 11:47 PM, Sebastian Pop wrote:
On Wed, Aug 11, 2010 at 10:29, Jie Zhang wrote:
Hi Sebastian,
I currently encountered an issue when testing
gcc.dg/graphite/interchange-9.c on a ARM bare-metal board which has only 4MB
memory.
Apparently, with
#define N
#define M
"int A
On Wed, Aug 11, 2010 at 10:29, Jie Zhang wrote:
> Hi Sebastian,
>
> I currently encountered an issue when testing
> gcc.dg/graphite/interchange-9.c on a ARM bare-metal board which has only 4MB
> memory.
>
> Apparently, with
>
> #define N
> #define M
>
> "int A[N*M]" in main is too large
Hi Sebastian,
I currently encountered an issue when testing
gcc.dg/graphite/interchange-9.c on a ARM bare-metal board which has only
4MB memory.
Apparently, with
#define N
#define M
"int A[N*M]" in main is too large to fit in stack.
There are several ways to solve this issue:
1.
Hello,
In the example accompanying the patch below we consider that the
types
forward_as_lref
at line marked with //#0 and
forward_as_lref::type::seq_type>
at the line marked with //#1 should compare equal. And I believe that
is correct[1].
It follows that during the instantiantion
On Wed, Aug 11, 2010 at 9:32 AM, Dennis Clarke wrote:
>
> Dear GCC Team :
>
> This is just a friendly letter. There probably will not be another GCC
> update from the Sunfreeware site ( which is still showing 3.4.6 ) for a
> long time now that Oracle has pulled finances. The same sad state of
> af
On Tue, Aug 10, 2010 at 6:48 PM, Ian Bolton wrote:
> I am in the process of fixing PR44328
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328)
>
> The problem is that gen_inbound_check in tree-switch-conversion.c subtracts
> info.range_min from info.index_expr, which can cause the MIN and MAX va
Dear GCC Team :
This is just a friendly letter. There probably will not be another GCC
update from the Sunfreeware site ( which is still showing 3.4.6 ) for a
long time now that Oracle has pulled finances. The same sad state of
affairs affects the OpenSolaris project as a whole.
I do expect that
17 matches
Mail list logo
