Dear GCC developers,
Would you please consider suppressing (relatively new) warnings like this one:
ignoring return value of 'int chdir(const char*)', declared with attribute
warn_unused_result
in cases when the source code explicitly casts the result to (void). Like in
(void) chdir("/");
Th
Well currently the fortran front-end scalarizes those operators. But
the fortran frontend has it's own ast which gets translated to gimple
so you might to take a look into that instead of gimple.
Sent from my iPhone
On May 27, 2010, at 9:10 PM, "Marcus G. Daniels"
wrote:
Andrew Pinski
> Please make another attempt at the language of the statement without
> editorializing about the name of the port.
Sorry about that. Like this?
Segher
diff -u -p -r1.90 changes.html
--- changes.html27 Apr 2010 13:53:21 - 1.90
+++ changes.html28 May 2010 04:09:20 -000
Andrew Pinski wrote:
How about doing a plugin instead?
I took a peek at the Treehydra plugin from Mozilla that does pre-GENERIC
for C++.
That looks like it would work, but we're concerned with Fortran, and
indeed would like to preserve things like Fortran array-level
operators. The GENERI
How about doing a plugin instead?
Sent from my iPhone
On May 27, 2010, at 8:21 PM, "Marcus G. Daniels"
wrote:
Hi all,
For the purposes of static analysis, can the output of -fdump-tree-
original-raw complete for reconstructing GENERIC data? Packages
like treehydra are intriguing, but
Hi all,
For the purposes of static analysis, can the output of
-fdump-tree-original-raw complete for reconstructing GENERIC data?
Packages like treehydra are intriguing, but they aren't complete, for
example, for Fortran.
Thanks,
Marcus Daniels
On Thu, May 27, 2010 at 9:16 PM, Segher Boessenkool
wrote:
> Probably no one uses these old processors anymore, and support for them
> is getting in the way of other work in the rs6000 port.
>
> Let's remove it in 4.6. Okay?
>
>
> Segher
>
>
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/changes.htm
Probably no one uses these old processors anymore, and support for them
is getting in the way of other work in the rs6000 port.
Let's remove it in 4.6. Okay?
Segher
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/changes.html,v
retrieving revision 1.90
diff -u -r1.90 changes.html
--- changes.html
Joern Rennecke writes:
> Quoting Russ Allbery :
>
>> "Alfred M. Szmidt" writes:
>>
>>> It should be noted that Debian considers the GFDL a non-free
>>> /software/ license; which it is, but then the GFDL is not a software
>>> license to begin with.
>>
>> The official Debian position is that the d
Snapshot gcc-4.5-20100527 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100527/
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/branches
Quoting Russ Allbery :
"Alfred M. Szmidt" writes:
It should be noted that Debian considers the GFDL a non-free
/software/ license; which it is, but then the GFDL is not a software
license to begin with.
The official Debian position is that the distinction between a software
license and a no
"Alfred M. Szmidt" writes:
> It should be noted that Debian considers the GFDL a non-free
> /software/ license; which it is, but then the GFDL is not a software
> license to begin with.
The official Debian position is that the distinction between a software
license and a non-software license for
This is the beta release of binutils 2.20.51.0.9 for Linux, which is
based on binutils 2010 0526 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
/wiki/Release%20Manager%20Q%26A?action=AttachFile&do=view&target=rmqa-20100527.txt
--
Joseph S. Myers
jos...@codesourcery.com
Thanks to all who participated in the GCC Release Manager Q&A on IRC
earlier today. Joseph Myers logged the chat session and will put it on
the GCC Wiki soon. There were a lot of good comments and questions.
Thanks especially to Richard Guenther and Joseph Myers who both
accommodated my unilater
On Thu, 2010-05-27 at 10:38 +0200, Basile Starynkevitch wrote:
> On Wed, May 26, 2010 at 02:40:21PM +0200, Basile Starynkevitch wrote:
> >
> > No, unfortunately, the bug is still here, and appears when configuring
> > GCC MELT with --enable-bootstrap and when compiling it with a gcc which
> > is n
On Thu, May 27, 2010 at 2:38 AM, Richard Guenther
wrote:
> On Wed, May 26, 2010 at 6:05 PM, Richard Guenther
> wrote:
>> On Wed, May 26, 2010 at 5:42 PM, Xinliang David Li
>> wrote:
>>> On Wed, May 26, 2010 at 2:58 AM, Richard Guenther
>>> wrote:
On Tue, May 25, 2010 at 10:02 PM, Easwaran
> Therefore, if I don't have an update "soon" (within a week or two), I'd
> suggest that we operate under the assumption that it will not be
> possible to combine GFDL manuals and GPL code in the near future.
I think it should be possible, Emacs does something similar I think.
However
Hi,
I've committed the following fix.
* cgraph.h (struct cgraph_node): Mark former_clone_of by GTY ((skip)).
* cgraphunit.c (clone_of_p): Compile only when checking is enabled.
Index: cgraph.h
===
*** cgraph.h(revi
Hi.
This mornings bootstrap fails with the following error:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-
> It seems that these make variables are not needed exactly for plugin
> support, but to compile plugins, in particular those in the testsuite.
"Compiler needed for plugin support" is supposed to mean compiler needed to
compile plugins here, it's the build machinery.
> Perhaps we should add a co
Hi,
it seems that bootstrap is broken in x86-64 since at least yesterday,
but apparently only if checking is disabled.
Compilation stops with this error message:
gcc -c -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes Wmissing-format-attribute -ped
Michael Meissner wrote:
> On Wed, May 26, 2010 at 08:09:57PM +0200, Ulrich Weigand wrote:
> > In the current patch, the SPU back-end uses somewhat of a hack to actually
> > perform that call: it is included in the REGISTER_TARGET_PRAGMAS macro.
> > Note that this macro is already being used by the
On Thu, May 27, 2010 at 1:37 PM, Paolo Bonzini wrote:
> On 05/27/2010 12:33 PM, Amker.Cheng wrote:
>>
>> while GCC3.4.4 treats the long long multiplication just like simple
>> ones, which generates only one
>> mult insn for each statement, like
>>
>> In my understanding, It‘s not necessary using t
Eggenmüller Bernd schrieb:
> Hi,
>
> I've to represent 32 bit immediates to trans late the libgcc2.
> The problem is that my assembler only can represent 16 Bit immediates.
> How can I implement a workaround for 32 Bit immediates.
libgcc is written in C, so it's likely that you have no proper sup
On Thu, 27 May 2010, Basile Starynkevitch wrote:
> However, could you (or some other well informed person) elaborate on
> that incompatibility. What exactly is incompatible? Is it some paragraph
> of GPLv3 versus another paragraph of GFDL1.2 - which ones? Or why is it
> incompatible?
Any two non-
On 05/27/2010 12:33 PM, Amker.Cheng wrote:
while GCC3.4.4 treats the long long multiplication just like simple
ones, which generates only one
mult insn for each statement, like
In my understanding, It‘s not necessary using three mult insn to implement
long long mult, since the operands are conve
Hi,
I have not really payed much attention to this thread, but...
On Thu, May 27, 2010 at 11:38:09AM +0200, Richard Guenther wrote:
> On Wed, May 26, 2010 at 6:05 PM, Richard Guenther
> wrote:
> > On Wed, May 26, 2010 at 5:42 PM, Xinliang David Li
> > wrote:
> >> On Wed, May 26, 2010 at 2:58 A
> Posting some random numbers without a test-case and precise command line
> parameters for both compilers makes the numbers useless, IMHO. You also
> only mention instruction counts. Have you actually benchmarked the
> resulting code? CPUs are complicated and what you might perceive as worse
> cod
On Wed, May 26, 2010 at 6:05 PM, Richard Guenther
wrote:
> On Wed, May 26, 2010 at 5:42 PM, Xinliang David Li wrote:
>> On Wed, May 26, 2010 at 2:58 AM, Richard Guenther
>> wrote:
>>> On Tue, May 25, 2010 at 10:02 PM, Easwaran Raman wrote:
On Fri, May 21, 2010 at 10:30 AM, Xinliang David L
Hi,
I've to represent 32 bit immediates to trans late the libgcc2.
The problem is that my assembler only can represent 16 Bit immediates.
How can I implement a workaround for 32 Bit immediates.
Thanks
Egge
On Thu, May 27, 2010 at 10:14 AM, Paolo Bonzini wrote:
> On 05/27/2010 10:10 AM, Steven Bosscher wrote:
>>
>> -/* FIXME: Still need to include rtl.h here (via expr.h) in a front-end
>> file.
>> - Pretend this is a back-end file. */
>> -#define IN_GCC_BACKEND
>> #include "expr.h" /* For vector_
On Wed, May 26, 2010 at 02:40:21PM +0200, Basile Starynkevitch wrote:
>
> No, unfortunately, the bug is still here, and appears when configuring
> GCC MELT with --enable-bootstrap and when compiling it with a gcc which
> is not 4.5. (I confess I rarely test that).
>
> I will investigate that late
Hello All,
The file gcc/Makefile.in (of gcc trunk revision ) contains near line 334
# Compiler needed for plugin support
PLUGINCC = @CC@
# Flags needed for plugin support
PLUGINCFLAGS = @CFLAGS@
# Libs and linker options needed for plugin support
PLUGINLIBS = @pluginlibs@
It seems that these
On 05/27/2010 10:10 AM, Steven Bosscher wrote:
-/* FIXME: Still need to include rtl.h here (via expr.h) in a front-end file.
- Pretend this is a back-end file. */
-#define IN_GCC_BACKEND
#include "expr.h" /* For vector_mode_valid_p */
Is this really the only reason? We don't have any othe
gcc/ChangeLog:
* Makefile.in (ALL_CFLAGS): Add file-specific CFLAGS.
(ALL_HOST_FRONTEND_OBJS): New, for all front-end specific objects.
(ALL_HOST_BACKEND_OBJS): New, for all backend and target objects.
(ALL_HOST_OBJS): Now a union of the above two.
:
On Thu, May 27, 2010 at 9:49 AM, Paolo Bonzini wrote:
> On 05/27/2010 08:25 AM, Steven Bosscher wrote:
>>
>> On Thu, May 27, 2010 at 7:15 AM, Paolo Bonzini wrote:
>> Well, gives me at least one clue so far: the implicit rule .c.o is
>> over-ruled by t-i386, which explains why the extra CFLAGS-$fi
On 05/27/2010 10:02 AM, Joern Rennecke wrote:
Quoting Paolo Bonzini :
On 05/26/2010 09:25 AM, Joern Rennecke wrote:
What we can't do under this scheme is retroactively re-use code
as documentation or vice versa; we'd need the appropriate license
grant from the FSF for each bit of code/document
> On Wed, May 26, 2010 at 5:53 PM, Bingfeng Mei wrote:
> > Hi, Richard,
> > With resolution file generated by GOLD (or I am going to hack gnu LD), is
> > externally_visible attribute still needed to annotate those symbols accessed
> > from non-LTO objects when compiling with -fwhole-program.
>
>
Quoting Paolo Bonzini :
On 05/26/2010 09:25 AM, Joern Rennecke wrote:
What we can't do under this scheme is retroactively re-use code
as documentation or vice versa; we'd need the appropriate license
grant from the FSF for each bit of code/documentation that we want
to re-use in that manner.
On 05/27/2010 08:25 AM, Steven Bosscher wrote:
On Thu, May 27, 2010 at 7:15 AM, Paolo Bonzini wrote:
Well, gives me at least one clue so far: the implicit rule .c.o is
over-ruled by t-i386, which explains why the extra CFLAGS-$file are
not passed to config/i386/i386-c.c. I'm now restarting the
On Thu, May 27, 2010 at 8:25 AM, Steven Bosscher wrote:
> On Thu, May 27, 2010 at 7:15 AM, Paolo Bonzini wrote:
>> On 05/27/2010 06:58 AM, Steven Bosscher wrote:
>>>
>>> Well, it looks like I do need something like @F because I now only get
>>> the define on files in gcc/. Any file with a / in th
42 matches
Mail list logo
