https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #8 from Andrew Pinski ---
(In reply to Janez Zemva from comment #7)
> The c++17 type deduction rules are also going on. This makes me wonder how
> std::make_tuple() circumvents the problem.
Easy, it does not use the C++17 deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #7 from Janez Zemva ---
The c++17 type deduction rules are also going on. This makes me wonder how
std::make_tuple() circumvents the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Andrew Pinski from comment #3)
> > Yes it is called the copy (or move) constructor :).
>
> That is:
> auto t = std::tuple(std::tuple(1,2));
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Yes it is called the copy (or move) constructor :).
That is:
auto t = std::tuple(std::tuple(1,2));
std::cout << type_name() << std::endl;
Will produce the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #4 from Janez Zemva ---
Ok, thank you :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #2 from Janez Zemva ---
I have no idea, but it seems wrong me. Is there an explanation for the lvalue
references? I expected rvalue references, but that's unrelated to the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #1 from Andrew Pinski ---
Hmm, even clang with libc++ produces the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
Bug ID: 103448
Summary: unexpected tuple collapse
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41731
Eric Gallager changed:
What|Removed |Added
Last reconfirmed||2021-11-27
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103447
--- Comment #2 from Greg Morse ---
Thanks for the v. quick reply. I feel like an idiot.G. M.
On Friday, November 26, 2021, 04:13:45 p.m. PST, pinskia at gcc dot gnu.org
wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103447
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103447
Bug ID: 103447
Summary: left shift operator gives wrong result for shift of 48
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Hi,
I forgot that IPA passes before ipa-inline must not return
TODO_cleanup_cfg from their transformation function because ordinary
CFG cleanup does not remove call graph edges associated with removed
call statements but must use
delete_unreachable_blocks_update_callgraph instead. This patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
--- Comment #8 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:9e2e47391b316493b52fbb47b4b992b0863795dd
commit r12-5554-g9e2e47391b316493b52fbb47b4b992b0863795dd
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #5 from Zloten ---
I use the latest MinGW, target-host are Windows, x86-64.
On Fri, 26 Nov 2021 at 12:43, Jonathan Wakely wrote:
>
> On Fri, 26 Nov 2021 at 12:39, Jakub Jelinek wrote:
> >
> > On Fri, Nov 26, 2021 at 12:29:25PM +, Jonathan Wakely via Gcc-patches
> > wrote:
> > > + // Internal version of std::is_constant_evaluated() for C++11.
> > > + // This can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #4 from Andrew Pinski ---
What target and what is the host?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #3 from Zloten ---
No. Just - O2.
Tested x86_64-linux, pushed to trunk.
This test was written to verify that the LWG 3265 changes work. But
those changes were superseded by LWG 3435, and the test is now incorrect
according to the current draft. The assignment operator is now
constrained to also require convertibility, which
Tested x86_64-linux, pushed to trunk.
When implementing constexpr std::vector I added a check for constant
evaluation in vector::_S_use_relocate(), so that we would not try to relocate
trivial objects by using memmove. But I put it in the constexpr function
that decides whether to relocate or
Tested x86_64-linux, pushed to trunk.
The FE bug was fixed, so we don't need this workaround now.
libstdc++-v3/ChangeLog:
PR libstdc++/96592
* include/std/tuple (tuple::is_constructible): Remove.
---
libstdc++-v3/include/std/tuple | 4
1 file changed, 4 deletions(-)
diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:76c6be48b7841524974754f8ea7533b82c7de77e
commit r12-5551-g76c6be48b7841524974754f8ea7533b82c7de77e
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103432
--- Comment #6 from Sergei Trofimovich ---
(In reply to Jan Hubicka from comment #4)
> Fixed on trunk by g:a70faf6e4df7481c2c9a08a06657c20beb3043de (sorry for
> cut wrong PR number).
Tested on full libjxl-0.5 testsuite. All works now. Thank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #2 from Andrew Pinski ---
Is there a full testcase including what options you used?
Did you use "-finput-charset=" and -fexec-charset= options?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #1 from Zloten ---
56481 = 0xDCA1
Snapshot gcc-10-20211126 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20211126/
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=103446
Bug ID: 103446
Summary: Invalid wide multibyte character constant
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84693
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103439
--- Comment #5 from Andrew Pinski ---
(In reply to Richard Biener from comment #4)
> so quite hard if not impossible to "fix" in genemit
The most complex one I saw in action was mod3 in aarch64.md:
(define_expand "mod3"
[(match_operand:GPI 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853
--- Comment #8 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #6)
> Then no change matching "g++.dg/modules/xtreme-" up to and including
> a29174904bb1 (r12-5240), which is the last run at this writing.
Update:
At
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
--- Comment #11 from Steve Kargl ---
On Fri, Nov 26, 2021 at 08:13:05PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
>
> --- Comment #10 from anlauf at gcc dot gnu.org ---
> (In reply to Steve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103411
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:4d540c7a4a7fb87b04d06e1ee7f9b004116279a4
commit r12-5550-g4d540c7a4a7fb87b04d06e1ee7f9b004116279a4
Author: Harald Anlauf
Date:
Le 26/11/2021 à 21:07, Harald Anlauf a écrit :
That should hopefully be the final version...
Yes it is OK. Thanks for your patience.
Mikael
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103445
--- Comment #4 from Jonathan Wakely ---
Sorry, I don't understand anything above. I don't care whether you're using
mingw or mingw-w64, what I asked is how old it is. Libstdc++ expects a recent
version, and I'm not surprised if it doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103438
--- Comment #8 from Nils Smeds ---
(In reply to Nils Smeds from comment #7)
> (In reply to Martin Liška from comment #6)
> > Lemme take a look.
>
> Great, thanks.
prefetch-loop-arrays appears to be activated on arm,s390 and i386 at level -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102787
--- Comment #8 from anlauf at gcc dot gnu.org ---
Simpler and better patch which handles array sections as well as vector
subscripts:
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 6552eaf3b0c..f870c225195 100644
---
On Linux/x86_64,
b41be002eda047093bbf4757cb65ffb4d525cc35 is the first bad commit
commit b41be002eda047093bbf4757cb65ffb4d525cc35
Author: Roger Sayle
Date: Fri Nov 26 17:22:10 2021 +
ivopts: Improve code generated for very simple loops.
caused
FAIL: gcc.dg/tree-ssa/ivopts-8.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103445
--- Comment #3 from cqwrteur ---
(In reply to cqwrteur from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > How old is that? We generally only support building with recent versions
> > that are still supported by MinGW.
>
> dev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59716
Andrew Pinski changed:
What|Removed |Added
Summary|variadic template multiple |[10/11 Regression] variadic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103445
--- Comment #2 from cqwrteur ---
(In reply to Jonathan Wakely from comment #1)
> How old is that? We generally only support building with recent versions
> that are still supported by MinGW.
dev C++'s mingw.
that is mingw-w64. not mingw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103445
--- Comment #1 from Jonathan Wakely ---
How old is that? We generally only support building with recent versions that
are still supported by mingw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392
--- Comment #9 from CVS Commits ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:dd1871c823e2ec9a500ac5ad3c87a117b934fa3b
commit r9-9846-gdd1871c823e2ec9a500ac5ad3c87a117b934fa3b
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:376b2c781d11f55644e92dfea91c3f214f20f4ac
commit r10-10311-g376b2c781d11f55644e92dfea91c3f214f20f4ac
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #9)
> "does not work for me" isn't too descriptive.
Well, you fixed a related issue, but not the problem in comment#0.
Try your patch on:
module m
Hi Mikael,
> Gesendet: Freitag, 26. November 2021 um 15:45 Uhr
> Von: "Mikael Morin"
> An: "Harald Anlauf" , fort...@gcc.gnu.org
> Cc: gcc-patches@gcc.gnu.org
> Betreff: Re: [PATCH, v2] PR fortran/103411 - ICE in
> gfc_conv_array_initializer, at fortran/trans-array.c:6377
>
> Le 25/11/2021 à
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103445
Bug ID: 103445
Summary: build failure for old versions of mingw32 (not
mingw-w64)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70435
Klaus Rudolph changed:
What|Removed |Added
CC||lts-rudolph at gmx dot de
--- Comment
Hi!
On Tue, Nov 23, 2021 at 12:40:45PM -0600, Bill Schmidt wrote:
> When a built-in function required by an overloaded function name is not
> currently enabled, the diagnostic message is not as clear as it should be.
> Saying that one built-in "requires" another is somewhat misleading. It
On Fri, 26 Nov 2021, Gerald Pfeifer wrote:
> I have received a report of GCC builds now failing on FreeBSD/i386:
Ah, and here are the logs (IPv6 required, unfortunately):
Log URL:
http://beefy5.nyi.freebsd.org/data/122i386-default/9e1bda400030/logs/gcc12-devel-12.0.0.s20211121.log
Build URL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59716
Klaus Rudolph changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
Recent improvements to null address warnings notice that for
targets that do not support HAVE_ELF_STYLE_WEAKREF the dummy stub
implementation of __cxa_get_globals() means that the address can
never be null.
Fixed by removing the test for such targets.
tested on i686, x86_64, powerpc-darwin and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
--- Comment #9 from Steve Kargl ---
On Thu, Nov 25, 2021 at 10:10:32PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
>
> --- Comment #6 from anlauf at gcc dot gnu.org ---
> Unfortunately the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103444
--- Comment #2 from kargl at gcc dot gnu.org ---
% gfcx -o z -fopenmp -g async_io_1.f90
% gdb ./z
(gdb) run
Starting program: /home/kargl/tmp/z
[New LWP 118209 of process 77440]
Thread 2 received signal SIGBUS, Bus error.
[Switching to LWP
This is the body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103444
--- Comment #1 from kargl at gcc dot gnu.org ---
=== libgomp Summary ===
# of expected passes7743
# of unexpected failures31
# of expected failures 72
# of unsupported tests 227
Each of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103444
Bug ID: 103444
Summary: Fortran async IO is broken on FreeBSD
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
--- Comment #7 from Andrew Pinski ---
*** Bug 103442 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103442
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159
--- Comment #9 from Martin Uecker ---
Yes the clang behavior is useful.
If we get the optimal code for types with sufficient alignment, then I do not
think a separate set of functions would be required. A programmer simply can
use the
On 11/26/21 23:34, Jakub Jelinek wrote:
On Fri, Nov 26, 2021 at 11:29:41PM +0530, Siddhesh Poyarekar wrote:
The trees in object_sizes are each a TREE_VEC with the first element
being the bytes from the pointer to the end of the object and the
second, the size of the whole object. This allows
Am Freitag, den 26.11.2021, 15:48 + schrieb Jonathan Wakely:
> On Fri, 26 Nov 2021 at 15:41, Martin Uecker wrote:
> > Am Freitag, den 26.11.2021, 09:24 + schrieb Jonathan Wakely:
> > > On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc
> > > wrote:
> > > > Am Freitag, den 26.11.2021,
On Fri, Nov 26, 2021 at 11:29:41PM +0530, Siddhesh Poyarekar wrote:
> > > The trees in object_sizes are each a TREE_VEC with the first element
> > > being the bytes from the pointer to the end of the object and the
> > > second, the size of the whole object. This allows analysis of negative
> > >
On Fri, 19 Nov 2021, David Malcolm via Gcc-patches wrote:
> On Mon, 2021-09-27 at 20:53 -0400, Antoni Boucher wrote:
>> I fixed an issue (it would show an error message when
>> gcc_jit_type_dyncast_function_ptr_type was called on a type different
>> than a function pointer type).
> The updated
On Fri, Nov 26, 2021 at 11:23:31PM +0530, Siddhesh Poyarekar wrote:
> On 11/26/21 22:16, Jakub Jelinek wrote:
> > On Fri, Nov 26, 2021 at 10:58:44AM +0530, Siddhesh Poyarekar wrote:
> > > A simple cleanup to allow inserting dynamic size code more easily.
> > >
> > > gcc/ChangeLog:
> > >
> > >
On 11/26/21 22:26, Jakub Jelinek wrote:
On Fri, Nov 26, 2021 at 10:58:46AM +0530, Siddhesh Poyarekar wrote:
Transform tree-object-size to operate on tree objects instead of host
wide integers. This makes it easier to extend to dynamic expressions
for object sizes.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45365
Roger Sayle changed:
What|Removed |Added
CC||shaohua.li at inf dot ethz.ch
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Roger Sayle changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
On 11/26/21 22:16, Jakub Jelinek wrote:
On Fri, Nov 26, 2021 at 10:58:44AM +0530, Siddhesh Poyarekar wrote:
A simple cleanup to allow inserting dynamic size code more easily.
gcc/ChangeLog:
* tree-object-size.c: New enum.
(object_sizes, computed, addr_object_size,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|10.3|10.4
Known to work|
Hi!
On Tue, Nov 23, 2021 at 01:14:05PM -0600, Bill Schmidt wrote:
> Paul Clarke pointed out to me that I had wrongly used a compile-time check
> instead of a run-time check in this executable test. This patch fixes
> that. I also fixed a typo in a string that caught my eye.
>
> Tested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #22 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:8d3391d64799d490117ad48432a9ad2cf38b0091
commit r11-9317-g8d3391d64799d490117ad48432a9ad2cf38b0091
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
--- Comment #6 from Martin Jambor ---
Created attachment 51884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51884=edit
Untested fix
I am testing this fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|11.3|10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|10.4|11.3
Status|NEW
On Fri, 26 Nov 2021 at 16:58, Gabriel Ravier wrote:
>
>
> On 11/26/21 16:48, Jonathan Wakely via Gcc wrote:
> > On Fri, 26 Nov 2021 at 15:41, Martin Uecker wrote:
> >> Am Freitag, den 26.11.2021, 09:24 + schrieb Jonathan Wakely:
> >>> On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102431
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101571
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101965
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103020
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
On 11/26/21 16:48, Jonathan Wakely via Gcc wrote:
On Fri, 26 Nov 2021 at 15:41, Martin Uecker wrote:
Am Freitag, den 26.11.2021, 09:24 + schrieb Jonathan Wakely:
On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc wrote:
Am Freitag, den 26.11.2021, 09:29 +0100 schrieb Eric Botcazou:
From: Sören Tempel
The stddef.h header checks/sets various hardcoded toolchain/os specific
macro guards to prevent redefining types such as ptrdiff_t, wchar_t, or
size_t. However, without this patch, the file does not check/set the
typedef macro guards for musl libc. This causes types such as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #18 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to Hongtao.liu from comment #16)
>
> > ix86_expand_vector_set is mainly used by vec_set_optab which exactly takes
> > target as both input and output,
On Fri, Nov 26, 2021 at 10:58:46AM +0530, Siddhesh Poyarekar wrote:
> Transform tree-object-size to operate on tree objects instead of host
> wide integers. This makes it easier to extend to dynamic expressions
> for object sizes.
>
> The compute_builtin_object_size interface also now returns a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #17 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #16)
> ix86_expand_vector_set is mainly used by vec_set_optab which exactly takes
> target as both input and output, it seems we can't create a new target for
> that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102894
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
On Fri, Nov 26, 2021 at 10:58:45AM +0530, Siddhesh Poyarekar wrote:
> Put all accesses to object_sizes behind functions so that we can add
> dynamic capability more easily.
>
> gcc/ChangeLog:
>
> * tree-object-size.c (object_sizes_grow, object_sizes_release,
> object_sizes_unknown_p,
On Fri, Nov 26, 2021 at 10:58:44AM +0530, Siddhesh Poyarekar wrote:
> A simple cleanup to allow inserting dynamic size code more easily.
>
> gcc/ChangeLog:
>
> * tree-object-size.c: New enum.
> (object_sizes, computed, addr_object_size,
> compute_builtin_object_size,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723
--- Comment #5 from cqwrteur ---
(In reply to Eric Gallager from comment #4)
> This is affecting The Battle for Wesnoth:
> https://github.com/wesnoth/wesnoth/issues/6291
C++ std::regex is just terrible and highly likely be deprecated in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101571
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:0d480b8403f2541402adeed82deb7eb028330b87
commit r10-10310-g0d480b8403f2541402adeed82deb7eb028330b87
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101965
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:30033d9bb9d5e5303fadf448999f4f27e2693ed6
commit r10-10309-g30033d9bb9d5e5303fadf448999f4f27e2693ed6
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102894
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:923637b6cb70986e83ae0109ec4bcd26fdfe3624
commit r10-10308-g923637b6cb70986e83ae0109ec4bcd26fdfe3624
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270
--- Comment #9 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:b3f135a50c3dd7fc04252e17d7fbb08ca95aa9a5
commit r10-10307-gb3f135a50c3dd7fc04252e17d7fbb08ca95aa9a5
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
--- Comment #12 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:5c86e63cb0383a38ec3dea24e9b3fe2f6e312057
commit r10-10305-g5c86e63cb0383a38ec3dea24e9b3fe2f6e312057
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101583
--- Comment #11 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:5c86e63cb0383a38ec3dea24e9b3fe2f6e312057
commit r10-10305-g5c86e63cb0383a38ec3dea24e9b3fe2f6e312057
Author: Jonathan
1 - 100 of 241 matches
Mail list logo
