On Fri, 22 Jul 2011 15:12:36 -0700
Ian Lance Taylor wrote:
> Basile Starynkevitch writes:
>
> > Should we add an option to the gcc driver which would print such checksums?
>
> I'm not quite sure what checksums you want.
>
> Suppose you just do
>
> md5sum `gcc --print-file-name=cc1`
>
> ?
>
Gabriel> We are tying to keep pph as "pluginable" as possible (Diego correct me
Gabriel> if I'm wrong), so changing the actual implementation of the linemap
Gabriel> would be our very last resort I think.
Gabriel> However since source_location aren't pointers per se, this wouldn't
Gabriel> work (a
On 07/20/2011 04:55 AM, Richard Sandiford wrote:
> The "loc_result &&" check makes it seem as though we're trying to cope
> with cases XVECLEN is zero, but that only works if the first (dead) load
> of XEXVECP (regs, 0, 0) is optimised away. Is a length of 0 valid
> in this context? If not, shoul
Snapshot gcc-4.6-20110722 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110722/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
This merge brings trunk into google/main (via google/integration).
It had been a long while since we had merged from trunk so it
took a while to fix and there are several broken modules.
We decided that it's better to commit the merge for now and fix
the broken modules next. So, if you had a copy
Basile Starynkevitch writes:
> Should we add an option to the gcc driver which would print such checksums?
I'm not quite sure what checksums you want.
Suppose you just do
md5sum `gcc --print-file-name=cc1`
?
That will give you a checksum without gcc going to the trouble of
generating it.
Ia
Thanks for the quick reply Tom,
On Fri, Jul 22, 2011 at 1:39 PM, Tom Tromey wrote:
>> "Gabriel" == Gabriel Charette writes:
>
> Gabriel> @tromey: We have a question for you: the problem is detailed
> Gabriel> here and our question to you is at the bottom. Thanks!
>
> Sure. I have not follow
> "Gabriel" == Gabriel Charette writes:
Gabriel> @tromey: We have a question for you: the problem is detailed
Gabriel> here and our question to you is at the bottom. Thanks!
Sure. I have not followed PPH progress very closely and after reading
your message I am not sure I have much to offer
Hi,
@tromey: We have a question for you: the problem is detailed here and
our question to you is at the bottom. Thanks!
So the line problem we are having in pph is much bigger then we
originally thought.
The problem is:
As we've had issues with before: the chain of name bindings in any
cpp_bindi
On Fri, Jul 22, 2011 at 8:37 AM, Paulo J. Matos wrote:
> On 22/07/11 16:22, Joern Rennecke wrote:
>>>
>>> I have to disagree, library issue means that it's an issue with the
>>> library, not gcc.
>>
>> It still makes sense to clarify the language to indicate that, depending
>> on
>> the library us
On the following page
http://gcc.gnu.org/mirrors.html
your Vietnam mirror
# Viet Nam, HoChiMinh: http://mirror-fpt-telecom.fpt.net/gcc/, thanks to Minh
Vu Tong (mirror at fpt dot net)
is messed up. I repeatedly get a 404 error.
Please do not add me to any mailing list or registry.
Have a ni
Hello All,
As far as I understand, plugins' shared objects are not supposed to (be
guaranteed to)
work when gcc changes, even from one patchlevel to the next, or perhaps even
when it has
been rebuilt.
In MELT, I am trying very hard to enforce that MELT modules (the *.so produced
by
compiling
On 22/07/11 16:22, Joern Rennecke wrote:
I have to disagree, library issue means that it's an issue with the
library, not gcc.
It still makes sense to clarify the language to indicate that, depending on
the library used, this might be, in fact, a library non-issue.
We might be interpreting t
Quoting "Paulo J. Matos" :
On 22/07/11 00:47, Diogo Sousa wrote:
But readers will focus on the word "Issue" here and think that there is
something missing. Perhaps there should be a footnote explaining that
glibc/eglibc has the needed support, but that other libraries might not.
I agree. I
On Fri, 22 Jul 2011, Ilya Enkovich wrote:
> Hello,
>
> I need to use enum tree_code for default hook in hooks.c. I had to add
> "tree.h" include into "hook.c" for that. But it caused some errors in
> gcc build:
hooks.c should only be for hooks with very generic prototypes likely to be
of use fo
Hi there! I would like to host a new mirror in US, Missouri, Saint Louis.
I have a server with alot free space and many bandwidth available.
The mirror will have URL like gcc.petsads.us
My email s.kutse...@gmail.com
My name is Sergey Kutserey
Please send me the details on how to setup a new mirror
2011/7/22 Richard Guenther :
>
> Elsewhere we use an unsigned int instead of enum tree_code.
>
> Richard.
>
Thanks for the hint!
Ilya
On Fri, Jul 22, 2011 at 3:02 PM, Ilya Enkovich wrote:
> Hello,
>
> I need to use enum tree_code for default hook in hooks.c. I had to add
> "tree.h" include into "hook.c" for that. But it caused some errors in
> gcc build:
>
> gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
>
Hello,
I need to use enum tree_code for default hook in hooks.c. I had to add
"tree.h" include into "hook.c" for that. But it caused some errors in
gcc build:
gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format
On 22/07/11 00:47, Diogo Sousa wrote:
But readers will focus on the word "Issue" here and think that there is
something missing. Perhaps there should be a footnote explaining that
glibc/eglibc has the needed support, but that other libraries might not.
I agree. It should say something as "Li
20 matches
Mail list logo
