On Mon, 24 Feb 2020 at 18:40, Christophe Lyon
wrote:
>
> On Mon, 24 Feb 2020 at 07:32, Prathamesh Kulkarni
> wrote:
> >
> > On Wed, 19 Feb 2020 at 19:54, Richard Biener
> > wrote:
> > >
> > > On Wed, Feb 19, 2020 at 12:19 AM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Tue, 18 Feb 2020
Hopefully less borked than the previous one, adds futex support.
- Original Message -
From: "Thomas Rodgers"
To: gcc-patches@gcc.gnu.org, libstd...@gcc.gnu.org
Sent: Wednesday, February 19, 2020 7:18:36 PM
Subject: Re: [PATCH] Add c++2a binary_semaphore
Should address the previous
On Mon, 24 Feb 2020, Patrick Palka wrote:
> This implements signed and unsigned integer-class types, whose width is one
> bit
> larger than the widest native signed and unsigned integral type respectively.
> In our case this is either __int128 and unsigned __int128, or long long and
> unsigned
This patch fixes a bug with -fdump-analyzer, which is meant to write
purely a dumpfile, but was erroneously sending part of the dump to
stderr.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as f2ca2088bc393a7d3d8eef4ff85cbe949db3cde0.
gcc/analyzer/ChangeLog:
*ping*
On Tuesday, January 28, 2020 4:45:59 PM PST Andrew Benson wrote:
> I opened PR93486 for this problem:
>
> The following causes an ICE with revision
> ad690d79cfbb905c5546c9333c5fd089d906505b:
>
> module ivs
> interface l
> module procedure l_
> end interface l
> contains
>
Dead code is probably not the right description.
Something like 'result that is not used' is better.
In event, the patch removes 3 useless lines.
Please commit.
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c
-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those. According to the reported that's
making it harder to use the warning to clean up LibreOffice.
The attached patch extends
On Mon, 24 Feb 2020, Patrick Palka wrote:
> libstdc++-v3/ChangeLog:
>
> LWG 3301 transform_view::_Iterator has incorrect iterator_category
> * include/std/ranges (transform_view::_Iterator::_S_iter_cat): Adjust
> determination of iterator_category as per LWG 3301.
> *
PR analyzer/93032 tracks a false negative where we fail to report
FILE * leaks within zlib/contrib/minizip/mztools.c.
The underlying issue is a combinatorial explosion of states within the
exploded graph. In particular, the state of the "taint" checker is
exploding, leading to the analyzer
PR analyzer/93899 reports an ICE within make_region_for_type when
handling a param of type OFFSET_TYPE within
exploded_graph::add_function_entry.
This patch fixes the ICE by further generalizing the "give up on this
tree code" logic from
r10-6667-gf76a88ebf089871dcce215aa0cb1956ccc060895
libstdc++-v3/ChangeLog:
LWG 3313 join_view::_Iterator::operator-- is incorrectly constrained
* include/std/ranges (join_view::_Iterator::operator--): Require that
range_reference_t<_Base> models common_range.
* testsuite/std/ranges/adaptors/lwg3313_neg.cc: New
libstdc++-v3/ChangeLog:
LWG 3325 Constrain return type of transformation function for
transform_view
* include/std/ranges (transform_view): Constrain the return type of the
transformation function as per LWG 3325.
*
libstdc++-v3/ChangeLog:
LWG 3292 iota_view is under-constrained
* include/std/ranges (iota_view): Require that _Winc models semiregular
as per LWG 3292.
* testsuite/std/ranges/iota/lwg3292_neg.cc: New test.
---
libstdc++-v3/include/std/ranges | 1
libstdc++-v3/ChangeLog:
LWG 3397 basic_istream_view::iterator should not provide
iterator_category
* include/std/ranges (basic_istream_view:_Iterator::iterator_category):
Rename to ...
(basic_istream_view:_Iterator::iterator_concept): ... this.
*
libstdc++-v3/ChangeLog:
LWG 3301 transform_view::_Iterator has incorrect iterator_category
* include/std/ranges (transform_view::_Iterator::_S_iter_cat): Adjust
determination of iterator_category as per LWG 3301.
* testsuite/std/ranges/adaptors/transform.cc:
On 2020-02-13, Fangrui Song wrote:
On 2020-02-09, Fangrui Song wrote:
PR driver/93645
* common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=.
* opts.c (common_handle_option): Handle OPT_fuse_ld_.
* gcc.c (driver_handle_option): Likewise.
On 2/20/20 11:52 AM, Marek Polacek wrote:
On Thu, Feb 20, 2020 at 12:13:07AM +, Jason Merrill wrote:
On 2/19/20 10:15 PM, Marek Polacek wrote:
On Fri, Feb 14, 2020 at 12:24:30AM +0100, Jason Merrill wrote:
On 2/11/20 8:54 PM, Marek Polacek wrote:
Since
On 2/21/20 7:41 PM, Martin Sebor wrote:
On 2/17/20 10:54 AM, Jason Merrill wrote:
On 2/14/20 9:06 PM, Martin Sebor wrote:
On 2/13/20 3:59 PM, Jason Merrill wrote:
On 2/12/20 9:21 PM, Martin Sebor wrote:
On 2/11/20 5:28 PM, Jason Merrill wrote:
On 2/11/20 9:00 PM, Martin Sebor wrote:
I don't think this is worth reverting the IRA changes. BUt in case
someone raises the issue
The bit_shift test for visium will fail with the recent IRA changes.
The change in register allocation results in not needing a move at the
start of the function. This is generally good :-)
These two test cases have assembly code that requires a valid TOC.
Make sure that we don't use the PC-relative ABI extensions that
violate this requirement.
Tested and verified on powerpc64le-unknown-linux-gnu. Is this
okay for trunk?
Thanks,
Bill
2020-02-24 Bill Schmidt
*
On 2/20/20 3:08 PM, Jérémy Lefaure wrote:
Hello,
Ping for https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01081.html.
Thank you,
Jérémy
On Sun, Dec 15, 2019 at 07:20:26PM +0100, Jérémy Lefaure wrote:
Hi!
Since in ARM state the value of PC is the address of the current
instruction plus 8
On Mon, Feb 24, 2020 at 03:41:47PM -0500, Marek Polacek wrote:
> This ICEs since my patch for P0388, which allowed conversions to arrays
> of unknown bound, but not the reverse, so these two static_casts are
> ill-formed.
>
> [expr.static.cast]/3 says that "cv1 T1" and "cv2 T2" have to be
>
This ICEs since my patch for P0388, which allowed conversions to arrays
of unknown bound, but not the reverse, so these two static_casts are
ill-formed.
[expr.static.cast]/3 says that "cv1 T1" and "cv2 T2" have to be
reference-compatible and the comment in build_static_cast_1 says it too
but then
This implements signed and unsigned integer-class types, whose width is one bit
larger than the widest native signed and unsigned integral type respectively.
In our case this is either __int128 and unsigned __int128, or long long and
unsigned long long.
Internally, the two integer-class types are
GCC maintianers:
The following patch fixes three typos in the gcc documentation file for
the __builtin_crypto_vpmsum* builtin function. The issue was reported
in
Bug 91276 - Doc typos in __builtin_crypto_vpmsum*
Please let me know if the patch is OK for mainline.
Thanks.
Jakub Jelinek writes:
> On Sun, Feb 23, 2020 at 10:55:53AM -0600, Bill Schmidt wrote:
>> > If/when it becomes necessary to have 'c' variants of functions, then a new
>> > version of
>> > the Vector Function ABI document will be created. And GLIBC and GCC
>> > modifications to
>> > comply with
‐‐‐ Original Message ‐‐‐
On Monday, February 24, 2020 10:20 AM, Bill Schmidt
wrote:
> So, I can answer a small amount of this, but I will say that overall, design
> or implementation documentation seems to be between lacking and nonexistent.
>
> This has to do with "#pragma omp simd"
DR 1423, which supersedes DR 654, says that you can't copy-init
a bool from a std::nullptr_t:
bool b = nullptr; // error
Conversely, it works with direct-initialization which is more
permissive than copy-initialization.
No code changes necessary since we handle it right.
Tested on
On Mon, 24 Feb 2020, Jason Merrill wrote:
> On 2/20/20 7:27 PM, Patrick Palka wrote:
> > This patch improves our concept diagnostics in two ways. First, it sets a
> > more
> > precise location for the constraint expressions built in
> > finish_constraint_binary_op. As a result, when a
On Mon, Feb 24, 2020 at 6:42 AM Ian Lance Taylor wrote:
>
> This patch by Svante Signell adds a missing Hurd build tag.
> Bootstrapped and ran Go tests on x86_64-pc-linux-gnu. Committed to
> mainline.
And another one, also tested and committed to mainline.
Ian
On 2/24/20 11:08 AM, Jakub Jelinek wrote:
On Mon, Feb 24, 2020 at 11:04:55AM -0600, Bill Schmidt wrote:
+ if (clonei->simdlen
+ && (clonei->simdlen < 2
+ || clonei->simdlen > 1024
Assuming that clonei->simdlen matches "vector length" in the ABI, 1024 is
too large a number. We can
This should do the same changes for std::insert_iterator, but it
currently crashes the compiler (PR 93907). I am not committing this
yet.
commit 2db20402125e6136d6768598f5974e917b2622c6
Author: Jonathan Wakely
Date: Mon Feb 24 15:50:59 2020 +
libstdc++: Add missing bits of P0896R4
On Mon, Feb 24, 2020 at 11:04:55AM -0600, Bill Schmidt wrote:
> > + if (clonei->simdlen
> > + && (clonei->simdlen < 2
> > + || clonei->simdlen > 1024
>
> Assuming that clonei->simdlen matches "vector length" in the ABI, 1024 is
> too large a number. We can have at most 8 vector
On 2/14/20 2:24 PM, GT wrote:
Function rs6000_simd_clone_adjust, even though it's body is empty,
cannot simply be removed. I tried it. It resulted in ICE. In my
view, leaving it empty is preferable to modifying other files
unrelated to rs6000.c in order to avoid having a function whose
body is
Here we crash when constexpr-initializing a class member of empty class
type with [[no_unique_address]]. Without the attribute we would have
a ctor (that initializes bar) of the form
{ .D.2173 = { .x = {} } }
but with the attribute reduced_constant_expression_p gets
{ .x = {} }
That means
Paths emitted by the analyzer can be quite verbose at the default of
-fanalyzer-verbosity=2.
Consider the double-free in this example:
#include
int foo ();
int bar ();
void test (int a, int b, int c)
{
void *p = malloc (1024);
while (a)
foo ();
if (b)
foo ();
On 2/20/20 5:55 PM, Martin Sebor wrote:
On 2/19/20 5:09 PM, Jason Merrill wrote:
On 2/19/20 1:02 AM, Martin Sebor wrote:
PR 93804 points out that issuing -Wredundant-tags for declarations
in C headers included in C++ isn't helpful because the tags cannot
be removed without breaking C programs
On 2/20/20 7:27 PM, Patrick Palka wrote:
This patch improves our concept diagnostics in two ways. First, it sets a more
precise location for the constraint expressions built in
finish_constraint_binary_op. As a result, when a disjunction is unsatisfied we
now print e.g.
Hi Roman,
Roman Zhuykov writes:
>> SMS is disabled in tests not to break them when SMS does loop versioning.
>
> And I'm not really sure about this. First of all, there are a lot of
> scan-assembler-times tests which fail when modulo-scheduler is enabled,
> probably the same happens when some
Hi,
On Sat, Feb 22 2020, Feng Xue OS wrote:
> It is a good solution.
>
OK, so I'd like to go with my patch as it hopefully keeps some of the
predicates a tiny bit simpler. I have re-based the patch on today's
trunk and amended function comments as necessary (which I forgot last
week). The
On 2/23/20 1:12 PM, Segher Boessenkool wrote:
On Sun, Feb 23, 2020 at 10:55:53AM -0600, Bill Schmidt wrote:
Though I'm usually uncomfortable with kicking the can down the road on these
sorts of things, I can probably be convinced in this case. Tulio and I were
wondering why the libmvec
On Mon, Feb 24, 2020 at 09:59:51AM -0500, Jason Merrill wrote:
> On 2/24/20 9:58 AM, Jason Merrill wrote:
> > On 2/21/20 2:14 PM, Marek Polacek wrote:
> > > This was approved in the Prague 2020 WG21 meeting so let's adjust the
> > > comment. Since it's supposed to be a DR I think we should no
On 2/21/20 1:06 PM, Marek Polacek wrote:
This is a crash in cp_parser_check_class_key:
tree type_decl = TYPE_MAIN_DECL (type);
tree name = DECL_NAME (type_decl); // HERE
because TYPE_MAIN_DECL of type was null as it's not a class type.
Instead of checking CLASS_TYPE_P we should simply
On 2/24/20 3:50 PM, Mark Eggleston wrote:
I've had a quick look and there doesn't appear to be a test for using
a non-constant for kind arguments. I think a proper set of tests for
invalid kind arguments that covers declarations and intrinsic
arguments should be added that is separate from
On 2/24/20 9:58 AM, Jason Merrill wrote:
On 2/21/20 2:14 PM, Marek Polacek wrote:
This was approved in the Prague 2020 WG21 meeting so let's adjust the
comment. Since it's supposed to be a DR I think we should no longer
limit it to C++20.
I'm a bit nervous about the impact, but OK. It's
On 2/21/20 2:14 PM, Marek Polacek wrote:
This was approved in the Prague 2020 WG21 meeting so let's adjust the
comment. Since it's supposed to be a DR I think we should no longer
limit it to C++20.
I'm a bit nervous about the impact, but OK. It's easy enough to turn
off -Wnarrowing if it's
On 2/21/20 6:48 PM, Marek Polacek wrote:
On Thu, Feb 20, 2020 at 12:28:42AM +, Jason Merrill wrote:
On 2/19/20 7:30 PM, Marek Polacek wrote:
On Fri, Feb 14, 2020 at 09:12:58AM +0100, Jason Merrill wrote:
On 2/13/20 8:56 PM, Marek Polacek wrote:
My P0388R4 patch changed build_array_conv
On 24/02/2020 14:34, Thomas Koenig wrote:
Hi Mark,
Might need
gfc_reduce_init_expr (e);
here. The kind type parameter should be a constant expression.
Not needed. I've also checked use of the kind argument, it is
evidently checked elsewhere: if k is allowed to be implicitly
This patch by Svante Signell adds a missing Hurd build tag.
Bootstrapped and ran Go tests on x86_64-pc-linux-gnu. Committed to
mainline.
Ian
027a3f1c38727a1ea0969088b0680b2f6bb1e977
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index ce10ee1d8d4..47fbeaeda61 100644
---
On 2/23/20 11:33 AM, Jakub Jelinek wrote:
On Sun, Feb 23, 2020 at 10:42:17AM -0600, Bill Schmidt wrote:
Have I missed something crucial?
I haven't seen anything in the patch that would only enable it for ELFv2,
and while powerpc64le-linux probably assumes TARGET_VSX unconditionally
(haven't
Hi Mark,
Might need
gfc_reduce_init_expr (e);
here. The kind type parameter should be a constant expression.
Not needed. I've also checked use of the kind argument, it is evidently
checked elsewhere: if k is allowed to be implicitly declared and is used
as the kind argument
On 24/02/20 09:12 -0500, Patrick Palka wrote:
On Mon, 24 Feb 2020, Jonathan Wakely wrote:
On 21/02/20 16:12 -0500, Patrick Palka wrote:
> On Fri, 21 Feb 2020, Patrick Palka wrote:
>
> > This patch adds std::shift_left and std::shift_right. Alhough these are
> > STL-style algos, they are
On 24/02/20 08:53 -0500, Patrick Palka wrote:
On Mon, 24 Feb 2020, Jonathan Wakely wrote:
On 24/02/20 08:29 -0500, Patrick Palka wrote:
> This adds some missing pieces of the Ranges TS that make
> back_insert_iterator and
> front_insert_iterator conform to the new output_iterator requirements.
On 24/02/20 13:40 +, Jonathan Wakely wrote:
Missing pieces of P0896R4 "The One Ranges Proposal" for C++20.
* include/bits/stream_iterator.h (istream_iterator(default_sentinel_t)):
Add constructor.
(operator==(istream_iterator, default_sentinel_t)): Add operator.
**ping**
The following was a reply to
https://gcc.gnu.org/ml/fortran/2020-02/msg00042.html
see response below. OK to commit?
On 11/02/2020 15:23, Steve Kargl wrote:
On Tue, Feb 11, 2020 at 12:10:41PM +, Mark Eggleston wrote:
Please find attached a patch for PR93484. The original author
Ping?
I'd also like to backport this and the main patch (svn r279463,
r10-5505-ge24f6408df1e4c5e8c09785d7b488c492dfb68b3)
to the gcc-9 branch.
I found the problem addressed by this patch while validating the
backport to gcc-9: although the patch applies cleanly except for
testcases dg
Am Mo., 24. Feb. 2020 um 15:12 Uhr schrieb Patrick Palka :
>
> On Mon, 24 Feb 2020, Jonathan Wakely wrote:
>
[...]
> > > @@ -3683,6 +3683,98 @@ namespace ranges
> > > inline constexpr __prev_permutation_fn prev_permutation{};
> > >
> > > } // namespace ranges
> > > +
> > > + template
> > > +
On Mon, 24 Feb 2020, Jonathan Wakely wrote:
> On 21/02/20 16:12 -0500, Patrick Palka wrote:
> > On Fri, 21 Feb 2020, Patrick Palka wrote:
> >
> > > This patch adds std::shift_left and std::shift_right. Alhough these are
> > > STL-style algos, they are nonetheless placed in
> > > because
> > >
On 2/24/20 9:06 AM, Jakub Jelinek wrote:
Hi!
The following patch implements my understanding of P1937R2, though I wonder
if https://eel.is/c++draft/expr.const#14.example-1 shouldn't have been
also either removed or adjusted by the P1937R2 paper.
Ah, good catch.
Bootstrapped/regtested on
Hi!
The following patch implements my understanding of P1937R2, though I wonder
if https://eel.is/c++draft/expr.const#14.example-1 shouldn't have been
also either removed or adjusted by the P1937R2 paper.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2020-02-24 Jakub
The grammar for variadic init-capture was fixed at the Prague C++ meeting
where we finalized C++20.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-02-24 Jason Merrill
P0780R2: Resolve lambda init-capture pack grammar.
* parser.c
On Mon, 24 Feb 2020, Jonathan Wakely wrote:
> On 24/02/20 08:29 -0500, Patrick Palka wrote:
> > This adds some missing pieces of the Ranges TS that make
> > back_insert_iterator and
> > front_insert_iterator conform to the new output_iterator requirements.
> >
> > It also fixes a bug in
On 21/02/20 16:12 -0500, Patrick Palka wrote:
On Fri, 21 Feb 2020, Patrick Palka wrote:
This patch adds std::shift_left and std::shift_right. Alhough these are
STL-style algos, they are nonetheless placed in because
they make use of some functions in the ranges namespace that are more easily
On 24/02/20 08:29 -0500, Patrick Palka wrote:
This adds some missing pieces of the Ranges TS that make back_insert_iterator
and
front_insert_iterator conform to the new output_iterator requirements.
It also fixes a bug in ranges::__copy_or_move and
ranges::__copy_or_move_backward in which we
Missing pieces of P0896R4 "The One Ranges Proposal" for C++20.
* include/bits/stream_iterator.h (istream_iterator(default_sentinel_t)):
Add constructor.
(operator==(istream_iterator, default_sentinel_t)): Add operator.
(ostream_iterator::difference_type): Define to
ZOn Mon, 24 Feb 2020, Patrick Palka wrote:
> This adds some missing pieces of the Ranges TS that make back_insert_iterator
> and
> front_insert_iterator conform to the new output_iterator requirements.
>
> It also fixes a bug in ranges::__copy_or_move and
> ranges::__copy_or_move_backward in
Hi Mark,
**ping**
OK!
Regards
Thomas
This adds some missing pieces of the Ranges TS that make back_insert_iterator
and
front_insert_iterator conform to the new output_iterator requirements.
It also fixes a bug in ranges::__copy_or_move and
ranges::__copy_or_move_backward in which we were inspecting the iter_value_t of
the output
Hi Mark,
OK for both trunk and gcc-9.
Thanks for taking this up, and thanks to Steve for debugging
this in the first place!
Regards
Thomas
On Mon, 24 Feb 2020 at 07:32, Prathamesh Kulkarni
wrote:
>
> On Wed, 19 Feb 2020 at 19:54, Richard Biener
> wrote:
> >
> > On Wed, Feb 19, 2020 at 12:19 AM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Tue, 18 Feb 2020 at 19:40, Richard Biener
> > > wrote:
> > > >
> > > > On Tue, Feb 18,
On Sat, Feb 15, 2020 at 7:26 AM H.J. Lu wrote:
>
> This patch set was originally submitted in Feb 2019:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01841.html
>
> I broke it into 10 smaller patches for easy review.
>
> On x86, when AVX and AVX512 are enabled, vector move instructions can
>
Forgot to add the purpose of the e-mail: OK to commit?
On 24/02/2020 12:24, Mark Eggleston wrote:
Please find attached a patch to fix PR93835. This patch ensures that
the array returned by SHAPE has its shape defined, the original patch
from Steve Kargl handled the lack of shape for the
On Mon, 24 Feb 2020 at 12:50, Jakub Jelinek wrote:
>
> On Mon, Feb 24, 2020 at 11:09:58AM +0100, Christophe Lyon wrote:
> > I'm seeing errors with the new testcase:
> > end of struct or union
> > /gcc/testsuite/gcc.dg/ipa/pr93763.c:8:1: warning: data definition has
> > no type or storage class
>
Please find attached a patch to fix PR93835. This patch ensures that the
array returned by SHAPE has its shape defined, the original patch from
Steve Kargl handled the lack of shape for the returned array.
The bonus white space issues fixed in the original patch have been retained.
A side
On 1/28/20 9:52 PM, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
>
> The patch was successfully tested and bootstrapped on x86_64.
>
> Unfortunately it is hard to create a test case for the patch. So there is no
> test for this PR.
* include/std/ranges (__deep_const_range, __enable_view_impl): Remove.
(ranges::enable_view): Simplify (LWG 3326).
* include/bits/range_access.h (ranges::enable_view): Declare.
* include/bits/regex.h (__enable_view_impl): Remove partial
specialization.
**ping**
On 17/02/2020 11:26, Mark Eggleston wrote:
Please find attached patch for PR93604.
gcc/fortran/ChangeLog
Steven G. Kargl
PR fortran/93604
* decl.c (gfc_match_data) : Check whether the data expression
is a derived type and is a constructor. If a BOZ constant
is
On Mon, Feb 24, 2020 at 11:09:58AM +0100, Christophe Lyon wrote:
> I'm seeing errors with the new testcase:
> end of struct or union
> /gcc/testsuite/gcc.dg/ipa/pr93763.c:8:1: warning: data definition has
> no type or storage class
...
Seems the test has been badly reduced (if the original
On Sat, 22 Feb 2020, Jakub Jelinek wrote:
> Hi!
>
> The following patch adds support for bitfields to push_partial_def.
> Previously pd.offset and pd.size were counted in bytes and maxsizei
> in bits, now everything is counted in bits.
>
> Not really sure how much of the further code can be
On Fri, 21 Feb 2020, Bernd Edlinger wrote:
> Hi,
>
> this fixes the signal handler calling signal unsafe vfprintf and/or passing
> uninitialized memory to unlink in signal handler.
>
> This time it is the patch for the gcc-9 branch.
>
> The difference to the gcc-8 branch is in tool_cleanup:
>
All is about OpenACC. First, when testing, I found out that "kernels
loop" wasn't checked for – only serial/parallel loop and an "acc loop".
For nested loops, besides using the "collapse" clause also the "tile"
clause can be used. Internally, those are processed identically (on the
FE side)
On 23/02/20 15:18 +0200, Ville Voutilainen wrote:
This shebang adds library tests for all cases of parenthesized aggregate
initialization that I could find. Tested locally on Linux-x64, going to
test with full suite on Linux-PPC64, OK for trunk if tests pass?
Please add: { dg-do run { target
… and fixing the syntax error (duplicated ).
Tobias
commit 8c721971af041d5df125d83df5a5b2d1390d77ac
Author: Tobias Burnus
Date: Mon Feb 24 11:28:31 2020 +0100
htdocs/gcc-10/changes.html – fix syntax
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index
Hi,
On Fri, 21 Feb 2020 at 21:23, Jeff Law wrote:
>
> On Fri, 2020-02-21 at 18:59 +0100, Martin Jambor wrote:
> > Hi,
> >
> > On Tue, Feb 18 2020, Feng Xue OS wrote:
> > > Currently, for self-recursive call, we never use value originated from
> > > non-passthrough
> > > jump function as source
Hi,
On Sun, 23 Feb 2020 at 22:26, Vladimir Makarov wrote:
>
> The following patch is for
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564
>
> The patch was successfully bootstrapped on x86-64 and benchmarked on
> SPEC2000.
>
It seems this patch causes regression on some arm cores (seen
Hi all,
I have committed a quip for OpenACC and AMD GCN. Comments and
suggestions are welcome. Thanks for Andrew and Sandra for comments on an
early draft.
Tobias
PS: The linked OpenACC wiki page is unfortunately not yet fully up to date…
commit 8c9fba2f83ef9bdace2fb6288f555c78949adfb6
On Mon, 17 Feb 2020, Martin Liška wrote:
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
This (or rather its predecessor?) breaks bootstrap on 32-bit
i386-unknown-freebsd11.3.
/scratch/tmp/gerald/gcc10-devel-work/gcc-10-20200223/gcc/value-prof.c: In
function 'void
On Mon, 24 Feb 2020, Li Jia He wrote:
Hi,
On 2020/2/22 11:12 PM, Marc Glisse wrote:
On Tue, 18 Feb 2020, Li Jia He wrote:
Also the pattern doing the standalone transform does
/* Optimize TRUNC_MOD_EXPR by a power of two into a BIT_AND_EXPR,
i.e. "X % C" into "X & (C - 1)", if X and C
88 matches
Mail list logo
