Hi!
On Mon, Jan 14, 2019 at 09:53:18PM +, Steve Ellcey wrote:
> I have a question about PR87763, these are aarch64 specific tests
> that are failing after r265398 (combine: Do not combine moves from hard
> registers).
>
> These tests are all failing when the assembler scan looks for
> specifi
I have a question about PR87763, these are aarch64 specific tests
that are failing after r265398 (combine: Do not combine moves from hard
registers).
These tests are all failing when the assembler scan looks for
specific instructions and these instructions are no longer being
generated. In some c
* Nathan Sidwell:
> On 1/10/19 9:32 AM, Jakub Jelinek wrote:
>> On Thu, Jan 10, 2019 at 03:20:59PM +0100, Florian Weimer wrote:
>>> Can we remove __has_include__?
>>
>> No.
>>
>>> Its availability results in code which is needlessly non-portable
>>> because for some reason, people write __has_incl
* Jakub Jelinek:
> Because the magic builtin is a preprocessor builtin, kind of macro,
> so you can't have a normal macro with the same name.
Could we turn this kind-of-macro into something that can be tested using
#ifdef?
Thanks,
Florian
On 1/10/19 9:32 AM, Jakub Jelinek wrote:
On Thu, Jan 10, 2019 at 03:20:59PM +0100, Florian Weimer wrote:
Can we remove __has_include__?
No.
Its availability results in code which is needlessly non-portable
because for some reason, people write __has_include__ instead of
__has_include. (I do
On Mon, 14 Jan 2019, Jim Wilson wrote:
> CodeSourcery wrote one called qmtest, but there apparently hasn't been any
> work done on it in a while. Joseph Myers indirectly referred to it. You can
> find a copy here
> https://github.com/MentorEmbedded/qmtest
Note that's a poor git-svn conversi
On 1/14/19 5:44 AM, MCC CS wrote:
I've been running the testsuite on my macOS, on which
it is especially unbearable. I want to (at least try to)
rewrite a DejaGNU replacement accepting the same
syntax and having no dependency, should therefore
be faster. I was wondering if there have been any
att
Hi devs,
consider below testcase:
$cat test.c
void foo(){
unsigned int x=-1;
double d=x;
}
$./cc1 test.c -msoft-float -m64
$cat test.s
.foo:
.LFB0:
mflr 0
std 0,16(1)
stdu 1,-128(1)
.LCFI0:
li 9,-1
stw 9,112(1)
lwa 9,112(1)
mr 3,9
bl
On Mon, 14 Jan 2019, Jeff Law wrote:
> On 1/14/19 9:39 AM, Paolo Carlini wrote:
> > Hi,
> >
> > On 14/01/19 17:28, Jakub Jelinek wrote:
> >> I think several testcases check for duplicate error messages, the
> >> regexp is
> >> against the whole text, so you can just check if it occurs more than o
Hi Jeff,
On 14/01/19 17:43, Jeff Law wrote:
On 1/14/19 9:39 AM, Paolo Carlini wrote:
Hi,
On 14/01/19 17:28, Jakub Jelinek wrote:
I think several testcases check for duplicate error messages, the
regexp is
against the whole text, so you can just check if it occurs more than once
there.
This i
On 1/14/19 9:39 AM, Paolo Carlini wrote:
> Hi,
>
> On 14/01/19 17:28, Jakub Jelinek wrote:
>> I think several testcases check for duplicate error messages, the
>> regexp is
>> against the whole text, so you can just check if it occurs more than once
>> there.
>
> This is essentially https://gcc.g
Hi,
On 14/01/19 17:28, Jakub Jelinek wrote:
I think several testcases check for duplicate error messages, the regexp is
against the whole text, so you can just check if it occurs more than once
there.
This is essentially https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30612
Paolo.
On Mon, Jan 14, 2019 at 03:50:32PM +0100, Paolo Carlini wrote:
> On 14/01/19 15:35, Jakub Jelinek wrote:
> > On Mon, Jan 14, 2019 at 03:15:05PM +0100, MCC CS wrote:
> > > Thank you for the quick replies. I was inspired by
> > > https://gcc.gnu.org/ml/gcc-help/2012-04/msg00223.html
> > > but it seem
On Mon, Jan 14, 2019 at 9:51 AM Paolo Carlini wrote:
>
> Hi,
>
> On 14/01/19 15:35, Jakub Jelinek wrote:
> > On Mon, Jan 14, 2019 at 03:15:05PM +0100, MCC CS wrote:
> >> Thank you for the quick replies. I was inspired by
> >> https://gcc.gnu.org/ml/gcc-help/2012-04/msg00223.html
> >> but it seems,
Hi,
On 14/01/19 15:35, Jakub Jelinek wrote:
On Mon, Jan 14, 2019 at 03:15:05PM +0100, MCC CS wrote:
Thank you for the quick replies. I was inspired by
https://gcc.gnu.org/ml/gcc-help/2012-04/msg00223.html
but it seems, according to your comments, that was outdated.
So, I don't really see what
On Mon, Jan 14, 2019 at 03:15:05PM +0100, MCC CS wrote:
> Thank you for the quick replies. I was inspired by
> https://gcc.gnu.org/ml/gcc-help/2012-04/msg00223.html
> but it seems, according to your comments, that was outdated.
Since then the parallelization has been changed, since 2014 all the
in
> On 14 Jan 2019, at 13:53, Rainer Orth wrote:
>
> "MCC CS" writes:
>
>> I've been running the testsuite on my macOS, on which
>> it is especially unbearable. I want to (at least try to)
>
> that problem may well be macOS specific: since at least macOS 10.13
> (maybe even 10.12; cannot curre
Thank you for the quick replies. I was inspired by
https://gcc.gnu.org/ml/gcc-help/2012-04/msg00223.html
but it seems, according to your comments, that was outdated.
The problem on my Mac was each of the processes used no more
than 10% of a core. Now I know that it's not so inefficient
on other pla
On Mon, Jan 14, 2019 at 2:54 PM Rainer Orth
wrote:
>
> "MCC CS" writes:
>
> > I've been running the testsuite on my macOS, on which
> > it is especially unbearable. I want to (at least try to)
>
> that problem may well be macOS specific: since at least macOS 10.13
> (maybe even 10.12; cannot cur
"MCC CS" writes:
> I've been running the testsuite on my macOS, on which
> it is especially unbearable. I want to (at least try to)
that problem may well be macOS specific: since at least macOS 10.13
(maybe even 10.12; cannot currently tell for certain) make -jN check
times on my Mac mini skyroc
Hi all,
I've been running the testsuite on my macOS, on which
it is especially unbearable. I want to (at least try to)
rewrite a DejaGNU replacement accepting the same
syntax and having no dependency, should therefore
be faster. I was wondering if there have been any
attempts on this? Knowing what
I've found a testcase where the stack protector code generated through
`-fstack-protector-all` doesn't actually protect anything.
#+name stack-reorder.c
#+begin_src c
#include
#include
int foo (int a, int b, int c) {
char buf[64];
buf[a] = 1;
buf[b] = c;
// Just add somethin
On Mon, Jan 14, 2019 at 12:41 PM Giuliano Belinassi
wrote:
>
> Hi,
>
> I am currently studying the GIMPLE IR documentation and thinking about a
> way easily gather the timing information. I was thinking about about
> adding this feature to gcc to show/dump the elapsed time on GIMPLE. Does
> this m
Hi,
I am currently studying the GIMPLE IR documentation and thinking about a
way easily gather the timing information. I was thinking about about
adding this feature to gcc to show/dump the elapsed time on GIMPLE. Does
this makes sense? Is this already implemented somewhere? Where is a good
way to
On Fri, Jan 11, 2019 at 9:02 PM Steve Ellcey wrote:
>
> Someone here was asking about GCC, ISL, and tiling and we looked at
> the test gcc.dg/graphite/interchange-3.c on Aarch64. When this
> test is run the graphite pass output file contains the string 'not
> tiled' and since the dg-final scan-tr
On Thu, Jan 10, 2019 at 3:00 PM Carter Cheng wrote:
>
> Hello,
>
> I am trying to assess an idea and whether it is possible to implement a
> certain idea as a gcc plugin. I look over some of the information on the
> web and the gcc internals documentation but I cannot still figure out some
> basic
26 matches
Mail list logo
