https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109327
Bug ID: 109327
Summary: ICE on valid code at -O1 and above with
"-fno-tree-ccp": Segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
On 2/27/23 10:29, Jonathan Yong wrote:
Attached patch OK?
Excess errors on x86_64-w64-mingw32:
/home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:50:3: warning: array subscript 4611686018427387902 is above array bounds of 'struct S16[]' [-Warray-bounds=]
From: Juzhe-Zhong
Co-authored-by: kito-cheng
Co-authored-by: kito-cheng
This path fix ICE of ternary intrinsic:
bug.C:144:2: error: unable to find a register to spill
144 | }
| ^
bug.C:144:2: error: this is the insn:
(insn 462 972 919 24 (set (reg/v:VNx8DI 546 [orig:192 var_10 ]
From: Juzhe-Zhong
bug.C:144:2: error: unrecognizable insn:
144 | }
| ^
(insn 684 683 685 26 (set (reg:SI 513)
(and:SI (const_int 4 [0x4])
(const_int 1 [0x1]))) "bug.C":115:47 -1
(nil))
andi a4,a4,1 ===> sgtu a4,a4,zero
vsetlvi tuvsetvli tu
vlse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109326
--- Comment #4 from Andrew Pinski ---
(In reply to Steve Thompson from comment #3)
> However I don't understand why olock_reset_op() is so large. It's
> a trivial initializer for a descriptor with an array of olock_op_element
> structures
This patch caches the current expression's location information in the
constexpr_global_ctx struct, which allows subexpressions that have lost
location information to still provide accurate diagnostics. Also
rewrites a number of 'error' calls as 'error_at' to provide more
specific location
This adds rudimentary lifetime tracking in C++ constexpr contexts,
allowing the compiler to report errors with using values after their
backing has gone out of scope. We don't yet handle other ways of ending
lifetimes (e.g. explicit destructor calls).
PR c++/96630
PR c++/98675
This is an update of the patch series at
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614759.html
The main change is modifying the first patch to store the "expired" flag
in the C++-specific lang_decl_base struct instead of tree_decl_common.
The second and third patches to improve
Currently, when typeck discovers that a return statement will refer to a
local variable it rewrites to return a null pointer. This causes the
error messages for using the return value in a constant expression to be
unhelpful, especially for reference return values.
This patch removes this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109326
--- Comment #3 from Steve Thompson ---
(In reply to Andrew Pinski from comment #1)
> init_olock_op_element_struct asm output looks fine to me:
>
> movzwl .LC0(%rip), %eax
> movq$0, (%rdi)
> movq$0, 8(%rdi)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109321
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109320
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109321
--- Comment #2 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:91293ffb6af18705ab7857dc47656bdd74a9ce31
commit r13-6922-g91293ffb6af18705ab7857dc47656bdd74a9ce31
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109320
--- Comment #2 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:91293ffb6af18705ab7857dc47656bdd74a9ce31
commit r13-6922-g91293ffb6af18705ab7857dc47656bdd74a9ce31
Author: Jason Merrill
Date:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The two hunks fix missing handling demonstrated by the two testcases: first,
if we omit one alias template parm but include another, we need to rewrite
the deduced template args to reflect the new position of the included parm.
Second, if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109274
Sam James changed:
What|Removed |Added
CC||sam at gentoo dot org
--- Comment #15 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109325
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109326
--- Comment #2 from Andrew Pinski ---
Note if you are disassemblying the object file with objdump -d, you might want
to add the -r option to enable dumping of the relocations that are produced
too. In the init_olock_op_struct case you miss the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109326
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109326
Bug ID: 109326
Summary: Bad assembler code generation for valid C on 886-64
Product: gcc
Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
Severity: normal
Priority:
This patch to the Go frontend marks a Call_expression multiple results
struct as a result struct. In https://go.dev/cl/343873 we stopped
padding zero-sized trailing fields in functions that return multiple
results where the last result is zero-sized. This CL makes the
corresponding change on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109256
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |MOVED
--- Comment #4 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109325
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109325
--- Comment #1 from Sam James ---
Created attachment 54781
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54781=edit
warpers.cpp.ii.xz
Originally reported by Adrien Dessemond at
https://bugs.gentoo.org/903505.
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109325
Bug ID: 109325
Summary: ICE in range_def_chain::in_chain_ when building opencv
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109324
Bug ID: 109324
Summary: Genrecog reports "source missing a mode?" for H8
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108118
--- Comment #7 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:629ed996f32cb03dd712789eede1f7f2036e497b
commit r12-9351-g629ed996f32cb03dd712789eede1f7f2036e497b
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108554
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108554
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:2fdfa3768b25c85df39eaf9b850e130e42a4dd6f
commit r12-9345-g2fdfa3768b25c85df39eaf9b850e130e42a4dd6f
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109299
--- Comment #11 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:00ac6fa3f2a54fb9cc17b7b7f51eae3c6bf7a1bd
commit r12-9330-g00ac6fa3f2a54fb9cc17b7b7f51eae3c6bf7a1bd
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109299
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Oooh, thank you for your help!
On Tue, Mar 28, 2023 at 4:25 PM Jonathan Wakely wrote:
>
> On Tue, 28 Mar 2023 at 22:30, Ken Matsui via Libstdc++
> wrote:
> >
> > Hi François,
> >
> > I tried to use `make check-debug`, but my Makefile does not include
> > the target. Could you please tell me how
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108413
--- Comment #10 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:83487e1f0c380859ed2dab2892afa8651d267fb3
commit r12-9327-g83487e1f0c380859ed2dab2892afa8651d267fb3
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109320
Jason Merrill changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109320
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
On Tue, 28 Mar 2023 at 22:30, Ken Matsui via Libstdc++
wrote:
>
> Hi François,
>
> I tried to use `make check-debug`, but my Makefile does not include
> the target. Could you please tell me how you generated your Makefile?
It's a target in the libstdc++ makefile, so you need to run it from
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387
--- Comment #11 from Jonathan Wakely ---
Fixed on trunk now.
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
For the powerpc64le build with two different long double
representations, we cannot use the ios_base::_M_num_put and
ios_base::_M_num_get pointers, because they might have been initialized
in a translation unit using the other long double type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:ec12639c82e944d37200a744156e183ea19add00
commit r13-6918-gec12639c82e944d37200a744156e183ea19add00
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109161
Nix changed:
What|Removed |Added
CC||nix at esperi dot org.uk
--- Comment #2 from Nix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318
David Binderman changed:
What|Removed |Added
Keywords||needs-bisection,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-03-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323
Bug ID: 109323
Summary: No error when neither of return_value or return_void
is defined
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Hello,
it feels like I have read only a small part of your conversation and so
may be missing quite some context, but...
On Wed, Mar 22 2023, Benjamin Priour via Gcc wrote:
> Hi Jason,
>
> Sorry for the delayed answer, I was in my exam period!
>
> I've almost finished the patch (PR12341
>
Hi François,
I tried to use `make check-debug`, but my Makefile does not include
the target. Could you please tell me how you generated your Makefile?
FYI, I did this command: `../configure --enable-languages=c++
--disable-error --disable-bootstrap`.
Sincerely,
Ken Matsui
On Mon, Mar 27, 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
Bug ID: 109322
Summary: -fc-prototypes does not correctly translate
INTEGER(KIND=C_SIZE_T), and other sizes
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #37 from Andrew Macleod ---
Created attachment 54780
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54780=edit
in progress patch
Well call me a liar.
It took me a while to understand why, but if we leave it to single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109321
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
Hi!
On 2023-02-24T07:16:51+0200, Rimvydas Jasinskas via Fortran
wrote:
> From 5b83226c714b17780334b5bad9b17c2266af8232 Mon Sep 17 00:00:00 2001
> From: Rimvydas Jasinskas
> Date: Fri, 24 Feb 2023 04:41:00 +
> Subject: Fortran: Add support for WEAK attribute for variables
>
> Add the rest
Hi All,
I have made a start on ASSOCIATE issues. Some of the low(-ish) hanging
fruit are already fixed but I have yet to check that they a really fixed
and to close them:
pr102106, pr102111, pr104430, pr106048, pr85510, pr87460, pr92960 & pr93338
The attached patch picks up those PRs involving
Hi all,
I’m Adi Prasad, a 2nd year Computing student at Imperial College London,
interested in doing the Separate Host Process Offloading GSoC project this
summer.
First off, I’m aware I’m getting in touch very late; I have been busy up until
now with a university project deadline. I am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109288
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
This avoids a bogus warning about overflowing a buffer, because GCC
can't tell that we don't copy into the buffer unless it fits. By adding
a __builtin_unreachable() hint we inform the compiler about the
invariant that the buffer is only used
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
The std::char_traits member functions require that [p,p+n) is a valid
range, which is true for p==nullptr iff n==0. But we must not call
memcpy, memset etc, in that case, as they require non-null pointers even
when n==0.
This std::char_traits
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
Import the new 2023a tzdata.zi file and update the expiry dates of the
hardcoded lists of leapseconds to 2023-12-28.
With the new data, Africa/Egypt no longer has a single unbroken sys_info
from 2014-09-25 to chrono::year::max(). Only check up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109299
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:bf78b43873b0b7e8f9a430df38749b8b61f9c9b8
commit r13-6915-gbf78b43873b0b7e8f9a430df38749b8b61f9c9b8
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109288
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:cf19ef9eca82b01dd0a3a0a8e4c8bcec236eb2d9
commit r13-6914-gcf19ef9eca82b01dd0a3a0a8e4c8bcec236eb2d9
Author: Jonathan Wakely
In looking over the recently committed support for zstd decompression
in libbacktrace, I found a few minor cases that needed fixing.
Bootstrapped and tested on x86_64-pc-linux-gnu. Committed to
mainline.
Ian
* elf.c (elf_zstd_read_fse): Call elf_fetch_bits after reading
bits, not before. Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
Alisdair Meredith changed:
What|Removed |Added
CC||alisdairm at me dot com
--- Comment
Hello,
Myself Deepanshu Joshi, pursuing Bachelors in Computer Science. I would
like to display my interest towards the Rust Front End project. Currently I
am working on my own compiler and hence contributing to this project will
help me expand my knowledge.
I would request you to brief me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318
--- Comment #3 from David Binderman ---
Seems broken with gcc-12-20211003.
Git hashes seem to be g:c3d3bb0f03dbd025 and g:d91056851c5c60f2
On Tue, 2023-03-28 at 08:08 -0400, Eric Feng wrote:
> My apologies. Forgot to CC the mailing list in my previous e-mail.
> Original reply below:
>
> ___
>
>
> Hi David,
>
> Thank you for your feedback!
>
> >
[...snip...]
> >
>
> > > Error-handling checking: Various checks for common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109321
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109320
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2023-03-28
CC|
On 26.03.23 08:52, Paul Richard Thomas via Fortran wrote:
If you will excuse the British cultural reference, that's a Norwegian Blue
alright! Good spot.
Still pining for the fjords, I gather?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109319
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109321
Bug ID: 109321
Summary: [13 Regression] ICE in iterative_hash_template_arg, at
cp/pt.cc:1727
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109320
Bug ID: 109320
Summary: [13 Regression] ICE in coerce_template_parameter_pack,
at cp/pt.cc:8795
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109319
Bug ID: 109319
Summary: [13 Regression] ICE in build_min_non_dep_op_overload,
at cp/tree.cc:3793
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107002
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
PR c/107002 reports an assertion failure from deep inside the
diagnostic_shows_locus when attempting to print fix-it hints relating
to -Wxor-used-as-pow. The case involves macro expansions with
-ftrack-macro-expansion=0.
It doesn't seem to make much sense to emit this warning for macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318
--- Comment #2 from David Binderman ---
Program seems fine with gcc-11-20210404, but goes wrong with gcc-12-20220403.
$ ~/gcc/results.20210404/bin/gcc -w -O1 -fipa-cp bug903.c
$ ./a.out
checksum = FC4F321
$ ~/gcc/results.20220403/bin/gcc -w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107002
--- Comment #5 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:22c3a6c3c118283dfef1b9928dd21110098679b7
commit r13-6912-g22c3a6c3c118283dfef1b9928dd21110098679b7
Author: David Malcolm
Date:
LoongArch backend used to save all GARs for a function with variable
arguments. But sometimes a function only accepts variable arguments for
a purpose like C++ function overloading. For example, POSIX defines
open() as:
int open(const char *path, int oflag, ...);
But only two forms are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109313
--- Comment #1 from Andrew Pinski ---
When ccp3 changes (correctly):
[local count: 958878296]:
.ASAN_MARK (POISON, , 4);
[/app/example.cpp:6:24] b.1_2 = b;
[/app/example.cpp:6:24] _3 = b.1_2 + 1;
[/app/example.cpp:6:24] b = _3;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318
--- Comment #1 from David Binderman ---
In gdb:
gdb) r 1
Starting program: /home/dcb36/csmith/a.out 1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Program received signal SIGSEGV,
Now that we resolve non-dependent variable template-ids ahead of time,
cp_finish_decl needs to handle a new invalid situation: we can end up
trying to instantiate a variable template with deduced return type
before we fully parsed (and attached) its initializer.
Bootstrapped and regtested on
Dear Jan Hubicka,
My name is Hathik , and I'm a student . I'm writing to express my interest
in the GCC LTO , and to ask for your guidance as I prepare my application.
I have some experience in C/C++ programming and a strong interest in
low-level systems programming, and I believe that this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
Xi Ruoyao changed:
What|Removed |Added
CC||chenglulu at loongson dot cn,
Z*inx is conflict with float extensions, add incompatible check when
z*inx and f extension both enabled.
Since all float extension imply f extension and all z*inx extension
imply zfinx extension, so we just need to check f with zfinx extension
as the base case.
Co-Authored by: Kito Cheng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318
Bug ID: 109318
Summary: csmith: -fipa-cp seems to cause trouble
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Hello All:
This patch makes REE pass as a default pass in rs6000 target. And
add necessary subroutines to eliminate extensions across basic blocks.
Bootstrapped and regtested on powerpc64-linu-gnu.
Thanks & Regards
Ajit
rtl-optimization: ppc backend generates unnecessary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387
--- Comment #9 from Jonathan Wakely ---
This fixes the testcase, but I'll check for other problems using the cached
facets:
--- a/libstdc++-v3/include/bits/ostream.tcc
+++ b/libstdc++-v3/include/bits/ostream.tcc
@@ -69,7 +69,12 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #36 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #35)
> (In reply to Andrew Macleod from comment #34)
> > I will poke at whether its possible to cheaply handle a second (or third)
> > level for single dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
--- Comment #9 from Jonathan Wakely ---
(In reply to Charles-Henri Gros from comment #7)
> For context, we're trying to detect cases where using "auto" unintentionally
> creates a copy (it's regrettably common).
> Here the copy is necessary to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
--- Comment #8 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> Removing it would make the code less efficient and more complex.
In fact, I don't even see how it would be possible, except by making *another*
copy, e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107002
--- Comment #4 from David Malcolm ---
Created attachment 54778
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54778=edit
Untested patch
(In reply to Jakub Jelinek from comment #3)
> David, any progress here?
I've currently testing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109317
Bug ID: 109317
Summary: -Os generates bigger code than -O2 on 32-bit ARM
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
--- Comment #7 from Charles-Henri Gros ---
For context, we're trying to detect cases where using "auto" unintentionally
creates a copy (it's regrettably common).
Here the copy is necessary to get a non-const value; that's definitely
something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
--- Comment #6 from Jonathan Wakely ---
For your reproducer, the allocator is std::allocator which is an empty
class and copying is a no-op. There is no efficiency concern whatsoever.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
--- Comment #4 from Marc-André Laverdière ---
The comment is "If this allocation throws there are no effects:" and I didn't
understand the implications. Thanks for you spelled it out the logic behind it.
May I encourage you to update the
Hi, Joseph and Jakub,
this is the 6th version of the patch.
compared to the 5th version, the major changes are:
1. Update the documentation Per Joseph's comments;
2. Change the name of the new warning option per Jakub's suggestions.
3. Update testing case per the above change.
these changes
the C front-end has been approved by Joseph.
Jacub, could you please eview the middle end part of the changes of this patch?
The major change is in tree-object-size.cc (addr_object_size).
(To use the new TYPE_INCLUDE_FLEXARRAY info).
This patch is to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #35 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #34)
> I will poke at whether its possible to cheaply handle a second (or third)
> level for single dependency defs.
Will those include also binary ops which have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #34 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #33)
> (In reply to Andrew Macleod from comment #32)
> > We could in theory expand it to look at 2 levels if its a single operand...
>
> Yeah, that would help here
Ignore this one - jakub just committed a fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109309
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Tested x86_64-linux. OK for trunk?
-- >8 --
gcc/cp/ChangeLog:
PR c++/109309
* contracts.cc (check_postcondition_result): Use complete
strings for diagnostics, so they can be translated.
---
gcc/cp/contracts.cc | 8
1 file changed, 4 insertions(+), 4
1 - 100 of 262 matches
Mail list logo
