https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94748
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94515
nsz at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94514
nsz at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94515
Bug 94515 depends on bug 94514, which changed state.
Bug 94514 Summary: aarch64: unwinding across mixed pac-ret and non-pac-ret
frames is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94514
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94515
--- Comment #4 from CVS Commits ---
The releases/gcc-8 branch has been updated by Szabolcs Nagy :
https://gcc.gnu.org/g:62ab8b9114b0bdae508ed76fa9028e0040d35e6b
commit r8-10253-g62ab8b9114b0bdae508ed76fa9028e0040d35e6b
Author: Szabolcs Nagy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94514
--- Comment #4 from CVS Commits ---
The releases/gcc-8 branch has been updated by Szabolcs Nagy :
https://gcc.gnu.org/g:d523cd5109bc5ab42edf85385f6a1085e0d6028c
commit r8-10252-gd523cd5109bc5ab42edf85385f6a1085e0d6028c
Author: Szabolcs Nagy
Hi Rainer,
> > Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this
> > very week I have been chasing a phenomenon with Expect's `wait' semantics
> > causing a reliable hang in remote testing if `ssh' to the target board
> > stops responding for whatever reason. I have come
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95136
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95135
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85883
Jonathan Wakely changed:
What|Removed |Added
CC||gccbugreport at yandex dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95136
Bug ID: 95136
Summary: missing -Wuninitialized on an array access with a
variable offset
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
On 5/6/20 5:48 PM, Patrick Palka wrote:
Here we're failing to do SFINAE in build_op_call when looking up the
class's operator() via lookup_fnfields, which calls lookup_member always
with complain=tf_warning_or_error. And from there we complain about an
ambiguous lookup for operator().
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95132
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
On Thu, 14 May 2020 at 17:07, Ramana Radhakrishnan
wrote:
>
> On Thu, May 14, 2020 at 3:58 PM Christophe Lyon via Gcc-patches
> wrote:
> >
> > The same code pattern occurs in several functions, so it seems cleaner
> > to move it into a dedicated function.
> >
> > 2020-05-14 Christophe Lyon
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #19 from Christophe Lyon ---
(In reply to Christophe Lyon from comment #8)
> Patch sent: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544872.html
>
> This is a simple improvement, hopefully simple enough for stage 4, yet
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94514
--- Comment #3 from CVS Commits ---
The releases/gcc-9 branch has been updated by Szabolcs Nagy :
https://gcc.gnu.org/g:6173489dbfe5828b2c4082d7a450a766779f87c7
commit r9-8592-g6173489dbfe5828b2c4082d7a450a766779f87c7
Author: Szabolcs Nagy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94515
--- Comment #3 from CVS Commits ---
The releases/gcc-9 branch has been updated by Szabolcs Nagy :
https://gcc.gnu.org/g:95833c34424f340a7e465ee38b6a41369bc7c90b
commit r9-8593-g95833c34424f340a7e465ee38b6a41369bc7c90b
Author: Szabolcs Nagy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94748
--- Comment #3 from CVS Commits ---
The releases/gcc-9 branch has been updated by Szabolcs Nagy :
https://gcc.gnu.org/g:9a1b74d49e2e25b29675fac4322bb7ba6cec5894
commit r9-8595-g9a1b74d49e2e25b29675fac4322bb7ba6cec5894
Author: Szabolcs Nagy
On 5/14/20 8:08 AM, Rainer Orth wrote:
>> stops responding for whatever reason. I have come up with a solution
>> (that I'd be happy to upstream, except that DejaGNU maintenance seems to
>> have been dead for like a year now), which I have also confirmed to be
>> required with current DejaGNU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
--- Comment #7 from CVS Commits ---
The releases/gcc-9 branch has been updated by Szabolcs Nagy :
https://gcc.gnu.org/g:f6e42cdee5de2b3441afc88cc1166bdffe57
commit r9-8594-gf6e42cdee5de2b3441afc88cc1166bdffe57
Author: Szabolcs Nagy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
--- Comment #4 from Thomas Koenig ---
So, in order for this to hang, two close statements
on the same unit are needed, the first one with an
error message.
Seems like the unit is not unlocked on the error return.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95135
Bug ID: 95135
Summary: Inconsistent CTAD behaviour with the "new" operator.
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95134
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On 5/14/20 9:04 AM, Iain Sandoe wrote:
Hi
thanks for the review and pointers ...
Nathan Sidwell wrote:
On 5/13/20 9:26 AM, Iain Sandoe wrote:
Nathan Sidwell wrote:
On 5/13/20 6:59 AM, Iain Sandoe wrote:
This is the equivalent of finish_return_stmt () in the parser, it knows nothing
Jason missed a c++2a mention. I couldn't resist changing the loop
following to place the initializers inside the fors.
pushed to master
nathan
--
Nathan Sidwell
2020-05-14 Nathan Sidwell
* parser.c (cp_parser_diagnose_invalid_typename): Mention
std=c++20 not 2a, reformat dependent binfo
On Fri, 1 May 2020 at 12:57, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: 30 April 2020 09:51
> > To: Kyrylo Tkachov
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: arm: Fix vfp_operand_register for VFP HI regs
> >
> > On Wed, 29 Apr 2020 at
On Thu, May 14, 2020 at 3:58 PM Christophe Lyon via Gcc-patches
wrote:
>
> The same code pattern occurs in several functions, so it seems cleaner
> to move it into a dedicated function.
>
> 2020-05-14 Christophe Lyon
>
> gcc/
> * config/arm/arm.c (reg_needs_saving_p): New
On Thu, May 14, 2020 at 3:57 PM Christophe Lyon via Gcc-patches
wrote:
>
> While running the tests with -march=armv5t -mthumb, I came across this
> error message which I think could be clearer.
>
> 2020-05-14 Christophe Lyon
>
> gcc/
> * config/arm/arm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95133
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-05-14
CC|
On Thu, 14 May 2020, Jeff Law wrote:
>> OK to commit?
> OK. In fact, this seems like you shouldn't need reviews -- you're just
> updating the docs for D.
Agreed, though always happy to help and provide review and feedback
- sometimes just a bit slow as in this case. But, indeed, you can
self
reg_needs_saving_p is only used when dealing with non-interrupt
routines, but it makes sense to extend it to support that context too,
and make arm_compute_save_reg0_reg12_mask use it.
Save only live registers for non-leaf functions, but assume a callee
could clobber any register.
2020-05-14
The same code pattern occurs in several functions, so it seems cleaner
to move it into a dedicated function.
2020-05-14 Christophe Lyon
gcc/
* config/arm/arm.c (reg_needs_saving_p): New function.
(use_return_insn): Use reg_needs_saving_p.
The interrupt attribute does not guarantee that the FP registers are
saved, which can result in problems difficult to debug.
Saving the FP registers and status registers can be a large penalty,
so it's probably not desirable to do that all the time.
If the handler calls other functions, we'd
While running the tests with -march=armv5t -mthumb, I came across this
error message which I think could be clearer.
2020-05-14 Christophe Lyon
gcc/
* config/arm/arm.c (thumb1_expand_prologue): Update error message.
---
gcc/config/arm/arm.c | 2 +-
1 file changed, 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
Pushed this bunch of simplifications to the template machinery. As
ever, discovered when implementing modules and figuring out how it worked.
inst-friend.diff
tsubst_friend_function's control flow was a little complicated. This
simplifies it, primarily by using more RAII.
lkp-class.diff
shl %eax
.cfi_def_cfa_offset 28
pushl $x
.cfi_def_cfa_offset 32
callmemcpy
addl$28, %esp
.cfi_def_cfa_offset 4
ret
.cfi_endproc
.LFE0:
.size func, .-func
.ident "GCC: (GNU) 11.0.0 2020051
On Mon, 2020-05-11 at 22:48 +0100, Andrew Burgess wrote:
> This commit is for the benefit of GDB, but as the binutils-gdb
> repository shares the contrib/ directory with gcc, this commit must
> first be applied to gcc then copied back to binutils-gdb.
>
> This commit extends the two scripts
On Sun, 2020-05-10 at 11:10 +0200, Iain Buclaw via Gcc-patches wrote:
> Ping
>
> On 03/05/2020 09:37, Iain Buclaw via Gcc-patches wrote:
> > Ping.
> >
> > There is a new mangle string "Nm" in the abi to denote the @live attribute,
> > however will add support in a follow up patch.
> >
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95133
Bug ID: 95133
Summary: [9/10/11 Regression] ICE in
gimple_redirect_edge_and_branch_force, at
tree-cfg.c:6075
Product: gcc
Version: 11.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95107
G. Steinmetz changed:
What|Removed |Added
Summary|[10/11 Regression] ICE in |ICE in hash_operand, at
On Wed, 2020-05-13 at 15:00 +0200, Iain Buclaw via Gcc-patches wrote:
> Ping.
>
> On 07/05/2020 16:04, Iain Buclaw via Gcc-patches wrote:
> > Hi,
> >
> > Updated the patch to include missed changes, and slighted reworded some
> > entries
> > to make them clearer/read easier.
> >
> > OK to
On Fri, 2020-05-08 at 06:44 -0700, H.J. Lu wrote:
> CET has been added since GCC 8. This patch defaults CET run-time support
> to auto. It enables CET run-time support if asssembler supports CET
> instructions and multi-byte NOPs are enabled via SSE2.
>
> OK for master?
>
> Thanks.
>
> H.J.
>
On 07/05/2020 16:04, Iain Buclaw via Gcc-patches wrote:
> Hi,
>
> Updated the patch to include missed changes, and slighted reworded some
> entries
> to make them clearer/read easier.
>
I've gone ahead and pushed it, after someone else did a review of the wording.
Iain.
Hi Maciej,
> On Wed, 13 May 2020, Rainer Orth wrote:
>
>> > I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.
>>
>> If we go beyond 1.5.x, we need to go all the way up to 1.6.2: 1.6 and
>> 1.6.1 have an ugly bug that can miss timeouts, causing tests to hang
>> indefinitely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95132
Bug ID: 95132
Summary: Concept checked after auto return type deduction
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
I discovered all the users of build_template_decl were explicitly
setting the RESULT and TYPE fields of the built decl. Let's just have
build_template_decl do that in the first place.
pushed to master.
nathan
--
Nathan Sidwell
2020-05-14 Nathan Sidwell
* pt.c (build_template_decl):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95131
Nathan Sidwell changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
--- Comment #12 from rsandifo at gcc dot gnu.org
---
(In reply to rguent...@suse.de from comment #11)
> On Thu, 14 May 2020, ubizjak at gmail dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
> >
> > --- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95131
Richard Biener changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95122
Andreas Schwab changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95122
chengcongxiu at huawei dot com changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
--- Comment #11 from rguenther at suse dot de ---
On Thu, 14 May 2020, ubizjak at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
>
> --- Comment #10 from Uroš Bizjak ---
> The patch is ready to be pushed, it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95131
Bug ID: 95131
Summary: Instantiate templates at pch generation time
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pch
> Jan Hubicka writes:
> >> The testcase has failed since r9-5035, because obj_type_ref_class
> >> tries to look up an ODR type when no ODR type information is
> >> available. (The information was available earlier in the
> >> compilation, but was freed during pass_ipa_free_lang_data.)
> >> We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95122
--- Comment #5 from chengcongxiu at huawei dot com ---
(In reply to Richard Earnshaw from comment #4)
> Don't use -mhard-float or -msoft-float. Instead, you should be using
> -mfloat-abi=[hard|softfp|soft] as appropriate. Also, rather than
Hi
thanks for the review and pointers ...
Nathan Sidwell wrote:
> On 5/13/20 9:26 AM, Iain Sandoe wrote:
>> Nathan Sidwell wrote:
>>> On 5/13/20 6:59 AM, Iain Sandoe wrote:
>> This is the equivalent of finish_return_stmt () in the parser, it knows
>> nothing of the eventual morphing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84007
Arjen Markus changed:
What|Removed |Added
CC||arjen.markus895 at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
--- Comment #10 from Uroš Bizjak ---
The patch is ready to be pushed, it is waiting for a decision what to do with
failed cases.
Richi, should this patch move forward (eventually XFAILing failed cases), or do
you plan to look at the fails from
On 5/13/20 7:53 PM, Joseph Myers wrote:
On Wed, 13 May 2020, Martin Liška wrote:
I'm sending the gcc-changelog relates scripts which should be added to contrib
folder. The patch contains:
- git_check_commit.py - checking script that verifies git message format
We need a documentation patch
On 5/13/20 7:53 PM, Joseph Myers wrote:
On Wed, 13 May 2020, Martin Liška wrote:
I'm sending the gcc-changelog relates scripts which should be added to contrib
folder. The patch contains:
- git_check_commit.py - checking script that verifies git message format
We need a documentation patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95050
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
Target
Jan Hubicka writes:
>> The testcase has failed since r9-5035, because obj_type_ref_class
>> tries to look up an ODR type when no ODR type information is
>> available. (The information was available earlier in the
>> compilation, but was freed during pass_ipa_free_lang_data.)
>> We then crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #21 from Bill Seurer ---
We can't modify the spec code but we can add "compatibility" options.
Shouldn't the if test make the compiler ignore the statement with the divide by
zero? It shouldn't ever be executed.
Hello.
I'm sending patch candidate that adds 2 new git aliases:
- gcc-backport - simple alias to 'git cherry-pick -x'
- gcc-revert - it similarly appends '(this reverts commit
365e3cde4978c6a7dbfa50865720226254c016be)'
to a reverted commit message
The script normally parses content of a git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95125
--- Comment #3 from Uroš Bizjak ---
It turns out that a bunch of patterns have to be renamed (and testcases added).
Easyhack, waiting for someone to show some love to conversion patterns in
sse.md.
Hello.
I'm sending patch candidate that adds 2 new git aliases:
- gcc-backport - simple alias to 'git cherry-pick -x'
- gcc-revert - it similarly appends '(this reverts commit
365e3cde4978c6a7dbfa50865720226254c016be)'
to a reverted commit message
The script normally parses content of a git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95125
--- Comment #2 from Uroš Bizjak ---
(In reply to Richard Biener from comment #1)
> ISTR I filed a duplicate 10 years ago or so. The issue is the vectorizer
> could not handle V4DFmode -> V4SFmode conversions.
>
> Could, because for SVE we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
Avi Kivity changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #22 from Avi Kivity ---
Certainly, closing as invalid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #21 from Iain Sandoe ---
Avi, If we are agreed that there is no GCC bug here (the change from pointer to
reference is already in the queue)
I would suggest that new design discussion would be better by putting a paper
or suggestions
Hi!
I've committed the patch, so that the rest can be handled incrementally.
On Wed, May 13, 2020 at 01:16:42PM +0200, Jakub Jelinek wrote:
> Honza/Martin, are the cgraph related changes acceptable to you?
>
> For LTO, the patch only saves/restores the two cgraph_node bits added in the
> patch,
> The testcase has failed since r9-5035, because obj_type_ref_class
> tries to look up an ODR type when no ODR type information is
> available. (The information was available earlier in the
> compilation, but was freed during pass_ipa_free_lang_data.)
> We then crash dereferencing the null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
Jonathan Wakely changed:
What|Removed |Added
Version|9.2.1 |10.1.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #20 from Avi Kivity ---
My coroutines do return suspend_never from initial_suspend(); so thanks for the
workaround, I'll use it until we have a better fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #22 from Jonathan Wakely ---
(In reply to rguent...@suse.de from comment #20)
> Doh. OK, guess I'd set up the twister in all cases and make it
> programatically skip itself when rdrand/rdseed is available so we
> could easily fall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #21 from Jonathan Wakely ---
(In reply to rguent...@suse.de from comment #18)
> Note in virtualized environments support for RDRAND might be disabled
> while RDSEED is enabled(?) even if no such hardware configuration
> exists [by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #19 from Iain Sandoe ---
(In reply to Ville Voutilainen from comment #17)
> (In reply to Ville Voutilainen from comment #16)
> > (In reply to Iain Sandoe from comment #14)
> > > (In reply to Ville Voutilainen from comment #12)
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #18 from Avi Kivity ---
The work-around works if initial_suspend() returns suspend_never or similar. If
the lambda is suspended before execution, the reference may dangle.
On 5/14/20 1:27 PM, Jakub Jelinek wrote:
On Thu, May 14, 2020 at 12:11:50PM +0200, Martin Liška wrote:
I would like to add unit-tests for gcc-changelog.
The test_patches.txt contains couple of patches extracted from gcc
via git format-patch.
Test output:
$ pytest contrib/gcc-changelog/
Test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #17 from Ville Voutilainen ---
(In reply to Ville Voutilainen from comment #16)
> (In reply to Iain Sandoe from comment #14)
> > (In reply to Ville Voutilainen from comment #12)
> > The idea of bringing the lambda's captures into the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95123
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95125
Richard Biener changed:
What|Removed |Added
Version|unknown |11.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #15 from Avi Kivity ---
I believe that my suggestion works for mutable lambdas (and for any coroutine
called as a member function):
- if the object passeed to the member function is an lvalue, then the
coroutine captures a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48998
--- Comment #2 from Zdenek Sojka ---
(In reply to Arseny Solokha from comment #1)
> Is it still an issue?
I can't reproduce this with r11-385.
gcc/ChangeLog:
2020-05-14 Uroš Bizjak
PR target/95046
* config/i386/sse.md (sse2_cvtpi2pd): Add memory to alternative 1.
(floatv2siv2df2): New expander.
(floatunsv2siv2df2): New insn pattern.
(fix_truncv2dfv2si2): New expander.
(fixuns_truncv2dfv2si2): New insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #20 from rguenther at suse dot de ---
On Thu, 14 May 2020, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
>
> --- Comment #19 from Jonathan Wakely ---
> If you mean the mersenne twister in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95046
--- Comment #9 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:365e3cde4978c6a7dbfa50865720226254c016be
commit r11-386-g365e3cde4978c6a7dbfa50865720226254c016be
Author: Uros Bizjak
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95126
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #19 from Jonathan Wakely ---
If you mean the mersenne twister in the std::random_device object, that's a
union member and doesn't exist when a proper source (/dev/random, rdrand,
rdseed etc) is available. So we'd need to add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #14 from Iain Sandoe ---
(In reply to Ville Voutilainen from comment #12)
> It sure seems to me that a coroutine lambda's captures should be copied to
> the coroutine state. I don't think the standard says that anywhere.
Maybe I am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #18 from rguenther at suse dot de ---
On Thu, 14 May 2020, hjl.tools at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
>
> --- Comment #15 from H.J. Lu ---
> (In reply to Jonathan Wakely from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #17 from rguenther at suse dot de ---
On Thu, 14 May 2020, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
>
> --- Comment #14 from Jonathan Wakely ---
> (In reply to Jonathan Wakely from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #16 from rguenther at suse dot de ---
On Thu, 14 May 2020, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
>
> --- Comment #12 from Jonathan Wakely ---
> (In reply to wnereiz from comment #9)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
Bug ID: 95130
Summary: GCC ignoring attribute(format(gnu_printf)) on printf
in mingw
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #15 from H.J. Lu ---
(In reply to Jonathan Wakely from comment #13)
> We could do this easily enough (which could be simplified if RDRAND is
> guaranteed to be available when RDSEED is available):
>
All Intel processors with RDSEED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
--- Comment #14 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #13)
> I'd rather not have to do everything shown at
> https://software.intel.com/content/www/us/en/develop/articles/intel-digital-
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #13 from Avi Kivity ---
Yes. gcc has a minor bug in that the lambda is reflected as a pointer instead
of a reference in coroutine_traits. The major bug is in the standard.
101 - 200 of 278 matches
Mail list logo
