https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97034
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197
Patrick Palka changed:
What|Removed |Added
CC||adamkzyzik at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98604
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |10.3
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98551
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98551
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:ee697d4bbb7991c99539ba6c20ec76b5d488cffc
commit r10-9241-gee697d4bbb7991c99539ba6c20ec76b5d488cffc
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197
--- Comment #9 from CVS Commits ---
The releases/gcc-10 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:afe708223f0bfffe688674659f7a71c5130f01d1
commit r10-9240-gafe708223f0bfffe688674659f7a71c5130f01d1
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
--- Comment #21 from kargl at gcc dot gnu.org ---
(In reply to Chinoune from comment #20)
> won't fix.
This is hilarious! Now, I know why you are so confused.
>From your code in comment #2
call system_clock( t1, count_rate_r32 )
c =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97714
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598
--- Comment #5 from Jiangning Liu ---
> It has to be done with care of course, cost modeling is difficult
> (we need to have a good estimate of n and m or need to version
> the whole nest). That said, usually we attempt the reverse transform.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97714
--- Comment #3 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:57450da2fef3a32dc463b85e7b3d67f519b282cb
commit r11-6561-g57450da2fef3a32dc463b85e7b3d67f519b282cb
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
Chinoune changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607
--- Comment #1 from Iain Buclaw ---
To be fair, C++ does the same as well. The problem is the inliner (though no
inlining occurs when using immintrin.h)
Hi Jason,
Thank you!
> To start with, do you have a copyright assignment on file or in the
> works already?
Good point. I incorrectly assumed it would only be a minor
contribution copyright-wise. Mr Edelsohn gave me a template which I've
now filled out and sent to ass...@gnu.org. I'm assuming I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599
--- Comment #2 from David Malcolm ---
As far as I can tell, there are two invocations of lto1: wpa, then ltrans.
The analyzer is run in the first invocation.
The analyzer updates the gimple stmt uids; if I disable this updating the crash
Hi,
I'm implementing named addresses spaces for a Harvard architecture machine
to support copying data from instruction memory to data memory. This is
achieved via a special instruction. e.g. think AVR and progmem/__flash.
However, the instruction memory is narrower than the data memory (12 vs
On 1/7/21 5:53 PM, Martin Sebor via Gcc-patches wrote:
> In PR 98097 Richard expects -Wstring-compare for a call to strcmp()
> with a member array and a string literal of larger size, used in
> an equality test.
>
> In virtually all cases the test will indicate the two are unequal
> because the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98606
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98606
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Snapshot gcc-9-20210108 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20210108/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98610
Bug ID: 98610
Summary: syscall.TestUnshareUidGidMapping sporadically fails on
powerpc64le
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609
Bug ID: 98609
Summary: sanitizer diagnoses VLAs with length zero although
zero-length arrays are a GNU extension
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98608
Bug ID: 98608
Summary: missing sanitizer detection for arrays with invalid
length defind using typeof
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
Hi,
The armv8_arm manual [C6.2.226, ROR (immediate)] uses a # in front
of the immediate rotation quantity.
Although, it seems, GAS is able to infer the # (or is leninent about
its absence) assemblers based on the LLVM back end expect it and error out.
tested on aarch64-linux-gnu (gcc115) and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66366
--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #11)
> The error vanishes if the typebound procedure is removed from the type
> declaration and the corresponding typebound call.
Or renaming the local instance:
On 1/5/21 8:12 PM, Kewen.Lin wrote:
> on 2021/1/6 上午2:19, Jeff Law wrote:
>>
>> On 1/4/21 7:36 PM, Kewen.Lin wrote:
>>> Hi Jeff,
>>>
>>> on 2021/1/5 上午7:13, Jeff Law wrote:
On 12/22/20 11:40 PM, Kewen.Lin via Gcc-patches wrote:
> Hi Segher,
>
> on 2020/12/22 下午9:55, Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66366
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
On Fri, Jan 8, 2021 at 1:52 PM Jakub Jelinek wrote:
>
> On Fri, Jan 08, 2021 at 06:37:03PM +, Jonathan Wakely wrote:
> > This uses __INT64_TYPE__ if that's defined, and long long otherwise. I
> > think that should be equivalent in all practical cases (I can imagine
> > some strange target
On Fri, Jan 8, 2021 at 12:15 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 1/8/21 12:55 PM, Qing Zhao via Gcc-patches wrote:
> > Hi,
> >
> > Is there an utility routine in GCC to query the pointer width of the
> > current target? Whether it’s 32bit pointer or 64 bit pointer for the target?
> >
>
On 1/7/21 9:14 AM, Martin Liška wrote:
> On 1/6/21 12:36 AM, Jeff Law wrote:
>> unresolved "could not find python interpreter $testcase" in
>> run-gcov-pytest if you find the right magic in the output of your spawn.
>
> Achieved that with the updated patch.
>
> Ready for master?
> Thanks,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607
Bug ID: 98607
Summary: GDC merging computations but rounding mode has changed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
On 1/8/21 12:51 AM, Richard Biener wrote:
On Thu, Jan 7, 2021 at 10:41 PM Martin Sebor wrote:
The test case in PR 98465 brings to light a problem we've discussed
before (e.g., PR 93971) where a standard container (std::string in
this case but the problem applies to any class that owns and
On 1/8/21 12:55 PM, Qing Zhao via Gcc-patches wrote:
> Hi,
>
> Is there an utility routine in GCC to query the pointer width of the current
> target? Whether it’s 32bit pointer or 64 bit pointer for the target?
>
> Thanks a lot for the help.
You can look at the GET_MODE_SIZE (Pmode) or
On 1/7/21 6:51 PM, Maciej W. Rozycki wrote:
> Remove the `cc' mode attribute that duplicates the implicitly defined
> `mode' attribute. No change to semantics.
>
> gcc/
> * config/vax/vax.md (cc): Remove mode attribute.
> (subst_, subst_f): Rename to...
> (subst_,
On 1/7/21 6:50 PM, Maciej W. Rozycki wrote:
> For predictable semantics propagate the mode from operands referred by
> the FP substitution to the `const_double_zero' expressions used with the
> associated condition code calculation. Use an iterator to make copies
> of the FP substitution
On 1/7/21 6:50 PM, Maciej W. Rozycki wrote:
> Handle machine mode specification with `const_double_zero' and handle
> the rtx with callable code produced from named insns. Complementing
> commit 20ab43b5cad6 ("RTL: Add `const_double_zero' syntactic rtx") and
> removing a commit c60d0736dff7
On 1/8/21 5:49 AM, Maciej W. Rozycki wrote:
> Remove fallout from commit 0bd675183d94 ("match.pd: Add ~(X - Y) -> ~X
> + Y simplification [PR96685]") and paper over the regression caused as
> it is not the matter of the test cases affected.
>
> Previously assembly like this:
>
> .text
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98592
--- Comment #2 from Martin Sebor ---
The idea is to print the cast indicating the MEM_REF type only when the size of
the accessed type is different from the size of the element type of the
underlying array or pointer. Structural equivalence
Hi,
Is there an utility routine in GCC to query the pointer width of the current
target? Whether it’s 32bit pointer or 64 bit pointer for the target?
Thanks a lot for the help.
Qing
On Fri, Jan 08, 2021 at 02:22:59PM -0500, Jason Merrill wrote:
> I like the idea to use *walk_subtrees to distinguish between walking
> syntactic subtrees and walking type-identity subtrees. But it should be
> more general; how does this look to you?
LGTM, thanks.
> diff --git a/gcc/cp/class.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98606
Bug ID: 98606
Summary: [10 regression] obj-c++.dg/template-4.mm fails
erratically
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Hi, Bernd
Thanks for investigating this and creating a revised version of the
patch. With the second patch, the gcc.misc-test/outputs.exp results
are clean on AIX.
Thanks, David
On Fri, Jan 8, 2021 at 1:59 PM Bernd Edlinger wrote:
>
> On 1/8/21 3:23 PM, David Edelsohn wrote:
> > On Thu, Jan
On 1/7/21 11:47 AM, Jakub Jelinek wrote:
In GCC10 cp_walk_subtrees has been changed to walk template arguments.
As the following testcase, that changed the mangling of some functions.
Argh.
I believe the previous behavior that find_abi_tags_r doesn't recurse into
template args has been the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
--- Comment #19 from Steve Kargl ---
On Fri, Jan 08, 2021 at 06:43:20PM +, mehdi.chinoune at hotmail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
>
> --- Comment #17 from Chinoune ---
> Once I reported a bug to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605
Bug ID: 98605
Summary: clang-tidy error parsing on libstdc++-v3
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On 1/8/21 10:39 AM, Bruce Korb via Gcc wrote:
> Hi,
>
> You are supposed to be able to post once you've subscribed.
>
> Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than
> MAXNAMELEN characters. That is provable.
>
> "def_str" points into a buffer of size ((MAXNAMELEN * 2) +
On 1/8/21 3:23 PM, David Edelsohn wrote:
> On Thu, Jan 7, 2021 at 5:18 PM Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> On 1/7/21 5:12 PM, Rainer Orth wrote:
>>> The unsetenv needs to be wrapped in
>>>
>>> if [info exists env(MAKEFLAGS)] {
>>>
>>
>> Done.
>>
>>> @@ -163,6 +167,9 @@ proc outest {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
--- Comment #18 from Steve Kargl ---
On Fri, Jan 08, 2021 at 06:43:20PM +, mehdi.chinoune at hotmail dot com
wrote:
>
> I concluded that is a waste of time arguing with him.
>
Did you run the test program from my last comment?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58243
--- Comment #2 from Hans-Peter Nilsson ---
Confirmed; identical code w./wo. -fno-tree-sra for cris-elf too.
Thanks.
On Fri, Jan 08, 2021 at 06:37:03PM +, Jonathan Wakely wrote:
> This uses __INT64_TYPE__ if that's defined, and long long otherwise. I
> think that should be equivalent in all practical cases (I can imagine
> some strange target where __INT64_TYPE__ is defined by the compiler,
> but int64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
--- Comment #17 from Chinoune ---
Once I reported a bug to gcc/gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337 but someone argued that it
was my fault to use "-Ofast" so I rewrite the reproducer in C and reported
again under another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91726
--- Comment #8 from Paul Thomas ---
(In reply to José Rui Faustino de Sousa from comment #7)
> Hi all!
>
> Still ICEs with 9/10/11 using -ftrapv -fcheck=bounds
>
> Best regards,
> José Rui
Yes, indeed. This with those compile options
module
On 06/01/21 19:41 -0500, David Edelsohn wrote:
Thanks for clarifying the issue.
As you implicitly point out, GCC knows the type of INT64 and defines
the macro __INT64_TYPE__ . The revised code can use that directly,
such as:
#if defined(_GLIBCXX_HAVE_INT64_T_LONG) \
||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58243
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47059
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47059
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
Hi,
I stumbled across PR 47059 from 2010 which has been addressed by
store-merging. I am going to close it but would like to add its
testcase too.
OK for trunk?
Thanks,
Martin
gcc/testsuite/ChangeLog:
2021-01-08 Martin Jambor
PR tree-optimization/47059
*
Hi,
You are supposed to be able to post once you've subscribed.
Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than
MAXNAMELEN characters. That is provable.
"def_str" points into a buffer of size ((MAXNAMELEN * 2) + 8) and at an
offset maximum of MAXNAMELEN+1 (also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98600
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
On Thu, Nov 12, 2020, 21:55 Antony Polukhin wrote:
> Final bits for libstdc/71579
>
Gentle reminder on last patch
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98604
Bug ID: 98604
Summary: Passing constexpr by const reference causes excessive
memory usage during compilation
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
kargl at gcc dot gnu.org changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--- Comment #16 from
On 1/8/21 5:35 PM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> The destination register is only partially overwritten, so + should be
> used instead of =.
>
> gcc/ChangeLog:
>
> 2021-01-08 Ilya Leoshkevich
>
> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #15 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:745d04e796c1a7ebcea0185d0742d58b0c0030ab
commit r11-6557-g745d04e796c1a7ebcea0185d0742d58b0c0030ab
Author: H.J. Lu
Date: Fri Jan 8
On Fri, Jan 8, 2021 at 6:43 AM H.J. Lu wrote:
>
> On Fri, Jan 8, 2021 at 6:31 AM Uros Bizjak wrote:
> >
> > On Fri, Jan 8, 2021 at 2:28 PM H.J. Lu wrote:
> > >
> > > On Fri, Jan 8, 2021 at 4:50 AM H.J. Lu wrote:
> > > >
> > > > On Fri, Jan 8, 2021 at 1:24 AM Uros Bizjak wrote:
> > > > >
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
Chinoune changed:
What|Removed |Added
Resolution|INVALID |WONTFIX
--- Comment #15 from Chinoune ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
The destination register is only partially overwritten, so + should be
used instead of =.
gcc/ChangeLog:
2021-01-08 Ilya Leoshkevich
* config/s390/vector.md (*tf_to_fprx2_0): Rename from
*mov_tf_to_fprx2_0
On 1/8/21 2:14 PM, Ilya Leoshkevich wrote:
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563034.html
> v1 -> v2: Use TARGET_VXE_P instead of TARGET_Z14_P.
>
>
>
> Give end users the opportunity to find out whether long doubles are
> stored in floating-point register pairs or in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
kargl at gcc dot gnu.org changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--- Comment #14 from
On Thu, 7 Jan 2021, Jason Merrill wrote:
> On 1/7/21 10:10 AM, Patrick Palka wrote:
> > We shouldn't do replace_result_decl after evaluating a call that returns
> > a PMF because PMF temporaries aren't wrapped in a TARGET_EXPR (and so we
> > can't trust ctx->object), and PMF initializers can't be
On Thu, 7 Jan 2021, Jason Merrill wrote:
> On 1/7/21 5:47 PM, Patrick Palka wrote:
> > On Thu, 7 Jan 2021, Jason Merrill wrote:
> >
> > > On 1/6/21 1:19 PM, Patrick Palka wrote:
> > > > In the first testcase below, we incorrectly reject the use of the
> > > > protected non-static member A::var0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98473
--- Comment #4 from Jonathan Wakely ---
(In reply to Borislav Stanimirov from comment #2)
> (In reply to Jonathan Wakely from comment #1)
>
> > To meet the requirements of the standard we would need to insert them at the
> > end and then use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98515
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98551
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:bb1f0b50abbfa01e0ed720a5225a11aa7af32a89
commit r11-6554-gbb1f0b50abbfa01e0ed720a5225a11aa7af32a89
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98515
--- Comment #5 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:98a1fb705ead9258642f2dec0431f11508a9b13c
commit r11-6553-g98a1fb705ead9258642f2dec0431f11508a9b13c
Author: Patrick Palka
Date:
I think we should consider making this -std=c++23 right away this time,
since we're on a three-year release schedule. Up to Jason though.
Marek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98556
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
> On Jan 7, 2021, at 8:50 PM, Maciej W. Rozycki wrote:
>
> ...
>
> Provide a new iterator to provide copies of FP substitutions across the
> FP modes supported as the substitutions now need to match the mode of
> the operands.
>
> gcc/
> * config/pdp11/pdp11.md (PDPfp): New
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #14 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #10)
> If we are emitting for nested functions
> pushq %r10
> 1:call__fentry__
> popq%r10
> (is it ok to misalign the stack for __fentry__?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #13 from H.J. Lu ---
Fixed for GCC 11 so far. Please open a new GCC bug for mcount stack
alignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #12 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:76be18f442948d1a4bc49a7d670b07097f9e5983
commit r11-6552-g76be18f442948d1a4bc49a7d670b07097f9e5983
Author: H.J. Lu
Date: Fri Jan 8
On Fri, Jan 8, 2021 at 6:31 AM Uros Bizjak wrote:
>
> On Fri, Jan 8, 2021 at 2:28 PM H.J. Lu wrote:
> >
> > On Fri, Jan 8, 2021 at 4:50 AM H.J. Lu wrote:
> > >
> > > On Fri, Jan 8, 2021 at 1:24 AM Uros Bizjak wrote:
> > > >
> > > > > Since R10 is preserved when calling mcount, R10 can be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98603
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98069
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
On Fri, Jan 8, 2021 at 3:27 PM Martin Liška wrote:
>
> The patch removes some memory leaks spotted by valgrind.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK.
Richard.
> Thanks,
> Martin
>
>
> gcc/ChangeLog:
>
> *
On Fri, Jan 8, 2021 at 2:28 PM H.J. Lu wrote:
>
> On Fri, Jan 8, 2021 at 4:50 AM H.J. Lu wrote:
> >
> > On Fri, Jan 8, 2021 at 1:24 AM Uros Bizjak wrote:
> > >
> > > > Since R10 is preserved when calling mcount, R10 can be used a scratch
> > > > register to call mcount in large model.
> > >
> >
The patch removes some memory leaks spotted by valgrind.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* gimple-if-to-switch.cc (struct condition_info): Use auto_var.
(if_chain::is_beneficial):
On Thu, Jan 7, 2021 at 5:18 PM Bernd Edlinger wrote:
>
> Hi,
>
> On 1/7/21 5:12 PM, Rainer Orth wrote:
> > The unsetenv needs to be wrapped in
> >
> > if [info exists env(MAKEFLAGS)] {
> >
>
> Done.
>
> > @@ -163,6 +167,9 @@ proc outest { test sources opts dirs out
> > if { $ogl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98603
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #23 from rguenther at suse dot de ---
On January 8, 2021 3:07:48 PM GMT+01:00, "mar...@mpa-garching.mpg.de"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
>
>--- Comment #22 from Martin Reinecke ---
>Brilliant, thank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98557
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #22 from Martin Reinecke ---
Brilliant, thank you very much for tracking this one down!
My FFT library now works correctly again with all optimizations enabled, which
is a great relief. The scipy maintainers will be happy that they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98557
--- Comment #12 from Jakub Jelinek ---
So fixed now? clang_delta bugs should be tracked elsewhere.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504
--- Comment #10 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #9)
> Are you going to fix co-ret-17-void-ret-coro.C too?
should be done with
https://gcc.gnu.org/pipermail/gcc-cvs/2021-January/340327.html
(as far as I am aware,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98603
Bug ID: 98603
Summary: aarch64: ICE in extract_insn (ira) on asm goto with
bad constraint
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98602
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
1 - 100 of 184 matches
Mail list logo
