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
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
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
> (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 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
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 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 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 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
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 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
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
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
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:
>
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
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
>> * .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
> 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.
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
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
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
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 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
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
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:
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.
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
27 matches
Mail list logo
