Hi Tristan,
> > http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00970.html
> I have not applied this patch. I will give it a try.
This patch is not fixing the issue.
Moreover, on compiling expr.c I get this warning:
/gcc/expr.c: In function 'expand_expr_addr_expr_1':
/gcc/expr.c:7603:10
On Jun 6, 2012, at 9:10 AM, Mailaripillai, Kannan Jeganathan wrote:
> Hi Tristan,
>
>>> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00970.html
>> I have not applied this patch. I will give it a try.
>
> This patch is not fixing the issue.
> Moreover, on compiling expr.c I get this warning:
>
Hi Tristan,
> how result can be used uninitialized as it is assigned just before
I am sorry. My mistake. I had replaced expand_expr_addr_expr_1 with
convert_memory_address_addr_space. I overlooked the patch as
- result = expand_expr_addr_expr_1 (inner, subtarget, tmode, modifier, as);
+ resul
On Jun 6, 2012, at 10:45 AM, Mailaripillai, Kannan Jeganathan wrote:
> Hi Tristan,
>
>> how result can be used uninitialized as it is assigned just before
>
> I am sorry. My mistake. I had replaced expand_expr_addr_expr_1 with
> convert_memory_address_addr_space. I overlooked the patch as
>
>
The first release candidate for GCC 4.7.1 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.1-RC-20120606
and shortly its mirrors. It has been generated from SVN revision 188257.
I have so far bootstrapped and tested the release candidate on
x86_64-linux. Please test it and report
Hi Tristan,
After applying the patch (correctly) the build proceeded further.
Now the build hits on another error, while compiling /libgomp/parallel.c:
/libgomp/parallel.c: In function 'omp_get_ancestor_thread_num':
/libgomp/parallel.c:166:1: internal compiler error: in plus_constant
On Jun 6, 2012, at 12:27 PM, Mailaripillai, Kannan Jeganathan wrote:
> Hi Tristan,
>
> After applying the patch (correctly) the build proceeded further.
> Now the build hits on another error, while compiling /libgomp/parallel.c:
>
> /libgomp/parallel.c: In function 'omp_get_ancestor_th
> What is the backtrace ?
#0 0x6db96a0:0 in plus_constant (mode=RFmode, x=0x18, c=1)
#1 0xd7503f0:0 in ia64_expand_tls_address (tls_kind=TLS_MODEL_INITIAL_EXEC,
op0=0x651ac120, op1=0x651ac0f0, orig_op1=0x651ac0f0, addend=0)
#2 0xd750dd0:0 in ia64_expand_move (op0=0x651ac120, op1=0x651ac0f0
> > > What is the backtrace ?
> #0 0x6db96a0:0 in plus_constant (mode=RFmode, x=0x18, c=1)
> #13 0x6f68260:0 in expand_expr_real_1 (exp=0x651ab420, target=0x0,
Full backtrace:
#0 0x6db96a0:0 in plus_constant (mode=RFmode, x=0x18, c=1)
#1 0xd7503f0:0 in ia64_expand_tls_address (tls_kind=TLS_MOD
On Tue, Jun 5, 2012 at 9:56 AM, Steven Bosscher wrote:
>> BSS was a later addition and there is no ".bss" pseudo-op directive,
>> unlike the ".comm" directive. There only is the BSS storage class.
>
> Do you know where I could find documentation for how to write out
> something with BSS storage c
On 03/06/2012 04:43, Hans-Peter Nilsson wrote:
> On Fri, 18 May 2012, Ralf Corsepius wrote:
>> On 05/18/2012 09:24 AM, Sebastian Huber wrote:
>>> Hi,
>>>
>>> if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11
>>> target, then I get several unexpected errors due to:
>>>
>>> gcc
On 06/06/2012 03:09 PM, Dave Korn wrote:
I am not sure, but AFAICT, -pthread is Linux-specific.
No, it's the canonical multi-os option to enable pthreads, as
generic as it gets.
According to the manual(*), it's a machine-dependent option for RS6000 and
Solaris 2 only!
And there's a lot o
I am interested in parsing DWARF debug output in order to know the calling
convention of each function. Reading the spec for DWARF-4, I can see that
there is an attribute DW_AT_calling_convention but its only defined values are
(pg 52):
DW_CC_normal
DW_CC_program
DW_CC_nocall
The spec als
On Jun 6, 2012 2:14 PM, "Florian Weimer" wrote:
>
> On 06/06/2012 03:09 PM, Dave Korn wrote:
I am not sure, but AFAICT, -pthread is Linux-specific.
>>>
>>>
>>> No, it's the canonical multi-os option to enable pthreads, as
>>> generic as it gets.
>>
>>
>> According to the manual(*), it's
On 06/06/2012 06:40 AM, Roger Cruz wrote:
Adding dwarf-discuss@ to CC.
I am interested in parsing DWARF debug output in order to know the calling
convention of each
function. Reading the spec for DWARF-4, I can see that there is an attribute
DW_AT_calling_convention but its only defined valu
Hi Michael,
Thanks for replying to my questions.
What I like to obtain somehow is the calling convention of each routine so I
can tell who is responsible for cleaning off the stack. Two calling
conventions of interest to me are: _stdcall and _cdecl which deal with the
arguments in a slightly
Over the last couple months I've been updating an out-of-tree back end for
the TI MSP430 to support 20-bit functionality. This is a 16-bit
microcontroller, where certain MCUs support 20-bit address and integer
operations with an extended ISA and registers that can hold slightly more
than one word.
On 06/06/2012 09:28 AM, Roger Cruz wrote:
Hi Michael,
Thanks for replying to my questions.
What I like to obtain somehow is the calling convention of each routine so
I can tell who is responsible for cleaning off the stack. Two calling
> conventions of interest to me are: _stdcall and _cdecl
i had a problem compiling from source , so i tried installing .deb from
http://packages.ubuntu.com/hardy-updates/g++-3.4
i installed :
cpp-3.4_3.4.6-6ubuntu5_i386.deb
gcc-3.4-base_3.4.6-6ubuntu5_i386.deb
g++-3.4_3.4.6-6ubuntu5_i386.deb
libstdc++6-dev_3.4.6-6ubuntu5_i386.deb
gcc-3.4_3.4.6-6ubu
On Wed, 6 Jun 2012, mixpro wrote:
i had a problem compiling from source , so i tried installing .deb from
http://packages.ubuntu.com/hardy-updates/g++-3.4
[...]
using gcc-3.4 or g++-3.4 i get :
In file included from /usr/include/stdio.h:28,
from ./hi.c:1:
/usr/include/features.h:324:26: bits/
Marc Glisse-6 wrote:
>
>
> export LIBRARY_PATH=/usr/lib/i386-linux-gnu
> export C_INCLUDE_PATH=/usr/include/i386-linux-gnu
> export CPLUS_INCLUDE_PATH=/usr/include/i386-linux-gnu
>
> --
> Marc Glisse
>
>
know i get :
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
-
On Wed, 6 Jun 2012, mixpro wrote:
Marc Glisse-6 wrote:
export LIBRARY_PATH=/usr/lib/i386-linux-gnu
export C_INCLUDE_PATH=/usr/include/i386-linux-gnu
export CPLUS_INCLUDE_PATH=/usr/include/i386-linux-gnu
know i get :
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
You c
i found libgcc_s in :
/usr/lib/gcc/i686-linux-gnu/4.6/libgcc_s.so
/usr/lib/gcc/i486-linux-gnu/3.4.6/64/libgcc_s.so
/usr/lib/gcc/i486-linux-gnu/3.4.6/64/libgcc_s_64.so
/usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_s.so
/usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_s_64.so
/lib/i386-linux-gnu/libgcc_s.so.1
a
Hi Steven,
On 5 Jun 2012, at 21:23, Steven Bosscher wrote:
> On Tue, Jun 5, 2012 at 8:55 PM, Iain Sandoe wrote:
>> I would welcome a simple solution if one is available, although I don't
>> quite see what you have in mind at present.
>
> This is what I have in mind. Untested, but it shows the
This is a followup mail to http://gcc.gnu.org/ml/gcc/2012-05/msg00400.html
now that I understand my problem better and can change the subject line to
reflect that.
I am trying to determine if a user specified the '-msynci' flag on his or her
GCC compile line or if it is on by default because when
mixpro wrote:
>
> i found libgcc_s in :
> /usr/lib/gcc/i686-linux-gnu/4.6/libgcc_s.so
> /usr/lib/gcc/i486-linux-gnu/3.4.6/64/libgcc_s.so
> /usr/lib/gcc/i486-linux-gnu/3.4.6/64/libgcc_s_64.so
> /usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_s.so
> /usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_s_64.so
> /li
On Wed, Jun 6, 2012 at 10:07 PM, Iain Sandoe wrote:
> Hi Steven,
> The attached patch survives normal and lto bootstrap on i686-darwin9 and
> x86_64-darwin10.
> No regressions for ObjC or Obj-C++.
> Otherwise, lightly tested, but appears to solve PR 48109 on the way.
>
> changes:
>
> o [minor] t
> This is a followup mail to http://gcc.gnu.org/ml/gcc/2012-05/msg00400.html
> now that I understand my problem better and can change the subject line to
> reflect that.
I'm not sure whether digging into the behavior of the driver is the best way to
solve this kind of testsuite problems. I think
On Wed, 2012-06-06 at 23:19 +0200, Eric Botcazou wrote:
> > This is a followup mail to http://gcc.gnu.org/ml/gcc/2012-05/msg00400.html
> > now that I understand my problem better and can change the subject line to
> > reflect that.
>
> I'm not sure whether digging into the behavior of the driver i
On 6 June 2012 19:57, mixpro wrote:
>
> i had a problem compiling from source
Questions about building GCC are not appropriate on this mailing list,
as you've posted via Nabble you should have seen Nabble's description
of the list which clearly says:
"Please note this is NOT, I repeat NOT, a GCC
Thanks Michael. So it sounds like DWARF won't help me in determining how a
called function should (or should not) clean up the stack and also if I want to
determine the calling convention, I would have to modify GCC itself to produce
those user extensions.
Roger
_
Hi!
A bit late to the game... :-)
On Fri, 6 Apr 2012 18:55:28 -0400, Diego Novillo wrote:
> I have started testing the switch to C++ and there is a pile of
> testing to be done. The testing itself is trivial, but the number of
> targets that need to be tested is large and I don't have access t
32 matches
Mail list logo
