libgcc - SJLJ probe failing on head on h8300 & m32c

[Joel Sherrill]

Hi

h8300-rtems and m32c-rtems both fail in libgcc during the configure
probes of make.

configure: WARNING: decimal float is not supported for this target, ignored
checking whether fixed-point is supported... no
checking whether to use setjmp/longjmp exceptions... unknown
configure: error: unable to detect exception model
make[1]: *** [configure-target-libgcc] Error 1

Any suggestions?

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: libgcc - SJLJ probe failing on head on h8300 & m32c

[DJ Delorie]

Last time you mentioned this, I asked what the contents of that
config.log were...

[Aarch64] LRA

[Evandro Menezes]

It doesn't seem that the option -mno-lra does what it implies.  If so, what
does it do, for the it does result in differences.

 

TIA

 

 

Evandro Menezes  Austin, TX

  e.mene...@samsung.com
+1-512-425-3365

 

Re: GCC 5.0 Status Report (2014-11-03), Stage 1 ends Nov 15th

[Olivier Hainque]

Hello Jakub,

On Nov 3, 2014, at 10:18 , Jakub Jelinek  wrote:
> The trunk is scheduled to transition from Stage 1 to Stage 3 at the end
> of Saturday, November 15th (use your timezone to your advantage)
...
> What larger merges are still planned for GCC 5?

> What else have been people working
> on and can get posted for review before stage1 closes?

We (AdaCore) are planning to submit a new port for inclusion.  The assignment
paperwork is just being finalized. There's essentially a new config directory,
no core change, so should be suitable for stage 3 as well.

Apart from this, we have been working on the production of standard dwarf
instead of ad-hoc encodings for more Ada constructs. The first patches were
submitted for review and you have provided very useful feedback already.
Improvements were proposed and my understanding is that this is just pending
a final round of review

  https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02217.html

We have a few followup patches on top of this one. Would be great if we could
get some of these in, and we'll be happy to submit at least the first pieces
for review. I understand this will be tight though and we'll wait until the
next stage1 for whatever remains.

Otherwise, still pending review is a correction to fix unwinding
on the e500 series of powerpc:

  https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03264.html

(this could be stage3 or even 4 IMO).

Thanks a lot for your help!

Re: [Aarch64] LRA

[Richard Earnshaw]

On 05/11/14 17:14, Evandro Menezes wrote:
> It doesn't seem that the option -mno-lra does what it implies.  If so, what
> does it do, for the it does result in differences.

It causes the compiler to use 'reload' rather than LRA for handling part
of the register allocation process.

R.

Re: libgcc - SJLJ probe failing on head on h8300 & m32c

[Joel Sherrill]

On 11/5/2014 11:10 AM, DJ Delorie wrote:
> Last time you mentioned this, I asked what the contents of that
> config.log were...
I thought I posted it. Anyway, here is the m32c-rtems and h8300-rtems
libgcc config.logs.

 It looks more obvious now. Both targets have an ICE compiling
the autoconf probe code. m32c when -mcpu=m32cm and h8300
when -ms.

I suppose I need to file these as target specific regressions since 4.9.

Thanks for prodding my rusty memory.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: how to keep a hard register across multiple instrutions?

[David Kang]

 Thank you very much.
It turns out that the FPU register is renamed.
After configuring HARD_REGNO_RENAME_OK, now one FPU register is used for those 
three instructions.

 David

- Original Message -
> From: "Joern Rennecke" 
> To: "David Kang" 
> Cc: "Jeff Law" , "GCC" 
> Sent: Monday, November 3, 2014 5:05:21 PM
> Subject: Re: how to keep a hard register across multiple instrutions?
> On 3 November 2014 21:51, David Kang  wrote:
> >
> >  Thank you for the tips.
> > I tried the following condition for split.
> >
> >   "reload_completed && FP_REG_P (operands[0])"
> >
> > But, the registers are still changed.
> > How can I specify "after register allocation" in the split
> > condition?
> 
> Are you sure that your problem is that the split is too early, or
> could you suffering
> from later register renumbering?
> You can get a set of dump files for all rtl passes by adding the -da
> option to gcc / cc1,
> so that you can see exactly when things go wrong.
> I would suspect the register renaming pass causing you trouble.
> You might have to define HARD_REGNO_RENAME_OK suitably for your
> target.

-- 
--
Dr. Dong-In "David" Kang
Computer Scientist
USC/ISI

Match-and-simplify and COND_EXPR

[Andrew Pinski]

Hi,
  I was trying to hook up tree-ssa-phiopt to match-and-simplify using
either gimple_build (or rather using gimple_simplify depending on if
we want to produce cond_expr for conditional move).  I ran into a
problem.
With the pattern below:
/* a ? 0 : 1 -> a if 0 and 1 are integral types. */
(simplify
  (cond_expr @0 integer_zerop integer_onep)
  (if (INTEGRAL_TYPE_P (type))
(convert @0)))

This produces a gimple statement with an incorrect gimple statement
where we have have a convert with an compare expression.

t.c: In function ‘f’:
t.c:1:5: error: invalid operand in unary operation
 int f(int c, int a, int b)
 ^
