On Tue, Oct 1, 2013 at 11:23 AM, Andrew Haley wrote:
> On 10/01/2013 03:19 PM, Joern Rennecke wrote:
>>
>> Quoting Richard Biener:
>>
>>> Good. So what remains is the configure parts, the libgcc parts and
>>> the documentation parts. Though for all of them they look ARC
>>> specific so maybe the
gcc --version
gcc (GCC) 4.8.1
(4.7.2 seems to work)
gcc -g -fPIC -O2 -Wall -o test test.c
./test
type_a is 0x0
Correct would be 0x14000. I don't see how the C-code could be
ambiguous, I think this is a bug?
test.c:
#include
typedef struct
{
unsigned int a:4;
unsigned int b:5;
un
On Tue, Oct 1, 2013 at 9:16 AM, Paul Pluzhnikov wrote:
> Thanks. I've also confirmed that trunk is similarly broken with
> --enable-symvers=gnu-versioned-namespace, and that the patch fixes that.
>
>> Would you like me to build the whole compiler package as well as a test
>> program?
>
> I am doi
> "Basile" == Basile Starynkevitch writes:
Basile> I want to merge the current trunk into the MELT branch, and I
Basile> have some trouble understanding how one should add new files
Basile> into GCC (i.e. into a branch)
Nothing much has changed there. You just don't need to list any
discove
On Tue, Oct 1, 2013 at 9:12 AM, Oleg Smolsky wrote:
> On 2013-10-01 09:00, Paul Pluzhnikov wrote:
>> 2013-10-01 Paul Pluzhnikov
>>
>> * src/c++11/snprintf_lite.cc: Add missing
>> _GLIBCXX_{BEGIN,END}_NAMESPACE_VERSION
>
> Thanks. This patch address the immediate issue and my build mov
Hi,
Jonathan Wakely ha scritto:
>On 1 October 2013 16:49, Paul Pluzhnikov wrote:
>>
>> Paolo, does attached patch look correct for trunk?
>
>There would need to be a corresponding _GLIBCXX_END_NAMESPACE_VERSION.
Indeed. Otherwise, if the patch passes testing (in the various configs) it's
cert
On 2013-10-01 09:00, Paul Pluzhnikov wrote:
I'll test trunk breakage with --enable-symvers above, and then
attached patch should fix it.
libstdc++-v3/ChangeLog:
2013-10-01 Paul Pluzhnikov
* src/c++11/snprintf_lite.cc: Add missing
_GLIBCXX_{BEGIN,END}_NAMESPACE_VERSION
Thanks. Th
On 1 October 2013 17:00, Paul Pluzhnikov wrote:
> On Tue, Oct 1, 2013 at 8:56 AM, Jonathan Wakely wrote:
>> On 1 October 2013 16:49, Paul Pluzhnikov wrote:
>>>
>>> The same problem likely exists on trunk, so please do tell how to configure
>>> GCC in order to reproduce it.
>>
>> The std::__7 names
On 2013-10-01 08:49, Paul Pluzhnikov wrote:
I've attached the fill log.
How was this GCC configured?
Hey Paul, thanks for the quick reply. Here is how the final compiler is
configured (it's an intel-to-intel sysroot'd cross-compiler):
../gcc48-google/configure \
--prefix=%{PREFIX} -
On Tue, Oct 1, 2013 at 8:56 AM, Jonathan Wakely wrote:
> On 1 October 2013 16:49, Paul Pluzhnikov wrote:
>>
>> The same problem likely exists on trunk, so please do tell how to configure
>> GCC in order to reproduce it.
>
> The std::__7 namespace implies --enable-symvers=gnu-versioned-namespace'
On 1 October 2013 16:49, Paul Pluzhnikov wrote:
>
> The same problem likely exists on trunk, so please do tell how to configure
> GCC in order to reproduce it.
The std::__7 namespace implies --enable-symvers=gnu-versioned-namespace'
On 1 October 2013 16:49, Paul Pluzhnikov wrote:
>
> Paolo, does attached patch look correct for trunk?
There would need to be a corresponding _GLIBCXX_END_NAMESPACE_VERSION.
On Tue, Oct 1, 2013 at 8:00 AM, Oleg Smolsky wrote:
> Hey all, hey Paul, it looks like the code branches/google/gcc-4_8 does not
> compile any more:
It sure does still build for us.
> I've attached the fill log.
How was this GCC configured?
> As a guess, it may be due to the following commit.
Hi,
I am resuming investigations about disabling peeling for
alignment (see thread at
http://gcc.gnu.org/ml/gcc/2012-12/msg00036.html).
As a reminder, I have a simple patch which disables peeling
unconditionally and gives some improvement in benchmarks.
However, I've noticed a regression where a
On 10/01/2013 03:19 PM, Joern Rennecke wrote:
Quoting Richard Biener:
Good. So what remains is the configure parts, the libgcc parts and
the documentation parts. Though for all of them they look ARC
specific so maybe the maintainership covers these as well.
I suppose this automatism when bei
On 10/01/13 09:23, Andrew Haley wrote:
On 10/01/2013 03:19 PM, Joern Rennecke wrote:
Quoting Richard Biener:
Good. So what remains is the configure parts, the libgcc parts and
the documentation parts. Though for all of them they look ARC
specific so maybe the maintainership covers these as w
Hey all, hey Paul, it looks like the code branches/google/gcc-4_8 does
not compile any more:
../../../../../gcc48-google/libstdc++-v3/src/c++11/snprintf_lite.cc: In
function 'int __gnu_cxx::__concat_size_t(char*, std::size_t, std::size_t)':
../../../../../gcc48-google/libstdc++-v3/src/c++11/snp
Quoting Richard Biener :
Good. So what remains is the configure parts, the libgcc parts and
the documentation parts. Though for all of them they look ARC
specific so maybe the maintainership covers these as well.
I suppose this automatism when being assigned the maintainership
escaped Joern a
Hello all,
Recently, it was created branch for OpenACC
(http://gcc.gnu.org/ml/gcc/2013-09/msg00235.html)
As had been promised, I provide design notes, that describe our
understanding of transformations of OpenACC constructs to OpenCL ones.
That's only the design draft and may be changed in fu
On Tue, Oct 1, 2013 at 3:24 PM, Andrew Haley wrote:
> On 10/01/2013 11:32 AM, Richard Biener wrote:
>>
>> Well, I want clarification as of whether assigning maintainership of the
>> port is equivalent to getting approval for checking in the port specific
>> parts. Which_I_ would think is reasona
On 10/01/2013 11:32 AM, Richard Biener wrote:
Well, I want clarification as of whether assigning maintainership of the
port is equivalent to getting approval for checking in the port specific
parts. Which_I_ would think is reasonable (for the maintainer being
Joern even more so).
Well, sure i
On Tue, Oct 01, 2013 at 04:15:53PM +0400, Ilya Enkovich wrote:
> I'd like to restart discussion on this topic. I see two viable options
> in this thread for PLT entry for MPX.
>
> The first one is to use new relocation for calls requiring extended
> PLT. Linker may decide then which PLT entries sh
Hi all,
I'd like to restart discussion on this topic. I see two viable options
in this thread for PLT entry for MPX.
The first one is to use new relocation for calls requiring extended
PLT. Linker may decide then which PLT entries should be extended and
use 16 byte entries when possible. The only
On Tue, Oct 1, 2013 at 11:10 AM, Andrew Haley wrote:
> On 10/01/2013 09:11 AM, Richard Biener wrote:
>> On Mon, Sep 30, 2013 at 6:09 PM, Jeremy Bennett
>> wrote:
>>> Hi all,
>>>
>>> You've probably seen that Joern Rennecke (amylaar) has been pinging
>>> repeatedly for help reviewing the ARC port:
Hello Tom and all
A big thanks for the automatic dependencies patch.
I want to merge the current trunk into the MELT branch, and I have some trouble
understanding how one should add new files into GCC (i.e. into a branch)
For the MELT branch, I just want to add gcc/melt-runtime.cc [which requir
On 10/01/2013 09:11 AM, Richard Biener wrote:
> On Mon, Sep 30, 2013 at 6:09 PM, Jeremy Bennett
> wrote:
>> Hi all,
>>
>> You've probably seen that Joern Rennecke (amylaar) has been pinging
>> repeatedly for help reviewing the ARC port:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02072.ht
On Mon, 30 Sep 2013, Vidya Praveen wrote:
> On Mon, Sep 30, 2013 at 02:19:32PM +0100, Richard Biener wrote:
> > On Mon, 30 Sep 2013, Vidya Praveen wrote:
> >
> > > On Fri, Sep 27, 2013 at 04:19:45PM +0100, Vidya Praveen wrote:
> > > > On Fri, Sep 27, 2013 at 03:50:08PM +0100, Vidya Praveen wrote:
On Mon, Sep 30, 2013 at 6:09 PM, Jeremy Bennett
wrote:
> Hi all,
>
> You've probably seen that Joern Rennecke (amylaar) has been pinging
> repeatedly for help reviewing the ARC port:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02072.html
>
> Joern is approved as a maintainer, and the tests
28 matches
Mail list logo
