On 08/28/2017 09:15 PM, Martin Liška wrote:
> On 08/28/2017 04:06 PM, Jeff Law wrote:
>> On 08/28/2017 01:16 AM, Martin Liška wrote:
>>> Hello.
>>>
>>> I've just repeatedly seen stuck in build process:
>>>
>>> make[5]: Entering directory
>>> `/home/marxin/Programming/gcc/objdir/powerpc64le-unknown
On Tue, Aug 29, 2017 at 9:32 AM, Martin Liška wrote:
> On 08/28/2017 09:15 PM, Martin Liška wrote:
>> On 08/28/2017 04:06 PM, Jeff Law wrote:
>>> On 08/28/2017 01:16 AM, Martin Liška wrote:
Hello.
I've just repeatedly seen stuck in build process:
make[5]: Entering director
Hi,
I got a SEGFAULT in my program when compiling it with gcc-7 but it
is/was all good when using gcc-6.
The SEGFAULT happens due to the line below:
d_point = *p;
And a fix for it (with gcc-7) has been:
memcpy(&d_point,
p,
sizeof(d_point));
Does this make any sense to anybody?
On 2017.08.29 at 12:31 +0200, Marco Varlese wrote:
> Hi,
>
> I got a SEGFAULT in my program when compiling it with gcc-7 but it
> is/was all good when using gcc-6.
>
> The SEGFAULT happens due to the line below:
> d_point = *p;
>
> And a fix for it (with gcc-7) has been:
> memcpy(&d_point,
>
On Tue, Aug 29, 2017 at 12:31:39PM +0200, Marco Varlese wrote:
> Hi,
>
> I got a SEGFAULT in my program when compiling it with gcc-7 but it
> is/was all good when using gcc-6.
>
> The SEGFAULT happens due to the line below:
> d_point = *p;
>
> And a fix for it (with gcc-7) has been:
> memcpy(&d_
On 2017.08.29 at 12:35 +0200, Markus Trippelsdorf wrote:
> On 2017.08.29 at 12:31 +0200, Marco Varlese wrote:
> > Hi,
> >
> > I got a SEGFAULT in my program when compiling it with gcc-7 but it
> > is/was all good when using gcc-6.
> >
> > The SEGFAULT happens due to the line below:
> > d_point =
On 08/29/2017 11:15 AM, Stefan Ring wrote:
> On Tue, Aug 29, 2017 at 9:32 AM, Martin Liška wrote:
>> On 08/28/2017 09:15 PM, Martin Liška wrote:
>>> On 08/28/2017 04:06 PM, Jeff Law wrote:
On 08/28/2017 01:16 AM, Martin Liška wrote:
> Hello.
>
> I've just repeatedly seen stuck in
On 08/29/2017 12:39 PM, Martin Liška wrote:
> (gdb) bt
> #0 0x3fff950e58e4 in syscall () from /lib64/libc.so.6
> #1 0x3fff94dbbdc4 in __cxxabiv1::__cxa_guard_acquire (g=0x3fff94f26d40
> namespace)::__future_category_instance()::__fec>) at
> ../../../../libstdc++-v3/libsupc++/guard.cc:3
On 2017.08.29 at 12:42 +0200, Martin Liška wrote:
> On 08/29/2017 12:39 PM, Martin Liška wrote:
> > (gdb) bt
> > #0 0x3fff950e58e4 in syscall () from /lib64/libc.so.6
> > #1 0x3fff94dbbdc4 in __cxxabiv1::__cxa_guard_acquire (g=0x3fff94f26d40
> > > namespace)::__future_category_instance(
On 08/29/2017 12:47 PM, Markus Trippelsdorf wrote:
> On 2017.08.29 at 12:42 +0200, Martin Liška wrote:
>> On 08/29/2017 12:39 PM, Martin Liška wrote:
>>> (gdb) bt
>>> #0 0x3fff950e58e4 in syscall () from /lib64/libc.so.6
>>> #1 0x3fff94dbbdc4 in __cxxabiv1::__cxa_guard_acquire (g=0x3fff94
On 2017.08.29 at 12:53 +0200, Martin Liška wrote:
> On 08/29/2017 12:47 PM, Markus Trippelsdorf wrote:
> > On 2017.08.29 at 12:42 +0200, Martin Liška wrote:
> >> On 08/29/2017 12:39 PM, Martin Liška wrote:
> >>> (gdb) bt
> >>> #0 0x3fff950e58e4 in syscall () from /lib64/libc.so.6
> >>> #1 0x0
On 29 August 2017 at 11:38, Marek Polacek wrote:
> On Tue, Aug 29, 2017 at 12:31:39PM +0200, Marco Varlese wrote:
>> Hi,
>>
>> I got a SEGFAULT in my program when compiling it with gcc-7 but it
>> is/was all good when using gcc-6.
>>
>> The SEGFAULT happens due to the line below:
>> d_point = *p;
>
On 08/29/2017 12:55 PM, Markus Trippelsdorf wrote:
> On 2017.08.29 at 12:53 +0200, Martin Liška wrote:
>> On 08/29/2017 12:47 PM, Markus Trippelsdorf wrote:
>>> On 2017.08.29 at 12:42 +0200, Martin Liška wrote:
On 08/29/2017 12:39 PM, Martin Liška wrote:
> (gdb) bt
> #0 0x3fff950e
Hi,
On Mon, 28 Aug 2017, Jeff Law wrote:
> > asm ("" : "=r" (x) : "r" (y+z));
> > asm ("" : "=r" (x) : "r" (z));
> > asm ("" : "=r" (x) : "r" (42));
>
> >
> > (are we still agreeing on this? I'm having a problem understanding why
> > you think the above wouldn't work)
>
> How do we rep
On Mon, Aug 28, 2017 at 05:49:22PM -0600, Jeff Law wrote:
> Going back to pshortis issue, it's interesting how the size of the input
> operand is being used to determine the mode of the matching output
> operand. That ought to be not-too-difficult to find within GCC... With
> any luck there'd be
Been doing stability testing on my x86_64 Ryzen cpu using openSUSE's
(Tumbleweed) "gcc7.1.1 20170802" + compiling Linux kernel source. Every so
often, the build curiously stalls on a futex between cc1 and as. cc1 is on the
futex. as is waiting to read. Could that hang be related to what's be
Hello GCC folks
Please can you add:
UNIX Packages www.unixpackages.com to your list of providers of GCC for
Solaris.
We have been providing pre-compiled GCC for over 20 years, initially as
Sunfreeware and then transitioning to UNIX Packages in 2010.
Many thanks
Colin Prior
UNIX Packages
+1 206
On 2017.08.29 at 15:22 +, Jason Mancini wrote:
> Been doing stability testing on my x86_64 Ryzen cpu using openSUSE's
> (Tumbleweed) "gcc7.1.1 20170802" + compiling Linux kernel source.
> Every so often, the build curiously stalls on a futex between cc1 and
> as. cc1 is on the futex. as is wa
On Tue, Aug 29, 2017 at 6:59 PM, Colin Prior wrote:
> Hello GCC folks
>
> Please can you add:
>
> UNIX Packages www.unixpackages.com to your list of providers of GCC for
> Solaris.
>
> We have been providing pre-compiled GCC for over 20 years, initially as
> Sunfreeware and then transitioning to U
Snapshot gcc-5-20170829 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170829/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
Dear GCC folk,
# Issue Background
We’re investigating an issue with redundant sign-extension instructions being
emitted with the riscv backend. Firstly I would like to state that riscv is
possibly a unique backend with respect to its canonical sign-extended register
form due to the following:
> On 30 Aug 2017, at 12:36 PM, Michael Clark wrote:
>
> Dear GCC folk,
>
>
> # Issue Background
>
> We’re investigating an issue with redundant sign-extension instructions being
> emitted with the riscv backend. Firstly I would like to state that riscv is
> possibly a unique backend with re
22 matches
Mail list logo