_4 = (int) (c_2(D) != 0);


Did I implement the pattern incorrectly or is there a bug due to the
way cond_expr handles its 0th operand in that it is valid for compares
there in gimple form.

I don't have a good patch to test tree-ssa-phiopt.c connection due the
patch having extra code in it already which handles creating cond_expr
for conditional moves already.

Thanks,
Andrew Pinski

gcc-4.9-20141105 is now available

[gccadmin]

Snapshot gcc-4.9-20141105 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20141105/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch 
revision 217161

You'll find:

 gcc-4.9-20141105.tar.bz2 Complete GCC

  MD5=686e1ccebf10ebab5afb5e4800fd4211
  SHA1=6d2e5e1100c7a8cdabd1d98fb509f9304749f98c

Diffs from 4.9-20141029 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

[Tobias Grosser]

On 04.11.2014 16:17, Tobias Burnus wrote:

Hi all,

currently, contrib/download_prerequisites downloads isl-0.12.2 from
ftp://gcc.gnu.org/pub/gcc/infrastructure/$ISL.tar.bz2

However, that version has a bug which causes an ICE (PR 62289).
End of October, ISL 0.14 was released, which should contain a fix for
that issue. Hence, one should consider using 0.14 instead of /infrastructure/
and download_prerequisites.
Download: http://isl.gforge.inria.fr


Thanks Tobias for bringing this one up.


Disclaimer: I haven't tested that version, yet.

  * * *

The page https://gcc.gnu.org/install/prerequisites.html lists 0.12.2 as
version to be used (without "(or later)").

The configure script does some version checks, but seeminly only to rule
out early version of ISL as it is only the check for an include file.

According to https://groups.google.com/forum/#!topic/isl-development/CQGVfj60SQM
"0.14 was kept backward compatible with 0.13." [But 0.15 will break it.]

Thus, assuming 0.13 works, 0.14 also should work. Release notes:
http://repo.or.cz/w/isl.git/blob/HEAD:/ChangeLog


Right. 0.13 should work from svn revision 213816.

As Richard pointed out, isl introduce a backward incompatible change in 
0.13 that unfortunately made it impossible to compile 4.8 with isl 0.13.


Judging from Richards comments, this seems to continue to cause issues.

@Sven, we need to be very careful with such changes in the future. If it 
is low cost, we may even consider to make isl_int again available for

a couple of releases (from 0.14.1 on).


Comments? Especially from Richard and Tobias?

* * *

Finally, is CLooG still needed or will GCC also work with only ISL? Looking
at https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01742.html , it seems as if
it is about the right time to remove it.


CLooG is not necessarily needed. You can run graphite just with ISL. The 
main reason that ISL code generation is not enabled by default is that 
we did not yet get extensive testing and it was unclear who will have 
the time to fix possible bugs.


@Mircae, Roman: Would you have time to help with bug-fixing if we do the 
switch now? (I am happy to review patches and give advice, but can not 
do the full move myself)


Cheers,
Tobias

Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

[Roman Gareev]

> CLooG is not necessarily needed. You can run graphite just with ISL. The
> main reason that ISL code generation is not enabled by default is that we
> did not yet get extensive testing and it was unclear who will have the time
> to fix possible bugs.

Could you please advise me which test suites should be used to make
performance comparison between CLooG and ISL generator? (I would like
to do this, even though the old generator is removed).

> @Mircae, Roman: Would you have time to help with bug-fixing if we do the
> switch now? (I am happy to review patches and give advice, but can not do
> the full move myself)

I could find time for this. What do you mean by ‘switch’? If I’m not
mistaken, ISL generator is already used by default. Should we remove
support of CLooG generator and all files related to it?


-- 
Cheers, Roman Gareev.

Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

[Tobias Grosser]

On 06.11.2014 07:04, Roman Gareev wrote:

CLooG is not necessarily needed. You can run graphite just with ISL. The
main reason that ISL code generation is not enabled by default is that we
did not yet get extensive testing and it was unclear who will have the time
to fix possible bugs.


Could you please advise me which test suites should be used to make
performance comparison between CLooG and ISL generator? (I would like
to do this, even though the old generator is removed).


I do not have specific advices. You can use various open source 
benchmarks e.g. the LLVM test suite or, if you have access, you could 
run SPEC or something.



@Mircae, Roman: Would you have time to help with bug-fixing if we do the
switch now? (I am happy to review patches and give advice, but can not do
the full move myself)


I could find time for this. What do you mean by ‘switch’? If I’m not
mistaken, ISL generator is already used by default. Should we remove
support of CLooG generator and all files related to it?


Wow, I must really have been sleeping (or just forgetting). The switch 
already happened. This is amazing.


As the ISL code generator has been default since a while and we did not 
get many bug reports, the actual switch seems to have worked well. We 
could probably still need some testing, but in this case it is most 
likely time to drop the CLooG support entirely. Are you interested to 
provide the relevant patches?


Also, as Tobias suggested we should raise the minimal supported isl 
level to 0.14 to be sure PR 62289 is fixed.


Cheers,
Tobias