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
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
>
> 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 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
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, 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
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 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
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 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
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 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*
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 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
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
* 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
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
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.
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 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
20 matches
Mail list logo
