https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980
--- Comment #16 from G. Steinmetz ---
Yeah, and other parts are sort of amazing too.
Let me allow to cite the complete 4.2, item 2, points (1)-(10) :
2 A processor conforms to this document if:
(1) it executes any standard-conforming program
On 7/7/20 6:40 PM, Marek Polacek wrote:
+ "% type specifier is a C++14 extension");
The usual phrasing is "...only available with %<-std=c++14%> or
%<-std=gnu++14%>". OK with that change.
Jason
On 7/7/20 3:36 PM, Patrick Palka wrote:
On Tue, 7 Jul 2020, Jason Merrill wrote:
On 7/7/20 9:33 AM, Patrick Palka wrote:
We are ICEing in the testcase below because we pass the
yet-uninstantiated class type A of the PARM_DECL b to
is_really_empty_class from
On Tue, Jul 7, 2020 at 6:59 AM CHIGOT, CLEMENT wrote:
>
> Description:
> On AIX, the compiler is able to handle DWARF-5 but not the linker.
>
> Changelog:
> 2020-07-07 Clement Chigot
> * configure.ac: Extend check to the linker for DWARF-5 support
> * configure: Regenerate
>
> Please apply
Segher Boessenkool writes:
Thanks all!
> Hi!
>
> On Mon, Jul 06, 2020 at 03:13:13PM +0800, guojiufu wrote:
>> For very small loops (< 6 insns), it would be fine to unroll 4
>> times to use cache line better. Like below loops:
>> `while (i) a[--i] = NULL; while (p < e) *d++ = *p++;`
>
> Yes,
On 2020/7/8 05:31, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Jul 07, 2020 at 04:39:58PM +0800, luoxhu wrote:
>>> Lots of questions, sorry!
>>
>> Thanks for the nice suggestions of the initial patch contains many issues:),
>
> Pretty much all of it should *work*, it just can be improved and
will schmidt writes:
Thanks!
> On Mon, 2020-07-06 at 15:13 +0800, guojiufu via Gcc-patches wrote:
>
> Hi,
>
> Assorted comments below. thanks :-)
>
>> For very small loops (< 6 insns), it would be fine to unroll 4
>> times to use cache line better. Like below loops:
>> `while (i) a[--i] =
The linux kernel guys are discussing about supporting TLS register based
stack proctector canary, the link is as follows:
https://lore.kernel.org/linux-riscv/202007051820.DABE7F87D7@keescook/T/#t
I implemented register based stack protector canary with reference to
aarch64 and x86. When
On Tue, Jul 07, 2020 at 12:45:08PM -0500, Aaron Sawdey via Gcc-patches wrote:
> Updated slightly, removed -Wno-psabi as requested and also fixed the
> fact that it wasn't actually checking __builtin_cpu_is or
> __builtin_cpu_supports. OK for trunk and backport to 10?
But you don't need that, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
--- Comment #14 from Ian McInerney ---
Is it possible to backport this to the GCC 10 branch? The printing of these
notes makes this warning almost impossible to use on any large project that
uses the standard library.
Hi!
On Mon, Jul 06, 2020 at 03:13:13PM +0800, guojiufu wrote:
> For very small loops (< 6 insns), it would be fine to unroll 4
> times to use cache line better. Like below loops:
> `while (i) a[--i] = NULL; while (p < e) *d++ = *p++;`
Yes, definitely.
> And for very complex loops which may
On 7/6/20 10:02 PM, Hans-Peter Nilsson via Gcc-patches wrote:
We say very little about reads and writes to aggregate /
compound objects, just scalar objects (i.e. assignments don't
cause reads). Let's lets say something safe about aggregate
objects, but only for those that are the same size as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95935
--- Comment #2 from Marek Polacek ---
Doesn't have to be scoped enum:
template struct X { };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95935
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|error-recovery
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92427
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Fixed in r10-5578.
PR c++/92427
* g++.dg/ext/flexary37.C: New test.
---
gcc/testsuite/g++.dg/ext/flexary37.C | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/ext/flexary37.C
diff --git a/gcc/testsuite/g++.dg/ext/flexary37.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92427
--- Comment #4 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:36e8db7c2af254a38fba5a874a3104a2cc1b1aac
commit r11-1907-g36e8db7c2af254a38fba5a874a3104a2cc1b1aac
Author: Marek Polacek
Date:
Segher:
I have fixed the issues you mentioned in version 2. I also rebased the
patch onto the latest mainline. This resulted in having to change
FUTURE to P10 everywhere.
I reran regression testing on Power 9 with no regression issues.
I also ran test cases manually on mambo.
Please let me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92427
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95789
--- Comment #5 from Marek Polacek ---
Another test:
// PR c++/96104
template void fn(T &);
class E {};
struct F {
template void mfn(T t) { t, fn(E()); } // { dg-error "cannot
bind non-const lvalue reference" }
};
int
main()
{
E e;
F f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96104
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95789
Marek Polacek changed:
What|Removed |Added
CC||60rntogo at gmail dot com
--- Comment
On 03/07/20 08:37 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the patch to fix the 2nd point of this mail below.
   I prefer to qualify _Rb_tree_impl move constructor based on
std::is_nothrow_move_constructible<_Base_key_compare> so that the
logic of copying _Compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96105
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96104
--- Comment #2 from Marek Polacek ---
Reduced:
// PR c++/96104
template void fn(T &);
class E {};
struct F {
template void mfn(T t) { t, fn(E()); } // { dg-error "cannot
bind non-const lvalue reference" }
};
int
main()
{
E e;
F f;
This is a harmless bug, as the script still works, but curl's '-O'
option isn't the same as wget's.
contrib/ChangeLog:
* download_prerequisites: Don't pass wget options to curl.
---
contrib/download_prerequisites | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 07/07/20 23:38 +0100, Jonathan Wakely wrote:
Also remove leading spaces that are followed by tabs.
libstdc++-v3/ChangeLog:
* include/std/limits: Whitespace changes.
I missed a couple of leading spaces, fixed with this one.
Committed to trunk.
commit
If you try to use decltype(auto) in C++11, we emit obscure
error: expected primary-expression before 'auto'
giving the user no hint as to what's wrong. This patch improves that
diagnostic. Since we've been giving an error, I'm also using error().
Bootstrapped/regtested on
I recently added std::__detail::__int_limits as a lightweight
alternative to std::numeric_limits, forgetting that the values it
provides (digits, min and max) are already provided by
__gnu_cxx::__numeric_traits.
This change adds __int_traits as an alias for __numeric_traits_integer.
This avoids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96104
Marek Polacek changed:
What|Removed |Added
Summary|internal compiler error: in |[10/11 Regression] internal
Also remove leading spaces that are followed by tabs.
libstdc++-v3/ChangeLog:
* include/std/limits: Whitespace changes.
Committed to trunk.
commit 9ca8fefeb720c8a9dec58e9a99042e6727309251
Author: Jonathan Wakely
Date: Tue Jul 7 23:26:38 2020 +0100
libstdc++: Whitespace changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96105
Bug ID: 96105
Summary: GCC not consistent on whether no_unique_address array
is an empty data member
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96102
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Hi!
On Tue, Jul 07, 2020 at 04:39:58PM +0800, luoxhu wrote:
> > Lots of questions, sorry!
>
> Thanks for the nice suggestions of the initial patch contains many issues:),
Pretty much all of it should *work*, it just can be improved and
simplified quite a bit :-)
> For this case, %1:SF matches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96104
Bug ID: 96104
Summary: internal compiler error: in finish_expr_stmt, at
cp/semantics.c:681
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96103
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980
--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #14)
> Even the standards changed, too.
> F2018 has the audacity to demand chapter 4.2, item 2.
"(2) it contains the capability to detect and report the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96085
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
That one produces a strange regression with pr50392.f.
Patch that regtests fine:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index
The sourceware.org/ml/libc-hacker links being broken (as a consequence
of the sourceware.org upgrade) brought my attention to this bit of
c99status.html.
This simplifies that section, uses active voice, and removes those three
links from twenty years ago.
Pushed.
Gerald
---
Hi!
On Mon, Jul 06, 2020 at 03:11:17AM +0200, Hans-Peter Nilsson wrote:
> TL;DR: fixing a misdetection of what is a "simple move".
As set before, this is not a fix, not a "misdetection", it is plain and
simple a behaviour change.
"Use single_set for is_just_move" would be a fine subject.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95303
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95303
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:9845b7b45621e3833aee47276cb111e43be0e48b
commit r11-1903-g9845b7b45621e3833aee47276cb111e43be0e48b
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96085
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
Hi!
On Tue, Jul 07, 2020 at 02:50:09AM +0200, Hans-Peter Nilsson wrote:
> > On Mon, Jul 06, 2020 at 03:11:17AM +0200, Hans-Peter Nilsson wrote:
> > > TL;DR: fixing a misdetection of what is a "simple move".
> >
> > That is not a very correct characterisation of what this does :-)
>
> That's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96103
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549225.html
On 6/30/20 6:23 PM, Martin Sebor wrote:
An enhancement to GCC 10 to improve the expansion of strncmp
calls with strings with embedded nuls introduced a regression
in similar calls to memcmp. A review of the changes that led
This patch adds execution tests that use the MMA builtins and
check for the right answer, and a new test that checks whether
__builtin_cpu_supports and __builtin_cpu_is return sane answers.
One final time now that I've gotten things sorted out. OK for trunk
and backport to 10?
Thanks,
Aaron
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93337
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93337
--- Comment #7 from CVS Commits ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:ed54352ccfc3f0ec6c14e61035a78d06d5d44194
commit r9-8724-ged54352ccfc3f0ec6c14e61035a78d06d5d44194
Author: Harald Anlauf
On Tue, 7 Jul 2020, Jason Merrill wrote:
> On 7/7/20 9:33 AM, Patrick Palka wrote:
> > We are ICEing in the testcase below because we pass the
> > yet-uninstantiated class type A of the PARM_DECL b to
> > is_really_empty_class from potential_rvalue_constant_expression when
> > parsing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #7)
> f951`gfc_resolve_formal_arglist(proc=0x00014301fbb0) at resolve.c:313:18
> frame #2: 0x0001000eb283
Setting a breakpoint here and
On 7/7/20 9:33 AM, Patrick Palka wrote:
We are ICEing in the testcase below because we pass the
yet-uninstantiated class type A of the PARM_DECL b to
is_really_empty_class from potential_rvalue_constant_expression when
parsing the requirement t += b.
Why are we getting to
[Sorry, been sitting on this patch for a while and just realised
I never sent it.]
This is yet another PR caused by constant integer rtxes not storing
a mode. We were calling REDUCE_BIT_FIELD on a constant integer that
didn't fit in poly_int64, and then tripped the as_a
assert on VOIDmode.
The code snippet for this test was returning 1 if power10
instructions executed correctly. It should return 0 if the
test passes.
Approved offline by Segher with slight change. Will
push after posting.
* lib/target-supports.exp (check_power10_hw_available):
Return 0 for passing
On 7/7/20 9:33 AM, Patrick Palka wrote:
In the testcase below, we pretty print the nested type A::B as
A::B because we don't check that B is itself a class template
before printing the innermost set of template arguments from B's
TEMPLATE_INFO (which in this case belongs to A). This patch fixes
On Tue, 7 Jul 2020, Patrick Palka wrote:
> We are ICEing in the testcase below because we pass the
> yet-uninstantiated class type A of the PARM_DECL b to
> is_really_empty_class from potential_rvalue_constant_expression when
> parsing the requirement t += b.
>
> This patch fixes the ICE by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96084
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-07-07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96058
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
As Dominique pointed out in the PR, the committed patch (part 1) fixed only
one of the provided testcases, but not the original one. That turned out
to be a long and winding road, requiring further checks for NULL pointer
dereferences.
The resulting attached changes have been regtested on
Ping. Despite its size, there isn't much new in the patch, it
pretty much just splits an existing warning into two, one for
buffer overflow and another for "overread."
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
On 6/23/20 8:05 PM, Martin Sebor wrote:
-Wstringop-overflow
Hello,
On Tue, Jul 7, 2020 at 7:46 AM Jakub Jelinek wrote:
> On Tue, Jul 07, 2020 at 07:38:13AM -0400, y2s1982 . wrote:
> > > I have no idea what this function is doing, but e.g. from aliasing
> point of
> > > view trying to access something as short/int/long long is dangerous,
> and
> > >
I discovered I'd missed applying a testcase when fixing up the EOF token
location a while back.
gcc/testsuite/
* c-c++-common/cpp/pragma-eof.c: New
--
Nathan Sidwell
diff --git c/gcc/testsuite/c-c++-common/cpp/pragma-eof.c w/gcc/testsuite/c-c++-common/cpp/pragma-eof.c
new file
I discovered I'd missed applying a testcase when fixing up the EOF token
location a while back.
gcc/testsuite/
* c-c++-common/cpp/pragma-eof.c: New
--
Nathan Sidwell : Facebook
diff --git c/gcc/testsuite/c-c++-common/cpp/pragma-eof.c
With C++ module header units it becomes important to distinguish between
macros defined in forced headers (& commandline & builtins) from those
defined in the header file being processed. We weren't making that easy
because we treated the builtins and command-line locations somewhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96100
Dominique d'Humieres changed:
What|Removed |Added
Target Milestone|--- |9.4
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96058
--- Comment #6 from Martin Sebor ---
The stack trace in comment #0:
during GIMPLE pass: strlen
../../chrome/browser/ui/views/sharing/sharing_icon_view.cc: In member function
‘GetVectorIconBadge’:
The code snippet for this test was returning 1 if power10
instructions executed correctly. It should return 0 if the
test passes.
OK for trunk and backport to 10?
Thanks,
Aaron
* lib/target-supports.exp (check_power10_hw_available):
Return 0 for passing test.
---
Updated slightly, removed -Wno-psabi as requested and also fixed the
fact that it wasn't actually checking __builtin_cpu_is or
__builtin_cpu_supports. OK for trunk and backport to 10?
Thanks,
Aaron
2020-06-30 Rajalakshmi Srinivasaraghavan
Aaron Sawdey
gcc/testsuite/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96099
--- Comment #2 from G. Steinmetz ---
Oh yes, of course ... a silly cut and paste thing.
It has to be :
$ cat z1.f90
program p
implicit class(t) (1)
type t
end type
end
$ cat z2.f90
program p
integer n1
parameter (n1 = 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96103
Bug ID: 96103
Summary: Unclear diagnostic for a function return with
"decltype(auto)"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96099
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2020-07-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96099
--- Comment #1 from Dominique d'Humieres ---
Confirmed before r11-1337, but r11-1810 (instrumented) and r11-1864 (+patches)
do not give the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
--- Comment #13 from Martin Sebor ---
Jon, is there anything else to do here or can we resolve this as fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96102
Bug ID: 96102
Summary: ICE in check_host_association, at
fortran/resolve.c:5994
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96102
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980
--- Comment #14 from G. Steinmetz ---
> ... and real programmers wrote fine Fortran programs.
Yeah, optimal world. That's probably the reason why some
"real" programs don't need test cases - or at most three,
because they cover everything ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
--- Comment #12 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:6f9c9ea40a1e937ea1b549625cf7762d4a8a2078
commit r11-1899-g6f9c9ea40a1e937ea1b549625cf7762d4a8a2078
Author: Martin Sebor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96087
--- Comment #3 from G. Steinmetz ---
Thanks for nailing down the commit for addon comment 1.
But when started the regression/issue from comment 0 ?
gfortran 9.3 does not have the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96101
Bug ID: 96101
Summary: [9/10/11 Regression] ICE in fold_convert_loc, at
fold-const.c:2398
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96100
Bug ID: 96100
Summary: [9/10/11 Regression] ICE in gimplify_expr, at
gimplify.c:14638
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96099
Bug ID: 96099
Summary: ICE in gfc_validate_kind, at fortran/trans-types.c:773
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Richard Biener writes:
> This fixes a condition that caused all negative step DR groups to
> be detected as single element interleaving. Such groups are
> rejected by interleaving vectorization but miscompiled by SLP
> which is fixed by forcing VMAT_STRIDED_SLP for now.
>
> Bootstrap & regtest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96098
Bug ID: 96098
Summary: [11 regression] gcc.dg/vect/bb-slp-pr68892.c fails
since r11-205
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #11 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96097
--- Comment #1 from Michael Bruck ---
trunk:
internal compiler error: in dependent_type_p, at cp/pt.c:26326
10.1:
internal compiler error: in dependent_type_p, at cp/pt.c:26343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96097
Bug ID: 96097
Summary: ICE in dependent_type_p, at cp/pt.c:26326
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
On Mon, 2020-07-06 at 15:13 +0800, guojiufu via Gcc-patches wrote:
Hi,
Assorted comments below. thanks :-)
> For very small loops (< 6 insns), it would be fine to unroll 4
> times to use cache line better. Like below loops:
> `while (i) a[--i] = NULL; while (p < e) *d++ = *p++;`
>
> And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96096
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95789
Marek Polacek changed:
What|Removed |Added
CC||agadethrowaway at gmail dot com
---
On Tue, Jul 7, 2020 at 8:56 AM Kirill Yukhin wrote:
>
> Hello HJ,
>
> On 28 июн 07:19, H.J. Lu via Gcc-patches wrote:
> > Enable FMA in rsqrt2 expander and fold rsqrtv16sf2 expander into
> > rsqrt2 expander which expands to UNSPEC_RSQRT28 for TARGET_AVX512ER.
> > Although it doesn't show
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96096
Bug ID: 96096
Summary: g++-10.1 silently ignores function violating const
instead of refusing to compile
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Hello HJ,
On 28 июн 07:19, H.J. Lu via Gcc-patches wrote:
> Enable FMA in rsqrt2 expander and fold rsqrtv16sf2 expander into
> rsqrt2 expander which expands to UNSPEC_RSQRT28 for TARGET_AVX512ER.
> Although it doesn't show performance change in our workloads, FMA can
> improve other workloads.
>
Hi,
thank you for looking into this.
I prepared new patch with all your comments addressed.
Thanks,
Dmitrij
On Tue, Jun 23, 2020 at 05:53:00PM +0100, Richard Sandiford wrote:
...
>
> I think it would be simpler to do it in this order:
>
> - check for Advanced SIMD, bail out if not
> -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96095
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96049
Maxim Kuvyrkov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
On Tue, 7 Jul 2020 at 15:41, Nino Pereira via Gcc wrote:
>
> The top line in
> https://gcc.gnu.org/onlinedocs/gcc-4.6.3/gfortran/BOZ-literal-constants.html
>
> says " The syntax is: `prefix quote digits quote', were the prefix is
> either b, o or z,"
>
> Here, 'were' must be 'where'
Thanks. That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038
Arjen Markus changed:
What|Removed |Added
CC||arjen.markus895 at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94260
Patrick Palka changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
As I don't have the commit privilege, if this is a sufficient approval
can someone commit it for me?
--
Thanks,
Anton
On 06.7.2020 21:04 , Richard Sandiford wrote:
Joel Jones writes:
I approve of this patch. I'm responsible for GCC for TX2 at Marvell. Andrew
Pinski should certainly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96095
Bug ID: 96095
Summary: decltype((r)) inside of lambda with copy capture gives
wrong type
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
1 - 100 of 217 matches
Mail list logo
