Re: C++ - compilation error for all implicit conversion

[Liu Hao]

在 2018年03月05日 15:42, Satya Prakash Prasad 写道:
> Is there a compiler flag that logs warning / error in case of any implicit
> conversions - like int32_t to uint32_t.
> 
> #include 
> #include 
> 
> using ::std::int32_t;
> using ::std::uint32_t;
> 
> int main(int argc, char *argv[])
> {
>int32_t x = 9;
> uint32_t i = x;
>uint32_t i1 = socketread(...); // returns  int32_t  -1 on error and >0
> on success
> std::cout << " " << x << " " << i << std::flush << std::endl;
> return 0;
> }
> c++ -std=c++11 -Wall -Wconversion -Wpedantic cast.cpp
> 
> I get no issues / warning / error during compilation - is there a way it
> can achieved.
> 

Try `-Wsign-conversion` in addition to `-Wconversion`.


-- 
Best regards,
LH_Mouse

Re: C++ - compilation error for all implicit conversion

[Satya Prakash Prasad]

I still does not throws an error:

#include 

#include 

using ::std::int32_t;

using ::std::uint32_t;

int32_t callme()

{

int32_t x = -1;

return x;

}

int main()

{

int32_t x = 9;

uint32_t i = x;

uint32_t i1 = callme();

std::cout << " " << x << " " << i << " " << i1 << std::flush << std::endl;

return 0;

}


/c/tools/mingw64/bin/c++ -std=c++11 -Wall -Wconversion -Wpedantic -Wextra
-w -Wsign-compare -Wnarrowing -Wreturn-type -Wno-int-conversion
-Wtype-limits -Wuseless-cast -Wsign-conversion -Wextra -Wsign-conversion
cast.cpp




On Mon, Mar 5, 2018 at 1:38 PM, Liu Hao  wrote:

> 在 2018年03月05日 15:42, Satya Prakash Prasad 写道:
> > Is there a compiler flag that logs warning / error in case of any
> implicit
> > conversions - like int32_t to uint32_t.
> >
> > #include 
> > #include 
> >
> > using ::std::int32_t;
> > using ::std::uint32_t;
> >
> > int main(int argc, char *argv[])
> > {
> >int32_t x = 9;
> > uint32_t i = x;
> >uint32_t i1 = socketread(...); // returns  int32_t  -1 on error and >0
> > on success
> > std::cout << " " << x << " " << i << std::flush << std::endl;
> > return 0;
> > }
> > c++ -std=c++11 -Wall -Wconversion -Wpedantic cast.cpp
> >
> > I get no issues / warning / error during compilation - is there a way it
> > can achieved.
> >
>
> Try `-Wsign-conversion` in addition to `-Wconversion`.
>
>
> --
> Best regards,
> LH_Mouse
>

Re: C++ - compilation error for all implicit conversion

[Liu Hao]

在 2018年03月05日 16:17, Satya Prakash Prasad 写道:
> I still does not throws an error:
> (... abridged ...)
> 
> /c/tools/mingw64/bin/c++ -std=c++11 -Wall -Wconversion -Wpedantic
> -Wextra -w -Wsign-compare -Wnarrowing -Wreturn-type -Wno-int-conversion
> -Wtype-limits -Wuseless-cast -Wsign-conversion -Wextra -Wsign-conversion
> cast.cpp
> 
> 

Your `-w` option suppressed all warnings.


-- 
Best regards,
LH_Mouse

Re: C++ - compilation error for all implicit conversion

[Satya Prakash Prasad]

Thanks a lot - I just picked up all compiler flags that we make use in our
project.

Thanks a lot for the information as provided.

Regards,
Prakash

On Mon, Mar 5, 2018 at 2:00 PM, Liu Hao  wrote:

