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 Russian team of translators. The file is available at:
https://translationproject.org/latest/cpplib/ru.po
(This file,
cpplib-10.1-b20200209.ru.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
The rule change in the title matches GCC's current behavior, so no change
was needed. But the paper also makes 'typename' optional in a
requirement-parameter-list, so this implements that.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-02-28 Jason Merrill
On Fri, Feb 28, 2020 at 4:16 PM Jeff Law wrote:
>
> On Thu, 2020-02-27 at 06:50 -0800, H.J. Lu wrote:
> >
> > How about this? If it looks OK, I will post the whole patch set.
> It's better. I'm guessing the two cases that were previously handled with
> vextract/vbroadcast aren't supposed to
On Thu, 2020-02-27 at 06:50 -0800, H.J. Lu wrote:
>
> How about this? If it looks OK, I will post the whole patch set.
It's better. I'm guessing the two cases that were previously handled with
vextract/vbroadcast aren't supposed to happen? They're caught here IIUC:
> + /* NB: To move
On 27/02/20 00:02 +, Jonathan Wakely wrote:
On Wed, 26 Feb 2020 at 18:31, Daniel Krügler wrote:
Am Mi., 26. Feb. 2020 um 16:20 Uhr schrieb Jonathan Wakely :
>
> This introduces a couple of convenience alias templates to be used for
> some repeated patterns using std::conditional_t.
I find
On Thu, 2020-02-27 at 15:40 -0700, Martin Sebor wrote:
> GCC considers valid explicit declarations of built-ins whose return
> types match in their modes, even if the types themselves are
> incompatible (say integer and pointer of the same size). This is
> more permissive than for argument types
On Fri, 28 Feb 2020, Tobias Burnus wrote:
> Regarding MIN and MAX: I think the IEEE 754 decided at some point
> decided that MAX(x, NaN) = x (IEEE 754:2008 alias ISO 60559:2011, if I
> recall correctly). I think one has to check what exactly the test case
> does and what is guaranteed where. I
On 17/02/20 15:32 +, Jonathan Wakely wrote:
Many uses of std::numeric_limits in C++17 and C++20 features only really
need the min(), max() and digits constants for integral types. By adding
__detail::__int_limits we can avoid including the whole header.
The header isn't especially large,
On 28/02/20 14:59 -0500, Patrick Palka wrote:
We were enabling the memcmp optimization in ranges::lexicographical_compare for
signed integral types and for integral types larger than a byte. But memcmp
gives the wrong answer for arrays of such types. This patch fixes this issue by
refining the
On 2/28/20 4:12 PM, Alexey Neyman wrote:
On 2/28/20 12:28 PM, Jason Merrill wrote:
On 2/28/20 2:11 PM, Alexander Monakov wrote:
On Fri, 28 Feb 2020, Eric Botcazou wrote:
+1 - I think Alexey correctly pointed out in the Bugzilla that
debuginfo
growth from this change would be minimal
On Fri, 28 Feb 2020, Alexandre Oliva wrote:
> I'm not sure it's appropriate for the error to not omit the host
> platform's executable suffix, just as it omits directory components from
> argv[0], so I'm undecided between fixing collect2.c's initialization of
> progname or extending the regexp,
On Fri, Feb 28, 2020 at 1:16 PM Jeff Law wrote:
>
> On Fri, 2020-02-28 at 05:54 -0800, H.J. Lu wrote:
> > On Fri, Feb 28, 2020 at 5:44 AM Maciej W. Rozycki wrote:
> > > On Fri, 28 Feb 2020, H.J. Lu wrote:
> > >
> > > > > libffi/
> > > > > * configure.ac: Add
On Wed, 2020-02-26 at 15:51 -0700, Martin Sebor wrote:
> GCC accepts attribute format even on functions without a prototype.
> However, when such a function is subsequently redeclared with
> a prototype the attribute validation runs into trouble. To avoid
> the ICE I considered a) dropping the
On Tue, 2020-02-25 at 17:52 +0800, Kewen.Lin wrote:
> Hi,
>
> Several scev/IVOPTs cases aim to check some array references are sceved and
> later marked as REFERENCE ADDRESS IV groups. With IV group type dumping
> improving, these check strings can be improved. Otherwise, they become
> fragile
>
On Fri, 2020-02-28 at 05:54 -0800, H.J. Lu wrote:
> On Fri, Feb 28, 2020 at 5:44 AM Maciej W. Rozycki wrote:
> > On Fri, 28 Feb 2020, H.J. Lu wrote:
> >
> > > > libffi/
> > > > * configure.ac: Add testsuite/libffi-site-extra.exp to output
> > > > files.
> > > > *
On Wed, 2020-02-26 at 16:59 +0200, Claudiu Zissulescu wrote:
> All ARC's small data adressing is using address scaling feature of the
> load/store instructions (i.e., the address is made of a general
> pointer plus a shifted offset. The shift amount depends on the
> addressing mode). This patch
On 2/28/20 12:28 PM, Jason Merrill wrote:
On 2/28/20 2:11 PM, Alexander Monakov wrote:
On Fri, 28 Feb 2020, Eric Botcazou wrote:
+1 - I think Alexey correctly pointed out in the Bugzilla that
debuginfo
growth from this change would be minimal (usually the number of global
variables is
On Wed, 2020-02-26 at 16:18 -0700, Martin Sebor wrote:
> On 2/26/20 3:09 PM, Jeff Law wrote:
> > On Wed, 2020-02-19 at 17:26 -0700, Martin Sebor wrote:
> > > The buffer overflow detection for multi-char stores uses the size
> > > of a source array even when what's actually being accessed (read
> >
Hi,
The awaitable initially committed for this test was returning
"always ready” which meant that the suspension code was not
used. Update the test to suspend at each co_await, since this
exercises more of the infrastructure.
tested on x86_64-darwin16,
applied to master,
thanks
Iain
On 2/28/20 2:11 PM, Alexander Monakov wrote:
On Fri, 28 Feb 2020, Eric Botcazou wrote:
+1 - I think Alexey correctly pointed out in the Bugzilla that debuginfo
growth from this change would be minimal (usually the number of global
variables is very small compared to number of functions (and
This libgo patch by eric fang sets sigpc and implement dumpregs for
arm64 GNU/Linux. Without this change, the cmd/vet tool test will fail
randomly, as discussed at https://golang.org/issue/20931.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
On 2/28/20 12:45 PM, Martin Sebor wrote:
On 2/28/20 9:58 AM, Jason Merrill wrote:
On 2/24/20 6:58 PM, Martin Sebor wrote:
-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.
This change:
> commit 3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d
> Author: Vladimir N. Makarov
> Date: Sun Feb 23 16:20:05 2020 -0500
>
> Changing cost propagation and ordering colorable bucket heuristics for
> PR93564.
>
> 2020-02-23 Vladimir Makarov
>
> PR
LAST_UPDATED: Thu Feb 27 09:29:19 UTC 2020 (revision r10-6885-g5f9cd512c427)
=== acats tests ===
=== acats Summary ===
# of expected passes2320
# of unexpected failures0
Native configuration is x86_64-apple-darwin16
=== g++
We were enabling the memcmp optimization in ranges::lexicographical_compare for
signed integral types and for integral types larger than a byte. But memcmp
gives the wrong answer for arrays of such types. This patch fixes this issue by
refining the condition that enables the memcmp optimization.
On Fri, 28 Feb 2020, Eric Botcazou wrote:
> > +1 - I think Alexey correctly pointed out in the Bugzilla that debuginfo
> > growth from this change would be minimal (usually the number of global
> > variables is very small compared to number of functions (and linemap info).
>
> Well, this will
We don't want to promote a conversion from viable == 0 to viable == -1.
Found in ranges-v3.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-02-28 Jason Merrill
* call.c (build_user_type_conversion_1): Don't look at the second
conversion of a non-viable
And it only needs to define _GLIBCXX_ASSERTIONS not _GLIBCXX_DEBUG.
* testsuite/24_iterators/range_operations/advance_debug_neg.cc: Run
test instead of just compiling it.
Tested x86_64-linux, committed to master.
commit 4735f92d48c373031be296fd0f7a2cf31fc955da
Author: Jonathan
Committed as revision r10-6924-g7485ace81de9ec9dd5c87edf67e359d31ce35a20
On Fri, 28 Feb 2020 at 12:15, Paul Richard Thomas
wrote:
>
> I will commit this tonight as 'obvious' unless there are any
> complaints. This descriptor renormalisation is already present in
> gfc_conv_derived_to_class.
>
>
On 28/02/20 12:57 -0500, Patrick Palka wrote:
On Fri, 28 Feb 2020, Jonathan Wakely wrote:
On 26/02/20 10:28 -0500, Patrick Palka wrote:
> On Wed, 26 Feb 2020, Jonathan Wakely wrote:
>
> > On 25/02/20 15:36 -0500, Patrick Palka wrote:
> > > This adds constexpr to 11 algorithms defined in as
On Fri, Feb 28, 2020 at 06:50:20PM +0100, Thomas Koenig wrote:
> Am 28.02.20 um 17:58 schrieb Steve Kargl:
> > Replacing MIN_EXPR/MAX_EXPR (everywhere?) would seem to
> > be a pessimization for correctly written code.
>
> Also note the following part of changes.html for 9.2:
>
> The MAX and MIN
On Fri, 28 Feb 2020, Jonathan Wakely wrote:
> On 26/02/20 10:28 -0500, Patrick Palka wrote:
> > On Wed, 26 Feb 2020, Jonathan Wakely wrote:
> >
> > > On 25/02/20 15:36 -0500, Patrick Palka wrote:
> > > > This adds constexpr to 11 algorithms defined in as per
> > > P1645R1.
> > > >
> > > >
On Fri, Feb 28, 2020 at 04:32:05PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 28, 2020 at 04:11:15PM +0100, Tobias Burnus wrote:
> > On 2/28/20 3:53 PM, Segher Boessenkool wrote:
> > > It happens with -O2 already. The frontend generates a MIN_EXPR (or
> > > MAX_EXPR) for this, which is undefined
On 10/23/19 2:11 PM, Martin Liška wrote:
On 9/2/19 10:56 AM, Martin Liška wrote:
Hi.
There are 2 more patches that I've just tested.
Martin
Hi.
There are 2 more patches that I've just tested.
Martin
Hi.
There's one more patch.
Martin
>From 08bf7bde9f2987b1c623d272cc71fc14a1622442 Mon
Am 28.02.20 um 17:58 schrieb Steve Kargl:
Replacing MIN_EXPR/MAX_EXPR (everywhere?) would seem to
be a pessimization for correctly written code.
Also note the following part of changes.html for 9.2:
The MAX and MIN intrinsics are no longer guaranteed to return any
particular value in case one
On 2/28/20 9:58 AM, Jason Merrill wrote:
On 2/24/20 6:58 PM, Martin Sebor wrote:
-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
> +1 - I think Alexey correctly pointed out in the Bugzilla that debuginfo
> growth from this change would be minimal (usually the number of global
> variables is very small compared to number of functions (and linemap info).
Well, this will drag the associated types too, so figures would be
Hi,
On Fri, 28 Feb 2020, Alexey Neyman wrote:
> On 2/26/20 11:40 AM, Richard Biener wrote:
>
> Attached is a revised patch that enables DIE generation for external variables
> at -g1 without an additional option.
I can't substantially review the patch, but there's a couple of nits that
will
On 2/26/20 11:40 AM, Richard Biener wrote:
On February 26, 2020 8:26:06 PM GMT+01:00, Alexander Monakov
wrote:
On Wed, 26 Feb 2020, Jason Merrill wrote:
Don't we want to fix the DWARF behavior to match the documentation?
+1 - I think Alexey correctly pointed out in the Bugzilla that
On 26/02/20 10:28 -0500, Patrick Palka wrote:
On Wed, 26 Feb 2020, Jonathan Wakely wrote:
On 25/02/20 15:36 -0500, Patrick Palka wrote:
> This adds constexpr to 11 algorithms defined in as per P1645R1.
>
> Tested on x86_64-pc-linux-gnu, OK to commit?
>
> libstdc++-v3/ChangeLog:
>
>P1645R1
On Fri, Feb 28, 2020 at 04:11:15PM +0100, Tobias Burnus wrote:
> On 2/28/20 3:53 PM, Segher Boessenkool wrote:
> > It happens with -O2 already. The frontend generates a MIN_EXPR (or
> > MAX_EXPR) for this, which is undefined for NaNs already. I think the
> > testcase is just invalid?
>
> Ups,
On Fri, Feb 28, 2020 at 05:54:56PM +0100, Martin Liška wrote:
> On 2/28/20 5:28 PM, Jakub Jelinek wrote:
> > That is not what you did (or at least you should pretend you didn't do it
> > that
> > way). Please write it as
> > * configure.ac: Improve ...
> > * configure: Regenerated.
>
>
On 2/24/20 6:58 PM, Martin Sebor wrote:
-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
On Wed, 2020-02-26 at 16:59 +0200, Claudiu Zissulescu wrote:
> Early expand ADDDI3 and SUBDI3 for better code gen.
>
> gcc/
> -xx-xx Claudiu Zissulescu
>
> * config/arc/arc.md (adddi3): Early expand the 64bit operation into
> 32bit ops.
> (subdi3): Likewise.
>
On Fri, Feb 28, 2020 at 04:04:10PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 28, 2020 at 08:53:11AM -0600, Segher Boessenkool wrote:
> > On Thu, Feb 27, 2020 at 09:25:27PM -0800, Steve Kargl wrote:
> > > On Fri, Feb 28, 2020 at 01:02:28PM +0800, Jiufu Guo wrote:
> > > >
> > > > With -ffast-math
On Wed, 2020-02-26 at 16:59 +0200, Claudiu Zissulescu wrote:
> With the refurbish of ARC600' accumulator support, the mlo_operand
> doesn't reflect the proper low accumulator register for the newer
> ARCv2 accumulator register used by the fma instructions, replace
> it with accl_operand predicate.
On Wed, 2020-02-26 at 16:59 +0200, Claudiu Zissulescu wrote:
> Add length attribute to eh_return pattern.
>
> gcc/
> -xx-xx Claudiu Zissulescu
>
> * config/arc/arc.md (eh_return): Add length info.
OK
jeff
>
On 2/28/20 5:28 PM, Jakub Jelinek wrote:
That is not what you did (or at least you should pretend you didn't do it that
way). Please write it as
* configure.ac: Improve ...
* configure: Regenerated.
Sorry, I didn't pay enough attention to the ChangeLog entry.
Ok with that
On 28/02/20 11:34 -0500, Patrick Palka wrote:
When the underlying range models common_range, then reverse_view::begin() is
O(1) without caching. So we should disable the cache in this case too.
libstdc++-v3/ChangeLog:
* include/std/ranges (reverse_view::_S_needs_cached_begin): Set to
On 2020-02-24 4:54 a.m., Christophe Lyon wrote:
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
The following patch is dealing with arm failures after submitting
original patch for PR93564.
Changing heuristics in the original patch resulted in different order
of allocation and creating gaps in hard reg file which were not enough
for pseudos requiring double regs. So RA started to
‐‐‐ Original Message ‐‐‐
On Thursday, February 27, 2020 4:32 PM, Bill Schmidt
wrote:
> On 2/27/20 2:21 PM, Bill Schmidt wrote:
>
> > On 2/27/20 12:48 PM, GT wrote:
> >
> > > Done.
> > >
> > > The updated document is at:
> > >
When the underlying range models common_range, then reverse_view::begin() is
O(1) without caching. So we should disable the cache in this case too.
libstdc++-v3/ChangeLog:
* include/std/ranges (reverse_view::_S_needs_cached_begin): Set to false
whenever the underlying range
On Fri, Feb 28, 2020 at 04:23:03PM +, GT wrote:
> Do we want to change the name and title of the document since Segher doesn't
> believe it
> is an ABI. My initial suggestion: "POWER Architecture Specification of Scalar
> Function
> to Vector Function Mapping".
It is an ABI, similarly like
On Fri, Feb 28, 2020 at 05:15:29PM +0100, Martin Liška wrote:
> Hi.
>
> The patch is about better ld date format detection as
> described in the PR in more detail. I'm also changing
> '[-]' into '-' which is a simplification.
>
> Ready to be installed after tests?
> Thanks,
> Martin
>
>
Hi!
As mentioned in the PR and discussed on IRC, the following patch is the
patch that fixes the originally reported issue.
We have there because of the premature bitfield comparison -> BIT_FIELD_REF
optimization:
s$s4_19 = 0;
s.s4 = s$s4_19;
_10 = BIT_FIELD_REF ;
_13 = _10 & 8;
and no
Hi.
The patch is about better ld date format detection as
described in the PR in more detail. I'm also changing
'[-]' into '-' which is a simplification.
Ready to be installed after tests?
Thanks,
Martin
gcc/ChangeLog:
2020-02-28 Martin Liska
PR other/93965
* configure:
On Fri, Feb 28, 2020 at 6:30 AM H.J. Lu wrote:
>
> When generating the separate file with LTO debug sections, we should
> also copy .note.gnu.property section.
>
> OK for master if there is no regression?
>
> Thanks.
>
> H.J.
> ---
> libiberty/
>
> PR lto/93966
> * simple-object.c
On Fri, Feb 28, 2020 at 04:11:15PM +0100, Tobias Burnus wrote:
> On 2/28/20 3:53 PM, Segher Boessenkool wrote:
> > It happens with -O2 already. The frontend generates a MIN_EXPR (or
> > MAX_EXPR) for this, which is undefined for NaNs already. I think the
> > testcase is just invalid?
>
> Ups,
On 2/28/20 3:23 AM, Jakub Jelinek wrote:
Hi!
Seems I've missed one thing, as the first hunk in
https://github.com/cplusplus/draft/commit/c8e68ed202b4a9260616bcee8a9768b5dca4bbca
changes the wording so that only potentially-evaluated id-expressions that
denote immediate functions must appear
On 2/28/20 3:53 PM, Segher Boessenkool wrote:
It happens with -O2 already. The frontend generates a MIN_EXPR (or
MAX_EXPR) for this, which is undefined for NaNs already. I think the
testcase is just invalid?
Ups, that shouldn't happen. It does seem to work here
(x86-64-gnu-linux), however,
On Fri, Feb 28, 2020 at 08:53:11AM -0600, Segher Boessenkool wrote:
> On Thu, Feb 27, 2020 at 09:25:27PM -0800, Steve Kargl wrote:
> > On Fri, Feb 28, 2020 at 01:02:28PM +0800, Jiufu Guo wrote:
> > >
> > > With -ffast-math -O3, this case `STOP 3` on a few platforms, e.g.
> > > ppc64le/x86.
> >
Hi Tobias,
On Fri, Feb 28, 2020 at 10:58:36AM +0100, Tobias Burnus wrote:
> (Do you really need to post to gcc@, fortran@ and gcc-patches@?
> Shouldn't be one of the list sufficient – like fortran@?)
Many people do not read that list. I asked Jiu Fu to post to both
fortran@ and one of gcc@ and
On Thu, Feb 27, 2020 at 09:25:27PM -0800, Steve Kargl wrote:
> On Fri, Feb 28, 2020 at 01:02:28PM +0800, Jiufu Guo wrote:
> >
> > With -ffast-math -O3, this case `STOP 3` on a few platforms, e.g.
> > ppc64le/x86.
>
> IMHO, using -ffast-math with Fortran code is never correct.
> With this
When generating the separate file with LTO debug sections, we should
also copy .note.gnu.property section.
OK for master if there is no regression?
Thanks.
H.J.
---
libiberty/
PR lto/93966
* simple-object.c (handle_lto_debug_sections): Also copy
.note.gnu.property
On 27/02/20 14:26 -0500, Patrick Palka wrote:
On Wed, 26 Feb 2020, Patrick Palka wrote:
On Tue, 11 Feb 2020, Patrick Palka wrote:
> This patch adds memoization for these four views so that their begin() has the
> required constant time amortized complexity.
>
> In the general case we use
On 27/02/20 19:30 +0100, François Dumont wrote:
When I use std::is_permutation in hashtable_policy.h I included
stl_algo.h which is a large header. No other header in include/bits
does this, I would prefer not being the first to do such a thing.
As it is a recent change I prefer to submit
On Fri, Feb 28, 2020 at 5:44 AM Maciej W. Rozycki wrote:
>
> On Fri, 28 Feb 2020, H.J. Lu wrote:
>
> > > libffi/
> > > * configure.ac: Add testsuite/libffi-site-extra.exp to output
> > > files.
> > > * configure: Regenerate.
> > > *
On Fri, 28 Feb 2020, H.J. Lu wrote:
> > libffi/
> > * configure.ac: Add testsuite/libffi-site-extra.exp to output
> > files.
> > * configure: Regenerate.
> > * testsuite/libffi-site-extra.exp.in: New file.
> > * testsuite/Makefile.am
On 28/02/20 13:25 +, Jonathan Wakely wrote:
These tests were failing on XFS because it doesn't support setting file
timestamps past 2038, so the expected overflow when reading back a huge
timestamp into a file_time_type didn't happen.
Additionally, the std::filesystem::file_time_type::clock
These tests were failing on XFS because it doesn't support setting file
timestamps past 2038, so the expected overflow when reading back a huge
timestamp into a file_time_type didn't happen.
Additionally, the std::filesystem::file_time_type::clock has an
epoch that is out of range of 32-bit
On 27/02/20 14:43 -0700, Martin Sebor wrote:
Should I just add -Wno-stringop-overflow to the testcase, or would it
be worth doing something like this to inform the compiler?
I'm not sure. Since the ctor is undefined when passed a size in
excess of the argument size the warning might be useful
Hi!
On Fri, Feb 28, 2020 at 12:32:06AM -0500, Michael Meissner wrote:
> As part of my work in adding support for -mcpu=future, I noticed an insn that
> would never match.
> It will never match, because the zero_extend result is the same mode as the
> input, so the machine independent parts of
Hi all!
Proposed patch to Bug 93963 - Select rank mishandling allocatable and
pointer arguments with bind(c).
Patch tested only on x86_64-pc-linux-gnu.
cfi_desc_to_gfc_desc, in ISO_Fortran_binding.c, will likely store -1 (or
garbage) in the upper bound of the descriptor for unallocated, or
I will commit this tonight as 'obvious' unless there are any
complaints. This descriptor renormalisation is already present in
gfc_conv_derived_to_class.
Paul
2020-02-28 Paul Thomas
PR fortran/92785
* trans-expr.c (gfc_conv_intrinsic_to_class): Renormalise non-
variable
On Thu, Feb 27, 2020 at 06:53:10PM -0500, Michael Meissner wrote:
> On Thu, Feb 27, 2020 at 04:57:28PM -0600, Segher Boessenkool wrote:
> > On Thu, Feb 27, 2020 at 03:38:54PM -0500, Michael Meissner wrote:
> > > Here are the equivalent changes for PR target/93932 for the GCC 9 branch.
> > > I
>
On Thu, Feb 27, 2020 at 5:18 PM Maciej W. Rozycki wrote:
>
> Fix a problem with the libffi testsuite using a method to determine the
> compiler to use resulting in the tool being different from one the
> library has been built with, and causing a catastrophic failure from the
> inability to
Add myself to MAINTAINERS file.
2020-02-28 Joel Hutton
* MAINTAINERS (Write After Approval) : Add myself.
>From c0671c0d82c6858a90ab4abc62cdb302646f2d51 Mon Sep 17 00:00:00 2001
From: Joel Hutton
Date: Fri, 28 Feb 2020 11:06:05 +
Subject: [PATCH] Add myself to MAINTAINERS
Hi,
(Do you really need to post to gcc@, fortran@ and gcc-patches@?
Shouldn't be one of the list sufficient – like fortran@?)
On 2/28/20 6:02 AM, Jiufu Guo wrote:
When I check a PR93709, I find the testcase maxlocval_4.f90 […]
With -ffast-math -O3, this case `STOP 3` on a few platforms, e.g.
On Wed, Feb 26, 2020 at 11:42:54AM +0100, Jan Hubicka wrote:
> 2020-02-26 Jan Hubicka
>
> PR middle-end/92152
> * alias.c (ends_tbaa_access_path_p): Break out from ...
> (component_uses_parent_alias_set_from): ... here.
> * alias.h (ends_tbaa_access_path_p): Declare.
>
Hi!
Seems I've missed one thing, as the first hunk in
https://github.com/cplusplus/draft/commit/c8e68ed202b4a9260616bcee8a9768b5dca4bbca
changes the wording so that only potentially-evaluated id-expressions that
denote immediate functions must appear only in the specified contexts.
That IMO means
82 matches
Mail list logo
