Bug 90923 shows that even though GCC hash-table based containers
like hash_map can be instantiated on types with user-defined ctors
and dtors they invoke the dtors of such types without invoking
the corresponding ctors.
It was thanks to this bug that I spent a day debugging "interesting"
miscompi
> From: Martin Liška
> Sent: Tuesday, June 18, 2019 11:20 AM
>
> .gcno files are created during compilation and contain info about a source
> file.
> These files will be created by a cross compiler, so that's fine.
>
> During a run of a program a .gcda file is created. It contains information
On Tue, Jun 18, 2019 at 06:40:15PM +0200, Thomas Schwinge wrote:
> I normally don't pay too much attention to how GCC builds proceed, but
> here, I was waiting for it to complete... ;-)
>
> Doing a native bootstrap build on x86_64-pc-linux-gnu, with
> '--enable-checking=yes,extra,df,fold,rtl' (is
Hi Thomas,
> On 18 Jun 2019, at 17:40, Thomas Schwinge wrote:
>
> I normally don't pay too much attention to how GCC builds proceed, but
> here, I was waiting for it to complete... ;-)
>
> Doing a native bootstrap build on x86_64-pc-linux-gnu, with
> '--enable-checking=yes,extra,df,fold,rtl'
Hi!
I normally don't pay too much attention to how GCC builds proceed, but
here, I was waiting for it to complete... ;-)
Doing a native bootstrap build on x86_64-pc-linux-gnu, with
'--enable-checking=yes,extra,df,fold,rtl' (is that excessive, maybe?), I
just noticed that stage 2 (thus actually '
On 6/18/19 3:31 PM, david.tay...@dell.com wrote:
> Dell Customer Communication - Confidential
>
>> From: Martin Liška
>> Sent: Tuesday, June 18, 2019 4:56 AM
>>
>> On 6/18/19 10:40 AM, Richard Biener wrote:
>>> I don't think we want to expose -auxbase. Iff then an alternate way
>>> to specify a
Dell Customer Communication - Confidential
> From: Martin Liška
> Sent: Tuesday, June 18, 2019 4:56 AM
>
> On 6/18/19 10:40 AM, Richard Biener wrote:
> > I don't think we want to expose -auxbase. Iff then an alternate way
> > to specify a coverage output file name.
>
> I'm not aware of it.
>
On Tue, Jun 18, 2019 at 12:31:13PM +, Joel Hutton wrote:
> from bar.c.263r.combine:
> Trying 10 -> 12:
> 10: r97:V4SF=float(r96:V4SI)
> REG_DEAD r96:V4SI
> 12: r98:V4SF=r97:V4SF*r99:V4SF
> REG_DEAD r97:V4SF
> REG_EQUAL r97:V4SF*const_v
Hi Segher,
> I'll need some compilable source code to investigate this. That means
> compilable for*me*, so with some target that is in trunk.
I'm not sure I can trigger this on trunk. I've attached a minimal patch, which
adds a pattern which can trigger the behaviour, and 2 c files: foo.c match
* Jeff Law:
> This is best addressed by changing GCC itself to know about the
> different ABIs. Trying to tackle in ASMs is going to be painful,
> particularly since your asms change the stack pointer and that's
> generally verboten for an ASM.
Standard practice is to use generic assembler tramp
On 6/18/19 10:40 AM, Richard Biener wrote:
> I don't think we want to expose -auxbase. Iff then an alternate way to
> specify
> a coverage output file name.
I'm not aware of it.
@David: Can you please summarize what you want to achieve with the .gcno files?
I can then help you.
Martin
On Mon, Jun 17, 2019 at 5:02 PM wrote:
>
> > From: Richard Biener
> > Sent: Monday, June 17, 2019 9:57 AM
> > To: taylor, david
> > Cc: GCC Development
> > Subject: Re: gcc: -ftest-coverage and -auxbase
>
> > On Mon, Jun 17, 2019 at 2:46 PM David Taylor wrote:
> > >
>
> > > From: Richard Bie
12 matches
Mail list logo
