Snapshot gcc-4.6-20110923 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110923/
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
On 09/24/2011 12:23 AM, David Edelsohn wrote:
My latest bootstrap of GCC on AIX failed due to missing symbols in
libstdc++ expected by libgmpxx:
On x86_64-linux are both still exported. And for sure nobody worked on
the code itself. I would say, it's a compiler issue..
Paolo.
My latest bootstrap of GCC on AIX failed due to missing symbols in
libstdc++ expected by libgmpxx:
exec(): 0509-036 Cannot load program exec(): 0509-036 Cannot load
program /tmp/20110922/./gcc/cc1plus/tmp/20110922/./g
cc/cc1plus because of the following errors:
because of the following errors:
Hi Jason,
Jason Molenda wrote:
> On Sep 23, 2011, at 10:58 AM, Cary Coutant wrote:
>
>>> The compiler puts DWARF in the .o file, the linker adds some records in the
>>> executable which help us to understand where files/function/symbols landed
>>> in the final executable[1].
>> Did you intend t
On Sep 23, 2011, at 10:58 AM, Cary Coutant wrote:
>> The compiler puts DWARF in the .o file, the linker adds some records in the
>> executable which help us to understand where files/function/symbols landed
>> in the final executable[1].
>
> Did you intend to add a footnote?
Yeah, I realized
On Fri, Sep 16, 2011 at 4:00 AM, Jiangning Liu wrote:
> Hi Richard,
>
> I slightly changed the case to be like below,
>
> int f(char *t) {
> int s=0;
>
> while (*t && s != 1) {
> switch (s) {
> case 0: /* path 1 */
> s = 2;
> break;
> case 2: /*
On Mon, Sep 12, 2011 at 10:10 AM, pavan tc wrote:
> Hi,
>
> I would like to know if there have been issues with optimized linked
> list code with GCC 4.3.2. [optiimization flag : -O2]
>
> The following is the inlined code that has the problem:
>
> static inline void
> list_add_tail (struct list_he
Pierre Vittet writes:
> Thanks for your interest,
>
> I just checked revision 179127 of GCC. Last revision is 177700, it has
> not been change for 6 weeks.
>
> My file is the same as this one:
> http://gcc.gnu.org/viewcvs/trunk/libiberty/md5.c?revision=177700&view=markup
>
> in libiberty/md5.c, f
Thanks for your interest,
I just checked revision 179127 of GCC. Last revision is 177700, it has
not been change for 6 weeks.
My file is the same as this one:
http://gcc.gnu.org/viewcvs/trunk/libiberty/md5.c?revision=177700&view=markup
in libiberty/md5.c, function md5_process_bytes start line 2
> The Apple approach has both the features of the Sun/HP implementation as well
> as the ability to create a standalone debug info file.
Thanks for the clarifications. I based my comments on a description
you sent me a couple of years ago, and I apologize for any
oversimplifications I introduced.
>> * .debug_pubtypes - Public types for use in building the
>> .gdb_index section at link time. This section will have an
>> extended format to allow it to represent both types in the
>> .debug_dwo_info section and type units in .debug_types.
> ^^^
> = .dwo_info , maybe both
Hi,
I notice the following description is different from how spu & m32c use it.
In internal manual:
bool TARGET_ADDR_SPACE_SUBSET_P (addr space t superset, [Target Hook]
addr space t subset)
Define this to return whether the subset named address space is contained
within the
superset named add
ok sorrythanks for replying..!!
Andrew Haley wrote:
>
> On 09/16/2011 11:30 AM, pankajsejwal wrote:
>>
>> I have build gcc and imported it on eclipse and started to debug it from
>> main
>> but after a few steps it stops and sends "malloc.c" not found error and
>> asks
>> to give a source pa
Pierre Vittet writes:
> The bug appears when:
> 1) We use libiberty compiled with -O0
> 2) We first call md5_process_bytes with a less than 64 bits buffer (we
> call his size len1).
> 3) We make a new call of md5_process_bytes with a buffer which has a
> size len2 such as:
>
Hello,
I recently asked for some help as I got a problem when using
md5_process_bytes (in libiberty/md5.c):
http://gcc.gnu.org/ml/gcc-help/2011-09/msg00126.html,
http://gcc.gnu.org/ml/gcc-help/2011-09/msg00127.html and it appears that
there is a bug in md5_process_bytes.
The bug can conduct to a
On Fri, 23 Sep 2011 09:30:48 -0400, amylaar wrote:
> Hiding the flags register would mean it is not represented in the rtl at
> all. You can have combined compare-branch instructions. Of course,
> going that route would mean that the model you present to GCC is even
> further from the hardware th
On Fri, 23 Sep 2011 02:21:44 +0200, Cary Coutant wrote:
> * .debug_pubtypes - Public types for use in building the
> .gdb_index section at link time. This section will have an
> extended format to allow it to represent both types in the
> .debug_dwo_info section and type units in .debug_types
Quoting "Paulo J. Matos" :
That's seriously annoying. The idea was to ditch cc0 and explicitly
represent CC in a register to perform optimizations like splitting add
and addc for a double word addition. If by hiding my register flags
means going back to cc0, then it seems that the only way to go
On 22/09/11 22:15, Richard Guenther wrote:
Btw, I think this is an old bug that has been resolved. Did you make sure to
test a recent 4.6 branch snapshot or svn head?
My hopes were high but unfortunately it is not fixed yet.
git head 36181f98 still generates the same unexpected code.
Cheers
On Thu, Sep 22, 2011 at 20:06, Hans-Peter Nilsson wrote:
> On Thu, 8 Sep 2011, Diego Novillo wrote:
>
>> On Thu, Sep 8, 2011 at 04:31, Richard Guenther
>> wrote:
>>
>> > I think it would be more useful to have a script parse gcc-testresults@
>> > postings from the various autotesters and produce
On 23/09/11 08:21, Joern Rennecke wrote:
Quoting "Paulo J. Matos" :
My addition instruction sets all the flags. So I have:
This is annoying, but can be handled. Been there, done that.
dse.c needs a small patch, which I intend to submit sometime in the future.
Ok. Actually I was quite happy
On 23/09/11 12:33, Paulo J. Matos wrote:
On 22/09/11 22:15, Richard Guenther wrote:
Btw, I think this is an old bug that has been resolved. Did you make
sure to
test a recent 4.6 branch snapshot or svn head?
Should have tested git head. Compiling git head now to check the current
status of t
On 22/09/11 22:15, Richard Guenther wrote:
Btw, I think this is an old bug that has been resolved. Did you make sure to
test a recent 4.6 branch snapshot or svn head?
Should have tested git head. Compiling git head now to check the current
status of this issue.
--
PMatos
> (Any reason this wasn't sent to the libstdc++ list?)
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852 proposes a "quiet
> mode" which would reduce code size by disabling some of the code in
> eh_term_handler.cc and pure.cc - would that do what you want?
>
> I've not had time to do anything a
On 23 September 2011 09:14, Amker.Cheng wrote:
> Hi,
>
> In libstdc++-v3/libsupc++/eh_term_handler.cc, it says by default the
> demangler things are pulled in,
> according to whether _GLIBCXX_HOSTED is defined. the demangler
> exception terminating handler
> are really big, especially for embedded
Hi,
In libstdc++-v3/libsupc++/eh_term_handler.cc, it says by default the
demangler things are pulled in,
according to whether _GLIBCXX_HOSTED is defined. the demangler
exception terminating handler
are really big, especially for embedded system.
Secondly, _GLIBCXX_HOSTED is now defined if --enabl
Quoting "Paulo J. Matos" :
My addition instruction sets all the flags. So I have:
This is annoying, but can be handled. Been there, done that.
dse.c needs a small patch, which I intend to submit sometime in the future.
And all my (define_insn "*mov..." are tagged with a (clobber (reg:CC
RCC
27 matches
Mail list logo
