Re: Can we please have the old mailing list back

[Dmitry Mikushin]

Maybe the best form of question is: Could the Overseer be so kind to
release the dump of the original old mailing list on any free public file
server?

ср, 25 мар. 2020 г. в 21:29, Bernd Edlinger :

> -On 3/25/20 7:55 PM, Christopher Faylor wrote:
> > On Wed, Mar 25, 2020 at 04:23:02PM +0700, Arseny Solokha wrote:
> >> I believe the canonical place for the "Linux suff" mailing lists these
> days is
> >> lore.kernel.org, powered by public-inbox[1]. ISTM that software can
> address most
> >> if not all needs of those involved in GCC development and even has NNTP
> support,
> >> though I've no idea whether it could be an acceptable solution from the
> >> overseers' perspective.
> >>
> >> [1] https://public-inbox.org/public-inbox.git
> >
> > The overseers are trying hard to use only software that can be installed
> > via the RHEL packaging system so as not to duplicate the mistake that
> > kept us dependent on poorly supported mail software.  Is there a
> > public-inbox rpm package for RHEL or CentOS?
> >
> > FWIW, this particular overseer is is also pretty exhausted from the
> > effort of moving sourceware to a new system + new software and would not
> > relish the effort involved in getting all of this moved to new software.
> >
>
> Honestly this is not about blaming you at all.
>
> I do not quite understand what is the exact software which
> was used previously?
>
> what is the exact problem that prevents it from being used any longer?
>
> Which software is being used now?
>
> Why is gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org.  and fort...@gcc.gnu.org
> even this e-mail thread visible
> on marc.info: https://marc.info/?l=gcc&m=158512515107459&w=2
> but not gdb-patches ?
>
> Could you add a link to https://marc.info/?l=gcc-patches
> https://marc.info/?l=gcc
> https://marc.info/?l=gcc-fortran
> note the unsystematic name gcc-fortran, the list is fort...@gcc.gnu.org
>
> There is no gcc-help on marc.info
> There is https://marc.info/?l=gcc
> but there is no gdb-patches
>
> what needs to be done to host those lists on marc.info as well?
>
> What needs to be done to host these lists on spinics for instance,
> or what else exists that can be used to search the messages?
>
>
> Bernd.
>

Re: The gcc version used for compiling qt4.

[Dmitry Mikushin]

Qt4 is an old release (the current one is almost Qt6). A newer compiler is
usually backward-compatible with older codes. So you should be able to
compile Qt4 on Ubuntu 20.04 with system-provided GCC right away.

пн, 18 мая 2020 г. в 14:34, Hongyi Zhao via Gcc :

> Hi,
>
> I want to compile qt4 on Ubuntu 20.04 which shipped with the following
> gcc version:
>
> $ gcc --version
> gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
>
> But I'm not sure whether this gcc version is suitable for qt4.  Any
> hints for this problem?
>
> Regards,
> --
> Hongyi Zhao 
>

Re: WWDC thread: support for darwin/macOS going forward

[Dmitry Mikushin]

Homebrew has GCC 9, which offers flawless development experience, at least
up to quite advanced applications. There of course could be corner cases in
ABI, exceptions handling, etc., which I however never came across myself on
MacOS. Thus, discussing gcc 4.2 seems to be highly nonsensical these days.
Good news is as long as the whole gadget stack is going to use the same cpu
family, getting a piece of broken iPhone would be enough to study the big
Mac :)

вт, 23 июн. 2020 г. в 00:52, Eric Gallager via Gcc :

> Hi, at Apple's WWDC this year they have announced that they are doing
> yet another architecture transition, so I was wondering what exactly
> would be the best way to go about adding support for it? The first
> issue would be just what to call the new architecture; it seems to be
> ARM-based, but there might be some proprietary extensions, so
> arm-apple-darwin or aarch64-apple-darwin might not work? The next
> issue would be how exactly to go about adding support for it: Apple
> had arm-apple-darwin support for gcc in their version of gcc-4.2 that
> I don't think they ever contributed back upstream, but that was for
> iOS, so I doubt it could just be forward-ported, and even if it could,
> previous attempts to grab stuff from Apple's version of gcc-4.2 have
> faltered for legal reasons, so that could also be a factor here. I'm
> guessing it might be better instead to just start afresh from scratch?
> I'd offer to help with testing but I *just* got a new Intel-based Mac
> that I haven't even managed to set up yet, so I highly doubt I'll have
> any money for a new ARM-based Mac anytime soon... Anyways, I'm
> interested to hear what people are thinking.
>
> Thanks,
> Eric Gallager
>

Re: gcc 8.1 + libc.a

[Dmitry Mikushin]

First of, "error opening libc.a" message looks highly unusual. It's not the
way ld typically complains about a missing library or wrong architecture.
More likely, here it is rather some gcc-internal lib.a to be deployed in
some special way, but was missing.

I would try two things:
1) Re-iterate the failing conftest manually, appending -v option to show
what underlying ld command is being executed
2) Search for libc.a in the gcc build tree on another server, where the
build was successful.

Good luck,
- Dmitry.


On Thu, Oct 4, 2018, 02:32 Jost, Gabriele (ARC-TNC)[Supersmith] via gcc <
gcc@gcc.gnu.org> wrote:

> Hello,
> I have successfully installed gcc 8.1 on one system. I had to build the
> accelerator on the front end, because the compute nodes did not have libc.a.
> The build process seems to require a libc.a.
> I am now struggling with trying to install it on a different system: Same
> concept, front end has libc.a, compute nodes don’t. But now I can’t even
> build the build the accelerator compiler, because of of the missing libc.a.
> But it lives in /usr/lib64, just like on the other system. Would you have
> any advise how I can get around this? Thanks in advance,
> Gabriele
>
>
> configure:3016: /nobackup/gcc_nvptx/gcc/build-accel/./gcc/xgcc
> -B/nobackup//gcc_nvptx/gcc/build-accel/./gcc/
> -B/nobackup/gcc-8.1.0-install/nvptx-none/bin/
> -B/nobackup/gcc-8.1.0-install/nvptx-none/lib/ -isystem
> /nobackup/gcc-8.1.0-install/nvptx-none/include -isystem
> /nobackup/gcc-8.1.0-install/nvptx-none/sys-include-g -O2   conftest.c
> -lc >&5
> error opening libc.a
> collect2: error: ld returned 1 exit status
> configure:3020: $? = 1
> configure:3057: result:
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "package-unused"
> | #define PACKAGE_TARNAME "libbacktrace"
> | #define PACKAGE_VERSION "version-unused"
> | #define PACKAGE_STRING "package-unused version-unused"
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
>
>
>