> 在 2018年03月05日 16:17, Satya Prakash Prasad 写道:
> > I still does not throws an error:
> > (... abridged ...)
> >
> > /c/tools/mingw64/bin/c++ -std=c++11 -Wall -Wconversion -Wpedantic
> > -Wextra -w -Wsign-compare -Wnarrowing -Wreturn-type -Wno-int-conversion
> > -Wtype-limits -Wuseless-cast -Wsign-conversion -Wextra -Wsign-conversion
> > cast.cpp
> >
> >
>
> Your `-w` option suppressed all warnings.
>
>
> --
> Best regards,
> LH_Mouse
>

how to generate - "procedure linkage table" for MIPS

[V R]

Hi MIPS developers ;


This is regarding usage of "procedure linkage table" for MIPS. I have
trouble and generating the plt stubs for

shared library calls and the steps are given below.


I understand that gcc-4.4 ; binutils - 2.19; glibc-2.9 are prereqs and I
have all packages above this on MIPS cluster.


###details##

*Create own shared library   *

##foo.h##





#ifndef foo_h__

#define foo_h__



extern void foo(void);



#endif  // foo_h__



#foo.c###

#include 





void foo(void)

{

puts("Hello, I'm a shared library");

}



##create a shared
library



gcc -fPIC -c foo.c

gcc -shared -fPIC -o libfoo.so foo.o -> shared library libfoo.



objdump -D libfoo.so | grep plt

Disassembly of section .rela.plt:

03c8 <.rela.plt>:

Disassembly of section .plt:

0410 :

0420 :

0430 <__cxa_finalize@plt>:

481:   e8 aa ff ff ff  callq  430 <__cxa_finalize@plt>

517:   e8 04 ff ff ff  callq  420 

Disassembly of section .got.plt:

002007a0 <.got.plt>:

###



#driver that calls my shared library function
foo()





#include 

#include "foo.h"



int main(void)

{

puts("This is a shared library test...");

foo();

return 0;

}



#compile
driver##



gcc -o driver -L. -lfoo driver.c ---> driver code that calls foo().



###disassemble
driver##



objdump -D driver | grep plt

Disassembly of section .rela.plt:

00400458 <.rela.plt>:

Disassembly of section .plt:

004004b8 :

004004c8 :

004004d8 <__libc_start_main@plt>:

004004e8 :

  400524:   e8 af ff ff ff  callq  4004d8 <__libc_start_main@plt
>

  4005e1:   e8 e2 fe ff ff  callq  4004c8 

  4005e6:   e8 fd fe ff ff  callq  4004e8 

Disassembly of section .got.plt:



#







gcc options on x86 is :



gcc -v

Using built-in specs.

Target: x86_64-redhat-linux

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info

--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib

--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-libgcj-multifile

--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi

--disable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic

--host=x86_64-redhat-linux

Thread model: posix

gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)



The above said tasks works for x86 and similar exercise was carried out for
mips

architecture. It was found that even with -mplt option for gcc the plt
entries

were not found on disassembling the code.



Also on enabling gcc on MIPS with "–with-mips-plt " option the plt stub
wasnt seen. Is there

anything missing that needs to be done or is there any limitation , please
let me know.


-best regards
vidya













#

Re: MIPS ASAN status? (and "volunteering")

[Jean Lee]

2018-03-03 21:14 GMT+08:00 Hans-Peter Nilsson :

