The condition of the 'if' encompassed that of the 'elsif', so the error
message wouldn't get a chance to be printed.
Regstrapped on x86_64-linux-gnu. I'm checking this in.
for gcc/ada/ChangeLog
* par-ch10.adb (P_Compilation_Unit): Reenable ada83 library
unit renaming test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102739
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102739
Bug ID: 102739
Summary: compiler ICE when run libcxx's test
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Hi,
This patch supports HFmode vector shuffle by creating HImode subreg when
expanding permutation expr.
Bootstrapped/regtested on x86_64-pc-linux-gnu{-m32,} and sde{-m32,}
OK for master?
gcc/ChangeLog:
* config/i386/i386-expand.c (ix86_expand_vec_perm): Convert
HFmode input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102700
--- Comment #4 from Hongtao.liu ---
(In reply to Martin Sebor from comment #3)
> It looks like it's just the the location of the warning that's off, the
> warning itself is still issued but it's swallowed by the dg-prune-output
> directive.
>
On Linux/x86_64,
97c320016642a40a347d558abc952cc487ad4ff6 is the first bad commit
commit 97c320016642a40a347d558abc952cc487ad4ff6
Author: Roger Sayle
Date: Wed Oct 13 19:49:47 2021 +0100
x86_64: Some SUBREG related optimization tweaks to i386 backend.
caused
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102738
--- Comment #2 from Andrew Pinski ---
So this is interesting, I think clang/LLVM does this optimization late in their
pipeline take:
int a1(int f, int g)
{
if (f == 0 || f == 1)
return (f-1) >> g;
return 0;
}
They don't remove the
On Wed, Oct 13, 2021 at 5:07 PM Hongyu Wang via Gcc-patches
wrote:
>
> Hi,
>
> Current mask/mask3 implementation for complex fma contains
> duplicated parameter in macro, which may cause error at -O0.
> Refactor macro implementation to builtins to avoid potential
> error.
>
> For round intrinsic
This change fixes building libgcc with -msoft-float. Getting soft float to
work in libgcc
is still a work in progress.
Tested on hppa-unkown-linux-gnu, hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Committed to active branches.
Dave
---
Fix TARGET_SOFT_FLOAT patterns in pa.md
2021-10-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95740
--- Comment #3 from Gabriel Ravier ---
I've also encountered what looks like a duplicate of this bug, although I'm not
sure but it seems likely:
int foo(float f)
{
union
{
float f;
int i;
} z = { .f = f };
return z.i - 1;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102738
Andrew Pinski changed:
What|Removed |Added
Summary|Failure to optimize right |Failure to optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102738
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102738
Bug ID: 102738
Summary: Failure to optimize right shift of 128-bit value after
it's already been shifted by 127
Product: gcc
Version: 12.0
Status: UNCONFIRMED
On Wed, Sep 29, 2021 at 04:32:19PM +0800, HAO CHEN GUI wrote:
> The patch punishes reload of alternative pair of "d, Z" for
> movsi_internal1. The reload occurs if 'Z' doesn't match and generates an
> additional insn. So the memory reload should be punished.
As David says, why only for loads?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101583
Arjan van de Ven changed:
What|Removed |Added
CC||arjan at linux dot intel.com
---
On Wed, Oct 13, 2021 at 12:04:39PM -0500, Paul A. Clarke wrote:
> On Mon, Oct 11, 2021 at 07:11:13PM -0500, Segher Boessenkool wrote:
> > > - _mm_mul_epu32: vec_mule(v4su) uses vmuleuw.
> >
> > Did this fail on p7? If not, add a test that *does*?
>
> Do you mean fail if not for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102733
--- Comment #4 from Andrew Pinski ---
(In reply to Martin Sebor from comment #3)
> A couple of data points: I see the same behavior for any constant address
> (not just null).
Right because DSE does not compare MEM_ADDR_SPACE. It is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102733
--- Comment #3 from Martin Sebor ---
A couple of data points: I see the same behavior for any constant address (not
just null). Clang 12 behaves the same as GCC, but Clang 13 emits both stores,
suggesting they fixed it as a bug:
On Wed, Oct 13, 2021 at 2:08 AM Uros Bizjak via Gcc-patches
wrote:
>
> On Wed, Oct 13, 2021 at 10:23 AM Roger Sayle
> wrote:
> >
> >
> > Good catch. I agree with Hongtao that although my testing revealed
> > no problems with the previous version of this patch, it makes sense to
> > call
On 13/10/21 21:19 +0100, Jonathan Wakely wrote:
On 13/10/21 20:41 +0100, Jonathan Wakely wrote:
Adjust the __detail::__effective_range overloads so they always return a
string or string view using std::char_traits, because we don't care
about the traits of an incoming string.
Use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102736
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at redhat dot com,
libstdc++-v3/ChangeLog:
* testsuite/27_io/filesystem/path/construct/102592.C: Moved to...
* testsuite/27_io/filesystem/path/construct/102592.cc: ...here.
* testsuite/28_regex/match_results/102667.C: Moved to...
* testsuite/28_regex/match_results/102667.cc: ...here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #14 from qinzhao at gcc dot gnu.org ---
All the 3 testing cases can be resolved by adding the following patch (check
whether the type has padding before adding call to __builtin_clear_padding):
I believe that this is a safe partial
On Wed, 13 Oct 2021, HAO CHEN GUI via Gcc-patches wrote:
> As to IEEE behavior, do you mean "Minimum and maximum operations" defined in
> IEEE-754 2019? If so, I think VSX/altivec min/max instructions don't conform
> with it. It demands a quite NaN if either operand is a NaN while our
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934
--- Comment #16 from joseph at codesourcery dot com ---
I don't think this bug is anything to do with -fsignaling-nans, for the
same reason as applies to bug 58416 and bug 71460.
The option -fsignaling-nans is only about correctly handling
I'd like to cancel the request to apply that patch.
At the time I had actually assumed that Clang was at fault, but your comment
made me pause. I'll submit a bug report as you suggest. We can reconsider the
patch in future once that bug is resolved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102737
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-10-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102737
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.5
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102737
Bug ID: 102737
Summary: [x86] Failure to optimize out bad register usage
involving int->double conversion
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102736
Andrew Pinski changed:
What|Removed |Added
Summary|wrong code at -O2 and -O3 |[12 Regression] wrong code
As work has progressed, we're pretty close to being able to functionally
replace VRP with another EVRP pass. At least it seems close enough that
we should discuss if thats something we might want to consider for this
release. Replacing just one of the 2 VRP passes is another option.
First,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102592
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102592
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:9ef31bab15a426a6829acf0e7ae5420d3b10cbae
commit r11-9149-g9ef31bab15a426a6829acf0e7ae5420d3b10cbae
Author: Jonathan
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211013 (experimental) [master r12-4363-g52055987fba] (GCC)
[593] %
[593] % gcctk -Os small.c; ./a.out
[594] %
[594] % gcctk -O2 small.c
[595] % ./a.out
Aborted
[596] %
[596] % cat small.c
int a, b = -1, c;
int d = 1;
char e(char f, int g
Hi Kito,
On 9/23/21 12:57 AM, Kito Cheng wrote:
Bit manipulation extension[1] is finishing the public review and waiting for
the rest of the ratification process, I believe that will become a ratified
extension soon, so I think it's time to submit to upstream for review now :)
As the title
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102648
--- Comment #2 from Andrew Macleod ---
This is another case of insufficient range representation in the old
value_range. The patch causing the issue allows us to produce better subranges
when the source ranges have small numbers of constants
On 13/10/21 20:41 +0100, Jonathan Wakely wrote:
Adjust the __detail::__effective_range overloads so they always return a
string or string view using std::char_traits, because we don't care
about the traits of an incoming string.
Use std::contiguous_iterator in the __effective_range(const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102735
Bug ID: 102735
Summary: privatization-1-compute.c results in both XFAIL and
PASS
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Hi Tobias,
Am 13.10.21 um 18:01 schrieb Tobias Burnus:
Dear all,
a minor update [→ v3].
this has become an impressive work.
I searched for XFAIL in Sandra's c-interop/ and found
two remaining true** xfails, now fixed:
- gfortran.dg/c-interop/typecodes-scalar-basic.f90
The conversion of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #27 from CVS Commits ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:8b333df9484c1697f3a80530a47aa90b1859e970
commit r11-9147-g8b333df9484c1697f3a80530a47aa90b1859e970
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102425
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102667
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102425
--- Comment #7 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:b90b39a33154949979def3117ca868950ce8025c
commit r9-9778-gb90b39a33154949979def3117ca868950ce8025c
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102667
--- Comment #5 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:081f08b80db2ce8a10375b3af118db008308affc
commit r9-9774-g081f08b80db2ce8a10375b3af118db008308affc
Author: Jonathan
Adjust the __detail::__effective_range overloads so they always return a
string or string view using std::char_traits, because we don't care
about the traits of an incoming string.
Use std::contiguous_iterator in the __effective_range(const Source&)
overload, to allow returning a
When creating a path from a pair of non-contiguous iterators we pass the
iterators to _S_convert(Iter, Iter). That function passes the iterators
to __string_from_range to get a contiguous sequence of characters, and
then calls _S_convert(const C*, const C*) to perform the encoding
conversions. If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102592
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:b83b810ac440f72e7551b6496539e60ac30c0d8a
commit r12-4381-gb83b810ac440f72e7551b6496539e60ac30c0d8a
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102592
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:85b24e32dc27ec2e70b853713e0713cbc1ff08c3
commit r12-4380-g85b24e32dc27ec2e70b853713e0713cbc1ff08c3
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102716
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102717
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Dear Fortranners,
another simple and obvious fix: we need to reorder the argument checks
to the SHAPE intrinsic so that invalid KIND arguments can be detected.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As I consider this a safe fix, I'd like to backport to suitable branches.
Thanks,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102705
--- Comment #1 from Andrew Macleod ---
That impact of that patch on this PR is that it teaches range extraction that
[0,1] % [5,5] is [0,1], unlike before which came up with [0,4]
This in turn causes the thread1 pass to decide to thread
Dear Fortranners,
when simplifying RESHAPE we hit a gcc_assert for negative entries in the
SHAPE array. Obvious solution: replace gcc_assert by an error message.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As this is a safe fix, I'd like to backport to suitable branches.
Thanks,
Simple mangled names (only with identifiers) are not being covered by coverage
tests.
Signed-off-by: Luís Ferreira
libiberty/ChangeLog:
* testsuite/d-demangle-expected: add test cases for simple special
mangles
---
libiberty/testsuite/d-demangle-expected | 8
1 file changed,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102733
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> RTL level DSE removes the first store. I suspect dse.c does not check
> ADDR_SPACE_GENERIC_P.
I mean MEM_ADDR_SPACE. And yes it looks like it does not check
On Oct 12, 2021, Richard Biener wrote:
> Are there any issues with respect to debugging when using such
> asm()s?
Not in this case. When creating short-lived copies for immediate use,
like I do in the proposed patch, either the original value remains live
in its original location and we use an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102733
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
Coverage tests doesn't include a case for function literals
Signed-off-by: Luís Ferreira
libiberty/ChangeLog:
* testsuite/d-demangle-expected: add test case for function literals
---
libiberty/testsuite/d-demangle-expected | 4
1 file changed, 4 insertions(+)
diff --git
On Tue, Oct 12, 2021 at 04:57:43PM +0800, HAO CHEN GUI wrote:
> b/gcc/config/rs6000/rs6000-call.c
> index b4e13af4dc6..90527734ceb 100644
> --- a/gcc/config/rs6000/rs6000-call.c
> +++ b/gcc/config/rs6000/rs6000-call.c
> @@ -12159,6 +12159,11 @@ rs6000_gimple_fold_builtin (gimple_stmt_iterator
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102611
Jakub Jelinek changed:
What|Removed |Added
Attachment #51595|0 |1
is obsolete|
On Wed, Oct 13, 2021 at 10:29:26AM +0200, Richard Biener wrote:
> On Wed, Oct 13, 2021 at 9:43 AM HAO CHEN GUI wrote:
> >As to IEEE behavior, do you mean "Minimum and maximum operations"
> > defined in IEEE-754 2019? If so, I think VSX/altivec min/max instructions
> > don't conform with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934
--- Comment #15 from Zoltan Vajda ---
In my special case, I have an embedded realtime application with a lot of FP
atithmetic on Intel 32 bit architecture (huge and complex legacy codebase). FPU
exceptions are enabled, so loading an SNaN results
Hi,
My current understanding of LTO is that the callgraph is very dynamic
(i.e., optimizations might add or remove cgraph_nodes). A while back I
encountered an issue where I couldn't print the cgraph_node::name of a
function during the execute stage in LTO. I found that the only thing
different
On Linux/x86_64,
3c0194d7ff21d61c02f3c6b111c83ef24a69e1f0 is the first bad commit
commit 3c0194d7ff21d61c02f3c6b111c83ef24a69e1f0
Author: Richard Biener
Date: Mon Oct 11 12:27:10 2021 +0200
tree-optimization/102659 - avoid undefined overflow after if-conversion
caused
FAIL:
This also helps get rid of warning
ctfc.h:215:18: warning: comma at end of enumerator list [-Wpedantic]
CTF_DTU_D_SLICE,
gcc/ChangeLog:
* ctfc.h (enum ctf_dtu_d_union_enum): Remove redundant comma.
---
gcc/ctfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi
libstdc++: [_GLIBCXX_DEBUG] Implement unordered container merge
The _GLIBCXX_DEBUG unordered containers need a dedicated merge
implementation
so that any existing iterator on the transfered nodes is properly
invalidated.
Add typedef/using declaration for everything used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 102630, which changed state.
Bug 102630 Summary: [12 Regression] Spurious -Warray-bounds with named address
space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
On Wed, 13 Oct 2021, Martin Uecker wrote:
> There is currently no standard way to set or query
> the static chain from C although this is used by
> many other languages. Also function pointers in C
> usually can not store the static chain. I am going
> to propose to WG14 to add some kind of wide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90787
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, Oct 11, 2021 at 07:11:13PM -0500, Segher Boessenkool wrote:
> On Mon, Aug 23, 2021 at 02:03:10PM -0500, Paul A. Clarke wrote:
> > Some compatibility implementations of x86 intrinsics include
> > Power intrinsics which require POWER8. Guard them.
>
> > emmintrin.h:
> > - _mm_cmpord_pd:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101388
--- Comment #5 from Gaius Mulley ---
Many thanks - I've applied the patch to the git repro. Fixed now I believe.
On 10/13/21 2:25 AM, Richard Biener wrote:
On Wed, Oct 13, 2021 at 3:32 AM Martin Sebor via Gcc-patches
wrote:
On 10/11/21 6:26 PM, Joseph Myers wrote:
The testcase uses the __seg_fs address space, which is x86-specific, but
it isn't in an x86-specific directory or otherwise restricted to
Hi,
On Mon, Sep 27 2021, Richard Biener via Gcc-patches wrote:
>
[...]
>
> The following is what I have pushed after re-bootstrapping and testing
> on x86_64-unknown-linux-gnu.
>
> Richard.
>
> From fc335f9fde40d7a20a1a6e38fd6f842ed93a039e Mon Sep 17 00:00:00 2001
> From: Richard Biener
> Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102734
Bug ID: 102734
Summary: Autodeduced method return type is available before the
class is complete
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
FE2:
.size test_null_store_fs_gs, .-test_null_store_fs_gs
.ident "GCC: (GNU) 12.0.0 20211013 (experimental)"
.section.note.GNU-stack,"",@progbits
Am Mittwoch, dem 13.10.2021 um 15:21 + schrieb Michael Matz:
> Hello,
>
> On Wed, 13 Oct 2021, Martin Uecker wrote:
>
> > does anybody know if all architectures support passing
> > an environment pointer in their function call ABI?
>
...
>
> Or you could mean what normally would be called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102732
Bug ID: 102732
Summary: quadratic/exponential time complexity on D demangler
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
--- Comment #7 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:54fa5567a27eb7ee72cd2321d0291c8a9b436ce9
commit r12-4376-g54fa5567a27eb7ee72cd2321d0291c8a9b436ce9
Author: Martin Sebor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102323
--- Comment #1 from Gaius Mulley ---
Confirmed, thank you for the bug report. Now fixed in the git repro.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102731
Martin Sebor changed:
What|Removed |Added
Blocks||56456, 88443
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102731
Bug ID: 102731
Summary: inconsistent handling of dereferncing a null pointer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
On Wed, 2021-10-13 at 16:42 +0100, Luís Ferreira wrote:
> On Wed, 2021-10-13 at 16:34 +0100, Luís Ferreira wrote:
> > Since Tuple!() is templated type from standard library, this can
> > make
> > two
> > demangled names undistinguishable.
> >
> > Signed-off-by: Luís Ferreira
> >
> >
Since Tuple!() is templated type from standard library, this can make two
demangled names undistinguishable.
Signed-off-by: Luís Ferreira
libiberty/ChangeLog:
* d-demangle.c (dlang_parse_tuple): use tuple() instead of Tuple!()
* testsuite/d-demangle-expected: rename the tests
This patches patch allows inlining 64-bit hardware multiplication on 32-bit
hppa targets
instead of using __muldi3 from libgcc. This should improve performance at the
expense of
a slight increase in code size.
We need this because I am testing a change to build libgcc with software float
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102729
Tobias Burnus changed:
What|Removed |Added
Blocks||102641
--- Comment #1 from Tobias
Dear all,
a minor update [→ v3].
I searched for XFAIL in Sandra's c-interop/ and found
two remaining true** xfails, now fixed:
- gfortran.dg/c-interop/typecodes-scalar-basic.f90
The conversion of scalars of type(c_ptr) was mishandled;
fixed now; the fix did run into issues converting a
Currently _D8demangle4testFYv and _D8demangle4testFXv report the same demangled
symbol and they are not the same. The official demangler reports
"demangle.test(, ...)", which is the distinguishable way to do it.
Signed-off-by: Luís Ferreira
libiberty/ChangeLog:
* d-demangle.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99580
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2021-03-14 00:00:00 |2021-10-13
Summary|False
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464
--- Comment #15 from Chengnian Sun ---
(In reply to Jakub Jelinek from comment #14)
> Yes. You'll get an error, like:
> error: t.c: ‘-fcompare-debug’ failure (length)
> or
> error: t.c: ‘-fcompare-debug’ failure
> Under the hood, the driver
> -Original Message-
> From: Andre Vieira (lists)
> Sent: Wednesday, October 13, 2021 2:09 PM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Cc: Christophe Lyon
> Subject: Re: [arm] Fix MVE addressing modes for VLDR[BHW] and
> VSTR[BHW]
>
>
> On 13/10/2021 13:37, Kyrylo Tkachov
On Wed, 2021-10-13 at 16:34 +0100, Luís Ferreira wrote:
> Since Tuple!() is templated type from standard library, this can make
> two
> demangled names undistinguishable.
>
> Signed-off-by: Luís Ferreira
>
> libiberty/ChangeLog:
>
> * d-demangle.c (dlang_parse_tuple): use tuple()
Since Tuple!() is templated type from standard library, this can make two
demangled names undistinguishable.
Signed-off-by: Luís Ferreira
libiberty/ChangeLog:
* d-demangle.c (dlang_parse_tuple): use tuple() instead of Tuple!()
---
libiberty/d-demangle.c | 2 +-
1 file changed, 1
>> gcc/
>> * config/rs6000/rs6000-call.c (altivec_expand_lxvr_builtin):
>> Modify the expansion for sign extension. All extentions are done
>> within VSX resgisters.
>
> Two typos here: extentions => extensions, resgisters => registers.
This is okay with Bill's comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90787
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:4be4888d6bddbcc106efeb19e18c380e7c1d041a
commit r10-10214-g4be4888d6bddbcc106efeb19e18c380e7c1d041a
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102730
Bug ID: 102730
Summary: Consistency of deprecation warning emission with type
alias
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102726
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2021-10-13
> The patch punishes reload of alternative pair of "d, Z" for
> movsi_internal1. The reload occurs if 'Z' doesn't match and generates an
> additional insn. So the memory reload should be punished.
>
> Bootstrapped and tested on powerpc64le-linux with no regressions. Is this
> okay for
Hello,
On Wed, 13 Oct 2021, Martin Uecker wrote:
> does anybody know if all architectures support passing
> an environment pointer in their function call ABI?
Define "environment pointer". I can imagine two things you could mean:
the custom to pass envp as third argument to main() in hosted
1 - 100 of 262 matches
Mail list logo
