This thread is off-topic for the GCC mailing list. Please follow up on
gnu.misc.discuss or some other suitable forum.
Thanks,
Ben
Hi there. This is in follow up to my email on the 24 th of May.
The short version is: how can I track down why GCC is picking between
two alternatives for implementing a function? In a memcpy() where
Pmode == SImode, I get a near ideal implementation. If Pmode ==
PSImode (due to limitations of
On Thu, Jul 23, 2009 at 11:50 PM, Mark Mielke wrote:
... snipped ...
> to contribute to a project does not usually say "I refuse to participate in
> your project because it has a BSD license." The GPL is evil and deserves to
> be struck down.
The GPL and LGPL achieve a delicate balance between th
On 07/23/2009 11:28 PM, graham_k wrote:
Can someone tell me definitively - if I use a ten line GPLed function, say
quicksort, in 500,000 lines of code which I write myself, do I need to GPL
all of my source code and make the ode free for all?
If you want a definitive answer you should conta
GPL is viral, one drop of it will make everything else GPL, especially
when you redistribute the code.
When there is a technical and legal due diligence, they use tools that
scan your source code and if there is a GPL or public code that is
also matching in their database (which is huge, believe m
Can someone tell me definitively - if I use a ten line GPLed function, say
quicksort, in 500,000 lines of code which I write myself, do I need to GPL
all of my source code and make the ode free for all?
--
View this message in context:
http://www.nabble.com/GPL-%28probably-a-FAQ%29-tp24638096p24
Hi,
Is it useful to implement a high-level universal function
tree_peeling_loop in tree-ssa-loop-manip.c? I want call it in
tree-ssa-loop-prefetch.c.
If yes, can anyone give me some clues? I find currently,
vect_do_peeling_for_loop_bound is doing a similar work in
tree-vect-transform.c.
Regards,
Ian Lance Taylor wrote:
> It seems to me that e-mail to gcc-b...@gcc.gnu.org is basically lost in
> the noise. It seems to me that we should not recommend that people send
> bug reports there; the chances that anything will happen are much
> smaller than the already small chance that anybody will
Snapshot gcc-4.5-20090723 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090723/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Thu, Jul 23, 2009 at 2:10 PM, Manuel
López-Ibáñez wrote:
> But they go to the mailing list or are they tracked by bugzilla? If
> they go to the mailing list, we should probably still remove the
> reference to gccbug, (Not gccbug itself, which can still be used by
> experienced developers).
They
2009/7/23 Andrew Pinski :
> On Thu, Jul 23, 2009 at 2:03 PM, Manuel
> López-Ibáñez wrote:
>> And from gccbug?
>
> I do know of one maintainer to GCC that still uses gccbug. And he
> does file good bug reports even with gccbug.
>
> Besides him, we get at maybe 1 bug reported by gccbug every three m
On Thu, Jul 23, 2009 at 2:03 PM, Manuel
López-Ibáñez wrote:
> And from gccbug?
I do know of one maintainer to GCC that still uses gccbug. And he
does file good bug reports even with gccbug.
Besides him, we get at maybe 1 bug reported by gccbug every three months.
Thanks,
Andrew Pinski
2009/7/23 Andrew Pinski :
> On Thu, Jul 23, 2009 at 10:14 AM, Ian Lance Taylor wrote:
>> It seems to me that e-mail to gcc-b...@gcc.gnu.org is basically lost in
>> the noise. It seems to me that we should not recommend that people send
>> bug reports there; the chances that anything will happen ar
On 07/23/2009 10:28 AM, Jan Hubicka wrote:
When you are not copying the whole function body, you will need to
remove those edges that are outside region being duplicated, perhaps
that is the problem?
Nope, I'm copying the whole body and adjusting it afterward.
r~
Hello
Sometimes, I am building & installing (on Linux/AMD64/Debian/Sid) the
trunk configured as
/usr/src/Lang/gcc-trunk/configure '--program-suffix=-trunk'
'--libdir=/usr/local/lib/gcc-trunk'
'--libexecdir=/usr/local/libexec/gcc-trunk'
'--with-gxx-include-dir=/usr/local/lib/gcc-trunk/inclu
Hi --
I don't think that a fix in GDB would be appropriate.
GDB is doing exactly what it should -- it places a breakpoint
at the first line in the function.
GCC should not output a line entry in the middle of the prologue.
Luis Machado wrote:
Hi,
Yes, this is exactly what i was chasing some
> Could I convince you to have a look at the transactional-memory branch
> test libitm/testsuite/libitm.c++/eh-1.C? I'm getting
>
> z.c:36:1: error: edge void f1()->void* __cxa_allocate_exception(long
> unsigned int) has no corresponding call_stmt
> D.2114_4 = __cxa_allocate_exception (4);
>
>
On Thu, Jul 23, 2009 at 10:14 AM, Ian Lance Taylor wrote:
> It seems to me that e-mail to gcc-b...@gcc.gnu.org is basically lost in
> the noise. It seems to me that we should not recommend that people send
> bug reports there; the chances that anything will happen are much
> smaller than the alrea
It seems to me that e-mail to gcc-b...@gcc.gnu.org is basically lost in
the noise. It seems to me that we should not recommend that people send
bug reports there; the chances that anything will happen are much
smaller than the already small chance that anybody will fix their
bugzilla bug report.
On 07/23/09 09:06, Tom Tromey wrote:
"Larry" == Larry Evans writes:
Larry> etags: Warning: "--language" option is obsolete; use "--language-force"
instead
Maybe you are not using the etags that comes with Emacs.
Exhuberant Ctags comes with an "etags" that, I believe, has incompatible
command
Hi,
On Thu, Jul 23, 2009 at 10:55, Jack Howarth wrote:
> Is it known yet whether the changes in cloog/ppl will require
> new soversions of those libraries or might the new cloog/ppl
> libraries be backward compatible with current gcc 4.4.x (ie have
> the same soversion number but a higher compati
I was building gcc-4.4.1 on an i686-linux-gnu slackware-12.2 box with
the default optimization flags. I'd last built/installed 4.4.0. The
current build dies at:
libtool: compile: /home/ronis/objdir/./gcc/xgcc -shared-libgcc
-B/home/ronis/objdir/./gcc -nostdinc++
-L/home/ronis/objdir/i686-pc-li
> "Larry" == Larry Evans writes:
Larry> etags: Warning: "--language" option is obsolete; use "--language-force"
instead
Maybe you are not using the etags that comes with Emacs.
Exhuberant Ctags comes with an "etags" that, I believe, has incompatible
command-line options...
Tom
Is it known yet whether the changes in cloog/ppl will require
new soversions of those libraries or might the new cloog/ppl
libraries be backward compatible with current gcc 4.4.x (ie have
the same soversion number but a higher compatibility version)?
Jack
On Sun, Jul 05, 2009 at 02
On 07/23/2009 08:26 AM, Larry Evans wrote:
etags: Warning: "--language" option is obsolete; use
"--language-force" instead
etags: Unknown language "none" in "language" option
etags: Unknown option: --include
It works fine for me with etags from GNU emacs 22.3.
Oh, and BTW, does anyone find et
>>
>> Could this be related to old-vs-new EABI? Is the stack aligned to the
>> same
>> multiple on entry to main in both old and new executables? The
assembler
>> code
>> looked basically the same, except the stack frame size has changed and a
>> lot
>> of things that were aligned to an (odd
On Thu, 2009-07-23 at 11:52 +0100, Dave Korn wrote:
> Danny Backx wrote:
> > On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote:
>
> > Kai Ruottu wrote :
> >> Comparing the output from some earlier working GCC with the gcc-4.4.0
> >> output would reveal if something was wrong in preparing inputs f
On Thu, 2009-07-23 at 15:17 +0300, Kai Ruottu wrote:
> Dave Korn wrote:
> > Danny Backx wrote:
> >> On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote:
> >
> >> Kai Ruottu wrote :
> >>> Comparing the output from some earlier working GCC with the gcc-4.4.0
> >>> output would reveal if something was
Dave Korn wrote:
Danny Backx wrote:
On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote:
Kai Ruottu wrote :
Comparing the output from some earlier working GCC with the gcc-4.4.0
output would reveal if something was wrong in preparing inputs for
the soft-float routines... Or maybe something wa
There's an etags target in the build/Makefile:
etags tags: TAGS
However, when invoking this target, I get:
make etags
make[1]: Entering directory `/home/evansl/download/gcc/4.4-20090630/build'
Doing TAGS in gcc
make[2]: Entering directory `/home/evansl/download/gcc/4.4-20090630/build/gcc'
cd
Danny Backx wrote:
> On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote:
> Kai Ruottu wrote :
>> Comparing the output from some earlier working GCC with the gcc-4.4.0
>> output would reveal if something was wrong in preparing inputs for
>> the soft-float routines... Or maybe something was changed
On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote:
> Are you using soft or hard fp?
Soft. Not all ARM processors have hardware fp.
> I don't think you're going to get anywhere with this until you start looking
> at the generated code to see precisely *what* is wrong with it. You've gone
> as
On 07/22/2009 09:17 PM, Kai Tietz wrote:
Hello,
Possibly somebody could give me a hint what the issue here is. In the
patch I attached, I enable multilib for x86 default mingw target
(i686-w64-mingw32). The core compilers are translating nicely. But
when it tries to build libgcc by -m64 it throw
Danny Backx wrote:
Hi Danny,
> The difference between the last two printf statements points out, I
> think, that a problem exists around printf. Might be float to double
> conversion.
Could also be stdargs. Or float arg passing in general. Or arg promotion.
Are you using soft or hard fp?
[I probably tried the wrong list earlier, got no reply on gcc-help.]
I've been looking into this problem, I don't seem to be able to track it
down. With the addition of gcc-4.4.0 to the cegcc toolset, the ARM
float/double arithmetic appears to be broken.
Environment is cross-development for execu
35 matches
Mail list logo
