We reset safe iterator state a lot, quite annoying when debugging.
Comitted as trivial.
2018-06-07 François Dumont
* src/c++11/debug.cc
(_Safe_iterator_base::_M_detach()): Reset state only if needed.
(_Safe_iterator_base::_M_detach_single()): Likewise.
(_Safe_local_iterator_b
On 06/06/2018 03:25 PM, David Edelsohn wrote:
> Thanks for both patches. GCC bootstrap on AIX is progressing much
> better with the patches installed.
>
> Thanks, David
Thanks David for testing, I've just installed both patches.
Martin
| Hi dear customer,
Have a great day. My name is Peter.
We are the facotory in China, produce stone abrasive and diamond tools.
Our main products as below:
1. Cutting tools.
2. Grinding & polishing tools.
3. Other tools to process stone, concrete, ceramics etc.
We also can make tools as your
GCC Maintainers:
This patch adds various missing test cases for a few builtins. It also
fixes the arguments to match the builtin specifications in the ABI.
The patch was retested on:
powerpc64le-unknown-linux-gnu (Power 8 LE)
powerpc64le-unknown-linux-gnu (Power 9 LE)
powerpc64-u
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Esperanto team of translators. The file is available at:
http://translationproject.org/latest/cpplib/eo.po
(This file, 'cpplib-8.1-b201801
cpplib-8.1-b20180128.eo.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Segher:
> > > > rtx tmp = gen_reg_rtx (SImode);
> > > > - emit_insn (gen_vctzlsbb_ (tmp, result));
> > > > + if (!BYTES_BIG_ENDIAN)
> > > > +emit_insn (gen_vctzlsbb_ (tmp, result));
> > > > + else
> > > > +emit_insn (gen_vclzlsbb_ (tmp, result));
> > > >
On Wed, Jun 06, 2018 at 03:30:17PM -0700, Carl Love wrote:
> > One thing that caught my eye, nothing new though:
> >
> > > {
> > > rtx tmp = gen_reg_rtx (SImode);
> > > - emit_insn (gen_vctzlsbb_ (tmp, result));
> > > + if (!BYTES_BIG_ENDIAN)
> > > +emit_insn (gen_vct
That's fine too, I was thinking of checking mcu_name[i] against NUL.
Any of those solutions would work :-)
Segher:
> > * gcc/config/rs6000/vsx.md (first_match_index_):
> > Calculate index using natureal element order.
>
> Typo ("natural"). You normally shouldn't do a line break after :
> btw.
>
Fixed both issues.
> One thing that caught my eye, nothing new though:
>
> > {
> >
On Wed, Jun 06, 2018 at 02:52:27PM -0500, Segher Boessenkool wrote:
> On Tue, Jun 05, 2018 at 07:11:41PM -0400, Michael Meissner wrote:
> > This patch makes the long double pack/unpack built-in functions only
> > available
> > if the long double format is IBM extended double.
> >
> > I added new
On 06/06/18 22:02, DJ Delorie wrote:
Jozef Lawrynowicz writes:
- for (i = start_upper; i < strlen (mcu_name); i++)
+ for (i = start_upper; i < strlen (mcu_name) - 2; i++)
Might be faster to test mcu_name[i] instead of calling strlen repeatedly
too, but this only runs once per invocat
Hello world,
I have just committed the attached patch as obvious after
regression-testing.
Since this fixes a regression, I will backport to gcc8 and gcc7 in
the next days.
Regards
Thomas
2018-06-06 Thomas Koenig
PR fortran/85641
* frontend-passes.c (is_fe_temp): A
We crash on this testcase containing a bogus attribute, because
cp_check_const_attributes accessed TREE_VALUE of a tree that happened to be
expr_pack_expansion. Since here we're merely trying to evaluate constexpr
arguments, I thought we could skip such bogus arguments.
Bootstrapped/regtested on
Jozef Lawrynowicz writes:
> - for (i = start_upper; i < strlen (mcu_name); i++)
> + for (i = start_upper; i < strlen (mcu_name) - 2; i++)
Might be faster to test mcu_name[i] instead of calling strlen repeatedly
too, but this only runs once per invocation ;-)
On 06/06/18 21:38, DJ Delorie wrote:
+ snprintf (mcu_name, sizeof (mcu_name) - 1, "__%s__", target_mcu);
+ start_upper = 0;
Can optimize this to 2 :-)
Otherwise OK.
Ah yes. Could also do:
- for (i = start_upper; i < strlen (mcu_name); i++)
+ for (i = start_upper; i
Richard Biener writes:
> On Tue, 5 Jun 2018, Richard Biener wrote:
>
>>
>> This is a prototype enforcing is_gimple_val conditions in
>> [VEC_]COND_EXPRs. It shows quite some fallout - some likely
>> due to necessary testsuite adjustments like gcc.dg/tree-ssa/ssa-lim-12.c
>> others because some
On Wed, Jun 06, 2018 at 10:07:23AM -0700, Carl Love wrote:
> The following patch moves the tests from builtins-3.c that require the
> -mvsx" command line option to the new test file builtins-4.c. The
> tests that are left in file builtins-3.c require just the -maltivec
> option.
> --- /dev/null
On Wed, Jun 06, 2018 at 08:29:47AM -0700, Carl Love wrote:
> 2018-06-06 Carl Love
> * gcc.target/powerpc/builtins-7-p9-runnable.c: Change first
> argument to vui_arg.
This is fine, please go ahead. Thanks!
Segher
On Wed, Jun 06, 2018 at 08:01:22AM -0700, Carl Love wrote:
> 2018-06-04 Carl Love
>
> * gcc/config/rs6000/vsx.md (first_match_index_):
> Calculate index using natureal element order.
Typo ("natural"). You normally shouldn't do a line break after : btw.
One thing that caught my ey
> + snprintf (mcu_name, sizeof (mcu_name) - 1, "__%s__", target_mcu);
> + start_upper = 0;
Can optimize this to 2 :-)
Otherwise OK.
> On Thu, May 24, 2018 at 11:36 AM Richard Sandiford
> wrote:
>>
>> This patch adds match.pd support for applying normal folds to their
>> IFN_COND_* forms. E.g. the rule:
>>
>> (plus @0 (negate @1)) -> (minus @0 @1)
>>
>> also allows the fold:
>>
>> (IFN_COND_ADD @0 @1 (negate @2) @3) -> (IF
On Tue, Jun 05, 2018 at 10:03:46PM -0500, Peter Bergner wrote:
> On 6/5/18 3:22 PM, Segher Boessenkool wrote:
> > Ah, that's the crux. Thanks. Add a comment to the code please?
>
> Like so? I tried placing it next to the mcpu=power8 clause, but it seems
> you cannot place comments there, as it
On Tue, Jun 05, 2018 at 07:11:41PM -0400, Michael Meissner wrote:
> This patch makes the long double pack/unpack built-in functions only available
> if the long double format is IBM extended double.
>
> I added new pack and unpack functions that use __ibm128 instead of long double
> in case somebo
This parameter is a reference-to-const so moving it doesn't do
anything. Allocators should be cheap to copy anyway.
* include/bits/shared_ptr_base.h (__shared_count): Remove redundant
move of const value.
Tested powerpc64le-linux, committed to trunk.
commit 11b524858a52ef3f22b5
Hi Steve,
The attached patch re-arranges the code in gfc_simply_mod().
This allows gfortran to test if the 2nd argument is zero.
Tested on i586-*-freebsd and x86_64-*-freebsd. OK to commit?
OK.
Thanks for the patch!
Regards
Thomas
This adds support for interrupt attributes to be used for user-level and
supervisor-level delegated interrupts by adding an argument that allows one
to specify the privilege level (aka mode). This also adds some testcases
and documentation updates for the new feature.
This was tested with riscv32
On 06/06/18 17:43, DJ Delorie wrote:
Jozef Lawrynowicz writes:
Word from TI is that the lowercase i is an exception, the rule is to have all
uppercase letters. No further msp430i devices are planned so the rules for
generating device names in this patch shouldn't need any future changes.
So a
On 6/6/18 1:23 PM, Paul Koning wrote:
>> On Jun 6, 2018, at 11:53 AM, Eric Botcazou wrote:
>> I would suggest using "diff -up" to generate patches with more context.
>
> Yes, sorry. I normally use the subversion internal diff which doesn't do
> this.
If you edit ~/.subversion/config and use th
> On Jun 6, 2018, at 11:53 AM, Eric Botcazou wrote:
>
>> That simplifies the patch, which now looks like this. Ok for trunk?
>>
>> paul
>>
>> gcc/ChangeLog:
>>
>> 2018-06-05 Paul Koning
>>
>> * compare-elim.c (try_merge_compare): Don't merge compare if
>> address contain
If we're going to allow it with a pedwarn, we shouldn't clobber the
decl with an error_mark_node.
Tested x86_64-pc-linux-gnu, applying to trunk and 8.
commit ee298d715781a806980f93348ba1b0afd62187db
Author: Jason Merrill
Date: Wed Jun 6 17:21:42 2018 +0200
PR c++/86060 - ICE on ran
On Wed, Jun 6, 2018 at 3:41 PM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, the current __cpp_transactional_memory macro
> value with -fgnu-tm is clearly bogus, what will be standardized in 2105
> is unknown.
>
> The big question is if we should go with the value that was meant to be us
OK.
On Wed, Jun 6, 2018 at 7:28 PM, Marek Polacek wrote:
> On Wed, Jun 06, 2018 at 06:22:16PM +0200, Jason Merrill wrote:
>> Right, you want to test conversion to the element type, not the array or
>> init list type.
>
> Indeed. Please tell me this is the right approach :).
>
> Bootstrapped/regt
For the dg-{warning,error,message,bogus} directives, a value of 0 for the line
argument can be passed to specify that the message is not associated with any
line. This patch documents that in the Directives section of the
documentation.
Ok for trunk?
>From d08160770abef420b6699f6bd2c30a055bd1035
Hi Mike,
On Tue, Jun 05, 2018 at 06:47:52PM -0400, Michael Meissner wrote:
> With this fix, the compiler no longer raises an internal error if you use
> explicit overloading of __ibm128 and long double. Instead it generates the
> expected error:
>
> foo01.C:33:15: error: 'bool foo::iszero(long d
On Wed, Jun 06, 2018 at 06:22:16PM +0200, Jason Merrill wrote:
> Right, you want to test conversion to the element type, not the array or
> init list type.
Indeed. Please tell me this is the right approach :).
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-06-06 Marek Polacek
On 6/5/18, David Edelsohn wrote:
> Martin,
>
> With your recent patch, I receive the following failure building
> libgcov-driver-system.c
>
> In file included from
> /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver.c:322:0:
> /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver-system.c: I
This is a respin of a AArch64 patch that adds support for builtin arithmetic
overflow operations. This update separates the patch into multiple pieces and
addresses comments made by Richard Earnshaw here:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00249.html
Original patch and motivation for
This is a respin of a AArch64 patch that adds support for builtin arithmetic
overflow operations. This update separates the patch into multiple pieces and
addresses comments made by Richard Earnshaw here:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00249.html
Original patch and motivation for
This is a respin of a AArch64 patch that adds support for builtin arithmetic
overflow operations. This update separates the patch into multiple pieces and
addresses comments made by Richard Earnshaw here:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00249.html
Original patch and motivation for
This is a respin of a AArch64 patch that adds support for builtin arithmetic
overflow operations. This update separates the patch into multiple pieces and
addresses comments made by Richard Earnshaw here:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00249.html
Original patch and motivation for
GCC Maintainers:
The builtins-3.c test fails on Power 6 since -mvsx is not enabled with
the -maltivec option.
The following patch moves the tests from builtins-3.c that require the
-mvsx" command line option to the new test file builtins-4.c. The
tests that are left in file builtins-3.c requi
Jozef Lawrynowicz writes:
> Word from TI is that the lowercase i is an exception, the rule is to have all
> uppercase letters. No further msp430i devices are planned so the rules for
> generating device names in this patch shouldn't need any future changes.
So a future-proof patch would TOUPPER
Hi!
On Tue, Jun 05, 2018 at 02:02:05PM -0400, Michael Meissner wrote:
> I tested this on a little endian power8 system running Linux. There were no
> regressions. Can I install this in the trunk and eventually back port it to
> GCC 8.2?
Please test on a BE system as well? And maybe on a p9? I
Hi
I review and rework this proposal. I noticed that the same idea to
limit buffer size within inplace_merge also apply to stable_sort.
I also change the decision when buffer is too small to consider the
buffer size rather than going through successive cuts of the original
ranges. Th
On Wed, Jun 6, 2018, 4:43 PM Marek Polacek wrote:
> On Fri, Jun 01, 2018 at 12:39:08PM -0400, Jason Merrill wrote:
> > Yes, we still need to do deduction on the array bound, so we can't
> > return immediately. We just want to avoid the
> >
> > FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (
> That simplifies the patch, which now looks like this. Ok for trunk?
>
> paul
>
> gcc/ChangeLog:
>
> 2018-06-05 Paul Koning
>
> * compare-elim.c (try_merge_compare): Don't merge compare if
> address contains a side effect.
> * gcc.c-torture/compile/20180605-1.c: New
On Wed, Jun 06, 2018 at 09:14:11AM -0600, Martin Sebor wrote:
> On 06/05/2018 04:19 PM, Jakub Jelinek wrote:
> > On Tue, Jun 05, 2018 at 03:43:17PM -0600, Martin Sebor wrote:
> > > --- a/gcc/builtins.def
> > > +++ b/gcc/builtins.def
> > > @@ -733,6 +733,7 @@ DEF_EXT_LIB_BUILTIN(BUILT_IN_STRNCAS
GCC maintainers:
Per the comment from Segher, there is a typo in the ABI.
On Tue, 2018-06-05 at 16:45 -0500, Bill Schmidt wrote:
> Hi Carl,
>
> That looks like a typo in the ABI document to me. The return type
> should match the
> argument types like it does for the other variants. Sorry --
On 06/05/2018 04:19 PM, Jakub Jelinek wrote:
On Tue, Jun 05, 2018 at 03:43:17PM -0600, Martin Sebor wrote:
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -733,6 +733,7 @@ DEF_EXT_LIB_BUILTIN(BUILT_IN_STRNCASECMP,
"strncasecmp", BT_FN_INT_CONST_STR
DEF_LIB_BUILTIN(BUILT_IN_STRNCAT
In this testcase, -Wmemset-elt-size was crashing because
TYPE_UNIT_SIZE of A was NULL. The first hunk fixes that. The
patch also moves the warning into finish_call_expr so that it can be
issued at instantiation time as well, for dependent arguments. And I
noticed that we were unnecessarily wrapp
GCC Maintainers:
The Power 9 builtins first_match_index, first_match_or_eos_index,
first_mismatch_index, first_mismatch_or_eos_index work for LE only.
The following patch adds BE support to each of the builtins.
Additional debug print statements were added to the test case to aid in
verifying th
Hi Shaokun,
On 01/06/18 10:56, Zhangshaokun wrote:
Hi Ramana,
Sorry to reply so later because of short leave.
On 2018/5/23 18:41, Ramana Radhakrishnan wrote:
On 23/05/2018 03:50, Zhangshaokun wrote:
Hi Ramana,
On 2018/5/22 18:28, Ramana Radhakrishnan wrote:
On Tue, May 22, 2018 at 9:40 AM
This libgo patch adjusts the hash and string fields computed by
reflect.StructOf to match the values that the compiler computes for a
struct type with the same field names and types. This makes the
reflect code match the compiler's Type::hash_for_method and
Type::reflection methods. This fixes ht
On 06/05/2018 06:39 PM, Eric Gallager wrote:
On 6/5/18, Martin Sebor wrote:
The attached patch adds basic support for handling strnlen
as a built-in function. It touches the strlen pass where
it folds constant results of the function, and builtins.c
to add simple support for expanding strnlen
On Wed, 6 Jun 2018, Jakub Jelinek wrote:
> Hi!
>
> The following testcase shows another case that can be handled easily.
> If rhs2 is defined in a bb dominated by first_bb, we need to be careful
> because we can't rely on value range information of it after we optimize the
> guarding >= 0 check i
On Fri, Jun 01, 2018 at 12:39:08PM -0400, Jason Merrill wrote:
> Yes, we still need to do deduction on the array bound, so we can't
> return immediately. We just want to avoid the
>
> FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
>
> loop.
Got it. But then there's this part
Hi!
The following testcase shows another case that can be handled easily.
If rhs2 is defined in a bb dominated by first_bb, we need to be careful
because we can't rely on value range information of it after we optimize the
guarding >= 0 check into 1. On the testcase, we have there
rhs2 = (int) so
Hi!
As mentioned in the PR, the current __cpp_transactional_memory macro
value with -fgnu-tm is clearly bogus, what will be standardized in 2105
is unknown.
The big question is if we should go with the value that was meant to be used
in r228462 as this patch does, or if we should go for 201505 -
Eliminate an "as_a ()" cast.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
I'm treating this as pre-approved, under the pre-approval on
rtx -> rtx_insn * cleanups here:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01310.html
Committed to trunk as r261233.
gcc/ChangeLog:
Hi Nicolas,
a few other nits:
* The current patch has a large number of GNU Coding Style violations,
many catched by contrib/check_GNU_style.{sh,py}.
* Others are partially pre-existing (additional blank before formal
paramater name as in
+destroy_adv_cond (struct adv_cond * ac)
and ma
Hi, Martin
Thanks for both patches. GCC bootstrap on AIX is progressing much
better with the patches installed.
Thanks, David
On Wed, Jun 6, 2018 at 5:05 AM Martin Liška wrote:
>
> On 06/06/2018 03:09 AM, David Edelsohn wrote:
> > Also, there seems to be a find-and-replace mistake in libgcov-d
process_store was wrongly bypassing a BIT_NOT_EXPR if there was a NOP_EXPR
right after it in the SSA chain.
Tested on x86-64/Linux, applied on the mainline as obvious.
2018-06-06 Eric Botcazou
PR tree-optimization/86066
* gimple-ssa-store-merging.c (process_store): Do not by
The following fixes another disconnect as to with respect to what
loop to analyze CHRECs.
Boostrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2018-06-06 Richard Biener
PR tree-optimization/85935
* graphite-scop-detection.c (find_params_in_bb): Analyze
I was overly cautionous when implementing this part of VN translation
but given the code is never executed from PRE (and thus the result
will never be inserted as real code) there's no TBAA issue to be
avoided.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
>From b44f9b
On Tue, 2018-06-05 at 18:31 +0100, Pedro Alves wrote:
> [adding gdb-patches]
>
> On 06/05/2018 06:56 PM, David Malcolm wrote:
> > On Tue, 2018-06-05 at 17:13 +0100, Pedro Alves wrote:
> > > On 06/05/2018 03:49 PM, David Malcolm wrote:
> > > > On Tue, 2018-06-05 at 04:40 -0400, Trevor Saunders wrot
Hi Jakub,
>> I do note that if one has, say, 8 files and only one
>> file uses async IO, then during linking of the 8 *.o
>> files to make the final execute -lpthread must be added.
>> How doesn't gfortran communicate that to the loader?
>
> ELF doesn't a way to do this, you'd need to add a specia
On 29/05/18 23:55, DJ Delorie wrote:
Jozef Lawrynowicz writes:
If an argument is passed to the interrupt attribute, GCC will create a section
for the interrupt vector when outputting the assembly. This, combined with the
code to ensure the interrupt function doesn't get optimized out, ensures t
On Thu, May 24, 2018 at 11:36 AM Richard Sandiford
wrote:
>
> This patch adds match.pd support for applying normal folds to their
> IFN_COND_* forms. E.g. the rule:
>
> (plus @0 (negate @1)) -> (minus @0 @1)
>
> also allows the fold:
>
> (IFN_COND_ADD @0 @1 (negate @2) @3) -> (IFN_COND_SUB @0
On Tue, 5 Jun 2018, Richard Biener wrote:
>
> This is a prototype enforcing is_gimple_val conditions in
> [VEC_]COND_EXPRs. It shows quite some fallout - some likely
> due to necessary testsuite adjustments like gcc.dg/tree-ssa/ssa-lim-12.c
> others because some code simply doesn't handle condi
On Tue, Jun 05, 2018 at 11:47:21PM -0700, Steve Kargl wrote:
> I have not looked at the source code, but do have a question.
> With -fopenmp, gfortran automatically adds -lpthread to
> the command line. Is it possible during the parsing
Even if it wouldn't, libgomp.so.1 depends on libpthread.so.
On 04/06/18 18:52, DJ Delorie wrote:
Jozef Lawrynowicz writes:
For the currently released msp430i* devices, only digits follow the i, so no
upper or lower case conversion is needed.
Thinking of the future... do we expect any new devices with letters?
Should we plan for them? Or better to wait
On 06/04/2018 11:21 PM, JonY wrote:
> On 06/03/2018 06:59 PM, Nicolas Koenig wrote:
>> Hello everyone,
>>
>> this patch adds asynchronous I/O support. Thomas and I finally finished
>> a feature-complete and debugged version, so here it is. In order to use
>> asynchronous I/O, it is still necessary
On 06/06/2018 03:09 AM, David Edelsohn wrote:
> Also, there seems to be a find-and-replace mistake in libgcov-driver.c
>
> #if !GCOV_LOCKED
> /* summary for all instances of program. */
> struct gcov_summary *cs_all;
> #endif
>
> cs_all is declared within the !GCOV_LOCKED macro
>
> but late
On 06/06/2018 02:28 AM, David Edelsohn wrote:
> Martin,
>
> With your recent patch, I receive the following failure building
> libgcov-driver-system.c
>
> In file included from
> /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver.c:322:0:
> /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driv
75 matches
Mail list logo