Re: GSoC

[Dmitry Mikushin]

Linear equation solvers is not the scope of . There are many
packages serving this particular purpose, try looking into e.g. LAPACK.

Kind regards,
- Dmitry.


пт, 1 мар. 2019 г. в 23:09, Ahmed Ashraf :

> Hello,
> I am Ahmed Ashraf, a first-year student at the Computer Engineering
> Department, Faculty of Engineering - Cairo University in Egypt.
>
> In the first semester, I was asked to create a CAD as the Circuits course
> project. The requirements were to simulate simple AC circuits that contain
> only (independent voltage sources, independent current sources, dependent
> voltage source, dependent current source, resistors, capacitors, and
> inductors).
>
> The main problem which faced me was the math behind the code. I needed to
> solve a system of equations in more than 3 variables and the equations
> contain complex numbers and the results also were complex but the "math.h"
> and "complex.h" were very poor and useless to my project.
>
> So, it's a great chance for me to participate in a project will improve
> that libraries to help other people who need it to have a better experiment
> in using them.
>
> I am very excited about participating with you in the project "  Add new
> math.h and complex.h functions as built-ins". I studied 2 courses in
> programming the first was about the basics of C++ and the second was about
> Object-Oriented Programming using C++. Currently, I'm studying the third
> course about "Data Structures and Algorithms" also using C++ but recently I
> started to learn Python from an MIT course and "Data Structures and
> Algorithms" specialization in Coursera. Participating in that will be a
> very good step in my career closer to my goal.
>
> I also studied some courses in mathematics such that three courses in
> Calculus, in different areas like "Differential Calculus", "Integral
> Calculus", "Differential Equations" and " Partial Derivatives and Laplace".
> Currently, I am studying a course on "Discrete Mathematics" and " Discrete
> Mathematics" specialization in Coursera.
>
> I am also training on problem-solving skills constantly from online judges
> such that Codeforces.
>
> So, is this enough to have a chance in your project? and how I can improve
> my self to be qualified to participate with you before the application
> deadline?
>
> GitHub Account 
>

Re: Does gcc automatically lower optimization level for very large routines?

[Dmitry Mikushin]

This issue is well-known in research/scientific software. The problem of
compiler hang or RAM overconsumption is actually not about the routine
size, but about too complicated control flow. When optimizing, the compiler
traverses the control flow graph, which may have the misfortune to explode
in terms of complexity. So you may want to check whether your routine
heavily deploys nested cascades of "if ... else" or goto-s. That is, the
routine size is not a good metric to catch this behavior. GCC may rather
attempt "reversible" strategy of optimizations to stop and undo those that
get beyond a certain threshold.

Kind regards,
- Dmitry.


чт, 19 дек. 2019 г. в 17:38, Qing Zhao :

> Hi,
>
> When using GCC to compile a very large routine with -O2, it failed with
> out of memory during run time.  (O1 is Okay)
>
> As I checked within gdb,  when “cc1” was consuming around 95% of the
> memory,  it’s at :
>
> (gdb) where
> #0  0x00ddbcb3 in df_chain_create (src=0x631006480f08,
> dst=0x63100f306288) at ../../gcc-8.2.1-20180905/gcc/df-problems.c:2267
> #1  0x001a in df_chain_create_bb_process_use (
> local_rd=0x7ffc109bfaf0, use=0x63100f306288, top_flag=0)
> at ../../gcc-8.2.1-20180905/gcc/df-problems.c:2441
> #2  0x00dde5a7 in df_chain_create_bb (bb_index=16413)
> at ../../gcc-8.2.1-20180905/gcc/df-problems.c:2490
> #3  0x00ddeaa9 in df_chain_finalize (all_blocks=0x63100097ac28)
> at ../../gcc-8.2.1-20180905/gcc/df-problems.c:2519
> #4  0x00dbe95e in df_analyze_problem (dflow=0x60600027f740,
> blocks_to_consider=0x63100097ac28, postorder=0x7f23761f1800,
> n_blocks=40768) at ../../gcc-8.2.1-20180905/gcc/df-core.c:1179
> #5  0x00dbedac in df_analyze_1 ()
> ….
>
> The routine that was compiled is very big, has about 119258 lines of code.
> I suspected that GCC’s data flow analysis might not handle very large
> routine very well, consume too much memory, therefore out of memory for
> very big routines.
>
> Currently, I found one GCC’s source level pragma,
>
> #pragma GCC optimize ("O1”)
>
> And added it before the large routine (also added another one #pragma GCC
> reset_options after the routine), this workaround the out of memory issue
> for now.
>
> However, manually locating large routines is time consuming, I am
> wondering whether GCC can automatically detect large routines and lower the
> optimization for those
> Routines automatically? Or is there any internal parameters inside GCC’s
> data flow analysis that compute the complexity of the routine, if it’s very
> big, then will turn off
> The aggressive analysis automatically?  Or any option provided to end user
> to control the aggressive data flow manually ?
>
>
> Thanks a lot for any help.
>
> Qing

Re: Does gcc automatically lower optimization level for very large routines?

[Dmitry Mikushin]

Trying to plan memory consumption ahead-of-work contradicts with the nature
of the graph traversal. Estimation may work very well for something simple
like linear or log-linear behavior. But many compiler algorithms are known
to be polynomial or exponential (or even worse in case of bugs). So,
estimation is a nice step ahead, but only fallback & recover can ultimately
solve the problem.

пт, 20 дек. 2019 г. в 02:32, David Edelsohn :

