On Tue, Aug 15, 2017 at 03:09:15PM +0800, Liu Hao wrote:
> On 2017/8/14 20:41, Alan Modra wrote:
> >On Sun, Aug 13, 2017 at 10:25:14PM +0930, Alan Modra wrote:
> >>On Sun, Aug 13, 2017 at 03:35:15AM -0700, David Wohlferd wrote:
> >>>Using "m"(*pStr) as an (unused) input parameter has no effect.
> >
On Wed, Aug 16, 2017 at 7:30 AM, David Miller wrote:
> From: Anatoly Pugachev
> Date: Tue, 15 Aug 2017 21:50:45 +0300
>
>> Together with Dmitry (ldv) , we've discovered that running test suite
>> from strace produces kernel OOPS, when kernel is compiled with gcc 7.1
>> or with gcc 7.2 , but not w
nerate_lto before lto_streamer_hooks_init.
...
why GCC v4.6 is still able to work
https://github.com/xiangzhai/dragonegg/blob/master/src/Backend.cpp#L1939
but GCC v6.x or v8.x (git-20170816) couldn't, please give me some hint
about the difference between GCC v4.6's LTO and GCC v6.
c_XXX for GCC v6.x or v8.x
(git-20170816), for example: struct GTY((for_user)) tree2WeakVH
https://github.com/xiangzhai/dragonegg/blob/master/include/dragonegg/gt-cache-8.0.inc#L1284
As ChangeLog-2014 mentioned:
2014-05-17 Trevor Saunders
...
(ggc_alloc): Install the type's destruc
When compiling the following code:
int* ptr = nullptr;
delete ptr;
GCC 7.1 on x86_64 generates a delete-operator-related call instruction in the
resulting program with both -O2 and -O3 optimization flags. This is a nonsense
piece of code, indeed, but imagine a class that has an owning raw poin
On Wed, Aug 16, 2017 at 12:09 PM, Daniel Langr wrote:
> When compiling the following code:
>
> int* ptr = nullptr;
> delete ptr;
>
> GCC 7.1 on x86_64 generates a delete-operator-related call instruction in
> the resulting program with both -O2 and -O3 optimization flags. This is a
> nonsense piec
Hi,
On 16/08/2017 12:09, Daniel Langr wrote:
When compiling the following code:
int* ptr = nullptr;
delete ptr;
I didn't understand why we don't already handle the easy case:
constexpr int* ptr = nullptr;
delete ptr;
and the below tiny front-end tweak would take care of it. But I'm not
sure
include/dragonegg/gt-cache-4.6.inc#L24
>
> but gengtype will not auto-generate ggc_alloc_XXX for GCC v6.x or v8.x
> (git-20170816), for example: struct GTY((for_user)) tree2WeakVH
> https://github.com/xiangzhai/dragonegg/blob/master/include/dragonegg/gt-cache-8.0.inc#L1284
>
> As
On Wed, Aug 16, 2017 at 11:42 AM, Anatoly Pugachev wrote:
> On Wed, Aug 16, 2017 at 7:30 AM, David Miller wrote:
>> From: Anatoly Pugachev
>> Date: Tue, 15 Aug 2017 21:50:45 +0300
>>
>>> Together with Dmitry (ldv) , we've discovered that running test suite
>>> from strace produces kernel OOPS, w
Hello.
Just small note, link to Nathan's patch that has been recently accepted:
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00878.html
Which provides info about process termination.
Martin
On 31.07.2017 19:54, Jeff Law wrote:
On 07/31/2017 11:23 AM, Segher Boessenkool wrote:
On Tue, Aug 01, 2017 at 01:12:41AM +0900, Oleg Endo wrote:
I could probably write a similar rant. This is the life of a "minority
target programmer". Most development efforts are being done with
primary tar
> Just the fact that the backends that get most attention and attract
> most developers don't use cc0 doesn't mean cc0 is a useless device.
Everything that can be done with cc0 can be done with the new representation,
at least theoritically, although this can require more work.
> As far as cc0 i
On Wed, 2017-08-16 at 15:53 +0200, Georg-Johann Lay wrote:
>
> This means it's actually waste of time to work on these
> backends. The code will finally end up in the dustbin as cc0
> backends are considered undesired ballast that has to be
> "jettisoned".
>
> "Deprecate all cc0" is just a nice
On Wed, 2017-08-16 at 13:30 +0200, Paolo Carlini wrote:
>
> I didn't understand why we don't already handle the easy case:
>
> constexpr int* ptr = nullptr;
> delete ptr;
>
What about overriding the global delete operator with some user defined
implementation? Is there something in the C++ sta
On 16 August 2017 at 15:27, Oleg Endo wrote:
> On Wed, 2017-08-16 at 13:30 +0200, Paolo Carlini wrote:
>>
>> I didn't understand why we don't already handle the easy case:
>>
>> constexpr int* ptr = nullptr;
>> delete ptr;
>>
>
> What about overriding the global delete operator with some user defin
On 16 August 2017 at 15:40, Jonathan Wakely wrote:
> On 16 August 2017 at 15:27, Oleg Endo wrote:
>> On Wed, 2017-08-16 at 13:30 +0200, Paolo Carlini wrote:
>>>
>>> I didn't understand why we don't already handle the easy case:
>>>
>>> constexpr int* ptr = nullptr;
>>> delete ptr;
>>>
>>
>> What ab
Is there a setup for writing and running as part of the test
suite unit tests that exercise internal GCC functions like
error and warning? I ask because of a couple of bugs that
were recently reported for the %s directive in GCC's
diagnostics (81859 and 81586) that were only caught by running
val
On Wed, Aug 16, 2017 at 08:46:20AM -0600, Martin Sebor wrote:
> Is there a setup for writing and running as part of the test
> suite unit tests that exercise internal GCC functions like
> error and warning? I ask because of a couple of bugs that
> were recently reported for the %s directive in GCC
On 8/15/17, Jonathan Wakely wrote:
> On 15 August 2017 at 04:10, Martin Sebor wrote:
>> On 08/14/2017 04:22 PM, Eric Gallager wrote:
>>>
>>> I'm emailing this manually to the list because Bugzilla is down and I
>>> can't file a bug on Bugzilla about Bugzilla being down. The error
>>> message looks
On 08/16/2017 08:14 AM, Eric Botcazou wrote:
>> Just the fact that the backends that get most attention and attract
>> most developers don't use cc0 doesn't mean cc0 is a useless device.
>
> Everything that can be done with cc0 can be done with the new representation,
> at least theoritically, al
On Wed, 2017-08-16 at 16:51 +0200, Marek Polacek wrote:
> On Wed, Aug 16, 2017 at 08:46:20AM -0600, Martin Sebor wrote:
> > Is there a setup for writing and running as part of the test
> > suite unit tests that exercise internal GCC functions like
> > error and warning? I ask because of a couple o
On 08/16/2017 08:44 AM, Jonathan Wakely wrote:
> On 16 August 2017 at 15:40, Jonathan Wakely wrote:
>> On 16 August 2017 at 15:27, Oleg Endo wrote:
>>> On Wed, 2017-08-16 at 13:30 +0200, Paolo Carlini wrote:
I didn't understand why we don't already handle the easy case:
constexp
On 08/16/2017 09:20 AM, David Malcolm wrote:
On Wed, 2017-08-16 at 16:51 +0200, Marek Polacek wrote:
On Wed, Aug 16, 2017 at 08:46:20AM -0600, Martin Sebor wrote:
Is there a setup for writing and running as part of the test
suite unit tests that exercise internal GCC functions like
error and wa
From: Anatoly Pugachev
Date: Wed, 16 Aug 2017 11:42:43 +0300
> On Wed, Aug 16, 2017 at 7:30 AM, David Miller wrote:
>> From: Anatoly Pugachev
>> Date: Tue, 15 Aug 2017 21:50:45 +0300
>>
>>> Together with Dmitry (ldv) , we've discovered that running test suite
>>> from strace produces kernel OOP
On Mon, Aug 14, 2017 at 11:10 PM, Martin Sebor wrote:
> On 08/14/2017 04:22 PM, Eric Gallager wrote:
>>
>> I'm emailing this manually to the list because Bugzilla is down and I
>> can't file a bug on Bugzilla about Bugzilla being down. The error
>> message looks like this:
>
> Bugzilla and the res
On Wed, 16 Aug 2017, Eric Gallager wrote:
> I see Richi redid all his 7.2 release changes; does that imply that
> the server restore is now complete?
No, there's still a search process ongoing to identify corrupted or
missing files by comparison with the last backup.
My expectation is that all
On Wed, 16 Aug 2017, NightStrike wrote:
> On Mon, Aug 14, 2017 at 11:10 PM, Martin Sebor wrote:
> > On 08/14/2017 04:22 PM, Eric Gallager wrote:
> >>
> >> I'm emailing this manually to the list because Bugzilla is down and I
> >> can't file a bug on Bugzilla about Bugzilla being down. The error
>
On Tue, Aug 15, 2017 at 5:43 PM, Daniel Santos wrote:
> On 08/15/2017 06:18 AM, Richard Biener wrote:
>> On Mon, Aug 14, 2017 at 5:23 PM, H.J. Lu wrote:
>>> For GCC 8, when --enable-checking=yes,rtl is used with x32 GCC,
>>> I got
>>>
>>> cc1plus: out of memory allocating 56137200 bytes after a t
Hello,
I have no problem working GnuPG. However, files on ftp://ftp.gnu.org
are signed by individuals, at least for the projects I am interested
in (binutils, gcc, gdb). Where might I find a GNU's endorsement of the
signers?
I started another thread about a related issue, my apologies if I
should
On Wed, Aug 16, 2017 at 3:53 PM, R0b0t1 wrote:
> Hello,
>
> I have no problem working GnuPG. However, files on ftp://ftp.gnu.org
> are signed by individuals, at least for the projects I am interested
> in (binutils, gcc, gdb). Where might I find a GNU's endorsement of the
> signers?
>
> I started
On Wed, Aug 16, 2017 at 03:53:24PM +0200, Georg-Johann Lay wrote:
> This means it's actually waste of time to work on these backends. The
> code will finally end up in the dustbin as cc0 backends are considered
> undesired ballast that has to be "jettisoned".
>
> "Deprecate all cc0" is just a nic
Hi,
Is there any reason for 3 loads being issued for these bitfield accesses, given
two of the loads are bytes, and one is a half; the compiler appears to know the
structure is aligned at a half word boundary. Secondly, the riscv code is using
a mixture of 32-bit and 64-bit adds and shifts. Thi
Here’s a more extreme example:
- https://cx.rv8.io/g/2HWQje
The bitfield type is unsigned int, so one or two 32-bit loads should suffice
(depending on register pressure). GCC is issuing a lw at some point in the asm.
struct foo {
unsigned int a : 3;
unsigned int b : 3;
unsigned int c : 3;
On Wed, Aug 16, 2017 at 3:29 PM, Michael Clark wrote:
> Hi,
>
> Is there any reason for 3 loads being issued for these bitfield accesses,
> given two of the loads are bytes, and one is a half; the compiler appears to
> know the structure is aligned at a half word boundary. Secondly, the riscv
>
Snapshot gcc-6-20170816 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20170816/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6
> On 17 Aug 2017, at 10:41 AM, Andrew Pinski wrote:
>
> On Wed, Aug 16, 2017 at 3:29 PM, Michael Clark wrote:
>> Hi,
>>
>> Is there any reason for 3 loads being issued for these bitfield accesses,
>> given two of the loads are bytes, and one is a half; the compiler appears to
>> know the str
When implementing the RISC-V port, I took the name of this macro at
face value. It does seem that we should follow Andrew's advice and
set it to 1. (For your examples, doing so does improve code
generation.)
We'll submit a patch if the change doesn't regress.
On Wed, Aug 16, 2017 at 4:00 PM, Mi
On Wed, Aug 16, 2017 at 11:23:27PM +0900, Oleg Endo wrote:
> > First of all, LRA cannot cope with cc0 (Yes, I know deprecating
> > cc0 is just to deprecate all non-LRA BEs). LRA asserts that
> > accessing the frame doesn't change condition code. LRA doesn't
> > provide replacement for LEGITIMITE_R
H for tree2WeakVH
https://github.com/xiangzhai/dragonegg/blob/master/include/dragonegg/gt-cache-4.6.inc#L24
but gengtype will not auto-generate ggc_alloc_XXX for GCC v6.x or v8.x
(git-20170816), for example: struct GTY((for_user)) tree2WeakVH
https://github.com/xiangzhai/dragonegg/blob/master/include/drag
After downloading and verifying the releases on
ftp://ftp.gnu.org/gnu/, I found that the maintainers used 1024 bit DSA
keys with SHA1 content digests. 1024 bit keys are considered to be
susceptible to realistic attacks, and SHA1 has been considered broken
for some time.
http://nvlpubs.nist.gov/nis
> The GNU Compiler Collection version 7.2 has been released.
Shouldn't the release have a tag on git?
It doesn't seem to be there: https://gcc.gnu.org/git/?p=gcc.git;a=tags
git tag gcc-7_2_0-release 1bd23ca8c30f4827c4bea23deedf7ca33a86ffb5
BR, Klaus
>
> GCC 7.2 is a bug-fix release from th
41 matches
Mail list logo