> > From: Jean Lee 
> > Date: Fri, 2 Mar 2018 13:29:39 +0800
>
> > 2018-03-02 7:53 GMT+08:00 Hans-Peter Nilsson <
> hans-peter.nils...@axis.com>:
> >
> > > There's no address-sanitizer support for MIPS (in particular for
> > > O32) on trunk, at least not when building for
> > > mipsisa32r2el-linux-gnu and libsanitizer/configure.tgt seems
> > > to support that observation.  There's a set of patches "floating
> > > around", but the last sign of work-in-progress was more than
> > > four years ago, according to a well-known search engine.
> > >
> > > Is there something holding it up getting it into trunk gcc?
> > > Is it just that someone needs to go the last mile?
> > >
> > > I can do that.  I can even go two miles!  Maybe even a merge
> > > from compiler-rt and MIPS port hacking (to be merged post
> > > gcc-8-branch to trunk, I presume).
> > >
> > > I'm a little worried that the "patches floating around" have
> > > unclear copyright status, so I haven't looked at them yet.  I'd
> > > rather not re-do MIPS ASAN on the gcc-side from scratch, but if
> > > it comes to that, so be it.
> > >
> > > brgds, H-P
> > >
> >
> > It is great to go the last mile. I had done the port  to
> > mipsel-linux-uclibc gcc for GCC 4.9/5.0/6.0.
> > Maybe I can give some help for you.
>
> That would be great, thanks in advance!
>
> First a few troublesome questions:
>
> Are you the sole copyright owner of the patches to gcc that you
> know of?  (Not including compiler-rt patches, those are for the
> compiler-rt people to worry about; I don't know their process.)
>
> If so, have you copyright assignment paper work in progress
> done or in progress with the FSF for gcc?  (From what I can
> tell, if so, it's not completed.)  If not, it'd be great if you
> can get that started, it takes quite a while.
>
> I believe that's necessary for gcc-specific parts, but I don't
> really decide that.  But, if those patches are small enough to
> not requiring paperwork they're probably also uninteresting
> enough that I add them as I go by.
>

My port of MIPS uclibc libsanitizer of gcc-6.x is now put in github.
https://github.com/xiaoyur347/sanitizer/
Much work was done to fix uclibc not MIPS.
If you just need MIPS, maybe two patches are needed.

1.
https://github.com/xiaoyur347/sanitizer/commit/016a8187c47f58de9b059eb77aa00e066aae309c
for gcc/config
2. libsanitizer/configure.tgt
+ mipsel-*-linux*)
;;
3.  Other works are for stack unwind, if the stack unwind doesn't call
malloc() at all, it will be easy.


> > Let's do the last mile.
> > To do this, I have some questions.
> > Should we port to the upstream LLVM first and port them back to GCC?
>
> I have no interest in LLVM at present, and can't wait, so:
> no, not on my behalf.
>
> But the question makes me wonder: are you implying that ASAN
> support for MIPS (O32 little-endian) isn't in upstream
> Clang/LLVM *too* or do I misunderstand you?  I'm not sure how to
> tell myself (save for building it from scratch and trying it,
> which I haven't done).
>
> *searches the web again...*
>
> It's not mentioned on
> , but that
> page seems out-of-date (known working platforms not mentioned).
> It's mentioned on
>  so
> maybe I concluded that since MIPS O32 support is not yet in GCC,
> it must have been developed using LLVM.  I thought I saw reviews
> for 3+ year accepted patches, but looking closer that must have
> been mips64 support.
>
> Thanks again for your support!
>
> brgds, H-P
>

Re: Interested to contribute in gsoc project

[Richard Biener]

On Sun, Mar 4, 2018 at 8:28 PM, shreya pohekar  wrote:
>
> Hello ,
> I am Shreya Pohekar, 2nd year student of University Institute of Technology 
> ,RGPV ,Bhopal, India. I am interested in applying in GSoC 2018, and would 
> like to contribute to the project : Parallelize the compilation using threads.
>
> I am working with c/c++ for a long time and would be an appropriate candidate 
> for this project. I have worked a bit on GCC as well , when I was learning 
> ARM exploitation.
>
> Can you guide me from where to get started? Or anything additional that I 
> need to study.

A good starting point is the GCC WIKI at https://gcc.gnu.org/wiki - there's a
Getting Started with GCC Development section.  It's good to get one
self familiar
with building GCC from source and to see how to do edit/compile/debug cycles.

For the project in question you need to make yourself familiar with
the highlevel
compilation flow.  toplev.c is where the main controlling pieces stick together.
See do_compile -> compile_file -> symtab->finalize_compulation_unit -> compile
which will eventually lead to the "pass manager".  The ultimate task would be
to change the "pass manager" to execute chunks of passes in parallel and the
first hurdle is to identify chunks that can be executed in parallel without too
many changes (read: least global shared state).

Richard.


> Thanks
>
> Regards,
> Shreya
> Sent from Mail for Windows 10
>

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Segher Boessenkool]

On Mon, Mar 05, 2018 at 08:01:14AM +0100, Eric Botcazou wrote:
> > C11 says in 7.13.2.1/2
> > "The longjmp function restores the environment saved by the most recent
> > invocation of the setjmp macro in the same invocation of the program with
> > the corresponding jmp_buf argument."
> > where "environment" is not really defined, but it includes all information
> > a program will need to return to its caller (so it has to restore the
> > non-volatile registers, set stack pointers correctly, that kind of thing).
> 
> Apparently the authors of the SPARC psABI thought that the last part of your 
> sentence is an interpolation and that the (historical) requirements were 
> vague 
> enough to allow their interpretation, IOW that the compiler can do the work.

Maybe we should have a target hook that says setjmp/longjmp are
implemented by simple function calls (or as-if by function calls), so
as not to penalize everyone who has an, erm, more conservative ABI?


Segher

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Eric Botcazou]

