https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99217
--- Comment #5 from huangpei at loongson dot cn
---
Hi, with this fix and bug 93242 fixed, a.c with mips16 is OK,
ambrosehua@3A1000-800M:~$ gcc -fpatchable-function-entry=3 -mips16 -mabi=32
-c a.c -S -o a.1.s
ambrosehua@3A1000-800M:~$ cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97222
Andrew Pinski changed:
What|Removed |Added
CC||liavonlida at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100742
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97222
Andrew Pinski changed:
What|Removed |Added
CC||kip at thevertigo dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97222
Andrew Pinski changed:
What|Removed |Added
CC||paul.groke at dynatrace dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82270
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60402
Andrew Pinski changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #3 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550
--- Comment #7 from cqwrteur ---
(In reply to Andrew Pinski from comment #5)
> (In reply to cqwrteur from comment #4)
> > (In reply to Andrew Pinski from comment #2)
> > > Looks like it is a register allocation/scheduling issue. The extra
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550
--- Comment #6 from cqwrteur ---
(In reply to Andrew Pinski from comment #5)
> (In reply to cqwrteur from comment #4)
> > (In reply to Andrew Pinski from comment #2)
> > > Looks like it is a register allocation/scheduling issue. The extra
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550
--- Comment #5 from Andrew Pinski ---
(In reply to cqwrteur from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > Looks like it is a register allocation/scheduling issue. The extra
> > instructions are mov.
>
> Are there good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59704
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550
--- Comment #4 from cqwrteur ---
(In reply to Andrew Pinski from comment #2)
> Looks like it is a register allocation/scheduling issue. The extra
> instructions are mov.
Are there good algos that can allocate registers optimal?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550
--- Comment #3 from cqwrteur ---
(In reply to Andrew Pinski from comment #2)
> Looks like it is a register allocation/scheduling issue. The extra
> instructions are mov.
yeah. I feel gcc generally has issues with register allocations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550
--- Comment #1 from Andrew Pinski ---
#include
#include
inline constexpr std::uint_least64_t s0(std::uint_least64_t x) noexcept
{
return std::rotr(x,1)^std::rotr(x,8)^(x>>7);
}
inline constexpr std::uint_least64_t s1(auto x) noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59704
--- Comment #3 from Andrew Pinski ---
(In reply to Arthur O'Dwyer from comment #2)
> Here is another example:
> https://wandbox.org/permlink/UYsLyMaLcBb6sjJa
That is PR 52145.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103550
Bug ID: 103550
Summary: 2 more instructions generated by gcc than clang
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52145
Andrew Pinski changed:
What|Removed |Added
Blocks|88655 |94404
Alias|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52145
Andrew Pinski changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77712
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52145
Andrew Pinski changed:
What|Removed |Added
CC||dominique.pelle at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88655
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Fri, Dec 03, 2021 at 08:57:54AM -0600, Bill Schmidt wrote:
> Hi!
>
> On 12/3/21 5:56 AM, Thomas Koenig wrote:
> >
> > Hi Jakub,
> >
> >> Note, we want to test both building gcc on ppc64le with older glibc
> >> and newer glibc (and that libgfortran will have the same ABI between both
> >> and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65707
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60223
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.2
David: PING
In case you missed it, that's the last patch left to review for now.
Le dimanche 21 novembre 2021 à 16:44 -0500, Antoni Boucher a écrit :
> Thanks for the review!
> I updated the patch.
>
> See notes below.
>
> Le samedi 20 novembre 2021 à 13:50 -0500, David Malcolm a écrit :
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028
--- Comment #8 from Alexandre Oliva ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90391
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2019-06-12 00:00:00 |2021-12-3
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86473
Andrew Pinski changed:
What|Removed |Added
Known to fail||10.3.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90412
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70438
--- Comment #4 from Andrew Pinski ---
The documentation says:
The result of the comparison is a vector of the same width and number of
elements as the comparison operands with a signed integral element type.
But it is obviously not true.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028
--- Comment #7 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:daca416fc2816a5e481b26c8d2010127101d77ce
commit r12-5787-gdaca416fc2816a5e481b26c8d2010127101d77ce
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65994
--- Comment #4 from Andrew Pinski ---
CWG2038 :
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2038
Looks like it is explicit that there should be a difference between C++11/14
and C++17
But I can't find a compiler which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85589
--- Comment #3 from Andrew Pinski ---
I suspect r9-3836-g4be5c72cf3ea3 fixed this (maybe on accident).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77950
--- Comment #2 from Ian Lance Taylor ---
Just a note that my Go demangler does demangle this symbol now, producing
ossia::vec_merger_impl<2>::operator() > >, ossia::strong_value > >, ossia::strong_value
> >, ossia::strong_value > >,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83258
--- Comment #11 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #4)
> Testcase from Bug 85589:
>
> template struct foo {};
>
> int main() {
> static auto v = "str";
> (void) foo {};
> }
Note comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103549
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-12-04
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85589
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|NEW
Ever confirmed|0
On Thu, Dec 02, 2021 at 12:56:38PM -0500, Jason Merrill wrote:
> On 12/2/21 10:27, Marek Polacek wrote:
> > On Wed, Dec 01, 2021 at 11:24:58PM -0500, Jason Merrill wrote:
> > > On 12/1/21 10:16, Marek Polacek wrote:
> > > > In C++23, auto(x) is valid, so decltype(auto(x)) should also be valid,
> >
List-Unsubscribe
On 12/4/21 00:54, Gary Oblock via Gcc wrote:
David,
Thanks, I've bookmarked your advice. I do use gdb but I've always
found the macros in common use are the biggest hurdle. In addition
C++ has its own associated difficulties.
Note, in the past working on other compilers I've always tried to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57570
Andrew Pinski changed:
What|Removed |Added
Known to fail||5.1.0, 6.1.0, 7.1.0, 7.5.0
Ever
On 11/8/2021 7:34 PM, Martin Sebor via Gcc-patches wrote:
The pointer-query code that implements compute_objsize() that's
in turn used by most middle end access warnings now has a few
warts in it and (at least) one bug. With the exception of
the bug the warts aren't behind any user-visible
David,
Thanks, I've bookmarked your advice. I do use gdb but I've always
found the macros in common use are the biggest hurdle. In addition
C++ has its own associated difficulties.
Note, in the past working on other compilers I've always tried to have
a function version of the macros available.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103549
Bug ID: 103549
Summary: [12 regression] Uninitialized member warning from
regex header
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
On 12/2/21 4:24 PM, Segher Boessenkool wrote:
> On Thu, Dec 02, 2021 at 10:43:24AM -0600, Bill Schmidt wrote:
>> The new built-in infrastructure is now enabled!
>
> Congratulations, and thanks for all the work!
A big +1!
Peter
On 12/2/21 9:46 PM, Kewen.Lin via Gcc-patches wrote:
> on 2021/11/30 上午12:57, Segher Boessenkool wrote:
>> On Wed, Sep 01, 2021 at 02:55:51PM +0800, Kewen.Lin wrote:
>>> This patch is to fix the inconsistent behaviors for non-LTO mode
>>> and LTO mode. As Martin pointed out, currently the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
Jim Wilson changed:
What|Removed |Added
CC||kito.cheng at gmail dot com
--- Comment
On Fri, Dec 03, 2021 at 11:27:27AM +0100, Jakub Jelinek wrote:
> Hi!
>
> The https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557903.html
> change broke the following testcases. The problem is when a pragma
> namespace allows expansion (i.e. p->is_nspace && p->allow_expansion),
> e.g. the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932
Andrew Pinski changed:
What|Removed |Added
Known to work|10.1.0, 11.1.0, 12.0|
Keywords|needs-bisection,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932
Andrew Pinski changed:
What|Removed |Added
Known to fail||8.1.0, 9.1.0, 9.4.0
Keywords|
Tested powerpc64le-linux, pushed to trunk.
This introduces a new RAII type to simplify the emplace members which
currently use try-catch blocks to deallocate a node if an exception is
thrown by the comparisons done during insertion. The new type is created
on the stack and manages the allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92300
--- Comment #5 from Jonathan Wakely ---
Created attachment 51924
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51924=edit
Patch to avoid creating a node if inserting something key-like into a map
This avoids the allocate/deallocate pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92300
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> This inserts the correct value type, and doesn't perform an addition
> allocation:
>
> assert(a.insert(std::pair(1, 1)).second);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82873
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
On Mon, 22 Nov 2021 at 16:31, Stephan Bergmann via Libstdc++
wrote:
>
> When using recent libstc++ trunk with Clang in C++20 mode,
> std::u16string literals as in
>
> > #include
> > int main() {
> > using namespace std::literals;
> > u""s;
> > }
>
> started to cause linker failures due to
Snapshot gcc-10-20211203 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20211203/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
--- Comment #23 from Peter Bergner ---
(In reply to Peter Bergner from comment #22)
> So this is also broken in GCC11, so I'm testing the simple backport.
Regression testing of the backport was clean. Just need approval for the
backport.
On 12/3/21 3:27 PM, Peter Bergner wrote:
> On 12/3/21 2:39 PM, Peter Bergner wrote:
>> On 10/29/21 4:45 PM, Segher Boessenkool wrote:
>>> On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
2021-10-27 Martin Liska
gcc/
PR target/101324
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82873
Andrew Pinski changed:
What|Removed |Added
Known to fail||10.3.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57977
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-12-03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82873
Andrew Pinski changed:
What|Removed |Added
Known to work||12.0
Keywords|
We can make some function signatures shorter to print by omitting redundant
nested-name-specifiers in the rest of the declarator.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* error.c (current_dump_scope): New variable.
(dump_scope): Check it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692
--- Comment #5 from Jonathan Wakely ---
"A type trait to detect reference binding to temporary"
https://wg21.link/p2255r2 is the current direction to resolve this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103540
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97222
Andrew Pinski changed:
What|Removed |Added
CC||myriachan at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84415
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103547
--- Comment #3 from H.J. Lu ---
r12-5778 builds now. It has happened once before. I will leave it open
until we find out exactly what is going on.
I intend to merge this patch next week, unless I hear objections. I
consider it a bug fix which fits the Stage 3 criteria. It fixes the
RPMSG firmware examples in the latest version 6.0 of TI's PRU Software
Package.
The .pru_irq_map section has been introduced by Linux kernel 5.10:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
Peter Bergner changed:
What|Removed |Added
Known to fail||11.0
Target Milestone|12.0
On 12/3/21 2:39 PM, Peter Bergner wrote:
> On 10/29/21 4:45 PM, Segher Boessenkool wrote:
>> On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
>>> 2021-10-27 Martin Liska
>>>
>>> gcc/
>>> PR target/101324
>>> * config/rs6000/rs6000.c (rs6000_option_override_internal): Move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #10)
> On Thu, Dec 02, 2021 at 09:51:23PM +, anlauf at gcc dot gnu.org wrote:
> >
> > Submitted as:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103283
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #4
ead model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211203 (experimental) (GCC)
with a base gcc of 7.5.0, what bootstrap gcc are you using?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
--- Comment #21 from Peter Bergner ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
--- Comment #7 from Jason Merrill ---
(In reply to Andrew Pinski from comment #6)
> Note I think this paper applies to C++20 too or at least part of it.
>
> From CWG1291:
> [Accepted at the November, 2020 meeting as part of paper P1787R6 and
When a request is made for the range of an ssa_name at some location,
the first thing we do is invoke range_of_stmt() to ensure we have looked
at the definition and have an evaluation for the name at a global
level. I recently added a patch which dramatically reduces the call
stack
has_edge_range_p() and may_recompute_p() currently only take an optional
edge as a parameter. They only indicate if a range *might* be
calculated for a name, but they do not do any calculations.
To determine the results, they always consult the exports for the
edge->src block. the value is
On 10/29/21 4:45 PM, Segher Boessenkool wrote:
> On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
>> 2021-10-27 Martin Liska
>>
>> gcc/
>> PR target/101324
>> * config/rs6000/rs6000.c (rs6000_option_override_internal): Move the
>> disabling of shrink-wrapping when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> PR 5739 is related (though I have not looked fully).
comment #10 which points out IRA was doing worse.
On 12/2/21 5:15 PM, Segher Boessenkool wrote:
>> Tested on powerpc64le*-linux with no regressions. Ok for mainline?
>
> What can "*" be there other than the empty string? Which valuse of "*"
> did you test? :-)
Heh, too used to typing powerpc64*-linux. Yeah, in this case * == "".
> Okay
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
--- Comment #1 from Andrew Pinski ---
I thought I had seen this before ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
--- Comment #20 from CVS Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:cff7879a381d3f5ed6556206896e6a6229800167
commit r12-5781-gcff7879a381d3f5ed6556206896e6a6229800167
Author: Martin Liska
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103537
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505
--- Comment #10 from Steve Kargl ---
On Thu, Dec 02, 2021 at 09:51:23PM +, anlauf at gcc dot gnu.org wrote:
>
> Submitted as: https://gcc.gnu.org/pipermail/fortran/2021-December/057102.html
>
Just saw the commit fly by. Thanks for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103544
Andrew Pinski changed:
What|Removed |Added
Component|c++ |tree-optimization
Known to work|
It can be used to speed up the libgcc unwinder, and the internal
_dl_find_dso_for_object function (which is used for caller
identification in dlopen and related functions, and in dladdr).
_dl_find_object is in the internal namespace due to bug 28503.
If libgcc switches to _dl_find_object, this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103537
--- Comment #2 from Hedayat Vatankhah ---
With these options, the code runs a bit more but still crashes. The output of
each option is given below:
Output with -fsanitize=undefined:
/home/hedayat/Projects/powerfake/powerfake.h:257:40: runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103544
--- Comment #1 from Andrew Pinski ---
Testcase:
#include
#include
int crash_me(char* ptr, size_t size){
std::array result = {0};
size_t no_iters = 0;
for(size_t i = 0; i < size - 12; i+= 13){
for(size_t j = 0; j < 12;
On Fri, 3 Dec 2021, 18:58 Dr. Jürgen Sauermann,
wrote:
> Hi,
>
> not sure if this matters or how int can be fixed, but today I observed
> the following:
>
> Your web page says that "Static assertions" are supported by GCC since
> version 4.3.
>
> Today I tried to use "Static assertions" on an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103547
Andrew Pinski changed:
What|Removed |Added
Keywords||build, wrong-code
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505
--- Comment #9 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:f46d32dd29b7623915e31b0508e2e925526fa7d8
commit r12-5779-gf46d32dd29b7623915e31b0508e2e925526fa7d8
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103542
Andrew Pinski changed:
What|Removed |Added
Known to fail||10.3.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103547
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103548
Peter Bergner changed:
What|Removed |Added
Target||powerpc*-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692
Andrew Pinski changed:
What|Removed |Added
CC||gcc at hazlewoods dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103543
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 232 matches
Mail list logo
