https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94676
Bug ID: 94676
Summary: constexpr destructors run too late for temporaries
created inside __builtin_constant_p
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #9 from Bas Vodde ---
Hi Jonathan,
You are right, I was drawing much too many conclusions there. I should have
waited with that comment until I slept :) Sorry for that. And it has been a
while since I read the proposal, it has been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69101
Dominique d'Humieres changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254
--- Comment #4 from Marek Polacek ---
But this one is accepted by icc/clang++ yet we ICE:
struct A {
A();
A(const A &);
};
struct B : A { };
A foo ();
int
main ()
{
B b{foo()};
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91465
Bug 91465 depends on bug 94592, which changed state.
Bug 94592 Summary: [10 Regression] ICE in non-type template parameter with
constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94592
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94592
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94592
--- Comment #10 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:d419e176d74162af6513be0b3bc1031726543993
commit r10-7836-gd419e176d74162af6513be0b3bc1031726543993
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #49 from Fritz Reese ---
(In reply to ktkachov from comment #48)
> (In reply to CVS Commits from comment #45)
[...]
>
> I think this broke the build for bare-metal (newlib) targets like
> aarch64-none-elf:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254
--- Comment #3 from Marek Polacek ---
This reduced test actually regressed with r241187:
struct A {
A(A &);
};
struct B : A { };
A foo ();
int
main ()
{
B{foo()};
}
$ ./cc1plus -quiet x.C -std=c++17
during RTL pass: expand
x.C: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94382
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|NEW
Summary|[8/9/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43382
--- Comment #8 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:a3a4f6be0c7ac1536c4d1def14217840b04dd488
commit r10-7835-ga3a4f6be0c7ac1536c4d1def14217840b04dd488
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628
--- Comment #13 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:a3a4f6be0c7ac1536c4d1def14217840b04dd488
commit r10-7835-ga3a4f6be0c7ac1536c4d1def14217840b04dd488
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #13 from joseph at codesourcery dot com ---
bpabi-lib.h is the existing mechanism for renaming libgcc2.c functions and
declaring them with __attribute__((pcs("aapcs"))). (But when causing more
such functions to be used, or such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92993
Thomas Koenig changed:
What|Removed |Added
Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91241
--- Comment #8 from Marek Polacek ---
Ping, can we get this fixed in GCC 10?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94674
--- Comment #5 from Jonathan Wakely ---
Your mistake is thinking that the iterators of views are like the iterators
you're used to.
They're not.
They have different properties (e.g. they might not be copyable, they might not
have operator->,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94674
--- Comment #4 from Jonathan Wakely ---
That iterator doesn't have a pointer type, because in the new Ranges world that
type is not useful. It is no longer required for iterators to have operator->
so what does the 'pointer' type even mean?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94647
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94635
--- Comment #4 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:3f5d94c192b81a3868f32f309dadd5571ef51cdf
commit r10-7833-g3f5d94c192b81a3868f32f309dadd5571ef51cdf
Author: Thomas Schwinge
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #30 from Martin Jambor ---
Created attachment 48320
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48320=edit
Todays WIP patch
This is my todays (still very much) WIP patch.
- It marks statements which should not be copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92430
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623
--- Comment #20 from Iain Buclaw ---
(In reply to David Binderman from comment #19)
> (In reply to ibuclaw from comment #17)
> > (In reply to David Binderman from comment #16)
> > >
> > > I am struggling to understand what this output means:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623
--- Comment #19 from David Binderman ---
(In reply to ibuclaw from comment #17)
> (In reply to David Binderman from comment #16)
> >
> > I am struggling to understand what this output means:
> >
> It's picking up the modules from a system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065
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=94623
--- Comment #18 from Iain Buclaw ---
(In reply to ibuclaw from comment #17)
> It's picking up the modules from a system location. These most certainly
> don't belong to the gdc compiler. Which bad package maintainer is
> installing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94674
--- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you for pointing me to this.
I find this highly unexpected. There was made a change to `std::type_traits` in
C++20 that sets default values, but it does not apply to all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90591
Thomas Schwinge changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94505
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94505
--- Comment #2 from CVS Commits ---
The releases/gcc-9 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:83eeda5f004c3b9cbeccd3da1c3fe58b3015e55f
commit r9-8518-g83eeda5f004c3b9cbeccd3da1c3fe58b3015e55f
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
Bug ID: 94675
Summary: [9 regression] -Warray-bounds false positive with -O2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94590
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94674
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92993
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> The testcase in comment#0 compiles for me with today's master.
Read: does not ICE; just gives an appropriate error message:
z1.f90:8:6:
8 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92993
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=94505
--- Comment #1 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:5bdd4c5d3fc9c143e8edea3b10828e4b75d7a385
commit r10-7830-g5bdd4c5d3fc9c143e8edea3b10828e4b75d7a385
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94674
--- Comment #1 from Jonathan Wakely ---
This is a known defect in the C++20 draft:
https://cplusplus.github.io/LWG/issue3394
--- Comment #17 from ibuclaw at gcc dot gnu.org ---
(In reply to David Binderman from comment #16)
>
> I am struggling to understand what this output means:
>
> binary
> /home/dcb/gcc/results.20200420.d5/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/d21
> version v2.076.1
> pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
Thomas Schwinge changed:
What|Removed |Added
CC||frederik at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94255
--- Comment #6 from Marek Polacek ---
Patch approved for GCC 11:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544081.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628
--- Comment #12 from Martin Liška ---
> How many times do you have to be told to test your patches? Besides,
> Patrick is already working on this PR.
As Marek said, it's really unpleasant to send untested patches and so come up
with noise in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628
--- Comment #11 from Marek Polacek ---
(In reply to Nicholas Krause from comment #9)
> Created attachment 48318 [details]
> Possible Fix
No, it's not a fix, it just replaces an ICE with another ICE, as Martin already
pointed out:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628
--- Comment #10 from Nicholas Krause ---
(In reply to Martin Liška from comment #8)
> (In reply to Nicholas Krause from comment #7)
> > After adding this it seems to work for me, Patrick:
> >case TYPE_ARGUMENT_PACK:
> > if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628
--- Comment #9 from Nicholas Krause ---
Created attachment 48318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48318=edit
Possible Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669
--- Comment #3 from David Binderman ---
(In reply to Jan Kratochvil from comment #2)
> These fixes are very simple, maybe you can check it in as obvious?
Sorry no, I have no checkin permission.
> BTW the file was written by Alexandre Oliva, I
/home/dcb/gcc/results.20200420.d5/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/d21
version v2.076.1
predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions GNU_StackGrowsDown
GNU_InlineAsm D_LP64 assert D_ModuleInfo D_Exceptions D_TypeInfo all X86_64
D_HardFloat Posix linux CRuntime_Gl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669
Jan Kratochvil changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
--- Comment #11 from Jakub Jelinek ---
Created attachment 48317
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48317=edit
gcc10-pr94383.patch
Testsuite coverage. This passes make -j32 -k check-c++-all
RUNTESTFLAGS=struct-layout-1.exp
on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666
Andreas Krebbel changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85046
--- Comment #8 from Nathan Sidwell ---
the reduced testcases no longer crash the compiler. The first emits a correct
error, the second succeeds.
The original testcase still crashes the compiler, after emitting a slew of
errors about ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94622
--- Comment #2 from acsawdey at gcc dot gnu.org ---
Solution is going to be to always use plq if prefixed, which makes sense anyway
for little endian because it avoids the ugly doubleword swap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94674
Bug ID: 94674
Summary: std::ranges::basic_istream_view::iterator is missing
std::iterator_traits entries
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94673
--- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
After playing with this a bit more, I found out that clang actually behaves
differently:
```c++
#include
#include
template
concept same_as = std::is_same_v;
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623
--- Comment #15 from Iain Buclaw ---
Created attachment 48316
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48316=edit
adjust hardcoded index of Error.bypassException
Can you apply this and see if it goes away?
If this fixes it, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #8 from CVS Commits ---
The master branch has been updated by Andreas Krebbel :
https://gcc.gnu.org/g:2930bb321794c241d8df5591a5bf447bf89c6e82
commit r10-7827-g2930bb321794c241d8df5591a5bf447bf89c6e82
Author: Andreas Krebbel
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94647
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623
--- Comment #14 from Iain Buclaw ---
(In reply to David Binderman from comment #13)
> (In reply to Iain Buclaw from comment #12)
> > (In reply to David Binderman from comment #11)
> > > Checking flag "extra" is the one.
> >
> > Without knowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94673
Bug ID: 94673
Summary: [concepts] What is the return type of local parameters
of requires expressions?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94575
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94575
--- Comment #2 from Joel Yliluoma ---
Sorry, the error Marek Polacek mentions is due to a copypaste mistake on my
part. The correct code that demonstrates the problem is here. The difference is
the && instead of &.
#include
template
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655
--- Comment #5 from Martin Sebor ---
We want stores by user code to be diagnosed based on strict language rules
(e.g., accessing a member via a reference to another member). To do that we
either have to teach the middle end to avoid taking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623
--- Comment #13 from David Binderman ---
(In reply to Iain Buclaw from comment #12)
> (In reply to David Binderman from comment #11)
> > Checking flag "extra" is the one.
>
> Without knowing too much about what that checking flag does. That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94575
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94560
--- Comment #2 from Marek Polacek ---
This ICE is the same as the second test in bug 93085.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94650
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
--- Comment #5 from Thomas Koenig ---
So, the problem seems to be that sym->attr.subref_array_pointer is
not set on the original test case. It should be set by
p => get(r(:)) (or by an equivalent call get2(r)) because
we don't know what the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623
--- Comment #12 from Iain Buclaw ---
(In reply to David Binderman from comment #11)
> (In reply to David Binderman from comment #10)
> > (In reply to David Binderman from comment #6)
> > > I'll reduce the checking flags down to "no" and see what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94549
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655
--- Comment #4 from Jakub Jelinek ---
I don't see how it makes a difference between whether it is a store created by
the vectorizer or some original user store.
What matters is what ADDR_EXPR picks up SCCVN for the base, and it will pick up
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655
--- Comment #3 from Martin Sebor ---
Using the base object in the MEM_REF instead of the member when accessing
another member should certainly fix it.
Another option might be to somehow mark up these synthesized stores (e.g., by
setting some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672
--- Comment #3 from Jakub Jelinek ---
Note, just making (some or all) optional PARM_DECLs predetermined shared (or
firstprivate) by the langhook isn't correct, because
subroutine foo (array)
real, optional :: array(:)
!$omp parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672
--- Comment #2 from Jakub Jelinek ---
>From quick look, seems the Fortran FE for the dummy optional argument uses
array.0, i.e. a local automatic array descriptor that is assigned if
if (array != 0B && (real(kind=4)[0:] * restrict) array->data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94668
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94668
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:5da301cbd81c41b2e9629f55dd1b1889f7dae75e
commit r10-7819-g5da301cbd81c41b2e9629f55dd1b1889f7dae75e
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
--- Comment #4 from Thomas Koenig ---
Taking the slightly modified test case
program array_temps
implicit none
type :: tt
integer :: u = 1
integer :: v = 2
end type tt
type(tt), dimension(:), pointer :: r
integer :: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |10.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48314=edit
failing testcase
This is a regression in gfortran-10 (reproduced in GNU Fortran (GCC) 10.0.1
20200420 (experimental) built from git master):
gfortran-master -Wall -fopenmp -c gf10bug.f90
gf10bug.f90:10:0:
10 |IF (PRESENT(ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94592
Richard Biener changed:
What|Removed |Added
Known to work||9.3.0
--- Comment #9 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454
Nathan Sidwell changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454
--- Comment #13 from Nathan Sidwell ---
Created attachment 48313
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48313=edit
testing shim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #7 from Jonathan Wakely ---
(In reply to Richard Biener from comment #3)
> The question is whether the standard allows eliding of the side-effect
> setting newCalled to true.
It does.
That side effect happens inside a replaceable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94583
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #3 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94582
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94549
Richard Biener changed:
What|Removed |Added
Known to work||9.3.0
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94546
Richard Biener changed:
What|Removed |Added
Known to work||9.3.0
--- Comment #3 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #6 from Jakub Jelinek ---
Well, the compiler shouldn't optimize away the allocation and not the
deallocation or vice versa, it needs to either optimize away allocation and all
corresponding deallocations, or none of that.
There were
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #5 from Bas Vodde ---
In the case we found this, it mostly uses the overload for accounting and thus
it doesn't cause a serious problem ('just' a test failure).
If you use the overloaded new/delete for providing your own memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94582
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:48c82310947355665d628d4d1c8e736df9987574
commit r10-7814-g48c82310947355665d628d4d1c8e736df9987574
Author: Jan Hubicka
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #4 from Bas Vodde ---
The newCalled to true in the example was the simplest way to show the behavior.
This bug came up in a open source project called CppuTest. This has the
functionality to detect memory leaks and does so by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 80051, which changed state.
Bug 80051 Summary: gcc/dwarf2out.c: PVS-Studio: V501
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80051
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80051
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
--- Comment #19 from Leo Yuriev ---
(In reply to CVS Commits from comment #4)
> The master branch has been updated by Richard Biener :
>
> https://gcc.gnu.org/g:a64468a3034dd8e2d0794a5be84b8da544ffe2c3
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #3 from Richard Biener ---
The question is whether the standard allows eliding of the side-effect setting
newCalled to true.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #2 from Bas Vodde ---
Oh wow, does this mean that it is the choice of the compiler to actually call
an overloaded operator new ?
That is interesting. Thanks.
I'd still consider it highly surprising behavior, at least it was for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #1 from Jonathan Wakely ---
No, this conforms to the standard. See [expr.new]
> An implementation is allowed to omit a call to a replaceable global allocation
> function (17.6.2.1, 17.6.2.2). When it does so, the storage is instead
1 - 100 of 187 matches
Mail list logo