> Maybe we should have a target hook that says setjmp/longjmp are
> implemented by simple function calls (or as-if by function calls), so
> as not to penalize everyone who has an, erm, more conservative ABI?

Yes, that sounds a sensible compromise to me.

-- 
Eric Botcazou

FYI: Latest gcc-8 snapshot gives ICE with later isl's

[Donald Parsons]

I am getting ICE bootstrapping gcc-8-20180304.tar.xz when using either
isl-0.18 or isl-0.19.   I had never had a problem using latest isl over
the past couple of years, so a change in gcc last week introduced the
problem.

Normally I disable-bootstrap and use last weeks gcc-8 to build this
weeks gcc-8 and avoid the extra long bootstrap time.  This actually
worked, at least with isl-0.18 but the resulting gcc-8 gave ICE errors
building latest "pari-gp" and the latest-rc4 Linux kernel.  So went
back to bootstrapping with (Redhat gcc-7.3.1-2) and discovered the
above.

Here is failure (using isl-0.18; 0.19 looks same):
...
libtool: compile:  /home/don/src/gcc-8-20180304-obj/./prev-gcc/xgcc
-B/home/don/src/gcc-8-20180304-obj/./prev-gcc/ -B/opt/gcc/gcc-8-
0304/x86_64-redhat-linux/bin/ -B/opt/gcc/gcc-8-0304/x86_64-redhat-
linux/bin/ -B/opt/gcc/gcc-8-0304/x86_64-redhat-linux/lib/ -isystem
/opt/gcc/gcc-8-0304/x86_64-redhat-linux/include -isystem /opt/gcc/gcc-
8-0304/x86_64-redhat-linux/sys-include -DHAVE_CONFIG_H -I. -I../../gcc-
8-20180304/isl -I../../gcc-8-20180304/isl/include -Iinclude/ -g -O2
-gtoggle -MT isl_factorization.lo -MD -MP -MF
.deps/isl_factorization.Tpo -c ../../gcc-8-
20180304/isl/isl_factorization.c -o isl_factorization.o
during GIMPLE pass: pre
../../gcc-8-20180304/isl/isl_factorization.c: In function
'isl_basic_set_factorizer':
../../gcc-8-20180304/isl/isl_factorization.c:256:28: internal compiler
error: in compute_antic_aux, at tree-ssa-pre.c:2148
 __isl_give isl_factorizer *isl_basic_set_factorizer(
^~~~
0x11e6790 compute_antic_aux
../../gcc-8-20180304/gcc/tree-ssa-pre.c:2148
0x11e713b compute_antic
../../gcc-8-20180304/gcc/tree-ssa-pre.c:2364
0x11ec1b1 execute
../../gcc-8-20180304/gcc/tree-ssa-pre.c:4131
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[5]: *** [Makefile:1463: isl_factorization.lo] Error 1
make[5]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl'
make[4]: *** [Makefile:1571: all-recursive] Error 1
make[4]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl'
make[3]: *** [Makefile:1167: all] Error 2
make[3]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl'
make[2]: *** [Makefile:6155: all-stage2-isl] Error 2
make[2]: Leaving directory '/home/don/src/gcc-8-20180304-obj'
make[1]: *** [Makefile:25157: stage2-bubble] Error 2
make[1]: Leaving directory '/home/don/src/gcc-8-20180304-obj'
make: *** [Makefile:947: all] Error 2

Thanks,
Don

Re: FYI: Latest gcc-8 snapshot gives ICE with later isl's

[Marek Polacek]

On Mon, Mar 05, 2018 at 12:58:23PM -0500, Donald Parsons wrote:
> 
> I am getting ICE bootstrapping gcc-8-20180304.tar.xz when using either
> isl-0.18 or isl-0.19.   I had never had a problem using latest isl over
> the past couple of years, so a change in gcc last week introduced the
> problem.
> 
> Normally I disable-bootstrap and use last weeks gcc-8 to build this
> weeks gcc-8 and avoid the extra long bootstrap time.  This actually
> worked, at least with isl-0.18 but the resulting gcc-8 gave ICE errors
> building latest "pari-gp" and the latest-rc4 Linux kernel.  So went
> back to bootstrapping with (Redhat gcc-7.3.1-2) and discovered the
> above.
> 
> Here is failure (using isl-0.18; 0.19 looks same):
> ...
> libtool: compile:  /home/don/src/gcc-8-20180304-obj/./prev-gcc/xgcc
> -B/home/don/src/gcc-8-20180304-obj/./prev-gcc/ -B/opt/gcc/gcc-8-
> 0304/x86_64-redhat-linux/bin/ -B/opt/gcc/gcc-8-0304/x86_64-redhat-
> linux/bin/ -B/opt/gcc/gcc-8-0304/x86_64-redhat-linux/lib/ -isystem
> /opt/gcc/gcc-8-0304/x86_64-redhat-linux/include -isystem /opt/gcc/gcc-
> 8-0304/x86_64-redhat-linux/sys-include -DHAVE_CONFIG_H -I. -I../../gcc-
> 8-20180304/isl -I../../gcc-8-20180304/isl/include -Iinclude/ -g -O2
> -gtoggle -MT isl_factorization.lo -MD -MP -MF
> .deps/isl_factorization.Tpo -c ../../gcc-8-
> 20180304/isl/isl_factorization.c -o isl_factorization.o
> during GIMPLE pass: pre
> ../../gcc-8-20180304/isl/isl_factorization.c: In function
> 'isl_basic_set_factorizer':
> ../../gcc-8-20180304/isl/isl_factorization.c:256:28: internal compiler
> error: in compute_antic_aux, at tree-ssa-pre.c:2148
>  __isl_give isl_factorizer *isl_basic_set_factorizer(
> ^~~~
> 0x11e6790 compute_antic_aux
>   ../../gcc-8-20180304/gcc/tree-ssa-pre.c:2148
> 0x11e713b compute_antic
>   ../../gcc-8-20180304/gcc/tree-ssa-pre.c:2364
> 0x11ec1b1 execute
>   ../../gcc-8-20180304/gcc/tree-ssa-pre.c:4131
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[5]: *** [Makefile:1463: isl_factorization.lo] Error 1
> make[5]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl'
> make[4]: *** [Makefile:1571: all-recursive] Error 1
> make[4]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl'
> make[3]: *** [Makefile:1167: all] Error 2
> make[3]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl'
> make[2]: *** [Makefile:6155: all-stage2-isl] Error 2
> make[2]: Leaving directory '/home/don/src/gcc-8-20180304-obj'
> make[1]: *** [Makefile:25157: stage2-bubble] Error 2
> make[1]: Leaving directory '/home/don/src/gcc-8-20180304-obj'
> make: *** [Makefile:947: all] Error 2

I bet this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670 which is 
already
fixed.

Marek

Re: FYI: Latest gcc-8 snapshot gives ICE with later isl's

[Donald Parsons]

On Mon, 2018-03-05 at 19:04 +0100, Marek Polacek wrote:
> On Mon, Mar 05, 2018 at 12:58:23PM -0500, Donald Parsons wrote:
> > 
> > I am getting ICE bootstrapping gcc-8-20180304.tar.xz when using
> > either
> > isl-0.18 or isl-0.19.   I had never had a problem using latest isl
> > over
> > the past couple of years, so a change in gcc last week introduced
> > the
> > problem.
> > 
> > Normally I disable-bootstrap and use last weeks gcc-8 to build this
> > weeks gcc-8 and avoid the extra long bootstrap time.  This actually
> > worked, at least with isl-0.18 but the resulting gcc-8 gave ICE
> > errors
> > building latest "pari-gp" and the latest-rc4 Linux kernel.  So went
> > back to bootstrapping with (Redhat gcc-7.3.1-2) and discovered the
> > above.
> > 
> > Here is failure (using isl-0.18; 0.19 looks same):
> > ...
> > libtool: compile:  /home/don/src/gcc-8-20180304-obj/./prev-gcc/xgcc
> > -B/home/don/src/gcc-8-20180304-obj/./prev-gcc/ -B/opt/gcc/gcc-8-
> > 0304/x86_64-redhat-linux/bin/ -B/opt/gcc/gcc-8-0304/x86_64-redhat-
> > linux/bin/ -B/opt/gcc/gcc-8-0304/x86_64-redhat-linux/lib/ -isystem
> > /opt/gcc/gcc-8-0304/x86_64-redhat-linux/include -isystem
> > /opt/gcc/gcc-
> > 8-0304/x86_64-redhat-linux/sys-include -DHAVE_CONFIG_H -I.
> > -I../../gcc-
> > 8-20180304/isl -I../../gcc-8-20180304/isl/include -Iinclude/ -g -O2
> > -gtoggle -MT isl_factorization.lo -MD -MP -MF
> > .deps/isl_factorization.Tpo -c ../../gcc-8-
> > 20180304/isl/isl_factorization.c -o isl_factorization.o
> > during GIMPLE pass: pre
> > ../../gcc-8-20180304/isl/isl_factorization.c: In function
> > 'isl_basic_set_factorizer':
> > ../../gcc-8-20180304/isl/isl_factorization.c:256:28: internal
> > compiler
> > error: in compute_antic_aux, at tree-ssa-pre.c:2148
> >  __isl_give isl_factorizer *isl_basic_set_factorizer(
> > ^~~~
> > 0x11e6790 compute_antic_aux
> > ../../gcc-8-20180304/gcc/tree-ssa-pre.c:2148
> > 0x11e713b compute_antic
> > ../../gcc-8-20180304/gcc/tree-ssa-pre.c:2364
> > 0x11ec1b1 execute
> > ../../gcc-8-20180304/gcc/tree-ssa-pre.c:4131
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > Please include the complete backtrace with any bug report.
> > See  for instructions.
> > make[5]: *** [Makefile:1463: isl_factorization.lo] Error 1
> > make[5]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl'
> > make[4]: *** [Makefile:1571: all-recursive] Error 1
> > make[4]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl'
> > make[3]: *** [Makefile:1167: all] Error 2
> > make[3]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl'
> > make[2]: *** [Makefile:6155: all-stage2-isl] Error 2
> > make[2]: Leaving directory '/home/don/src/gcc-8-20180304-obj'
> > make[1]: *** [Makefile:25157: stage2-bubble] Error 2
> > make[1]: Leaving directory '/home/don/src/gcc-8-20180304-obj'
> > make: *** [Makefile:947: all] Error 2
> 
> I bet this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670
> which is already
> fixed.
> 
>   Marek

Adding Richard Biener to cc.

Marek, thanks for the heads up.  I applied the patch from the bugzilla
but it still fails to bootstrap with same ICE error, only line numbers
changes by about 4.  (isl-0.19 was used in this case)

So I tried using the system's (Fedora 26) isl-0.16 and this makes
everything build correctly.  So the latest isl-0.18 or 0.19 are more
sensitive to the changes made to gcc last week.

So it might be easiest to fix gcc to work with isl-0.18/19 now while
the changes being made to gcc are fresh in mind.

Don


PS: I had to manually apply the patch, so in case I misunderstood, here
 is resulting diff:

 --- tree-ssa-pre.c.orig2018-03-05 13:48:02.446954477 -0500
+++ tree-ssa-pre.c  2018-03-05 13:52:51.851014394 -0500
@@ -1393,8 +1393,12 @@
else
  {
unsigned value_id = get_expr_value_id
(constant);
-   constant = find_leader_in_sets (value_id,
set1, set2,
-   AVAIL_OUT
(pred));
+   /* We want a leader in ANTIC_OUT to be
consistent
+  with the rest of phi_translate but we don't
have
+  that available (and it isn't complete yet)
so
+  we resort to AVAIL_OUT here.  */
+   constant = bitmap_find_leader (AVAIL_OUT
(pred),
+  value_id);
if (constant)
  return constant;
  }
(sorry, evolution wrapped it)

Re: Interested to contribute in gsoc project

[shreya pohekar]

Thanks, I'll check them out.

On 5 Mar 2018 9:01 pm, "Richard Biener"  wrote:

> On Sun, Mar 4, 2018 at 8:28 PM, shreya pohekar 
> wrote:
> >
> > Hello ,
> > I am Shreya Pohekar, 2nd year student of University Institute of
> Technology ,RGPV ,Bhopal, India. I am interested in applying in GSoC 2018,
> and would like to contribute to the project : Parallelize the compilation
> using threads.
> >
> > I am working with c/c++ for a long time and would be an appropriate
> candidate for this project. I have worked a bit on GCC as well , when I was
> learning ARM exploitation.
> >
> > Can you guide me from where to get started? Or anything additional that
> I need to study.
>
> A good starting point is the GCC WIKI at https://gcc.gnu.org/wiki -
> there's a
> Getting Started with GCC Development section.  It's good to get one
> self familiar
> with building GCC from source and to see how to do edit/compile/debug
> cycles.
>
> For the project in question you need to make yourself familiar with
> the highlevel
> compilation flow.  toplev.c is where the main controlling pieces stick
> together.
> See do_compile -> compile_file -> symtab->finalize_compulation_unit ->
> compile
> which will eventually lead to the "pass manager".  The ultimate task would
> be
> to change the "pass manager" to execute chunks of passes in parallel and
> the
> first hurdle is to identify chunks that can be executed in parallel
> without too
> many changes (read: least global shared state).
>
> Richard.
>
>
> > Thanks
> >
> > Regards,
> > Shreya
> > Sent from Mail for Windows 10
> >
>

Re: FYI: Latest gcc-8 snapshot gives ICE with later isl's

[Donald Parsons]

On Mon, 2018-03-05 at 19:04 +0100, Marek Polacek wrote:
> On Mon, Mar 05, 2018 at 12:58:23PM -0500, Donald Parsons wrote:
> > 
> > I am getting ICE bootstrapping gcc-8-20180304.tar.xz when using
> > either
> > isl-0.18 or isl-0.19.   I had never had a problem using latest isl
> > over
> > the past couple of years, so a change in gcc last week introduced
> > the
> > problem.
> >
...
> I bet this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670
> which is already
> fixed.
> 
>   Marek

> Adding Richard Biener to cc.
> 
> Marek, thanks for the heads up.  I applied the patch from the
> bugzilla but it still fails to bootstrap with same ICE error,
> only line numbers changes by about 4.  (isl-0.19 was used in
> this case)


I'm sorry I missed the main patch in the bugzilla.  Fully patching
 "tree-ssa-pre.c" correctly, allows gcc to bootstrap without errors
when using isl-0.19 (and undoubtedly isl-0.18 too)

Sorry for the extra noise!
Thanks,
Don