On 6/18/19 11:51 PM, david.tay...@dell.com wrote:
>> 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 pr
Hi.
I've written a patch draft that replaces zlib with the zstd compression
algorithm ([1])
in LTO. I'm also sending statistics that are collected for couple of quite big
C++ source
files. Observation I did:
- LTO stream compression takes 3-4% of LGEN compile time
- zstd in default compression
On Tue, Jun 18, 2019 at 12:19:51PM +0200, Florian Weimer wrote:
> For example, on POWER, the condition register is used to indicate
> errors. Instead of using that directly, we need to store that in a
> register, via mfcr:
Hrm, that example shows that my suggestion in
https://gcc.gnu.org/ml/gcc/2
Hi,
Recently I wanted to take and print the address of a label. When
compiling with -O2, I noticed that the address equals the function body
start address if the label is not used as a goto target.
Here is an example:
#include
int main(void) {
printf("main: %p\n", main);
printf("labe
* Segher Boessenkool:
>> <__GI___getdents64>:
>>0: addis r2,r12,0
>> 0: R_PPC64_REL16_HA .TOC.
>>4: addir2,r2,0
>> 4: R_PPC64_REL16_LO .TOC.+0x4
>>8: li r0,202
>>c: sc
>> 10: mfcr
Hello.
I have made following changes to inspect inlining of roundeven with
the following test code:
double
plusone (double d)
{
return __builtin_roundeven (d) + 1;
}
Running the program using -O2 foo.c gave internal compiler error which
I believe is because gcc_unreachable() at:
if (TARGET_SS
On 6/19/19 7:04 AM, Florian Rommel wrote:
> Hi,
>
> Recently I wanted to take and print the address of a label. When
> compiling with -O2, I noticed that the address equals the function body
> start address if the label is not used as a goto target.
>
> Here is an example:
>
> #include
> int m
On 6/19/19 3:21 AM, Martin Liška wrote:
> Hi.
>
> I've written a patch draft that replaces zlib with the zstd compression
> algorithm ([1])
> in LTO. I'm also sending statistics that are collected for couple of quite
> big C++ source
> files. Observation I did:
>
> - LTO stream compression take
On Wed, Jun 19, 2019 at 09:39:01AM -0600, Jeff Law wrote:
> A label used as a value, but which is not a jump target will have an
> indeterminate value -- it'll end up somewhere in its containing
> function, that's all we guarantee in that case.
In gimple it was fine and expected, and expand *did*
Dell Customer Communication - Confidential
> From: Martin Liška
> Sent: Wednesday, June 19, 2019 3:19 AM
>
> On 6/18/19 11:51 PM, david.tay...@dell.com wrote:
> >> From: Martin Liška
> >> Sent: Tuesday, June 18, 2019 11:20 AM
> >>
> >> .gcno files are created during compilation and contain info
On Wed, Jun 19, 2019 at 03:09:08PM +0200, Florian Weimer wrote:
> * Segher Boessenkool:
>
> >> <__GI___getdents64>:
> >>0: addis r2,r12,0
> >> 0: R_PPC64_REL16_HA .TOC.
> >>4: addir2,r2,0
> >> 4: R_PPC64_REL16_L
On 6/19/19 11:09 AM, Segher Boessenkool wrote:
> On Wed, Jun 19, 2019 at 09:39:01AM -0600, Jeff Law wrote:
>> A label used as a value, but which is not a jump target will have an
>> indeterminate value -- it'll end up somewhere in its containing
>> function, that's all we guarantee in that case.
>
On June 19, 2019 6:03:21 PM GMT+02:00, Jeff Law wrote:
>On 6/19/19 3:21 AM, Martin Liška wrote:
>> Hi.
>>
>> I've written a patch draft that replaces zlib with the zstd
>compression algorithm ([1])
>> in LTO. I'm also sending statistics that are collected for couple of
>quite big C++ source
>> fi
Hi
I was double checking the C++17 support in GCC for someone and the text at
this URL states
the support is experimental and gives the impression that the support is
incomplete. The table
of language features now has them all implemented.
Is this text still accurate?
https://gcc.gnu.org/project
On Wed, 19 Jun 2019 at 20:05, Joel Sherrill wrote:
>
> Hi
>
> I was double checking the C++17 support in GCC for someone and the text at
> this URL states
> the support is experimental and gives the impression that the support is
> incomplete. The table
> of language features now has them all impl
On Wed, Jun 19, 2019 at 2:07 PM Jonathan Wakely
wrote:
> On Wed, 19 Jun 2019 at 20:05, Joel Sherrill wrote:
> >
> > Hi
> >
> > I was double checking the C++17 support in GCC for someone and the text
> at
> > this URL states
> > the support is experimental and gives the impression that the suppor
On Wed, Jun 19, 2019 at 11:55 AM Richard Biener
wrote:
>
> On June 19, 2019 6:03:21 PM GMT+02:00, Jeff Law wrote:
> >On 6/19/19 3:21 AM, Martin Liška wrote:
> >> Hi.
> >>
> >> I've written a patch draft that replaces zlib with the zstd
> >compression algorithm ([1])
> >> in LTO. I'm also sending
>
> At least allow it to be built as part of the normal build like GMP,
> etc. are done.
> And include it in downloading using contrib/download_prerequisites
> like the libraries are done.
Anoying detail is that zstd builds with cmake, not autotools
Honza
>
> Thanks,
> Andrew Pinski
>
> >
> >
On Wed, Jun 19, 2019 at 12:29 PM Jan Hubicka wrote:
>
> >
> > At least allow it to be built as part of the normal build like GMP,
> > etc. are done.
> > And include it in downloading using contrib/download_prerequisites
> > like the libraries are done.
>
> Anoying detail is that zstd builds with c
Hi Andrew,
Thanks for working on this.
Enable elimination of zext/sext with VRP patch had to be reverted in
(https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00672.html) due to the
need for value ranges in PROMOTED_MODE precision for at least 1 test
case for alpha.
Playing with ranger suggest that
20 matches
Mail list logo
