Hi,
Please consider this as a personal reminder to review the patch
at following link and let me know your comments on the same.
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01333.html
Thanks,
Naveen
Hi,
Please consider this as a personal reminder to review the patch
at following link and let me know your comments on the same.
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01334.html
Thanks,
Naveen
Hi,
Please consider this as a personal reminder to review the patch
at following link and let me know your comments on the same.
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01260.html
Thanks,
Naveen
Hi,
Please consider this as a personal reminder to review the patch
at following link and let me know your comments on the same.
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00505.html
Thanks,
Naveen
Hi,
Please consider this as a personal reminder to review the patch
at following link and let me know your comments on the same.
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00504.html
Thanks,
Naveen
Hi,
Please consider this as a personal reminder to review the patch
at following link and let me know your comments on the same.
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00226.html
Thanks,
Naveen
Hi,
Please consider this as a personal reminder to review the patch
at following link and let me know your comments on the same.
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00222.html
Thanks,
Naveen
Hi,
Please consider this as a personal reminder to review the patch
at following link and let me know your comments on the same.
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00839.html
Thanks,
Naveen
On Thu, May 25, 2017 at 6:43 PM, Jerry DeLisle wrote:
> On 05/25/2017 02:57 PM, Thomas Koenig wrote:
>>
>> Hi everybody,
>>
>> I have committed the patch (with the corrections for the name)
>> as rev 248472.
>>
>> The infrastructure is in place, so we will be able to make
>> any fine-tuning easily
On 05/25/2017 02:57 PM, Thomas Koenig wrote:
Hi everybody,
I have committed the patch (with the corrections for the name)
as rev 248472.
The infrastructure is in place, so we will be able to make
any fine-tuning easily.
Regards
Thomas
Based on my testing I think it is close enough as i
https://gcc.gnu.org/svnwrite.html#authenticated says "approval from
the mailing list is not needed in this one case" so I've gone ahead
and committed the attached patch.
ChangeLog:
2017-05-25 Eric Gallager
* MAINTAINERS: Add self to Write After Approval
Index: MAINTAINERS
=
Hi everybody,
I have committed the patch (with the corrections for the name)
as rev 248472.
The infrastructure is in place, so we will be able to make
any fine-tuning easily.
Regards
Thomas
On Thu, May 25, 2017 at 5:08 AM, Jakub Jelinek wrote:
> On Thu, May 25, 2017 at 10:51:56AM +0200, Jakub Jelinek wrote:
>> On Tue, May 09, 2017 at 04:37:16PM -0400, Jason Merrill wrote:
>> > For C++17 aggregate bases, we have started adding base fields for
>> > empty bases. The code for calculatin
This patch finally expunges OVL_CURRENT & OVL_NEXT. Everything's
switched over to using the new iterators.
The use in check_explicit_specialization is temporary, until I enable 2D
overload sets, and then it'll just use lookup_add on the overload set.
nathan
--
Nathan Sidwell
2017-05-25 Nath
On Thu, May 25, 2017 at 11:24 AM, augustine.sterl...@gmail.com
wrote:
> On Mon, May 22, 2017 at 2:09 PM, Max Filippov wrote:
>> Now that XCHAL_* macros don't have to be preprocessor constants add
>> include/xtensa-dynconfig.h that defines them as fields of a structure
>> returned from the xtensa_
On 05/25/2017 10:20 AM, Janne Blomqvist wrote:
On Thu, May 25, 2017 at 1:45 PM, Thomas Koenig wrote:
Hello world,
the attached patch speeds up the library version of matmul for AMD chips
by selecting AVX128 instructions and, depending on which instructions
are supported, either FMA3 (aka FMA)
On Thu, 25 May 2017, Mike Stump wrote:
>> I’m suggesting we apply the following patch to provide links to macOS
>> package managers, where users can download binaries for GCC on macOS. I
>> have included the two major ones, Homebrew and MacPorts.
> I'm not against it. :-) I'd let the doc people
On Thu, May 25, 2017 at 09:56:20PM +0200, Florian Weimer wrote:
> On Thu, May 25, 2017 at 8:25 PM, Michael Meissner
> wrote:
> > This patch adds the initial attribute((target_clone(...))) support to the
>
> Patch seems to be missing.
>
> Florian
>
Sorry about that.
This patch adds the initial
On Thu, May 25, 2017 at 8:25 PM, Michael Meissner
wrote:
> This patch adds the initial attribute((target_clone(...))) support to the
Patch seems to be missing.
Florian
On Thu, May 25, 2017 at 8:22 AM, Peryt, Sebastian
wrote:
> Hi,
>
> Thank you very much for the answers. Can someone please commit this patch for
> me?
Committed as r248468.
Uros.
On 05/25/2017 03:07 PM, Jason Merrill wrote:
The recursion is a rare event, so we optimize the non-recursive case.
Sounds like it would make sense to use a hash_set rather than flags on
the decls.
I don't think that would be a win. Although both are O(1), the constant
factor is greater for
On Thu, May 25, 2017 at 9:03 AM, Nathan Sidwell wrote:
> Anyway, this implementation introduces LOOKUP_SEEN_P and LOOKUP_FOUND_P to
> directly mark the DECL node. Hence determination is now O(1) rather than
> O(N^2). We still have a vector to recall which decls we need to unmark at
> the end of
OK, thanks.
On Thu, May 25, 2017 at 10:22 AM, Jakub Jelinek wrote:
> On Wed, May 24, 2017 at 12:13:40PM -0400, Jason Merrill wrote:
>> On Wed, May 24, 2017 at 2:48 AM, Jakub Jelinek wrote:
>> > On Tue, May 23, 2017 at 09:45:10PM -0400, Jason Merrill wrote:
>> >> Someone on IRC complained that th
With namespace lookup reimplemented we need neither DECL_NAMESPACE_USERS
nor DECL_NAMESPACE_ASSOCIATIONS.
This patch nukes them.
The change in libcp1plugin.cc, which checks before setting will make
more sense when the next change to inline namespace representation lands.
nathan
--
Nathan Sid
This patch adds the initial attribute((target_clone(...))) support to the
PowerPC. It looks at the HWCAP bits for ISA 2.05 (power6), ISA 2.06 (power7),
ISA 2.07 (power8) and ISA 3.0 (power9) to determine which clone function to
run. The implementation used the existing i386/x86_64 support for tar
On Mon, May 22, 2017 at 2:09 PM, Max Filippov wrote:
> Now that XCHAL_* macros don't have to be preprocessor constants add
> include/xtensa-dynconfig.h that defines them as fields of a structure
> returned from the xtensa_get_config function.
> Define that structure and fill it with default parame
On Mon, May 22, 2017 at 2:09 PM, Max Filippov wrote:
> XCHAL_* macros from the xtensa-config.h are used in a number of places
> that require them to be preprocessor constants. Rewrite these places so
> that non-constant XCHAL_* definitions could be used there.
>
> 2017-05-22 Max Filippov
> gcc/
Hi,
I believe this tests has been wrongly modified previously. It is to test that
the exit check on
pointer shouldn't be replaced by integer IV. Somehow GCC starts replacing the
check on
integer IV with pointer IV. It's valid, though inefficient. And somehow we
starting checking
this iv repl
Hi,
Test gcc.target/i386/l_fma_double_1.c depends on how many times prolog/epilog
loops are unrolled.
This patch adapts the test strings in line with patch at
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01689.html
Bootstrap and test in series on x86_64. Is it OK?
Thanks,
bin
gcc/testsuite/Ch
On Thu, May 25, 2017 at 1:45 PM, Thomas Koenig wrote:
> Hello world,
>
> the attached patch speeds up the library version of matmul for AMD chips
> by selecting AVX128 instructions and, depending on which instructions
> are supported, either FMA3 (aka FMA) or FMA4.
>
> Jerry tested this on his AMD
This patch reimplements unqualified namespace lookup.
Unqualified lookup progresses from namespace X towards ::, stopping once
something is found. However, using directives are searched in parallel
at the common ancestor of the namespace containing the using directive
and the target it nomina
warnings, line 62)
FAIL: gcc.dg/overflow-warn-9.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20170525/gcc/testsuite/gcc.dg/overflow-warn-9.c:62:9:
warning: signed conversion from 'long unsigned int' to 'long int' changes value
from '2147483648' to &#
We ICE on this testcase in
9812 /* Transform x * -C into -x * C if x is easily negatable. */
9813 if (TREE_CODE (op1) == INTEGER_CST
9814 && tree_int_cst_sgn (op1) == -1
9815 && negate_expr_p (op0)
9816 && (tem = negate_expr (op1))
On 15/05/17 19:57 +0200, François Dumont wrote:
Hi
Following what I have started on RbTree here is a patch to default
implementation of default and move constructors on std::vector.
As in _Rb_tree_impl the default allocator is not value initialized
anymore. We could add a small helper
On 05/25/2017 01:22 PM, Markus Trippelsdorf wrote:
> On 2017.05.25 at 11:55 +0200, Martin Liška wrote:
>> Hi.
>>
>> As I spoke about the PGO with Honza and Richi, current 3-stage is not ideal
>> for following
>> 2 reasons:
>>
>> 1) stageprofile compiler is train just on libraries that are built du
On 25/05/17 16:56 +0200, Jakub Jelinek wrote:
On Thu, May 25, 2017 at 03:52:47PM +0100, Jonathan Wakely wrote:
I'd probably write that like this instead:
void
foo (const void *p)
{
typedef const int* ptr_type;
ptr_type const q = (ptr_type) p;
ptr_type const r = (ptr_type) p;
(void) q;
(voi
FAIL: gcc.dg/overflow-warn-9.c (test for warnings, line 59)
FAIL: gcc.dg/overflow-warn-9.c (test for warnings, line 60)
FAIL: gcc.dg/overflow-warn-9.c (test for warnings, line 62)
FAIL: gcc.dg/overflow-warn-9.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20170525/gcc/testsuite
This patch reimplements qualified namespace lookup. It extends the
name_lookup object I introduced for ADL.
qualified namespace lookup is essentially a flood-fill algorithm, where
if nothing is found in namespace X you follow the using directives
therein. You stop when you find something (or
On May 23, 2017, at 1:41 AM, FX wrote:
>
> I’m suggesting we apply the following patch to provide links to macOS package
> managers, where users can download binaries for GCC on macOS. I have included
> the two major ones, Homebrew and MacPorts.
I'm not against it. :-) I'd let the doc people
On Tue, May 23, 2017 at 5:23 PM, Bin Cheng wrote:
> Hi,
> As commented in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815#c1,
> We can relax minimal segment length of DR_B for merging. With this change,
> the new test can be improved to only one alias check. Note the
> condition is still accu
On Wed, May 24, 2017 at 11:54 AM, Richard Sandiford
wrote:
> "Bin.Cheng" writes:
>> On Tue, May 23, 2017 at 6:53 PM, Richard Sandiford
>> wrote:
>>> AIUI, the reason the old code mishandled negative steps was that the
>>> associated segment lengths were stored as sizetype and so looked like
>>>
On May 24, 2017, at 1:25 AM, Richard Biener wrote:
>
> There's trailing_wide_ints. But having 6 of them is still expensive.
>
> Something nice would be to make wide_ints not tied to use HOST_WIDE_INT
> as basic element type but for example uint32.
wide_int was made so that they would be calcul
On Thu, May 25, 2017 at 03:52:47PM +0100, Jonathan Wakely wrote:
> I'd probably write that like this instead:
>
> void
> foo (const void *p)
> {
> typedef const int* ptr_type;
> ptr_type const q = (ptr_type) p;
> ptr_type const r = (ptr_type) p;
> (void) q;
> (void) r;
> }
>
> It names the t
On 25/05/17 16:11 +0200, Jakub Jelinek wrote:
On Thu, May 25, 2017 at 03:02:42PM +0100, Jonathan Wakely wrote:
On 25/05/17 11:07 +0100, Jonathan Wakely wrote:
> On 25/05/17 10:05 +0200, Andreas Schwab wrote:
> > ../../gcc/ada/gcc-interface/utils2.c: In function 'int
compare_elmt_bitpos(const vo
Hi Jerry,
Yes, OK. Maybe test Ryzen first?
Sure, I can wait for a bit :-)
I just confirmed access to the Ryzen machines so I plan to get set up
and test there.
The gcc compile farm machines? My ssh key does not work there...
I have based the choice of FMA(3) over FMA4 when both are avail
On Thu, May 25, 2017 at 04:11:19PM +0200, Jakub Jelinek wrote:
> On Thu, May 25, 2017 at 03:02:42PM +0100, Jonathan Wakely wrote:
> > On 25/05/17 11:07 +0100, Jonathan Wakely wrote:
> > > On 25/05/17 10:05 +0200, Andreas Schwab wrote:
> > > > ../../gcc/ada/gcc-interface/utils2.c: In function 'int
On Wed, May 24, 2017 at 12:13:40PM -0400, Jason Merrill wrote:
> On Wed, May 24, 2017 at 2:48 AM, Jakub Jelinek wrote:
> > On Tue, May 23, 2017 at 09:45:10PM -0400, Jason Merrill wrote:
> >> Someone on IRC complained that there was no way to suppress -Wunused
> >> on structured bindings. It seeme
On Thu, May 25, 2017 at 04:11:19PM +0200, Jakub Jelinek wrote:
> So, what can one do with typeof or similar to avoid the warning?
>
> void
> foo (const void *p)
> {
> const int *const q = (const int *const) p;
> typeof (q) r = (typeof (q)) p;
> (void) q;
> (void) r;
> }
>
> AFAIK typeof d
On Thu, May 25, 2017 at 03:02:42PM +0100, Jonathan Wakely wrote:
> On 25/05/17 11:07 +0100, Jonathan Wakely wrote:
> > On 25/05/17 10:05 +0200, Andreas Schwab wrote:
> > > ../../gcc/ada/gcc-interface/utils2.c: In function 'int
> > > compare_elmt_bitpos(const void*, const void*)':
> > > ../../gcc/a
On 05/25/2017 03:45 AM, Thomas Koenig wrote:
Hello world,
the attached patch speeds up the library version of matmul for AMD chips
by selecting AVX128 instructions and, depending on which instructions
are supported, either FMA3 (aka FMA) or FMA4.
Jerry tested this on his AMD systems, and found
On 25/05/17 11:07 +0100, Jonathan Wakely wrote:
On 25/05/17 10:05 +0200, Andreas Schwab wrote:
../../gcc/ada/gcc-interface/utils2.c: In function 'int
compare_elmt_bitpos(const void*, const void*)':
../../gcc/ada/gcc-interface/utils2.c:1937:73: error: type qualifiers ignored on
cast result type
This patch tackles the issue reported in PR71607. This patch takes a different
approach for disabling the creation of literal pools. Instead of disabling the
patterns that would normally transform the rtl into actual literal pools, it
disables the creation of this literal pool rtl by making the tar
This patch reimplements ADL.
I replace the existing adl_lookup object with a new name_lookup object,
and move all the workers into it as member fns.
In terms of implementation, ADL requires us to look in a bunch of
places, and we obviously want to look in each place only once. The
current i
On 25/05/17 14:35 +0200, Richard Biener wrote:
On May 25, 2017 1:38:36 PM GMT+02:00, Nathan Sidwell wrote:
On 05/25/2017 07:21 AM, Jonathan Wakely wrote:
I don't mind removing the warning again if preferred. I thought it
was
useful (as we already warn for ignored const in return types).
O
On May 25, 2017 1:38:36 PM GMT+02:00, Nathan Sidwell wrote:
>On 05/25/2017 07:21 AM, Jonathan Wakely wrote:
>
>> I don't mind removing the warning again if preferred. I thought it
>was
>> useful (as we already warn for ignored const in return types).
>
>Oh yeah, I recall noticing we did that (and
On 05/25/2017 07:21 AM, Jonathan Wakely wrote:
I don't mind removing the warning again if preferred. I thought it was
useful (as we already warn for ignored const in return types).
Oh yeah, I recall noticing we did that (and noting we didn't warn
elsewhere). This new warning seems consistent
On 2017.05.25 at 11:55 +0200, Martin Liška wrote:
> Hi.
>
> As I spoke about the PGO with Honza and Richi, current 3-stage is not ideal
> for following
> 2 reasons:
>
> 1) stageprofile compiler is train just on libraries that are built during
> stage2
> 2) apart from that, as the compiler is also
On 25/05/17 12:19 +0100, Jonathan Wakely wrote:
On 25/05/17 06:54 -0400, Nathan Sidwell wrote:
On 05/25/2017 01:29 AM, Richard Biener wrote:
On May 25, 2017 3:22:18 AM GMT+02:00, Nathan Sidwell wrote:
On 05/24/2017 09:13 PM, Nathan Sidwell wrote:
On 05/24/2017 08:56 PM, Nathan Sidwell wrote:
On 25/05/17 06:54 -0400, Nathan Sidwell wrote:
On 05/25/2017 01:29 AM, Richard Biener wrote:
On May 25, 2017 3:22:18 AM GMT+02:00, Nathan Sidwell wrote:
On 05/24/2017 09:13 PM, Nathan Sidwell wrote:
On 05/24/2017 08:56 PM, Nathan Sidwell wrote:
On 05/24/2017 08:34 PM, Nathan Sidwell wrote:
Hi,
patch is at https://gcc.gnu.org/ml/fortran/2017-05/msg00133.html
(didn't to through to gcc-patches due to size limitations).
Regards
Thomas
Weitergeleitete Nachricht
Betreff: [patch, libfortran] AMD-specific versions of library matmul
Datum: Thu, 25 May 2017 12:4
On 05/25/2017 05:52 AM, Martin Liška wrote:
On 05/25/2017 05:35 AM, Martin Sebor wrote:
On 05/12/2017 07:04 AM, Martin Liška wrote:
Third part removes TDF_* flags mentioned in the subject. These flags are used
to enable all passes of specific type and Nathan has recently separated these
by a ne
On 05/25/2017 01:29 AM, Richard Biener wrote:
On May 25, 2017 3:22:18 AM GMT+02:00, Nathan Sidwell wrote:
On 05/24/2017 09:13 PM, Nathan Sidwell wrote:
On 05/24/2017 08:56 PM, Nathan Sidwell wrote:
On 05/24/2017 08:34 PM, Nathan Sidwell wrote:
We now warn on casts to T const. Applied as obv
On 25/05/17 10:05 +0200, Andreas Schwab wrote:
../../gcc/ada/gcc-interface/utils2.c: In function 'int
compare_elmt_bitpos(const void*, const void*)':
../../gcc/ada/gcc-interface/utils2.c:1937:73: error: type qualifiers ignored on
cast result type [-Werror=ignored-qualifiers]
const constructor
Hello.
Following patch tries to resolve following 2 issues:
a) When one takes address of a function that uses target_clones attribute,
default implementation is always returned.
b) Using dlsym("foo") should work and thus the resolver function should
use the default name. Because of that, d
On 24/05/17 20:09 -0700, Andrew Pinski wrote:
On Wed, May 24, 2017 at 8:07 PM, Andrew Pinski wrote:
This change caused a bootstrap failure on aarch64-linux-gnu and
x86_64-linux-gnu:
In file included from ../../gcc/gcc/system.h:691:0,
from ../../gcc/gcc/read-rtl.c:31:
../../gcc/
Hello.
Having value of parameter partial-inlining-entry-probability bigger than 100
does not
make sense and can be just used to artificially trigger partial inlining.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Martin
>From 4f849447030daa05f64a0
Hi.
As I spoke about the PGO with Honza and Richi, current 3-stage is not ideal for
following
2 reasons:
1) stageprofile compiler is train just on libraries that are built during stage2
2) apart from that, as the compiler is also used to build the final compiler,
profile
is being updated during
On 05/25/2017 05:35 AM, Martin Sebor wrote:
> On 05/12/2017 07:04 AM, Martin Liška wrote:
>> Third part removes TDF_* flags mentioned in the subject. These flags are used
>> to enable all passes of specific type and Nathan has recently separated these
>> by a new pair of macros. I hope moving these
Tested on Linux-x64, running full suite on Linux-ppc64. It seems fitting
to put the test into the library tests, we don't have separate tests
on the front-end side for __is_constructible, so I think adding such
would be a separate job.
2017-05-25 Ville Voutilainen
cp/
PR c++/80812
On 24/05/17 17:19, Richard Earnshaw (lists) wrote:
> On 24/05/17 17:03, Jim Wilson wrote:
>> On Wed, May 24, 2017 at 8:17 AM, Richard Earnshaw (lists)
>> wrote:
>>> On 24/05/17 15:18, Jim Wilson wrote:
On Wed, May 24, 2017 at 6:56 AM, Richard Earnshaw (lists)
wrote:
> OK. does this
Hello.
After a discussion with Richi, using adding "-O2" to STAGE1 cflags with a recent
enough compiler can significantly speed up bootstrap. Thus I'm suggesting to
introduce --with-stage1-cflags where one can provide such options.
Apart from that, maybe it would be handy to automatically enable
On Thu, May 25, 2017 at 10:51:56AM +0200, Jakub Jelinek wrote:
> On Tue, May 09, 2017 at 04:37:16PM -0400, Jason Merrill wrote:
> > For C++17 aggregate bases, we have started adding base fields for
> > empty bases. The code for calculating whether a class is standard
> > layout needs to ignore the
On Tue, May 09, 2017 at 04:37:16PM -0400, Jason Merrill wrote:
> For C++17 aggregate bases, we have started adding base fields for
> empty bases. The code for calculating whether a class is standard
> layout needs to ignore these.
>
> The C++17 mode diagnostic for direct-enum-init1.C was incorrec
../../gcc/ada/gcc-interface/utils2.c: In function 'int
compare_elmt_bitpos(const void*, const void*)':
../../gcc/ada/gcc-interface/utils2.c:1937:73: error: type qualifiers ignored on
cast result type [-Werror=ignored-qualifiers]
const constructor_elt * const elmt1 = (const constructor_elt * co
74 matches
Mail list logo
