rdcoded and quite wrong for big tables...
>
> Also what is the codesize difference on SPEC2006/2017? I don't see
> any mention of performance impact either...
>
> Wilco
--
Regards,
Mikhail Maltsev
rrectly diagnoses both errors. But if I swap these two
functions so that 'bar' comes before 'foo', the error in 'foo' is not diagnosed.
I did not dive into details, but my speculation is that the parser enters some
strange state and skips 'foo' entirely (-f
When parsing SSA names, we should check that parent names are scalars.
In fact, this patch just uses the condition of a 'gcc_assert' in
'make_ssa_name_fn'.
--
Regards,
Mikhail Maltsev
gcc/testsuite/ChangeLog:
2017-05-01 Mikhail Maltsev
* gcc.dg/gimplefe-
This patch deals with invalid __MEM construct. Before we start building an
expression for __MEM, we must check that parsing succeeded and that the __MEM
operand is a pointer.
--
Regards,
Mikhail Maltsev
gcc/c/ChangeLog:
2017-05-01 Mikhail Maltsev
* gimple-parser.c
This is essentially the same problem as in patch 2, but with unary '*'. We
should verify that its argument is a pointer.
--
Regards,
Mikhail Maltsev
gcc/c/ChangeLog:
2017-05-01 Mikhail Maltsev
* gimple-parser.c (c_parser_gimple_unary_expression): Check argument
This bug happens when the LHS of operator '->' is either missing, i.e.:
(->a) = 0;
or it is not a pointer:
int b;
b_2->c = 0;
LHS should be validated.
--
Regards,
Mikhail Maltsev
gcc/testsuite/ChangeLog:
2017-05-01 Mikhail Maltsev
* gcc.dg/gimplefe-
nding code uses 'c_parser_error', but this function does not handle
locations very well (in fact, it uses input_location).
--
Regards,
Mikhail Maltsev
gcc/testsuite/ChangeLog:
2017-05-01 Mikhail Maltsev
* gcc.dg/gimplefe-error-4.c: New test.
* gcc.dg/gimplefe-err
(although, I see some noise in the tree-prof tests). The patches are intended
for GCC 8.
--
Regards,
Mikhail Maltsev
On 05/23/2016 05:15 PM, Kyrill Tkachov wrote:
>
> expand_simple_binop may fail. I think you should add a check that diff_rtx is
> non-NULL
> and bail out early if it is.
>
Fixed.
--
Regards,
Mikhail Maltsev
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index a9c146b..e1473eb 1
This patch adds a new if-conversion pattern for the following case:
if (test) x = A; else x = B;
A and B are constants, abs(A - B) == 2^N, A != 0, B != 0
Bootstrapped and regtested on x86_64-linux. OK for trunk?
--
Regards,
Mikhail Maltsev
gcc/testsuite/ChangeLog:
2016-05-23
nstead and uses it to select the
correct branch. Also, ISTM that the last 'else' branch is unreachable.
Bootstrapped and regtested on x86_64-linux. OK for trunk?
--
Regards,
Mikhail Maltsev
gcc/ChangeLog:
2016-05-23 Mikhail Maltsev
* ifcvt.c (noce_try_store_flag_constan
,
Mikhail Maltsev
On 05/17/2016 06:09 PM, Richard Biener wrote:
>
> The patch is ok.
>
Committed as r236344.
--
Regards,
Mikhail Maltsev
On 05/17/2016 04:39 PM, Richard Biener wrote:
>
> Are you sure narrowing conversions are valid for rotates?
>
> (char)short_var < byte.
>
Yes, but the transformation leaves conversions as-is. Only bit_not is removed.
--
Regards,
Mikhail Maltsev
nts), but I don't think it can currently cause
> issues for these particular transformations.
Fixed.
>
> I don't know if we might want some :c / single_use restrictions, maybe on the
> outer convert and the rshift/rotate.
>
I don't think :c can be used here. As for :s,
On 05/10/2016 10:51 PM, Joseph Myers wrote:
> On Sat, 9 Apr 2016, Mikhail Maltsev wrote:
>
>> gcc/c/ChangeLog:
>>
>> 2016-04-08 Mikhail Maltsev
>>
>> PR c/43651
>> * c-decl.c (declspecs_add_qual): Warn when -Wduplicate-decl-speci
On 05/08/2016 10:57 PM, Marc Glisse wrote:
> On Sun, 8 May 2016, Mikhail Maltsev wrote:
>
>> Hi!
>>
>> I decided to revive this patch:
>> https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00999.html.
>> I addressed review comments about sign conversions. Bootstr
Hi!
I decided to revive this patch:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00999.html.
I addressed review comments about sign conversions. Bootstrapped and regtested
on x86_64-linux-gnu {,-m32}. OK for trunk?
--
Regards,
Mikhail Maltsev
gcc/testsuite/ChangeLog:
2016-05-08 Mikhail
On 04/10/2016 11:12 PM, Martin Sebor wrote:
> On 04/09/2016 06:28 AM, Mikhail Maltsev wrote:
>> On 04/08/2016 08:54 PM, Martin Sebor wrote:
>>>> The name for new option "-Wduplicate-decl-specifier" and wording was
>>>> chosen to match the same option
lete(void*, std::size_t, const std::nothrow_t&);
void operator delete[](void*, std::size_t, const std::nothrow_t&);
IIUC, 'delete(void*, std::size_t)' is used by default in C++14
(https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01266.html). How should we handle
this?
--
Regards,
Mikhail Maltsev
r webpages. Below is a
> draft I came up with. Thoughts?
>
Probably contrib/clang-format and https://gcc.gnu.org/wiki/FormattingCodeForGCC
are also worth mentioning.
--
Regards,
Mikhail Maltsev
ECF_FREE.
Fixed.
--
Regards,
Mikhail Maltsev
diff --git a/gcc/ada/gcc-interface/trans.c b/gcc/ada/gcc-interface/trans.c
index 357d26f..00e4f84 100644
--- a/gcc/ada/gcc-interface/trans.c
+++ b/gcc/ada/gcc-interface/trans.c
@@ -400,7 +400,7 @@ gigi (Node_Id gnat_root,
ftype,
-linux-gnu.
--
Regards,
Mikhail Maltsev
gcc/c/ChangeLog:
2016-04-16 Mikhail Maltsev
* c-decl.c (merge_decls): Handle free_flag.
gcc/ChangeLog:
2016-04-16 Mikhail Maltsev
* builtin-attrs.def: Add attribute free.
* builtins.def (free): Add attribute free
?
>
> Also, in C11 mode, Clang issues the warning for duplicated
> _Atomic qualifiers but it doesn't look like GCC would with
> the patch. Here again, unless there's some reason not to,
> I would expect GCC to issue the same warning as Clang for
> the same code.
>
F
On 04/08/2016 12:50 AM, Joseph Myers wrote:
> New options need documenting in invoke.texi.
>
Done.
--
Regards,
Mikhail Maltsev
gcc/c/ChangeLog:
2016-04-08 Mikhail Maltsev
PR c/43651
* c-decl.c (declspecs_add_qual): Warn when -Wduplicate-decl-specifier
was
chosen to match the same option in Clang.
Bootstrapped and regtested on x86_64-linux. OK for next stage 1?
--
Regards,
Mikhail Maltsev
gcc/c/ChangeLog:
2016-04-04 Mikhail Maltsev
PR c/43651
* c-decl.c (declspecs_add_qual): Warn when
-Wduplicate-decl-specifie
when should we build "co_await p.yield_value(e)"
from it and further expand co_await?
--
Regards,
Mikhail Maltsev
diff --git a/.gitignore b/.gitignore
index c9a6158..4595d5e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -37,6 +37,9 @@ TAGS.sub
.clang-format
+.agignore
+.ycm_extra_
bootstrap-asan".
OK for trunk?
--
Regards,
Mikhail Maltsev
ChangeLog:
2016-01-24 Mikhail Maltsev
PR bootstrap/69329
* Makefile.in: Regenerate.
* Makefile.tpl (BASE_FLAGS_TO_PASS): Add LSAN_OPTIONS.
diff --git a/Makefile.in b/Makefile.in
index 2733c4d..20d1c90
n. Note also that 'style-src'
was not explicitly set, so 'default-src' is used as a fallback."
I think, this can be fixed by replacing 'style="color:red"' with 'class="..."'
and adding the corresponding CSS class to the stylesheet.
--
Regards,
Mikhail Maltsev
o
instrumentation. In just enables consistency checks of the compiler's
internal state, i.e. it is more related to debugging GCC itself.
--
Regards,
Mikhail Maltsev
On 11/24/2015 02:43 AM, Bernd Schmidt wrote:
> On 11/24/2015 12:09 AM, Mikhail Maltsev wrote:
>> The attached patch fixes a problem introduced in r229567: the assertion
>>
>> gcc_assert (is_sse);
>>
>> is checked if flag_checking is false, and this causes an I
Hi!
The attached patch fixes a problem introduced in r229567: the assertion
gcc_assert (is_sse);
is checked if flag_checking is false, and this causes an ICE when compiling with
-fno-checking.
Bootstrapped and regtested on x86_64-pc-linux-gnu. OK for trunk?
--
Regards,
Mikhail Maltsev
the same approach: testcases
are objects which store metainformation (such as name) and have methods
for running tests.
--
Regards,
Mikhail Maltsev
On 11/01/2015 11:34 PM, Bernhard Reutner-Fischer wrote:
> Mikhail,
>
> On November 1, 2015 9:19:19 PM GMT+01:00, Mikhail Maltsev
> wrote:
>> This patch cleans up remaining bits related to ENABLE_CHECKING. After
>> applying
>> this patch (on top of part 9) we will
On 11/03/2015 02:35 AM, Jeff Law wrote:
> This is good fore the trunk too. Please install.
>
> Thanks!
>
> jeff
Committed as r229758.
--
Regards,
Mikhail Maltsev
}
>> }
> I think this condition was reversed, right?
>
> Please fix that and install on the trunk.
>
> Thanks again!
>
> jeff
Fixed and committed as r229756.
--
Regards,
Mikhail Maltsev
-checking=release.
libcpp/ChangeLog:
2015-11-01 Mikhail Maltsev
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Remove ENABLE_CHECKING.
gcc/ChangeLog:
2015-11-01 Mikhail Maltsev
* cfganal.c (inverted_post_order_compute): Remove conditional
ning a second check after rebasing).
OK for trunk?
--
Regards,
Mikhail Maltsev
gcc/c-family/ChangeLog:
2015-10-31 Mikhail Maltsev
* c-omp.c (c_omp_split_clauses): Remove conditional compilation. Use
flag_checking.
gcc/cp/ChangeLog:
2015-10-31 Mikhail Maltsev
al value got from
command-line options).
--
Regards,
Mikhail Maltsev
On 10/26/2015 12:47 PM, Richard Biener wrote:
> I committed the attached to fix build with the valgrind annotations active.
>
> Richard.
>
Doh! Sorry for breakage.
--
Regards,
Mikhail Maltsev
be faster than checking
> flag_checking.
I fixed this and other issues, and committed the attached patch.
--
Regards,
Mikhail Maltsev
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 81d0e1c..d8a22c3 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2015-10-26 Mikhail
it (I would like to hear Jeff's and Richard's opinion).
Of course it will be easy for me to adjust the patch to whatever the
final decision will be.
--
Regards,
Mikhail Maltsev
bcpp/system.h' parts into the first patch of the series. As for
replacing linemap_assert, I hope it can be done separately.
--
Regards,
Mikhail Maltsev
libcpp/ChangeLog:
2015-10-19 Mikhail Maltsev
* include/line-map.h: Use CHECKING_P instead of EN
On 10/06/2015 03:59 PM, Richard Biener wrote:
> On Tue, Oct 6, 2015 at 2:46 PM, Bernd Schmidt wrote:
>> On 10/06/2015 01:39 AM, Mikhail Maltsev wrote:
>>>
>>> void verify_insn_chain (void);
>>> +static inline void checking_verify_insn_chain ();
>>>
On 10/06/2015 03:45 PM, Richard Biener wrote:
> On Tue, Oct 6, 2015 at 2:41 PM, Bernd Schmidt wrote:
>> On 10/06/2015 01:32 AM, Mikhail Maltsev wrote:
>>>
>>> gcc/ChangeLog:
>>>
>>> 2015-10-05 Mikhail Maltsev
>>>
>>>
genextract, and always enable debugging
functions in gengtype.
--
Regards,
Mikhail Maltsev
gcc/ChangeLog:
2015-10-19 Mikhail Maltsev
* genautomata.c: Use CHECKING_P instead of ENABLE_CHECKING.
* genconditions.c: Define CHECKING_P in the generated code.
* ge
ects gengtype's internal debugging option (and is also rather small), I
think it's OK to commit it without approve (as obvious).
Bootstrapped and regtested on x86_64-pc-linux-gnu.
--
Regards,
Mikhail Maltsev
gcc/ChangeLog:
2015-10-18 Mikhail Maltsev
PR other/65800
P.S. I am planning to post at least some of the other updated parts today, and I
also hope to get in time with the whole series (before stage1 ends).
--
Regards,
Mikhail Maltsev
gcc/ChangeLog:
2015-10-18 Mikhail Maltsev
* config.in: Regenerate.
* configure
On 10/06/2015 04:46 PM, Jason Merrill wrote:
> Hi, sorry for the slow response. Please feel free to ping once a week.
>
> On 08/27/2015 02:27 PM, Mikhail Maltsev wrote:
>> + if (TREE_THIS_VOLATILE (t) && (!DECL_P (t) || want_rval))
>
> Why the !DECL_P check
PING.
On 08/27/2015 09:27 PM, Mikhail Maltsev wrote:
> Hi.
> This patch fixes a rejects-valid bug related to volatile-qualified arguments
> of
> constexpr functions. This is essentially a one-line change in constexpr.c.
> Bootstrapped and regtested on x86_64-pc-linux-gnu. OK for
gcc/ChangeLog:
2015-10-05 Mikhail Maltsev
* config/alpha/alpha.c (alpha_function_arg): Use gcc_checking_assert.
* config/arm/arm.c (arm_unwind_emit_sequence): Adjust to use CHECKING_P.
* config/bfin/bfin.c (hwloop_optimize): Likewise.
* config/i386/i386.c
gcc/ChangeLog:
2015-10-05 Mikhail Maltsev
* attribs.c (check_attribute_tables): Define new function.
(init_attributes): Use it.
* cfgcleanup.c (try_optimize_cfg): Use flag_checking.
* cfgexpand.c (expand_goto, expand_debug_expr): Likewise.
(pass_expand
gcc/ChangeLog:
2015-10-05 Mikhail Maltsev
* genautomata.c: Use CHECKING_P instead of ENABLE_CHECKING.
* genconditions.c: Define CHECKING_P in generated code.
* genextract.c: Use CHECKING_P instead of ENABLE_CHECKING.
* gengtype.c (main): Likewise
gcc/ChangeLog:
2015-10-05 Mikhail Maltsev
* alloc-pool.h (base_pool_allocator::initialize, ::allocate,
::remove): Adjust to use CHECKING_P.
>From ed727b2279dd36e2fbf1ab6956270cbd487b1a01 Mon Sep 17 00:00:00 2001
From: Mikhail Maltsev
Date: Sun, 4 Oct 2015 22:50:40 +0
gcc/fortran/ChangeLog:
2015-10-05 Mikhail Maltsev
* trans-common.c (create_common): Adjust to use flag_checking.
* trans.c (gfc_add_modify_loc): Use gcc_checking_assert.
>From 8113b4d5bc943772145abdd6562d4af6093d9718 Mon Sep 17 00:00:00 2001
From: Mikhail Maltsev
Date:
gcc/java/ChangeLog:
2015-10-05 Mikhail Maltsev
* decl.c (java_mark_decl_local): Use flag_checking instead of
ENABLE_CHECKING.
gcc/ada/ChangeLog:
2015-10-05 Mikhail Maltsev
* gcc-interface/decl.c (gnat_to_gnu_entity): Use gcc_checking_assert.
* gcc
libcpp/ChangeLog:
2015-10-05 Mikhail Maltsev
* include/line-map.h: Fix use of ENABLE_CHECKING.
* init.c: Likewise.
* macro.c (struct macro_arg_token_iter, set_arg_token,
macro_arg_token_iter_init, macro_arg_token_iter_forward
es mentioned above) on
x86_64-linux. I'll also run it through config-list.mk.
--
Regards,
Mikhail Maltsev
gcc/ChangeLog:
2015-10-05 Mikhail Maltsev
* common.opt: Add flag_checking.
* system.h (CHECKING_P): Define.
libcpp/ChangeLog:
201
disappear during RT libraries build) with valgrind checks on x86_64-linux.
Markus also helped with valgrind test on ppc64le-linux.
Committed as obvious, r228033.
2015-09-23 Mikhail Maltsev
PR middle-end/67649
* memory-block.h (memory_block_pool::allocate): Use valgrind API to
On 09/10/2015 12:07 AM, Jeff Law wrote:
>> On Mon, Aug 31, 2015 at 7:49 AM, Mikhail Maltsev
>>> In lra.c we have:
>>>
>>> #ifdef ENABLE_CHECKING
>>>
>>> /* Function checks RTL for correctness. If FINAL_P is true, it is
>>>
Ping.
On 08/27/2015 09:27 PM, Mikhail Maltsev wrote:
> Hi.
> This patch fixes a rejects-valid bug related to volatile-qualified arguments
> of
> constexpr functions. This is essentially a one-line change in constexpr.c.
> Bootstrapped and regtested on x86_64-pc-linux-gnu. OK for
the OS (i.e. write
wrappers of mmap/VirtualAlloc) to these files. Of course right now memory-block
makes much more sense.
>
> I think the patch is ok with the above correctness fix and whatever
> choice you take
> for the bikeshedding. Also fixing Richards review comments, of course.
Ping.
On 08/03/2015 11:40 AM, Mikhail Maltsev wrote:
> On Jul 26, 2015, at 11:50 AM, Andi Kleen wrote:
>> I've been compiling gcc with tcmalloc to do a similar speedup. It would be
>> interesting to compare that to your patch.
> I repeated the test with TCMalloc and jemall
Hi.
This patch fixes a rejects-valid bug related to volatile-qualified arguments of
constexpr functions. This is essentially a one-line change in constexpr.c.
Bootstrapped and regtested on x86_64-pc-linux-gnu. OK for trunk?
gcc/cp/ChangeLog:
2015-08-25 Mikhail Maltsev
PR c++/67333
On 08/18/2015 10:00 PM, Jeff Law wrote:
> On 08/14/2015 10:02 PM, Mikhail Maltsev wrote:
>>
>> gcc/ChangeLog:
>>
>> 2015-08-15 Mikhail Maltsev
>>
>> * dominance.c (new_zero_array): Define.
>> (dom_info): Redefine as class wit
a macro gcc_obstack_init, which now uses functions from
virtual-memory.h. Alternatively I could just declare those functions in
coretypes.h. Would that be better?
--
Regards,
Mikhail Maltsev
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index c1cb4ce..1b4198d 100644
--- a/gcc/Makefile.in
+++ b
.
>
By the way, speaking of timevars. I wrote about my concerns w.r.t. them, but did
not get any feedback:
https://gcc.gnu.org/ml/gcc/2015-07/msg00165.html
Briefly speaking, I noticed that our timers introduce rather significant
measurement errors and proposed some ideas about reducing them. Wha
em I see with Richi's idea now that I think about it more is keeping
> that information up-to-date. Ie, if we've stuffed away those pointers, what
> happens if (for example) a block gets deleted from the graph. What if that
> block happens to be the exit block we've r
lace elaborated type specifiers (i.e.
"struct/enum foo") by simple ones (i.e., just "foo") in function prototypes.
Bootstrapped and regtested on x86_64-linux. Tested build of config-list.mk.
gcc/ChangeLog:
2015-08-14 Mikhail Maltsev
* (ENABLE_CHECKING): Def
hink it ever went
>> forward on the gdb side.
I think, a possible solution is to define a macro which expands to "namespace {"
during normal build and expands to nothing in some sort of "debug build" (for
example, when ENABLE_CHECKING is defined).
--
Regards,
Mikhail Maltsev
; sounds like a good idea. Maybe still allow pools to use their own backing if
> the object size is larger than the block size of the caching pool?
Yes, I though about it, but I hesitated, whether this should be implemented in
advance. I attached the updated patch.
--
Regards,
Mikhail M
pools inside gcc::context. Eventually this will be needed for
multi-threaded compilation in GCCJIT (is it planned?).
6. Use ASAN poisoning in pool allocators. Add red zones between allocated
objects when GCC is configured to use ASAN checks.
gcc/ChangeLog:
2015-07-26 Mikhail Maltsev
On 07/17/2015 07:46 PM, Mike Stump wrote:
> On Jul 17, 2015, at 2:28 AM, Mikhail Maltsev wrote:
>> The following code (reduced from wide-int.h) is rejected by Intel C++
>> Compiler (EDG-based):
>
> So, could you test this with the top of the tree compiler and file a bug
>
ed on
x86_64-linux. OK for trunk?
--
Regards,
Mikhail Maltsev
diff --git a/gcc/wide-int.h b/gcc/wide-int.h
index d8f7b46..6e0275f 100644
--- a/gcc/wide-int.h
+++ b/gcc/wide-int.h
@@ -360,21 +360,18 @@ namespace wi
inputs. Note that CONST_PRECISION and VAR_PRECISION cannot be
On 07/14/2015 07:38 PM, Marek Polacek wrote:
> Ok, in that case I think easiest would the following (I hit the same issue
> when writing the -Wtautological-compare patch):
Thanks for taking care of this issue.
--
Regards,
Mikhail Maltsev
On 07/10/2015 11:44 PM, Jeff Law wrote:
>
> OK after regression testing.
>
> jeff
>
Bootstrapped and regtested on x86_64-unknown-linux-gnu. Applied as r225727.
--
Regards,
Mikhail Maltsev
NGLER macro to
cp-demangle.c (it already contains a comment for other similar macros)
and replaced __builtin_abort() with abort(). For some reason I thought
that it might need an additional #include, but in reality libiberty (and
the demangler too) already use abort().
The changelog is also atta
K&R-style definitions there), and it uses (DMGL_PARAMS |
DMGL_ANSI | DMGL_TYPES) by default.
(snip)
> FWIW, demangler.com doesn't give any results for that case. It just returns
> DpDv1_c
But "_Z1fDpDv1_c" makes it crash :)
--
Regards,
Mikhail Maltsev
e about compiler warnings, but AFAIR, in multilib
build libiberty is also built for 32-bit target, and I did not get any
additional warnings.
--
Regards,
Mikhail Maltsev
---
libiberty/cp-demangle.c | 3 +++
libiberty/testsuite/demangle-expected | 12
2 files changed, 15 insertions(+)
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 289a704..4ca285e 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@
---
libiberty/cp-demangle.c | 7 +++
libiberty/testsuite/demangle-expected | 4
2 files changed, 11 insertions(+)
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 424b1c5..289a704 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -324
---
libiberty/cp-demangle.c | 2 ++
libiberty/testsuite/demangle-expected | 4
2 files changed, 6 insertions(+)
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index befa6b6..424b1c5 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -3167,6 +3
---
libiberty/cp-demangle.c | 3 ++-
libiberty/testsuite/demangle-expected | 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 44a0a9b..befa6b6 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle
---
libiberty/cp-demangle.c | 4 +++-
libiberty/testsuite/demangle-expected | 6 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 12093cc..44a0a9b 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-deman
---
libiberty/cp-demangle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 2988b6b..12093cc 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -715,7 +715,7 @@ d_dump (struct demangle_component *dc, int
---
libiberty/cp-demangle.h | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/libiberty/cp-demangle.h b/libiberty/cp-demangle.h
index 6fce025..c37a91f 100644
--- a/libiberty/cp-demangle.h
+++ b/libiberty/cp-demangle.h
@@ -135,12 +135,41 @@ struc
, there are cases when
conversion operator is used as a nested (qualified) name:
_Z1fIN1CcvT_EEvv -> segfault
Presumably this means:
template
void f()
I wonder, if it is possible in valid C++ code?
Notice that the following template instantiation is demangled correctly:
void f()
_Z1fIN1CcviE
AL USE ONLY
$ /opt/intel/bin/icpc -c ./test2.ii
./test2.ii(11): error: declaration is incompatible with function
template "void hash_table>::traverse>(Argument)" (declared at line 4)
void hash_table::traverse(Argument) {}
^
compilation aborted for ./test2.ii (code 2)
--
Regards,
Mikhail Maltsev
B::value>::type
- operator=(Expr); // { dg-message "declared" }
+ operator=(Expr); // { dg-message "private" }
};
void fn1()
{
D opt;
- opt = 0; // { dg-error "private" }
+ opt = 0; // { dg-error "this context" }
}
But I am not sure, what should I do in this case. Maybe it is better to
remove the failing testcase from GCC 5 branch (provided that
inhibit-warn-1.C tests a fix for the same bug and does not fail)?
--
Regards,
Mikhail Maltsev
On 23.06.2015 22:49, Marek Polacek wrote:
> On Sat, Jun 20, 2015 at 03:02:06AM +0300, Mikhail Maltsev wrote:
>> - /* We do not warn for constants because they are typical of macro
>> - expansions that test for features. */
>> - if (CONSTANT_CLASS_P (op_left) || CONST
weird to me: it does not
reimplement the hash function. I.e. the pointer value is used as hash. I
wonder, is it intentional or not? This could actually work if strings
are interned (but in that case there is no need to compare them, because
comparing pointers would be enough).
--
Regards,
Mikhail Maltsev
t on arm-eabi simulator today.
The applied patch is identical to the one I have posted in my original
message, so I'm not repeating it here.
--
Regards,
Mikhail Maltsev
nk.
I see that version 5.2 is set as target milestone for this bug. Should I
backport the patch?
--
Regards,
Mikhail Maltsev
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index eb5e4c5..6656441 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,8 @@
+2015-06-20 Mikhail Maltsev
ux. OK for trunk?
--
Regards,
Mikhail Maltsev
gcc/c-family/ChangeLog:
2015-06-19 Mikhail Maltsev
PR c++/66572
* c-common.c (warn_logical_operator): Treat constant-initialized
VAR_DECLs like literal constants.
gcc/testsuite/ChangeLog:
2015-06-19 Mikhail Maltsev
different
types and tree folding fails (if I change int to long, everything is
OK). Should this be addressed somehow?
3. Do the new patterns require any special handling of nop-conversions?
--
Regards,
Mikhail Maltsev
gcc/ChangeLog:
2015-06-15 Mikhail Maltsev
* match.pd: (~((~
/
For example, this would work if result of gen_* function is passed
directly to some emit_pattern_* function (they can handle NULL pointers).
>> +/* Print out a dummy for generator for instruction NAME with NUM arguments
>> + which either does nothing, or aborts (depending on U
-
Regards,
Mikhail Maltsev
gcc/ChangeLog:
2015-06-14 Mikhail Maltsev
* auto-inc-dec.c (reverse_mem): Remove.
(reverse_inc): Remove.
(parse_add_or_inc): Use std::swap instead of reverse_{mem,inc}.
(find_inc): Likewise.
* combine.c (combine_simplify_rtx
probably some
of them will be fixed in the same way, I propose a patch, which allows
to generate required stubs in genflags.
Bootstrapped and regtested on x86_64-unknown-linux-gnu, testing for full
target list in progress. OK for trunk?
--
Regards,
Mikhail Maltsev
gcc/ChangeLog:
2015-06-10
09.05.2015 1:54, Jeff Law wrote:
> On 05/04/2015 02:18 PM, Mikhail Maltsev wrote:
[snip]
>> I'm trying to continue and the next patch (peep_split.patch,
>> peep_split.cl) is addressing the same task in some of the generated code
>> (namely, gen_peephole2_* and gen_s
tin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect((x), 0)
Is it worth adding them to, say, system.h or ansidecl.h?
--
Regards,
Mikhail Maltsev
1 - 100 of 125 matches
Mail list logo
