https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
mark changed:
What|Removed |Added
CC||markrubn at yahoo dot com
--- Comment #18 from ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782
--- Comment #8 from Kai Tietz ---
Hmm, that behavior of gcc seems to be indeed pretty bad. The SEH commands for
registers above index 15 (0..15) for xmm? are indeed undefined, and even worse,
can't be coded proper into the seh table correctly.
An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93636
Bug ID: 93636
Summary: Incorrect diagnostic of a potential string overflow in
strncat
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #19 from Jonathan Wakely ---
The main reason is that reinterpret_cast subverts the type system. Constant
expressions have to be free of undefined behaviour, which is impossible to do
if arbitrary nonsense^W code that violates the type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #20 from Jonathan Wakely ---
(In reply to mark from comment #18)
> And of course none of this is needed when coding in C instead of C++. The
> following struct is placed in .data without any workarounds being required:
And doesn't ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93633
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:81958cd6adf402a85dc7d21b43caac56fba0af21
commit r10-6533-g81958cd6adf402a85dc7d21b43caac56fba0af21
Author: Jakub Jelinek
Date: Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93633
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #21 from mark ---
(In reply to Jonathan Wakely from comment #19)
> The main reason is that reinterpret_cast subverts the type system.
> Constant expressions have to be free of undefined behaviour, which is
> impossible to do if arbitr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #15 from Vincent Lefèvre ---
(In reply to Rich Felker from comment #14)
> It sounds like you misunderstand the standard's requirements on, and GCC's
> implementation of, FLT_EVAL_METHOD==2/excess-precision. The availability of
> regis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637
Bug ID: 93637
Summary: [9/10 Regression] ICE: Segmentation fault (in
force_operand)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599
--- Comment #7 from Thomas Koenig ---
Hi Jerry,
this is without Janne's patch (which, as far as I see, concerns
handling I/O when the threads have already started).
Regarding testing: I could not get the original test case to fail
on gcc135, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #22 from Jonathan Wakely ---
(In reply to mark from comment #21)
> The behavior here is non-portable, but well defined. If it wasn't, the
> runtime reinterpret_cast would also be undefined. Why are/should constant
> expressions be dif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #23 from Jonathan Wakely ---
What you want (and what everybody I've seen asking for similar things) is to
give a compile-time constant value to a pointer. All that's needed for that is
an extension to provide a compile-time constant v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70813
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93638
Bug ID: 93638
Summary: [concepts] Dependent names in requires clause reported
as different types when function definition is not
inline
Product: gcc
Version: 10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #16 from Rich Felker ---
> And GCC does not do spills in this format, as see in bug 323.
In my experience it seems to (assuming -fexcess-precision=standard), though I
have not done extensive testing. I'll check and follow up.
> This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #17 from Rich Felker ---
And indeed you're right that GCC does it wrong. This can be seen from a minimal
example:
double g(),h();
double f()
{
return g()+h();
}
where gcc emits fstpl/fldp around the second call rather than fstpt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #18 from Rich Felker ---
It was just pointed out to me that this might be an invalid test since GCC
assumes (correctly or not) that the return value of a function does not have
excess precision. I'll see if I can make a better test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #34 from Lewis Hyatt ---
(In reply to Eric Gallager from comment #33)
> This is a big enough feature that it should probably get an entry in
> gcc-10/changes.html
I emailed a suggested patch to that effect here:
https://gcc.gnu.org/m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #19 from Rich Felker ---
Test case provided by Szabolcs Nagy showing that GCC does seem to spill right
if it can't assume there's no excess precision to begin with:
double h();
double ff(double x, double y)
{
return x+y+h();
}
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93639
Bug ID: 93639
Summary: [c++2a] Segfault on non type template parameter and
consteval (master)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93639
--- Comment #1 from raphael grimm ---
Created attachment 47803
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47803&action=edit
ii file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93640
Bug ID: 93640
Summary: The write_only and read_write attributes can be
mistyped due to invalid strncmp size argument
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93639
--- Comment #2 from raphael grimm ---
Created attachment 47804
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47804&action=edit
more minimal example also causing this error
test.cpp:23:28: internal compiler error: Segmentation fault
23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93641
Bug ID: 93641
Summary: Wrong strncmp and strncasecmp size arguments
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #147 from Peter Bisroev ---
(In reply to The Written Word from comment #145)
> Created attachment 47799 [details]
> gcc-8.3.0 patches v2
>
> v2 of our patch set.
Thank you The Written Word. However I still get an ICE failure with se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #148 from The Written Word
---
(In reply to The Written Word from comment #144)
> We have a build running that seems to be going well. We are using gcc-4.9.4
> to build 8.3.0. I will attach the current patch set we are building again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93642
Bug ID: 93642
Summary: [Coroutines] internal compiler error: in
expand_expr_addr_expr_1, at expr.c:8070 using
co_return
Product: gcc
Version: 10.0
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93642
--- Comment #1 from Wesley Shillingford ---
Created attachment 47806
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47806&action=edit
Original file showing the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93642
--- Comment #2 from Wesley Shillingford ---
Not sure if I can edit my comment, but just realised the #include in the
original comment should be #include not #include . The
attachments are fine though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #149 from Peter Bisroev ---
(In reply to The Written Word from comment #148)
> (In reply to The Written Word from comment #144)
> > We have a build running that seems to be going well. We are using gcc-4.9.4
> > to build 8.3.0. I will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #150 from The Written Word
---
(In reply to Peter Bisroev from comment #149)
> (In reply to The Written Word from comment #148)
> > (In reply to The Written Word from comment #144)
> > > We have a build running that seems to be going
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93643
Bug ID: 93643
Summary: Static function pointer inside inline function with
"C" linkage is not mangled
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93405
--- Comment #5 from Toon Moene ---
I have no problem with it.
I will ACK it on the fortran mailing list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
Bug ID: 93644
Summary: -Wreturn-local-addr July regression: new
false-positive warning
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #151 from David Malcolm ---
(In reply to Peter Bisroev from comment #139)
[...]
> I am not sure how these selftests work yet but will take a look into them to
> see if we can reproduce a reliable minimal test case.
FWIW, I added th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90556
Bug 90556 depends on bug 81811, which changed state.
Bug 81811 Summary: missing -Wreturn-local-addr returning strcpy result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81811
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81811
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
Component|tree-optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
--- Comment #2 from Marc Glisse ---
# buffer_2 = PHI <&stack_bufD.1939(3), buffer_7(D)(9)>
buffer_18 = ASSERT_EXPR ;
Can't we deduce from this
buffer_18 = buffer_7(D)
? Of course that's not a general solution, but it looks like a sensib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60669
--- Comment #2 from Andrew Pinski ---
I ran into this same issue when I am writing a patch for PR55177 (attached
below) but with f8 rather than f7 from vrp65.c.
diff --git a/gcc/match.pd b/gcc/match.pd
index 363006e28fd..a31fe598a25 100644
--- a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93640
Martin Sebor changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93640
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93636
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #24 from comexk at gmail dot com ---
> All that's needed for that is an extension to provide a compile-time
> constant value to a pointer, not to allow arbitrary reinterpret_casts in
> constexpr.
Well, there aren't that many things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
--- Comment #4 from Martin Sebor ---
pr90735 suggests using the location of the closing curly brace of the function
instead. Another alternative might be to use the location associated with the
note.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93618
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #21 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #20)
> diff --git a/gcc/match.pd b/gcc/match.pd
I ran into a testcase regression with my new correct version. See PR 60669 for
that case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645
Bug ID: 93645
Summary: Support -fuse-ld=/absolute/path/to/ld
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93646
Bug ID: 93646
Summary: confusing -Wstringop-truncation on strncat where
-Wstringop-overflow is expected
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93646
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645
--- Comment #1 from Fangrui Song ---
Posted a patch https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00510.html
I agree with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321#c4
we should use a new option, instead of overloading --print-prog-nam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52982
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #4 from F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93647
Bug ID: 93647
Summary: ICE in get_lvalue_1, at analyzer/region-model.cc:4613
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93636
Sebastian Unger changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93203
--- Comment #1 from CVS Commits ---
The master branch has been updated by Feng Xue :
https://gcc.gnu.org/g:a0f6a8cb414b687f22c9011a894d5e8e398c4be0
commit r10-6540-ga0f6a8cb414b687f22c9011a894d5e8e398c4be0
Author: Feng Xue
Date: Tue Jan 21 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93203
--- Comment #2 from CVS Commits ---
The master branch has been updated by Feng Xue :
https://gcc.gnu.org/g:a5f79f225e637d59a7b6e26ae62b74b0019d2e85
commit r10-6541-ga5f79f225e637d59a7b6e26ae62b74b0019d2e85
Author: Feng Xue
Date: Mon Feb 10 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93636
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
--- Comment #3 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93643
Andrew Pinski changed:
What|Removed |Added
Keywords||assemble-failure,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92599
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
---
66 matches
Mail list logo
