https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99750
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
Jonathan Wakely changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98894
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #5 from Jonathan Wakely ---
(In reply to Segher Boessenkool from comment #3)
> In an ideal world the user can just assume those types exist always. In a
> less ideal world, use autoconf? You have to anyway, if you want to support
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99752
--- Comment #3 from Jonathan Wakely ---
Your example is an infinite loop because you're asking for the last occurrence
of e in an infinite range. There is no end of an infinite range.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #7 from Jonathan Wakely ---
(In reply to Segher Boessenkool from comment #6)
> Yes. And it does not mean the type exist (or is usable), either.
Example?
> Do we? The types should always exist!
Please tell that to our IBM colleagu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99770
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99770
--- Comment #2 from Jonathan Wakely ---
(In reply to Nishant Chauhan from comment #0)
> Is this a bug in gcc on arm?
No, the warning is correct. You are passing NULL where a size_t is expected.
That's probably a bug in your code, you should fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99772
Bug ID: 99772
Summary: New built-ins for pointer comparisons that yield a
total order
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99789
--- Comment #10 from Jonathan Wakely ---
We don't want the assembly file. If you want to investigate what Rust does, you
are free to do that. But stop asking us to do that for you. There is no GCC bug
here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely changed:
What|Removed |Added
Summary|address_of() is broken by |to_address() is broken by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #15 from Jonathan Wakely ---
(In reply to Giuseppe D'Angelo from comment #14)
> This gets evil really quick: the presence of both value_type and
> element_type in an contiguous iterator will make you smash face-first
> against LWG3446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85907
--- Comment #3 from Jonathan Wakely ---
(In reply to David Edelsohn from comment #2)
> This should be fixed with the recent patch to collect2.c, which will be
> released in GCC 8.2, GCC 7.4, GCC 6.5.
Is it fixed now then?
https://gcc.gnu.org/pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
--- Comment #1 from Jonathan Wakely ---
I cannot reproduce this with upstream GCC. This looks like a bug in
devtoolset-10, so I'll report it to Red Hat's bugzilla instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95592
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|11.0|10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|11.0|10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93151
--- Comment #9 from Jonathan Wakely ---
And for 10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98319
--- Comment #4 from Jonathan Wakely ---
And for 10.3 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
--- Comment #19 from Jonathan Wakely ---
Re-fixed for 10.3 as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99077
Jonathan Wakely changed:
What|Removed |Added
Summary|[9/10 Regression] Cannot|[9 Regression] Cannot build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99537
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536
--- Comment #5 from Jonathan Wakely ---
And for 10.3 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99533
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> Fixed for gcc-11 only for now.
And 10.3 now too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79070
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2017-02-08 00:00:00 |2021-3-30
--- Comment #4 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #11 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #10)
> Is your compiler intentionally configured without --with-long-double-128,
No.
> i.e. are you intentionally testing the double == long double case?
Not inte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #12 from Jonathan Wakely ---
Also, the docs for --with-long-double-128 say
When neither of these configure options are used, the default will be 128-bit
long double when built against GNU C Library 2.4 and later, 64-bit long
doub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99827
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
Bug ID: 99832
Summary: std::chrono::system_clock::to_time_t needs ABI tag for
32-bit time_t
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
--- Comment #5 from Jonathan Wakely ---
Reduced:
namespace std {
using size_t = decltype(sizeof(0));
struct nothrow_t { } const nothrow = { };
}
void* operator new(std::size_t);
void* operator new[](std::size_t);
void operator delete(void*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
--- Comment #6 from Jonathan Wakely ---
(In reply to Keith Halligan from comment #0)
> class MemAlloc {
> public:
> MemAlloc() {}
> void* operator new[](size_t sz, const std::nothrow_t& nt) {
> return ::operator new(sz, nt);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
--- Comment #8 from Jonathan Wakely ---
Alternatively, compile with -fcheck-new to tell the compiler that *all*
operator new overloads can return a null pointer. That means it always checks
for null, even for overloads that are declared as potent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99851
Bug ID: 99851
Summary: Warn about operator new that takes std::nothrow_t but
is potentially-throwing
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99851
--- Comment #2 from Jonathan Wakely ---
(In reply to Martin Sebor from comment #1)
> Confirmed, thanks! Just to make sure I understand: we want a warning for
> the operator new declaration (irrespective of its definition) because the
> nothrow_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99851
--- Comment #3 from Jonathan Wakely ---
And just to be clear, this should apply to operator new and operator new[]. The
examples above both use the array form, but there's no reason this shouldn't
apply to the single object form too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99858
--- Comment #2 from Jonathan Wakely ---
As requested by https://gcc.gnu.org/bugs/ please provide code, not just a URL.
Reduced:
extern "C" int printf(const char*, ...);
int main() try {
try {
throw (void*)1;
} catch (void*& ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99871
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99871
--- Comment #1 from Jonathan Wakely ---
I wonder if there's a reason we don't just put the visibility on the namespace
the way we do elsewhere:
namespace std _GLIBCXX_VISIBILITY(default)
I will do that, or just move the pragma after the include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
Jonathan Wakely changed:
What|Removed |Added
Known to fail||10.2.0, 11.0, 9.3.0
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99868
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-04-01
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876
--- Comment #2 from Jonathan Wakely ---
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -65,19 +65,12 @@ namespace posix = std::filesystem::__gnu_posix;
fs::path
fs::absolute(const path& p)
{
-#ifdef _GLIBCXX_F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
--- Comment #4 from Jonathan Wakely ---
Wow, this is tricksy.
The bug happens when parsing the string into a path. The path is split into
components and the offset of each component from the beginning of the string is
stored, so that parent_path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
--- Comment #5 from Jonathan Wakely ---
It would have worked if it used std::as_const(_M_pathname).data() or
_M_pathname.c_str() instead of _M_pathname.data(). It's only the non-const
data() added in C++17 which reallocates (since r261642 anyway)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86169
--- Comment #5 from Jonathan Wakely ---
Oh dear, this should have removed the 'noexcept' from the non-const data(),
since it might now fail to allocate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
--- Comment #10 from Jonathan Wakely ---
(In reply to Jason Merrill from comment #8)
> Any opinions on what our behavior should be? Should there be an LWG issue?
Yes, we want an LWG issue. That might then result in a new core issue too, if
we c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99891
--- Comment #2 from Jonathan Wakely ---
This seems like something you should ask on the mailing list, it's not a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99891
--- Comment #3 from Jonathan Wakely ---
And if you're comparing a recent Ti compiler with GCC 4.8.1, I hope you realise
that GCC 4.8.1 is eight years old.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99894
--- Comment #2 from Jonathan Wakely ---
This is not a bug report. lease use the gcc-help mailing list for basic
question about GCC, don't report bugs to ask questions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896
--- Comment #1 from Jonathan Wakely ---
(In reply to Tom de Vries from comment #0)
> With g++, we have instead:
> ...
> collect2 ... main.o foo.o -lpcre2-posix ...
> ...
It isn't dropped, it's moved to the end:
main.o foo.o -lpcre2-posix -lstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90183
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-04-03
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99892
--- Comment #2 from Jonathan Wakely ---
(In reply to ZhangMin from comment #0)
> However, in version 4.8.1, only a few processors such as PowerPC support -
> pthread option, and the more commonly used arm and x86 processors do not
> support this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896
--- Comment #4 from Jonathan Wakely ---
(In reply to Tom de Vries from comment #2)
> I don't understand. AFAICT, it's dropped. It's not moved to the end,
> because -lc is already at the end without specifying -lc.
OK, it's dropped because it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99066
--- Comment #6 from Jonathan Wakely ---
(In reply to Jason Merrill from comment #3)
> r104041, yes. Bizarre that this went unnoticed for over 15 years.
Very surprising, isn't it!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99934
Bug ID: 99934
Summary: bad_array_new_length thrown when non-throwing
allocation function would have been used
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Jonathan Wakely changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780
--- Comment #3 from Jonathan Wakely ---
I think that would be great.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99871
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |12.0
--- Comment #2 from Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99938
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99942
Bug ID: 99942
Summary: [8/9/10/11 Regression] COW std::string::data() is
noexcept but can throw
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99942
Jonathan Wakely changed:
What|Removed |Added
Known to work||7.3.0, 8.1.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99894
--- Comment #5 from Jonathan Wakely ---
(In reply to ZhangMin from comment #3)
> Thanks, I want to know which version of gcc can support OpenCL?
This is still not a bug report, so doesn't belong in bugzilla.
GCC does not come with OpenCL suppor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99954
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99954
--- Comment #2 from Jonathan Wakely ---
> using -O2 "fixes" the issue on GCC 9 and below but not on 10.
And that changed with r271553
PR tree-optimization/88440
* opts.c (default_options_table): Enable
-ftree-loop-distribute-pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #49 from Jonathan Wakely ---
Looks like you didn't rebuild something properly. The __once_functor symbol
should not have changed at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97930
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99957
Bug ID: 99957
Summary: Ill-formed std::pair construction supported
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: minor
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99957
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
Jonathan Wakely changed:
What|Removed |Added
Summary|[9/10/11 Regression]|[9/10 Regression]
|f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99961
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99958
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99958
--- Comment #2 from Jonathan Wakely ---
This seems to work:
diff --git a/libstdc++-v3/include/pstl/glue_algorithm_defs.h
b/libstdc++-v3/include/pstl/glue_algorithm_defs.h
index 48bc56ae401..cef78e22e31 100644
--- a/libstdc++-v3/include/pstl/glue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
--- Comment #19 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #16)
> includes so std::boyer_moore_searcher can use
> std::vector, but it doesn't need it at all. Using std::unique_ptr would
> do fine.
We can't change that n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
--- Comment #20 from Jonathan Wakely ---
As noted in PR 99958 comment 1, got big, because:
is included by which is included by
which is included by which is included by
which is included by which is included
by .
is included by , wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
--- Comment #21 from Jonathan Wakely ---
This seems to work:
diff --git a/libstdc++-v3/include/pstl/glue_algorithm_defs.h
b/libstdc++-v3/include/pstl/glue_algorithm_defs.h
index 48bc56ae401..cef78e22e31 100644
--- a/libstdc++-v3/include/pstl/glu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99958
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
Jonathan Wakely changed:
What|Removed |Added
CC||hewillk at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |12.0
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99968
Bug ID: 99968
Summary: [11 Regression] ICE on remove_const_t in requires-expression
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99968
Jonathan Wakely changed:
What|Removed |Added
Known to work||10.2.1
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99968
--- Comment #1 from Jonathan Wakely ---
The ICE only happens with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99968
Jonathan Wakely changed:
What|Removed |Added
Summary|[10/11 Regression] ICE on |ICE on
|remove_const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99846
--- Comment #2 from Jonathan Wakely ---
That's because C++20 <=> comparisons aren't present on the branch. They were
added by g:9e58988061f4175896de11af0caf9bdd48c9b046
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99846
--- Comment #3 from Jonathan Wakely ---
Actually that's not true, that commit *is* on the gcc-10 branch. I'll bisect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99846
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362
Jonathan Wakely changed:
What|Removed |Added
Known to work||10.3.0
--- Comment #10 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96029
Jonathan Wakely changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99970
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
Jonathan Wakely changed:
What|Removed |Added
Priority|P1 |P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
Jonathan Wakely changed:
What|Removed |Added
Known to work||10.3.1, 11.0
Summary|[9/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96029
Jonathan Wakely changed:
What|Removed |Added
Summary|[8/9/10 Regression] |[8/9 Regression]
|In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96029
Jonathan Wakely changed:
What|Removed |Added
Summary|[8/9 Regression]|[8 Regression]
|Inco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99979
--- Comment #1 from Jonathan Wakely ---
The _Unlock type was introduced for PR libstdc++/50862 (and then modified
slightly by PR libstdc++/53830).
101 - 200 of 7031 matches
Mail list logo