> On Thu, Dec 19, 2019 at 7:41 PM Jeff Law  wrote:
> >
> > On Thu, 2019-12-19 at 17:06 -0600, Qing Zhao wrote:
> > > Hi, Dmitry,
> > >
> > > Thanks for the responds.
> > >
> > > Yes, routine size only cannot determine the complexity of the routine.
> Different compiler analysis might have different formula with multiple
> parameters to compute its complexity.
> > >
> > > However, the common issue is: when the complexity of a specific
> routine for a specific compiler analysis exceeds a threshold, the compiler
> might consume all the available memory and abort the compilation.
> > >
> > > Therefore,  in order to avoid the failed compilation due to out of
> memory, some compilers might set a threshold for the complexity of a
> specific compiler analysis (for example, the more aggressive data flow
> analysis), when the threshold is met, the specific aggressive analysis will
> be turned off for this specific routine. Or the optimization level will be
> lowered for the specific routine (and given a warning during compilation
> time for such adjustment).
> > >
> > > I am wondering whether GCC has such capability? Or any option provided
> to increase or decrease the threshold for some of the common analysis (for
> example, data flow)?
> > >
> > There are various places where if we hit a limit, then we throttle
> > optimization.  But it's not done consistently or pervasively.
> >
> > Those limits are typically around things like CFG complexity.
> >
> > We do _not_ try to recover after an out of memory error, or anything
> > like that.
>
> I have mentioned a few times before that IBM XL Compiler allows the
> user to specify the maximum memory utilization for the compiler
> (including "unlimmited").  The compiler optimization passes estimate
> the memory usage for the data structures of each optimization pass.
> The the memory usage is too high, the pass attempts to sub-divide the
> region and calculates the estimated memory usage again, recursing
> until it can apply the optimization within the memory limit or the
> optimization would not be effective.  IBM XL Compiler does not try to
> recover from an out of memory error, but it explicitly considers
> memory use of optimization passes.  It does not adjust the complexity
> of the optimization, but it does adjust the size of the region or
> other parameters to reduce the memory usage of the data structures for
> an optimization.
>
> Thanks, David
>

Re: Does gcc automatically lower optimization level for very large routines?

[Dmitry Mikushin]

Yes, much more. When you traverse a CFG, the analysis develops into a tree
(for example a tree of uses). That is, every basic block could be
*recursively* a root of an individual linear iteration for up to all basic
blocks. Sum them up, and you will get a polynomial expression. I don't
insist that this is the best way, but often the way it is.

пт, 20 дек. 2019 г. в 23:52, Segher Boessenkool :

> On Fri, Dec 20, 2019 at 02:57:57AM +0100, Dmitry Mikushin wrote:
> > Trying to plan memory consumption ahead-of-work contradicts with the
> nature
> > of the graph traversal. Estimation may work very well for something
> simple
> > like linear or log-linear behavior.
>
> Almost everything we do is (almost) linear.
>
> > But many compiler algorithms are known
> > to be polynomial or exponential
>
> Many?  There are a few (register allocation is a well-known example),
> but anything more than almost linear is quite easy to make blow up.  It
> is also not super hard in most cases to make things linear, it just
> needs careful attention.
>
> > (or even worse in case of bugs).
>
> Well, sure, if there is a bug *anything* can go wrong ;-)
>
>
> Segher
>

Re: How to get GCC on par with ICC?

[Dmitry Mikushin]

Dear Paul,

The opinion you've mentioned is common in scientific community. However, in
more detail it often surfaces that the used set of GCC compiler options
simply does not correspond to that "fast" version of Intel. For instance,
when you do "-O3" for Intel it actually corresponds to (at least) "-O3
-ffast-math -march=native" of GCC. Omitting "-ffast-math" obviously
introduces significant performance gap.

Kind regards,
- Dmitry Mikushin | Applied Parallel Computing LLC |
https://parallel-computing.pro


2018-06-06 18:51 GMT+03:00 Paul Menzel :

> Dear GCC folks,
>
>
> Some scientists in our organization still want to use the Intel compiler,
> as they say, it produces faster code, which is then executed on clusters.
> Some resources on the Web [1][2] confirm this. (I am aware, that it’s
> heavily dependent on the actual program.)
>
> My question is, is it realistic, that GCC could catch up and that the
> scientists will start to use it over Intel’s compiler? Or will Intel
> developers always have the lead, because they have secret documentation and
> direct contact with the processor designers?
>
> If it is realistic, how can we get there? Would first the program be
> written, and then the compiler be optimized for that? Or are just more GCC
> developers needed?
>
>
> Kind regards,
>
> Paul
>
>
> [1]: https://colfaxresearch.com/compiler-comparison/
> [2]: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.679
> .1280&rep=rep1&type=pdf
>
>

Re: Plan for removing global state from GCC's internals

[Dmitry Mikushin]

FWIW, we also needed to perform multiple invocations of toplev_main from
a single execution of GCC frontend, which seems to be quite similar. The
dirty dirty hack is to save the backup the content of .data and .bss
symbols with ELF API before the first call to toplev_main and reset them
to backup values before each subsequent call. And it works. Would be
great to get rid of global state in a better way, maybe our approach
could be useful for transition period.

- D.

