Hi,
this is a variant of patch that globs also the rest of integer types.
Note that we will still get false warnings out of lto-symtab when the
values are not wrapped up in structures. This is because lto-symtab
uses types_compatible_p that in turn uses useless_type_conversion and
that one needs t
> Hi,
> this patchs makes fortran's C_SIGNED_CHAR and C_SIZE_T interoperable with
> signed char and size_t as standard require. There are two issues here.
>
> First Fortran integers are always signed, but the standard insist on the
> signed integer to match C size_t that is unsigned (if it was p
Hi,
while preparing the fortran testcases I noticed that warn_types_mismatch
generally ICEs on non-C++ types because these have IDENTIFIER_NODE in TYPE_NAME
while C++ FE uses TYPE_DECL.
warn_types_mismatch was not exactly written with non-C++ types in mind. This
patch should fix the ICEs and it al
Hi,
currently we stream BUILTINS_LOCATION by expanding it and streaming resulting
filename/line/col tripplet. That is a nonsense and breaks some logic
that special case it.
This patch fixes it by special casing it same way as we do UNKNOWN_LOCATION
(we have precisely 2 special location codes, so
On 06/07/2015 02:33 PM, Richard Biener wrote:
On June 7, 2015 6:00:05 PM GMT+02:00, Aldy Hernandez wrote:
On 06/07/2015 11:25 AM, Richard Biener wrote:
On June 7, 2015 5:03:30 PM GMT+02:00, Aldy Hernandez
wrote:
On 06/06/2015 05:49 AM, Andreas Schwab wrote:
Bootstrap fails on aarch64:
Com
Hi,
this patchs makes fortran's C_SIGNED_CHAR and C_SIZE_T interoperable with
signed char and size_t as standard require. There are two issues here.
First Fortran integers are always signed, but the standard insist on the
signed integer to match C size_t that is unsigned (if it was ptrdiff_t, we
The new heuristic turns out to trigger a common false positive (see test
case below) in many programs. I have applied this diff on top of the
original patch to make the heuristic more strict.
diff --git a/gcc/c-family/c-indentation.c b/gcc/c-family/c-indentation.c
index d3e842b..5532ff4 100644
-
Hi,
this is variant of patch I ended up comitting.
Tobias: I would still welcome a final word about validity of my fortran
testcase.
The original version run into checking failures with nested functions
tranpolines because we now all pointers have the same TYPE_CANONICAL that makes
useless_type_c
Fixed fortran mail-list address. Sorry for inconvenience.
08.06.2015, 00:01, "Ilmir Usmanov" :
> Hi Cesar!
>
> This patch fixes checks of OpenMP and OpenACC continuations in case if
> someone mixes them (i.e. continues OpenMP directive with !$ACC sentinel or
> vice versa).
>
> OK for gomp branch
Hi Cesar!
This patch fixes checks of OpenMP and OpenACC continuations in case if someone
mixes them (i.e. continues OpenMP directive with !$ACC sentinel or vice versa).
OK for gomp branch?
--
Ilmir.
From 5492bf5bc991b6924f5e3b35c11eeaed745df073 Mon Sep 17 00:00:00 2001
From: Ilmir Usmanov
Date
This patch refactors the entry point of -Wmisleading-indentation from:
void
warn_for_misleading_indentation (location_t guard_loc,
location_t body_loc,
location_t next_stmt_loc,
enum cpp_tt
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 Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-5.1.0.sv.po', has just
Aldy Hernandez writes:
> check_global_declarations is called for more symbols now. All the defined
> but not used errors I've seen in development have been legitimate. For
> tests, the tests should be fixed. For built-ins such as these, does the
> attached fix the problem?
Yes, it does.
Andr
On 06/07/2015 06:19 AM, Andreas Schwab wrote:
Another fallout:
FAIL: obj-c++.dg/try-catch-5.mm -fgnu-runtime (test for excess errors)
Excess errors:
: warning: '_OBJC_Module' defined but not used [-Wunused-variable]
check_global_declarations is called for more symbols now. All the
defined bu
On 7 June 2015 at 11:33, Ville Voutilainen wrote:
>>> You use a lot: typename enable_if::type=true
>>> while the current code seems to favor: class=typename enable_if::type.
>>> I don't really care which one is used, but it is easier to read when the
>>> style is consistent through the library.
>>
On Sun, 7 Jun 2015, Ville Voutilainen wrote:
On 7 June 2015 at 11:12, Ville Voutilainen wrote:
Does the following code still compile with your patch?
struct A { int a,b; };
std::tuple a(3,4,{1,2});
No. :/ And we have no test for it.. I'll need to look at that.
Ahem, yes, this is because th
On 7 June 2015 at 11:12, Ville Voutilainen wrote:
>> Does the following code still compile with your patch?
>> struct A { int a,b; };
>> std::tuple a(3,4,{1,2});
>
> No. :/ And we have no test for it.. I'll need to look at that.
Ahem, yes, this is because the constructor that used to take _Elemen
On 7 June 2015 at 09:53, Marc Glisse wrote:
> Since the paper does not mention looking at _MoveConstructibleTuple or
> _ImplicitlyMoveConvertibleTuple here, could you add a comment explaining
> why that is needed?
Sure.
> Does the following code still compile with your patch?
> struct A { int a,
18 matches
Mail list logo
