https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113125
Bug ID: 113125
Summary: [D] internal compiler error: in make_import, at
d/imports.cc:48
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #13 from Jiu Fu Guo ---
(In reply to GCC Commits from comment #9)
> The master branch has been updated by Hans-Peter Nilsson :
>
> https://gcc.gnu.org/g:3d03630b123411340e52d05124cb0cacfa1fc8b0
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
Hans-Peter Nilsson changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #11 from Hans-Peter Nilsson ---
(In reply to Jiu Fu Guo from comment #8)
> I'm wondering if we need to revert r14-6674 to avoid this functionality
> issue. And revisit/enhance the patch later.
No need, not anymore; not because of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #10 from Hans-Peter Nilsson ---
(In reply to Andrew Pinski from comment #6)
> So I did a quick audit of the EH_RETURN_HANDLER_RTX
Yeah, me too.
> and most are registers
> rather than a memory location . And the ones which were
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #9 from GCC Commits ---
The master branch has been updated by Hans-Peter Nilsson :
https://gcc.gnu.org/g:3d03630b123411340e52d05124cb0cacfa1fc8b0
commit r14-6817-g3d03630b123411340e52d05124cb0cacfa1fc8b0
Author: Hans-Peter Nilsson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #8 from Jiu Fu Guo ---
(In reply to Andrew Pinski from comment #6)
> So I did a quick audit of the EH_RETURN_HANDLER_RTX and most are registers
> rather than a memory location . And the ones which were memory locations
> used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #7 from Jiu Fu Guo ---
(In reply to Hans-Peter Nilsson from comment #3)
>
> I'm "guessing" that the problem with the patch, is that anything any port
> stores through a pointer based on virtual_incoming_args_rtx before
> returning,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761
--- Comment #5 from Desmond Gold ---
when I mentioned being "inspired by," I was referring to drawing guidance from
existing reference implementations like libc++, STL, and Kokkos for the
implementation in libstdc++. Specifically, for how they
/* sprintf()関数 */
#include
int main(void)
{
char buffer[80];
double x = 1234.5, y = 678.9, z = -753.1, a = x * y + z;
int output_len = sprintf(buffer, "For the input values %f, %f, and %f,"
"\nthe result was %f.\n", x , y, z, a);
puts(buffer);
/* if (output_len >= 80)
{
fprintf(stderr, "Output
#include
int main(void)
{
char buffer[80];
double x = 1234.5, y = 678.9, z = -753.1, a = x * y + z;
int output_len = sprintf(buffer, "For the input values %f, %f, and %f,"
"\nthe result was %f.\n", x , y, z, a);
puts(buffer);
#include
int main(void)
{
char buffer[80];
double x = 1234.5, y = 678.9, z = -753.1, a = x * y + z;
int output_len = sprintf(buffer, "For the input values %f, %f, and %f,"
"\nthe result was %f.\n", x , y, z, a);
puts(buffer);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112581
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
--- Comment #4 from Andrew Pinski ---
When you say C structures here you mean the standard layout types (or the C++98
older definition of PODs)? Or do you mean structure types which has no member
functions/constructors at all?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #6 from Andrew Pinski ---
So I did a quick audit of the EH_RETURN_HANDLER_RTX and most are registers
rather than a memory location . And the ones which were memory locations used
either frame or stack pointer directly which seemed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #5 from Hans-Peter Nilsson ---
(In reply to Andrew Pinski from comment #4)
> Hmm, see PR 32398 and PR 32769. PR 32769 is interesting because it was
> caused by the merge of the df branch where the store was being removed just
> like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
--- Comment #3 from Andrew Pinski ---
Is this a reasonable extension maybe. But this is an extension to the language
after all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
--- Comment #2 from Alexey Dobriyan ---
this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99081
but I don't care about the warning, only about error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
--- Comment #1 from Alexey Dobriyan ---
This is getting lengthy:
Please allow C99 semantics for "simple enough" stuff (read: C structs):
* allow reordering
* allow duplicating (possibly with warning),
* allow holes in the middle of arrays (1-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
Bug ID: 113124
Summary: g++ should relax designated initialiser rules for
trivial classes (read: C structures) and C arrays.
Product: gcc
Version: 13.2.1
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761
--- Comment #4 from Jonathan Wakely ---
What does "inspired by" mean? We need to be careful of authorship, copyright
ownership, and licensing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112883
--- Comment #2 from John David Anglin ---
The excess errors differ.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761
Desmond Gold changed:
What|Removed |Added
CC||cooky.ykooc922 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113123
Bug ID: 113123
Summary: ASAN_OPTIONS=log_to_syslog=true leads to deadlock
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113122
Bug ID: 113122
Summary: Assembler messages: Error: operand type mismatch for
`movabs' / bad expression / invalid use of register
with -fprofile -mcmodel=large -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113105
--- Comment #5 from XChy ---
(In reply to Jakub Jelinek from comment #4)
> So, e.g. on x86_64,
> unsigned int
> f1 (unsigned val)
> {
> return val / 10 * 16 + val % 10;
> }
>
> unsigned int
> f2 (unsigned val)
> {
> return val / 10 * 6 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113071
XChy changed:
What|Removed |Added
CC||xxs_chy at outlook dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113119
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #4 from andysem at mail dot ru ---
> It's mostly OK to mix code with -frtti and -fno-rtti, but sometimes it bites
> you.
Note that in this case, it is the standard library that is built with -frtti
and the rest of the code is built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #3 from andysem at mail dot ru ---
I think, a failing dynamic_cast would not be useful as this would make
std::use_facet unusable with -fno-rtti.
Re. ODR violation in the latest code, while it is true that the
dynamic/static_cast is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113121
Bug ID: 113121
Summary: failed to load pendings for
‘std::__format::__do_vformat_to’
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
YunQiang Su changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
--- Comment #8 from GCC Commits ---
The releases/gcc-13 branch has been updated by YunQiang Su :
https://gcc.gnu.org/g:63df799074351e9b3ab90f5b3031ba2691385af8
commit r13-8175-g63df799074351e9b3ab90f5b3031ba2691385af8
Author: YunQiang Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
--- Comment #7 from GCC Commits ---
The master branch has been updated by YunQiang Su :
https://gcc.gnu.org/g:384dbb0b4e751e6eb7ba3f9993a6cce466743926
commit r14-6811-g384dbb0b4e751e6eb7ba3f9993a6cce466743926
Author: YunQiang Su
Date: Tue
35 matches
Mail list logo