On 06/26/2013 02:46 PM, David Malcolm wrote:
> I've been looking at removing global state from GCC with a view to
> making it be usable as a shared library.
> 
> I've been posting various patches relating to this, but I thought it was
> time to post a comprehensive plan so you can see how I think it all
> ought to fit together.
> 
> You can see an HTML version of my proposal at:
>   http://dmalcolm.fedorapeople.org/gcc/global-state/
> 
> and the source for the doc can be seen at:
>   https://github.com/davidmalcolm/gcc-global-state/
> (restructured text, using the Sphinx toolchain).
> 
> I've gone through all of GCC's passes, identifying internal state, and
> also looked at the most-frequently used global variables in GCC.  You
> can see detailed notes on these in the appendices.
> 
> It's still a work-in-progress - there are still quite a few TODOs in
> there, but it seemed time to post to this list.
> 
> A single-paragraph summary is that I want to move global variables and
> functions into classes: these classes will be "singletons" in the normal
> build, and will have multiple instances in a shared library build,
> allowing for multiple "parallel universes" of state within one GCC
> process.  There are various tricks to (a) maintain the performance of
> the standard "monolithic binaries" use case and (b) minimize the
> patching and backporting pain relative to older GCC source trees.  In
> particular, it introduces a new compiler attribute "force_static" which
> gets used in stages 2 and 3 of the bootstrap to eliminate "this" from
> methods of the various singleton classes.
> 
> I hope the plan seems reasonable to the core GCC maintainers, and I'm
> keen to get moving on this for GCC 4.9.   However I appreciate that I'm
> a relative newcomer to GCC development (albeit the author/maintainer of
> the gcc python plugin, for the last 2 years).
> 
> There are various questions e.g. what can go into trunk vs a branch?
> various naming decisions etc.
> 
> The "trunk vs branch" question is the one I'm most keen to resolve.  In
> particular, I'm aware that Andrew MacLeod recently posted another
> architectural proposal:
>   http://gcc.gnu.org/ml/gcc/2013-06/msg00163.html
> AIUI his proposal and mine are mostly orthogonal to each other: his
> makes changes to the insides to "tree", whereas mine bundles up global
> variables and functions into classes.  Both proposals involve touching a
> lot of code but both can largely be done incrementally, and, I hope
> independently of each other - but I want to avoid painful branch
> mergers, of course.
> 
> BTW, I will be at the GNU Tools Cauldron next month.
> 
> Thoughts?
> Dave
> 

Re: Plan for removing global state from GCC's internals

[Dmitry Mikushin]

Yes, generation of both binary code and LLVM IR in a single GCC
invocation. So, first toplev_main goes as usual, and another one - with
DragonEgg plugin enabled. LLVM IR ends up as GPU kernels code a bit later.

Yes, that is the right patch.

Of course, not thread-safe, not generally portable and very fragile.
That's why I'm saying "FWIW", meaning it might be useful for some
internal transitioning during your very useful effort.

- D.

On 06/26/2013 03:54 PM, David Malcolm wrote:
> On Wed, 2013-06-26 at 15:19 -0400, Dmitry Mikushin wrote:
>> FWIW, we also needed to perform multiple invocations of toplev_main from
>> a single execution of GCC frontend, which seems to be quite similar. 
> 
> Interesting.  Yes, this sounds very similar to the kinds of use-cases
> I'm considering.  Am I right in thinking you're using GCC (and LLVM) to
> target GPUs?
> 
>> The
>> dirty dirty hack is to save the backup the content of .data and .bss
>> symbols with ELF API before the first call to toplev_main and reset them
>> to backup values before each subsequent call. And it works. 
> 
> Thanks.  I went looking for your code; for reference, is this what
> you're referring to?
> https://hpcforge.org/scm/viewvc.php/trunk/patches/gcc.patch?revision=1918&root=kernelgen&view=markup
> (i.e. the changes to "main"?)
> 
>> Would be
>> great to get rid of global state in a better way, maybe our approach
>> could be useful for transition period.
> 
> The "backup of .data and .bss" approach allows for repeated calls to
> toplev_main, but it doesn't allow for multiple threads to be running
> simultaneously within one process.
> 
> As you say, it's a "dirty dirty hack" - I'm glad it works for you, but
> it seems very fragile: e.g. what happens about GCC plugins and other
> DSOs linked into the process: presumably they also have state, which
> isn't going to get handled if you're only blowing away the state of the
> main executable.
> 
> I'm interested in cleaning this up "properly"... for some definition of
> that word, of course!
> 
> 
> 
>> - D.
>>
>> On 06/26/2013 02:46 PM, David Malcolm wrote:
>>> I've been looking at removing global state from GCC with a view to
>>> making it be usable as a shared library.
>>>
>>> I've been posting various patches relating to this, but I thought it was
>>> time to post a comprehensive plan so you can see how I think it all
>>> ought to fit together.
>>>
>>> You can see an HTML version of my proposal at:
>>>   http://dmalcolm.fedorapeople.org/gcc/global-state/
>>>
>>> and the source for the doc can be seen at:
>>>   https://github.com/davidmalcolm/gcc-global-state/
>>> (restructured text, using the Sphinx toolchain).
>>>
>>> I've gone through all of GCC's passes, identifying internal state, and
>>> also looked at the most-frequently used global variables in GCC.  You
>>> can see detailed notes on these in the appendices.
>>>
>>> It's still a work-in-progress - there are still quite a few TODOs in
>>> there, but it seemed time to post to this list.
>>>
>>> A single-paragraph summary is that I want to move global variables and
>>> functions into classes: these classes will be "singletons" in the normal
>>> build, and will have multiple instances in a shared library build,
>>> allowing for multiple "parallel universes" of state within one GCC
>>> process.  There are various tricks to (a) maintain the performance of
>>> the standard "monolithic binaries" use case and (b) minimize the
>>> patching and backporting pain relative to older GCC source trees.  In
>>> particular, it introduces a new compiler attribute "force_static" which
>>> gets used in stages 2 and 3 of the bootstrap to eliminate "this" from
>>> methods of the various singleton classes.
>>>
>>> I hope the plan seems reasonable to the core GCC maintainers, and I'm
>>> keen to get moving on this for GCC 4.9.   However I appreciate that I'm
>>> a relative newcomer to GCC development (albeit the author/maintainer of
>>> the gcc python plugin, for the last 2 years).
>>>
>>> There are various questions e.g. what can go into trunk vs a branch?
>>> various naming decisions etc.
>>>
>>> The "trunk vs branch" question is the one I'm most keen to resolve.  In
>>> particular, I'm aware that Andrew MacLeod recently posted another
>>> architectural proposal:
>>>   http://gcc.gnu.org/ml/gcc/2013-06/msg00163.html
>>> AIUI his proposal and mine are mostly orthogonal to each other: his
>>> makes changes to the insides to "tree", whereas mine bundles up global
>>> variables and functions into classes.  Both proposals involve touching a
>>> lot of code but both can largely be done incrementally, and, I hope
>>> independently of each other - but I want to avoid painful branch
>>> mergers, of course.
>>>
>>> BTW, I will be at the GNU Tools Cauldron next month.
>>>
>>> Thoughts?
>>> Dave
>>>
>>
> 
> 

