On 03/04/2017 09:58 AM, Andre Vehreschild wrote:
> Hi all,
>
> attached patch polishes the one begun by Alessandro. It adds documentation and
> fixes the style issues. Furthermore did I try to interpret the standard
> according to the FAIL IMAGE statement. IMHO should it just quit the executable
>
While creating gcc-8/porting_to.html I noticed the introduction
we've been using is really a bit verbose. This makes it a little
shorter and is aligned with what I put in gcc-8/porting.html.
Committed.
Gerald
Index: gcc-7/porting_to.html
=
Hi Alessandro,
Yes of course. I planned to. Sorry that I forgot.
- Andre
Am 4. März 2017 20:51:58 MEZ schrieb Alessandro Fanfarillo
:
>Hi Andre,
>thanks for your work on the patch. I agree with you about exit(0)
>statement in libcaf_single.
>Could you please add my name and contact (Alessandro
Hi Andre,
thanks for your work on the patch. I agree with you about exit(0)
statement in libcaf_single.
Could you please add my name and contact (Alessandro Fanfarillo
) below yours in the changelog?
Thanks,
Alessandro
2017-03-04 10:58 GMT-07:00 Andre Vehreschild :
> Hi all,
>
> attached patch p
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators. The file is available at:
http://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-7.1-b20170226.fr.po', h
Hi all,
attached patch polishes the one begun by Alessandro. It adds documentation and
fixes the style issues. Furthermore did I try to interpret the standard
according to the FAIL IMAGE statement. IMHO should it just quit the executable
without any error code. The caf_single library emits "FAIL I
On Tue, 24 May 2016, Richard Biener wrote:
> Can we update to a non-marketing name then, like i586-unknown-freebsd
> please? config.gcc accepts i[34567]86-*-freebsd*. It at least confused
> me.
Of course, once I hacked config.gcc, I realized that the simple
patch below is all you actually may h
On Tue, 24 May 2016, Richard Biener wrote:
>> As Jeff noted, i386 actually is the "marketing" name used for the
>> platform, GCC has been defaulting to i486 for ages, and I upgraded
>> to i586 last year:
>>
>> 2015-11-15 Gerald Pfeifer
>>
>> * config/i386/freebsd.h (SUBTARGET32_DEFAU
On Tue, 28 Feb 2017, Jan Hubicka wrote:
>> And one question: "declaration linking" is used in the description
>> of Link-time optimization improvements, alas that string does not
>> appear anywhere in either the source tree or documentation?
> It is my own name indeed. lto-symtab.c does merge decl
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-7.1-b20170226.de.po', h
On Thu, 2 Mar 2017, Thomas Preudhomme wrote:
>> This should be mentioned in the "porting to" page when it eventually
>> goes in, as it may be surprising behavior.
> Will do once the file is created for gcc-8. Thanks for the suggestion
Here we go. :-) Applied.
Gerald
Index: porting_to.html
There should be a space after the semicolon.
Bootstrapped/regtested on x86_64-linux, applying to trunk.
2017-03-04 Marek Polacek
PR c/79847
* c-decl.c (implicit_decl_warning): Add missing space.
diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index f46ca11..645304a 100644
--- gcc/c/
On Fri, Mar 3, 2017 at 8:44 PM, Jakub Jelinek wrote:
> On Fri, Mar 03, 2017 at 12:18:09PM +0100, Uros Bizjak wrote:
>> Yes. Although expander takes care not to generate two memory
>> references, combine can propagate memory to the other operand,
>> creating semi-invalid RTX that is later resolved
In committee review of the rule to restore effective hiding in
overload resolution between a base constructor with a default argument
and a derived constructor without, it was observed that what we were
doing doesn't properly handle the case where both constructors are
from bases, just one more der
Along with the C++17 change to make noexcept part of the type I added
a warning for situations where this changes the mangled name of a
symbol, as part of -Wc++1z-compat. This is troublesome since there's
no way to adjust your code to avoid it, so this patch gives it a
separate flag.
Tested x86_6
15 matches
Mail list logo