https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618
Eric Gallager changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91383
Bug ID: 91383
Summary: C++17 should remove some library feature deprecated in
C++14
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81429
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #7 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91382
Bug ID: 91382
Summary: Missing pedwarn when using [[maybe_unused]] in C++14
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81429
--- Comment #6 from Marek Polacek ---
I have a fix. Extended testcase:
void fn1([[maybe_unused]] int a) { }
void fn2(int a [[maybe_unused]]) { }
void fn3(__attribute__((unused)) int a) { }
void fn4(int a __attribute__((unused))) { }
struct S1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91334
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47191
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P5 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #29 from Lewis Hyatt ---
(In reply to jos...@codesourcery.com from comment #28)
> Thanks for working on this! I encourage sending this to gcc-patches once
> a few fixes have been made and you've done the legal paperwork, see
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91359
--- Comment #11 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Aug 6 21:32:09 2019
New Revision: 274149
URL: https://gcc.gnu.org/viewcvs?rev=274149=gcc=rev
Log:
2019-08-06 Steven G. Kargl
PR fortran/91359
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #16 from joseph at codesourcery dot com ---
I think the most likely case for code using such comparisons is not a
mistake, but code doing something like memmove - code that checks whether
two arrays overlap, and which one comes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91371
--- Comment #4 from Roland Schulz ---
Are there any known issues with the libc++ solution? Otherwise it seems like
the simpler solution than adding a builtin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84591
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81429
--- Comment #5 from Marek Polacek ---
Small test from Hana:
void foo([[maybe_unused]] int a) { }
struct bar {
bar([[maybe_unused]] int a) { }
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81429
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81429
Hana Dusíková changed:
What|Removed |Added
CC||hanicka at hanicka dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42546
--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Aug 6 19:46:29 2019
New Revision: 274147
URL: https://gcc.gnu.org/viewcvs?rev=274147=gcc=rev
Log:
2019-08-01 Steven G. Kargl
PR fortran/42546
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #9 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #8)
> you'd still need a change to the Itanium ABI.
Or an attribute like [[clang::trivial_abi]], or the one that p1029 is trying to
standardize. But since we would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91371
--- Comment #3 from Jonathan Wakely ---
We already have 24 partial specializations. To handle ms_abi, fastcall and
thiscall would need another 72. We could probably stamp them out with
preprocessor macros, but I'd prefer not to. I think we need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91380
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #8 from Jonathan Wakely ---
Yes, when configured with --enable-symvers=gnu-versioned-namespace
But that's just for the library, you'd still need a change to the Itanium ABI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91359
--- Comment #10 from Brian T. Carcich ---
thank you.
On Tue, Aug 6, 2019 at 2:28 PM kargl at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91359
>
> --- Comment #9 from kargl at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #70 from Eric Gallager ---
With some distributions wanting to make LTO the default, I'd think this issue
might become a bit more important...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91359
--- Comment #9 from kargl at gcc dot gnu.org ---
Against my better judgement, I have submitted a patch that seems to fix this
issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91352
mateuszb at poczta dot onet.pl changed:
What|Removed |Added
CC||mateuszb at poczta dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91371
--- Comment #2 from Roland Schulz ---
Would you recommend to fix this by adding the specializations for the
alternative calling conventions to std::is_function or by switching to the
libc++ approach?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #28 from joseph at codesourcery dot com ---
On Mon, 22 Jul 2019, lhyatt at gmail dot com wrote:
> I am interested in helping out with this if there is still interest to support
> this feature. (Full disclosure, I don't have any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91381
Bug ID: 91381
Summary: ARM NEON register variable DWARF incorrect
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91226
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91226
--- Comment #1 from joseph at codesourcery dot com ---
This appears to be a bug in libdecnumber/bid/bid2dpd_dpd2bid.c.
_bid_to_dpd32 checks for a too-large significand, but _bid_to_dpd64 does
not. Furthermore, _bid_to_dpd128 has the same bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91380
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91380
Bug ID: 91380
Summary: Requesting a better diagnostic for dumb include
mistake
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91379
Bug ID: 91379
Summary: internal compiler error __gcov_fork
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #10 from rguenther at suse dot de ---
On August 6, 2019 5:36:49 PM GMT+02:00, "matz at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
>
>--- Comment #9 from Michael Matz ---
>(In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91351
--- Comment #10 from Marc Glisse ---
(In reply to Martin Liška from comment #9)
> So the integer_type of the enumeral_type hash precision:5 and:
> min
>
> and
>
> max
>
> which is what one would expect from -fstrict-enums.
But the enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #9 from Michael Matz ---
(In reply to rguent...@suse.de from comment #8)
> >The fun thing is, there's a difference between these two loop nests:
> >
> > for (i) for (j) a[i][0] = f(a[i+1][0]);
> > for (i) for (j) b[i][j] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91362
--- Comment #3 from matic at nimp dot co.uk ---
Sorry I was not aware of "aliasing". Thanks for the pointers to solutions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91206
--- Comment #3 from joseph at codesourcery dot com ---
There is a known ambiguity in the standard requirements where the argument
has the correct promoted type but not the expected type before promotion.
I wrote up some notes on this some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #7 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #6)
> libstdc++ would not take
> advantage of it because it would break the library's stable ABI.
There is always this mode (is it _GLIBCXX_INLINE_VERSION? I thought
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #14 from Martin Sebor ---
Jeff has a setup that builds most if not all targets. I think he's also got it
hooked up to an emulator but I'm not sure he runs tests. Unfortunately,
there's no Web interface to it that we could access.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91193
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #32 from joseph at codesourcery dot com ---
I concur that passing CL_DRIVER instead of CL_LANG_ALL is correct here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91281
Marc Glisse changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91281
Marc Glisse changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #2 from Marc Glisse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #13 from joseph at codesourcery dot com ---
As I noted in bug 40883 comment 8, you can detect such issues in
target-specific code by building a cross compiler using a native compiler
from the same trunk version, and configuring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64679
Jonathan Wakely changed:
What|Removed |Added
Keywords|diagnostic |
Last reconfirmed|2017-09-28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91155
--- Comment #4 from Martin Liška ---
Jason?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91351
--- Comment #9 from Martin Liška ---
On 8/6/19 2:54 PM, glisse at gcc dot gnu.org wrote:
> Does the enum really have a precision of 5 bits? I would have expected
> (1<<5)-11 instead of 4294967285 (i.e. (1<<32)-11), without looking at it too
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91371
--- Comment #1 from Jonathan Wakely ---
The problem is not with bind and bind_front, it's that std::is_function doesn't
recognize such a function, and so std::decay doesn't know what to do with it:
#include
int bar(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67225
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91378
--- Comment #1 from Jason Merrill ---
Author: jason
Date: Tue Aug 6 14:07:59 2019
New Revision: 274143
URL: https://gcc.gnu.org/viewcvs?rev=274143=gcc=rev
Log:
PR c++/91378 - ICE with noexcept and auto return type.
Here, since the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91371
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91378
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91378
Bug ID: 91378
Summary: [9/10 regression] [C++17] ICE in
type_dependent_expression_p with noexcept and deduced
return type
Product: gcc
Version: 9.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #6 from Jonathan Wakely ---
No, it needs co-operation between G++ and all other compilers using the same
ABI, which makes it out of scope for GCC's bugzilla. G++ cannot unilaterally
change the ABI here, and even if we could,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90597
--- Comment #5 from dave.anglin at bell dot net ---
On 2019-08-05 10:45 p.m., msebor at gcc dot gnu.org wrote:
> --- Comment #4 from Martin Sebor ---
> pr89797 reported a similar (but not quite the same) ICE in the aarch64
> back-end. Maybe the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91358
--- Comment #3 from Michael Matz ---
(In reply to Antony Polukhin from comment #2)
> (In reply to Michael Matz from comment #1)
> Valgrind complains are distracting. GDB entering the destructor is
> missleading. Is there a simple way to change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91351
--- Comment #8 from Marc Glisse ---
(In reply to Martin Liška from comment #7)
> --- a/gcc/tree.c
> +++ b/gcc/tree.c
> @@ -11926,7 +11926,7 @@ int_cst_value (const_tree x)
> tree
> signed_or_unsigned_type_for (int unsignedp, tree type)
> {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91305
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91377
Bug ID: 91377
Summary: (regression) ICE with non-static block scope
constexpr, captured in lambda, used as template
parameter
Product: gcc
Version: 9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #19 from Rich Felker ---
Re comment 17, non-prototype declarations might be error-prone, but they're
valid C and necessary for certain usage cases. The motivation for making this
error-by-default is that "implicit function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91352
Martin Liška changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91351
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91351
--- Comment #7 from Martin Liška ---
(In reply to Marc Glisse from comment #3)
> Switch lowering produces things like
>
> _6 = e_2(D) + 4294967285;
> if (_6 > 2)
>
> for range checking, where _6 has type enum E, and VRP2 later takes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #18 from Rich Felker ---
Just to clarify, an "implicit function declaration" is use of a token that
could be an identifier as the operand of the function call operator (), with no
declaration for the identifier in scope. A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #17 from Vincent Lefèvre ---
(In reply to Florian Weimer from comment #16)
> (In reply to Vincent Lefèvre from comment #15)
> > OK, but the issue is similar: in both cases, the parameters/arguments are
> > not checked, yielding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #16 from Florian Weimer ---
(In reply to Vincent Lefèvre from comment #15)
> (In reply to Florian Weimer from comment #14)
> > (In reply to Vincent Lefèvre from comment #13)
> > > By "implicit function declarations", does this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
Bug ID: 91376
Summary: g++.dg/lto/pr90990 FAILs with gld 2.32.51
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #5 from Niels Möller ---
(In reply to Jonathan Wakely from comment #4)
> Why wouldn't you take unique_ptr&& instead of passing by value?
Because passing unique_ptr (and other move-only types) by value seems to be the
mainstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91373
--- Comment #7 from Qiang ---
Sorry to be a bother and thanks all of you.
'-fsanitize=undefined' & '-fwrapv' are new item to me.
'-fsanitize=undefined' is helpful to me to find out the similar issue in our
code.
'-fwrapv' may hide other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #15 from Vincent Lefèvre ---
(In reply to Florian Weimer from comment #14)
> (In reply to Vincent Lefèvre from comment #13)
> > By "implicit function declarations", does this include K style
> > declarations?
>
> No, there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #14 from Florian Weimer ---
(In reply to Vincent Lefèvre from comment #13)
> By "implicit function declarations", does this include K style
> declarations?
No, there is nothing implicit about them.
> I've found out a few days ago
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91373
--- Comment #6 from Jonathan Wakely ---
And Bugzilla asks you to read https://gcc.gnu.org/bugs before creating a new
bug, and that page asks you to try -fsanitize=undefined to see if your code is
undefined. If you'd done that you'd have been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41423
--- Comment #4 from Jonathan Wakely ---
I'm not aware of an existing one that would be suitable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91358
--- Comment #2 from Antony Polukhin ---
(In reply to Michael Matz from comment #1)
> So, if you've seen a real problem somewhere (and not just valgrind
> complaining about uninitialized registers in comparisons),
> then you've reduced the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #13 from Vincent Lefèvre ---
By "implicit function declarations", does this include K style declarations?
I've found out a few days ago that GMP still uses K style declarations, and
that's in a configure script. The issue is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90991
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90991
Jakub Jelinek changed:
What|Removed |Added
CC||kretz at kde dot org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91142
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91375
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91375
Bug ID: 91375
Summary: [8/9/10 Regression] ICE on valid code in
subbinfo_with_vtable_at_offset at ipa-devirt.c:2760
since r256685
Product: gcc
Version: 10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91142
Martin Kronbichler changed:
What|Removed |Added
CC||kronbichler.martin at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #3 from Marc Glisse ---
(In reply to Niels Möller from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > The ABI dictates the calling conventions and there's certainly nothing that
> > libstdc++ can do about it.
>
> My
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91373
--- Comment #5 from Marc Glisse ---
Note that gcc (like clang) provides a tool to help you detect this kind of
issue. If you compile with -fsanitize=undefined, then at runtime you will see:
main.c:7:20: runtime error: signed integer overflow:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91373
--- Comment #4 from Andrew Pinski ---
>If GCC need to follow rule, it should not be relative to GCC optimization.
So there are two rules here getting involved. One is the implicit promoting to
int. The second rule is that signed integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91373
--- Comment #3 from Andrew Pinski ---
>but it's a burden that tool need user to explicitly cast it too follow the
>implicit rule, isn't it?
Except that is what the language says. It is like saying a natural language
rules dont need to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #8 from rguenther at suse dot de ---
On August 5, 2019 9:53:48 PM GMT+02:00, "matz at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
>
>--- Comment #7 from Michael Matz ---
>Created attachment 46675
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #2 from Niels Möller ---
(In reply to Jonathan Wakely from comment #1)
> The ABI dictates the calling conventions and there's certainly nothing that
> libstdc++ can do about it.
My impression was that C++ ABI is under the control of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91373
--- Comment #2 from Qiang ---
Hi Andrew,
Thank your for your quickly reply.
I still have some questions about this issue.
It's very natural to write down the following code.
All arguments are declared with 'U16', and the return type is 'U32'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91374
Bug ID: 91374
Summary: [Missed optimization] Versioning opportunities to
improve performance
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity:
91 matches
Mail list logo