Error: no such instruction: `eovq -32(%rbp),%rdx'

[Dmitry Mikushin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear all,

With gcc-4.7-20130629 and binutils-2.23.2 I'm getting

Error: no such instruction: `eovq -32(%rbp),%rdx'

There was no such issue with May' gcc snapshot and binutils-2.22. Is it
a binutils-specific problem? Which version of binutils is known to work
well with gcc-4.7-20130629 ?

Thanks,
- - D.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJR1JpTAAoJENwm3+sbf/pMvYoH/2/eao48G2782OaR3654uvJU
xdFODidyTMFQXDIF3KXqYFl1AplPN5q95Te71RiAuuqyZLcIjPP3QzrYprgqmtaW
RaOLYZ+qHjBlaBK7R8nsERZEGw+C2wcafHah9SFYTTJJWRl2kdita+z/KytlGPlc
qhpv64sT0nSeQxDzLca2bzEmveIYfXM/FdPC9GD8tH5tMKeKawwaqN4pnKR9Y9DM
9LyRKWW/CcjisJrrks2UotrlcMuyfw92VWYEj4G80ildDA3ISLfgeX3z3z9lK688
ugmJxKxghuzr988MILPXzqsFI5+0OF3OVqg+7Mc5Rl6A9HnRFj16fj+c+OtAJB4=
=fivA
-END PGP SIGNATURE-

Re: Error: no such instruction: `eovq -32(%rbp),%rdx'

[Dmitry Mikushin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Anthony, H.J. Lu,

Thanks, it was indeed a memory corruption. Not DIMM, but simply an
effect of the patch I made. The origin of the problem is not very
clear though:

- --- a/gcc-snapshot/lto-plugin/lto-plugin.c  2015-10-02
01:59:07.0 +0400
+++ b/gcc-snapshot/lto-plugin/lto-plugin.c  2015-10-02
02:09:17.0 +0400
@@ -591,7 +591,7 @@
 all_symbols_read_handler (void)
 {
   unsigned i;
- -  unsigned num_lto_args = num_claimed_files + lto_wrapper_num_args + 1;
+  unsigned num_lto_args = num_claimed_files + 2;
   char **lto_argv;
   const char **lto_arg_ptr;
   if (num_claimed_files == 0)
@@ -611,8 +611,8 @@

   free_1 ();

- -  for (i = 0; i < lto_wrapper_num_args; i++)
- -*lto_arg_ptr++ = lto_wrapper_argv[i];
+  if (lto_wrapper_num_args > 0)
+*lto_arg_ptr++ = lto_wrapper_argv[0];

   for (i = 0; i < num_claimed_files; i++)
 {

GCC compiled with this change is used to recompile GCC itself. LTO is
not used, so I did not expect any problem. However, GCC built with
this change randomly segfaults or corrupts the output assembly files.

- - D.

On 07/04/2013 06:31 AM, Anthony Foiani wrote:
> Dmitry Mikushin  writes:
> 
>> Error: no such instruction: `eovq -32(%rbp),%rdx'
> 
> That's only a one-bit error away from "movq ..."
> 
> ('m' = 0x6d = 0b 0110 1101, 'e' = 0x65 = 0b 0110 0101)
> 
> Maybe run memory tester overnight?
> 
> (This is from personal experience -- I had a bad stick of RAM that 
> caused all sorts of bizarre compile problems.  I eventually
> isolated the problem and replaced the DIMM; the compile problems
> went away.)
> 
> Good luck!
> 
> Best regards, Anthony Foiani
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJR4WXeAAoJENwm3+sbf/pMdb8H/2jpjaR3CtNb2vC2RB2oMM8p
f3QeNdCCrmWqOMto/OnF8idt84NaAupYaQYiI1L9mGIg7RLjewG0fjCAET/kPUVj
33yZACXFxPFY2i3Uha8ThUf/N0RGCDrysNarioobGcZ8ROmGemhsVHemgBFn4DkB
khZmDO395GpdjZaN0UhBtzIOk+O+aT4ltiQdabrH7VP41C1O04KMtRcSTSQHU41d
t+4znSP9rqqOQwITJOM7zajSmApsdLXo2WpC7MDMcRTR5aLKcS8Ya8MdVPLf/j4k
ee1n/p8sXs3puzYKmYsWyayGqLe6AuVLEiqbN7/njlwfp0khnXgWXT+WhHbGqYw=
=5izP
-END PGP SIGNATURE-

unrecognized command line option '-mlong-double-80' '-fbuilding-libgcc'

[Dmitry Mikushin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear all,

I'm trying to build a GCC toolchain (4.8-20130912 snapshot) targeting
x86-64 multiarch on i686 host, using x86-64 builder:

+ cd
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912
+ mkdir build
+ cd build/
+ CC=gcc -m32  CXX=g++ -m32  FC=gfortran -m32  F77=gfortran -m32
../configure --enable-build-with-cxx
-
--prefix=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/
- --program-prefix=kernelgen- --enable-languages=fortran,c++
-
--with-mpfr-include=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include/
-
--with-mpfr-lib=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/lib
-
--with-gmp-include=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include/
-
--with-gmp-lib=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/lib
-
--with-mpc-include=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include/
-
--with-mpc-lib=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/lib
- --enable-plugin --enable-gold=default --disable-ld
-
--with-ld=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/bin/kernelgen-ld
- --disable-multilib
-
--libdir=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/lib
- --build=x86_64-linux-gnu --host=i686-linux-gnu --target=x86_64-linux-gnu

+ cd
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build
+ CC=gcc -m32  CXX=g++ -m32  FC=gfortran -m32  F77=gfortran -m32
CPLUS_INCLUDE_PATH=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include:/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include/libelf
KERNELGEN_FALLBACK=1 make -j24 CFLAGS=-g -O0 CXXFLAGS=-g -O0

The build fails with

cc   -g -O2 -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE
- -DNATIVE_CROSS  -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
- -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
- -isystem ./include   -fpic -mlong-double-80 -g -DIN_LIBGCC2
- -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -fpic
- -mlong-double-80 -I. -I. -I../.././gcc -I../../../libgcc
- -I../../../libgcc/. -I../../../libgcc/../gcc
- -I../../../libgcc/../include -I../../../libgcc/config/libbid
- -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -o morestack_s.o
- -MT morestack_s.o -MD -MP -MF morestack_s.dep -DSHARED -c
- -xassembler-with-cpp ../../../libgcc/config/i386/morestack.S
sed -e 's/__PFX__/__/g' \
-e 's/__FIXPTPFX__/__/g' <
../../../libgcc/libgcc-std.ver.in > libgcc-std.ver
dest=../.././gcc/include/tmp$$-unwind.h; \
cp unwind.h $dest; \
chmod a+r $dest; \
sh ../../../libgcc/../move-if-change $dest
../.././gcc/include/unwind.h
echo timestamp > libgcc_tm.stamp
cc1: error: unrecognized command line option '-mlong-double-80'
cc1: error: unrecognized command line option '-mlong-double-80'
cc1: error: unrecognized command line option '-fbuilding-libgcc'
cc1: warning: unrecognized command line option "-Wno-narrowing"
[enabled by default]

What's wrong here?

Thanks,
- - D.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJSZLXLAAoJENwm3+sbf/pMzdYH/1uBnqjXJ5Sb+HZTtgXq/9rD
B0ydUay2By51yFNgs4+fHlRlUpXjDiXq4o3DQ9YurSaGLhPa7z50nj+eF8Mq5rx1
Lr7SLOjApha0oKR8Qst4l+x3oKxdFYPbrwmVdXXq9C0LjUNpjhGpsBMxtcf5ZzW1
Yq8wtgp1zhMs79zqrqcc301E6nmugGS0pZAclYIPjoW7hzgndJiDVB93lJbLjKik
vsza4XEj1iNoqMvxlB58oaucFisixpCoWoU1ExMsVO5NzAlwpr/sP1cHle3eStUz
IDmBoeyt4VdgS5eCJBF+QQkEWD88Dd2K7buFT9BMwcuRXWhM47mgbfBsdGoEe5U=
=3ycd
-END PGP SIGNATURE-

Re: unrecognized command line option '-mlong-double-80' '-fbuilding-libgcc'

[Dmitry Mikushin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ian,

I'm NOT using --build/--host/--target:

+ CC=gcc -m32  CXX=g++ -m32  FC=gfortran -m32  F77=gfortran -m32
../configure --enable-build-with-cxx
-
--prefix=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/
- --program-prefix=kernelgen- --enable-languages=fortran,c++
-
--with-mpfr-include=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include/
-
--with-mpfr-lib=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/lib
-
--with-gmp-include=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include/
-
--with-gmp-lib=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/lib
-
--with-mpc-include=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include/
-
--with-mpc-lib=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/lib
- --enable-plugin --enable-gold=default --disable-ld
-
--with-ld=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/bin/kernelgen-ld
- --disable-multilib
-
--libdir=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/lib

But I get:

checking dynamic linker characteristics... configure: error: Link
tests are not allowed after GCC_NO_EXECUTABLES.

Or actually even earlier than that there is

configure:2934: checking for C compiler default output file name
configure:2956:
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/xgcc
-
-B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/
-
-B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/x86_64-unknown-linux-gnu/bin/
-
-B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/x86_64-unknown-linux-gnu/bin/
-
-B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/x86_64-unknown-linux-gnu/lib/
- -isystem
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/x86_64-unknown-linux-gnu/include
- -isystem
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/x86_64-unknown-linux-gnu/sys-include
   -m32 -gtoggle  -static-libstdc++ -static-libgcc  conftest.c  >&5
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/bin/kernelgen-ld:
error:
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/crtbegin.o:
incompatible target
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/bin/kernelgen-ld:
error:
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/crtend.o:
incompatible target
collect2: error: ld returned 1 exit status

So, crtbegin.o/crtend.o are still ELF64.

On 10/24/2013 07:07 AM, Ian Lance Taylor wrote:
> On Wed, Oct 23, 2013 at 9:59 PM, Dmitry Mikushin
>  wrote:
>> Still all sorts of problems:
>> 
>> with BOOT_CFLAGS="-m32" and CFLAGS_FOR_TARGET="-m32" I get a
>> number of compilation errors e.g. "error: unknown type name
>> 'UTItype'" with BOOT_CFLAGS="-m32" only I get "configure: error:
>> Link tests are not allowed after GCC_NO_EXECUTABLES."
> 
> 
> Should have said this last time: please reply to the mailing list,
> not just to me.  Thanks.
> 
> I would not expect to see the "Link tests" error unless you are
> still using the --build/--host/--target configure arguments.  I
> was suggesting that you omit those.
> 
> Ian
> 
>> 2013/10/24 Ian Lance Taylor 
>>> 
>>> 
>>> On Oct 23, 2013 8:27 PM, "Dmitry Mikushin"
>>>  wrote:
>>>> 
>>>> Dear Ian,
>>>> 
>>>> I started exactly with adding -m32 options as you mentioned,
>>>> but in this case the resulting toolchain executables are
>>>> ELF64.
>>> 
>>> You'll probably also have to set BOOT_CFLAGS or something like
>>> that--see the install instructions.
>>> 
>>> Ian
>>> 
>>>> 2013/10/21 Ian Lance Taylor 
>>>>> 
>>>>> On Sun, Oct 20, 2013 at 10:04 PM, Dmitry Mikushin 
>>>>>  wrote:
>>>>>> 
>>>>>> I'

Re: unrecognized command line option '-mlong-double-80' '-fbuilding-libgcc'

[Dmitry Mikushin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OK, it's getting better with --enable-multilib, BOOT_CFLAGS="-m32" and
XGCC_FLAGS_FOR_TARGET="-m32". But the internal xg++ still tries to
pick up 64-bit libraries (see below). The question is how to make him
switch to the */32/* multilib libraries path.

$
/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/xg++
-
-B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/
-
-B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/x86_64-unknown-linux-gnu/bin/
- -nostdinc++
-
-B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-
-B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-
-I/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-
-I/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-
-I/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/libstdc++-v3/libsupc++
-
-L/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-
-L/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
  -m32 -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti
- -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
- -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
- -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
- -static-libstdc++ -static-libgcc  -o gfortran gcc.o ggc-none.o
gfortranspec.o driver-i386.o  libcommon-target.a libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
../../gcc/vec.h:1303: error: undefined reference to 'operator
new(unsigned int)'
collect2: error: ld returned 1 exit status

On 10/24/2013 07:51 AM, Dmitry Mikushin wrote:
> Ian,
> 
> I'm NOT using --build/--host/--target:
> 
> + CC=gcc -m32  CXX=g++ -m32  FC=gfortran -m32  F77=gfortran -m32 
> ../configure --enable-build-with-cxx - 
> --prefix=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/
>
> 
- --program-prefix=kernelgen- --enable-languages=fortran,c++
> - 
> --with-mpfr-include=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include/
>
> 
- -
> --with-mpfr-lib=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/lib
>
> 
- -
> --with-gmp-include=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include/
>
> 
- -
> --with-gmp-lib=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/lib
>
> 
- -
> --with-mpc-include=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/include/
>
> 
- -
> --with-mpc-lib=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/lib
>
> 
- --enable-plugin --enable-gold=default --disable-ld
> - 
> --with-ld=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/INSTALL/bin/kernelgen-ld
>
> 
- --disable-multilib
> - 
> --libdir=/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/lib
>
>  But I get:
> 
> checking dynamic linker characteristics... configure: error: Link 
> tests are not allowed after GCC_NO_EXECUTABLES.
> 
> Or actually even earlier than that there is
> 
> configure:2934: checking for C compiler default output file name 
> configure:2956: 
> /home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/xgcc
>
> 
- -
> -B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILD/gcc-4.8-20130912/build/./prev-gcc/
>
> 
- -
> -B/home/marcusmae/rpmbuild/kernelgen/head_llvm192445_i686-linux-gnu_x86_64-linux-gnu_debug/BUILDROOT/x86_64-unknown-linux-gnu/bin/
>
> 
- -
> -B/home/marcus

Re: OpenACC in GCC - how does it not violate the license?

[Dmitry Mikushin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Alec,

> Nvidia (IIRC, this was like a year ago though) don't even give out
the instruction set for their GPUs

I understand you don't want to bound to PTX virtual assembler, as it
conversion to GPU native assembler relies on proprietary component. We
too.

According to our experince [1], complete decoding of NVIDIA ISA could
be performed in reasonable time using NVIDIA's disassembler,
automation tools and some binary-level hooking. Same things should be
done at Pathscale and Nouveau. If disassembler will also be provided
for Maxwell, then OpenACC implementation would have enough to support
native ISAs of all known GPU families from 2008 to 2014.

GPU driver/runtime is more trickier, but there is Gdev project [2]

[1]
http://hpcforge.org/scm/viewvc.php/*checkout*/doc/opennvisa/opennvisa.pdf?root=kernelgen
[2] https://github.com/shinpei0208/gdev

- - D.

On 11/17/2013 05:58 AM, Alec Teal wrote:
> Hey all,
> 
> I got linked this by a friend today: 
> http://www.mentor.com/embedded-software/blog/post/we-are-bringing-openacc-to-the-gnu-compiler-suite--8d06289f-c4e9-44c8-801b-7a11496e7300
>
> 
> 
> It seems to suggest that GCC can target Nvidia GPUs To quote:
>> or OpenACC 2.0 in GCC, , and generating assembly level
>> instructions for an NVIDIA GPU. Let’s not underestimate the
>> effort involved, which includes teaching GCC how to parse OpenACC
>> directives, how to translate the directives into appropriate
>> blocks of code and data migration, and how to generate
>> instructions for the target device itself.
> Now while great, is this true!? Nvidia (IIRC, this was like a year
> ago though) don't even give out the instruction set for their GPUs,
> can we have GCC targeting closed things? Also there (must be and
> is) a Cuda runtime, wouldn't we need an open runtime to link
> against?
> 
> To quote again:
>> Duncan Poole is responsible for strategic partnerships for
>> NVIDIA’s Accelerated Computing Division. His responsibilities
>> reach across the developer tool chain
> (the stuff after that quote is just guff)
> 
> This is by no means an accusation, I'm sure he's doing fine work;
> but he's doing something I didn't think the GPLv3 allowed (so I
> want to be corrected) he seems to have added something that
> requires a closed runtime for a target with a closed instruction
> set - probably for Nvidia (as he is responsible for "strategic
> partnerships" with them)
> 
> I do try and live my life entirely within free software, it means
> I never have to care about these things. Sorry for my ignorance.
> 
> Also a search for OpenACC produced very little.
> 
> Alec
> 
> 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJSiFSoAAoJENwm3+sbf/pMZHoH+wZjlFIo8U+jbAtPj5enuo4F
bFOBm/oJAikbB5UkHapG8UDwnpdnkaD7yba6Si4bT7SI/mtUQVMjctL3rmSur8r7
qIikj/S0R/DUj9RBq2li6w+SEYIN4nu/fqIbNNrj8KonR1ROeLwuiv3F1MQsOyZ/
e/kW0mN/0PioX1kB0jwvPFwxjDQPhHmHY1LZvdU1ZaQoCwSlujO+efJQ9ass8T8a
Z6SmFlKKdlT8JotnWrdTBOV2wVsRVyc8hER3z8izbE81DFOE+RwAjuZHsJLxwF/1
esmwKQgoOv7Lu3p+dH7i6jgEh+FzmI5wCPJ51SupFGH+6r3VAKNGmGxcpK4wODM=
=1lgD
-END PGP SIGNATURE-

How to write an array var into .s file without null-terminator

[Dmitry Mikushin]

Dear All,

We are trying to embed a raw vector of chars into .s file using the 
following code:


tree index_type = build_index_type(size_int(moduleBitcode.size()));
tree const_char_type = build_qualified_type(
unsigned_char_type_node, TYPE_QUAL_CONST);
tree string_type = build_array_type(const_char_type, index_type);
string_type = build_variant_type_copy(string_type);
tree string_val = build_string(moduleBitcode.size(), 
moduleBitcode.data());

TREE_TYPE(string_val) = string_type;

tree var = create_tmp_var_raw(string_type, NULL);
char* tmpname = tmpnam(NULL) + strlen(P_tmpdir);
if (*tmpname == '/') tmpname++;
DECL_NAME (var) = get_identifier (tmpname);
DECL_SECTION_NAME (var) = build_string (11, ".kernelgen");
TREE_PUBLIC (var) = 1;
TREE_STATIC (var) = 1;
TREE_READONLY (var) = 1;
DECL_INITIAL (var) = string_val;
varpool_finalize_decl (var);

The problem is that build_string always null-terminates our data array, 
which is unexpected. I tried to clone build_string and modify it in such 
way that it does not add '\0' in the end. But even in this case the 
output object size is moduleBitcode.size() + 1. Why? How to change this 
code to write the data exactly as it is - without null-terminator?


Many thanks,
- Dima.

How to write an array var into .s file without null-terminator

[Dmitry Mikushin]

Dear All,

We are trying to embed a raw vector of chars into .s file using the 
following code:


tree index_type = build_index_type(size_int(moduleBitcode.size()));
tree const_char_type = build_qualified_type(
unsigned_char_type_node, TYPE_QUAL_CONST);
tree string_type = build_array_type(const_char_type, index_type);
string_type = build_variant_type_copy(string_type);
tree string_val = build_string(moduleBitcode.size(), 
moduleBitcode.data());

TREE_TYPE(string_val) = string_type;

tree var = create_tmp_var_raw(string_type, NULL);
char* tmpname = tmpnam(NULL) + strlen(P_tmpdir);
if (*tmpname == '/') tmpname++;
DECL_NAME (var) = get_identifier (tmpname);
DECL_SECTION_NAME (var) = build_string (11, ".kernelgen");
TREE_PUBLIC (var) = 1;
TREE_STATIC (var) = 1;
TREE_READONLY (var) = 1;
DECL_INITIAL (var) = string_val;
varpool_finalize_decl (var);

The problem is that build_string always null-terminates our data array, 
which is unexpected. I tried to clone build_string and modify it in such 
way that it does not add '\0' in the end. But even in this case the 
output object size is moduleBitcode.size() + 1. Why? How to change this 
code to write the data exactly as it is - without null-terminator?


Many thanks,
- Dima.

Primary and secondary sysroot?

[Dmitry Mikushin]

Deal all,

We have a version of GCC coming as additional toolchain for several 
supported Linux distros. Moreover, package we are shipping also contains 
modified glibc and some other libraries. In this situation, applications 
built with this compiler should first logically use its own sysroot, but 
in case when a header/library from host's sysroot is needed - fallback 
to the default "/usr" sysroot. I think this could be accomplished by 
providing two sysroots - one primary, and secondary - to complement it 
for the rest of things. Looks like currently gcc only supports a single 
setting for TARGET_SYSTEM_ROOT. Do you see any other options regarding 
this issue?


Thanks,
- Dima.

Re: Primary and secondary sysroot?

[Dmitry Mikushin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Ian,

Thanks for reply, unfortunately setting extra flags does not help in
our case, as we want to conserve original build rules for any application.

A brilliant solution suggested by Richard Guenther on IRC is to place
first-priority includes and headers into
lib/gcc/x86_64-unknown-linux-gnu/4.6.4/ (or also in 32/, if multilib).
Then, this content would have higher priority than system
include/library paths. Thus, lib/gcc/x86_64-unknown-linux-gnu/4.6.4/
becomes primary root and system becomes secondary root!

- - D.

On 01/08/2013 08:37 AM, Ian Lance Taylor wrote:
> On Mon, Jan 7, 2013 at 2:47 AM, Dmitry Mikushin
>  wrote:
>> 
>> We have a version of GCC coming as additional toolchain for
>> several supported Linux distros. Moreover, package we are
>> shipping also contains modified glibc and some other libraries.
>> In this situation, applications built with this compiler should
>> first logically use its own sysroot, but in case when a
>> header/library from host's sysroot is needed - fallback to the 
>> default "/usr" sysroot. I think this could be accomplished by
>> providing two sysroots - one primary, and secondary - to
>> complement it for the rest of things. Looks like currently gcc
>> only supports a single setting for TARGET_SYSTEM_ROOT. Do you see
>> any other options regarding this issue?
> 
> You are correct: GCC only supports a single system root.  But I
> think you can do what you want with appropriate -I and -L options,
> perhaps via the C_INCLUDE_PATH and LIBRARY_PATH environment
> variables.
> 
> Ian
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ+DHgAAoJENwm3+sbf/pMYPkH/3EDJ/1j7nbbUMGHKPwfMLzx
1Xg0fP0NaY3eSfSdQk/zQ9ivYCothC9u6lyPeCbiGBus0TR0C1ra/aPMKwqwkJpJ
FeuTExQxtqB/xxD1xmdOFNY023mivkoVZoZ4HYdHa2Xe6Uk+Pg/3MWzVaq+ePUgM
IILUaUz7iVf7rg/8gIy1U11vXBH2br9cbogXpuQv6L7UqlZsPmo3FhXbdWxeXn+3
+ZnhERwY4fKxABGE4gcYDwUCysjQymo8a/AsV5cQsnesLxDV/6svAElBV2MJkf7z
HKDrZuEJt9BG9Nmemn6jl3Jmp8ZlGS4qH8XGAvjZiJYWaf61z/eme5t7hYq1ixg=
=n52n
-END PGP SIGNATURE-