Re: target hooks / plugins

[Joern Rennecke]

Quoting "Joseph S. Myers" :

If you want to have documentation extracted from source files, you need to
engage with the SC and FSF at an early stage to get suitable license
exception wording to permit the relevant text to be used in the manuals as
well as the main (GPL) sources.


I haven't gotten any reply to my proposal from the 5th of January
http://gcc.gnu.org/ml/gcc/2010-01/msg00082.html

Is the GCC mailing list no longer the right place to reach the  
steering committee?



 Of course, the ordering and (especially)
section divisions in the internals manual are human-designed not arbitrary
so you need to retain the ability to put the documentation of each hook in
an appropriate position in an appropriate section of the manual.


I have posted my current patch here:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00559.html


If you can make this work it should reduce the risk of people not
documenting new hooks


We actually have a number of instances where the target hook documentation is
out of sync with the sources.  I have attached a file with my notes on this.


, but for it to work the FSF agreement is critical


So who do I have to talk to for this?


as
is ensuring it genuinely works as well as the existing system without
regressions (including working in update_web_docs).


tm.texi is half a megabyte, so it would be nice not to have it as a generated
file in the repository.  Also, it'd be annoying to have to regenerate & check
it in for every target.def change even though the build works fine with
the generated file in the build directory.
Will it be acceptable to have update_web_docs build a generator program
(written in C) to rebuild tm.texi?
various hooks: why are we referring to 'the diagnostic message'?
the context does not suggest a particular one, and I thought we had more
than one in gcc.

various documentation used rtx / tree instead of const_rtx / const_tree.

TARGET_ASM_ASSEMBLE_VISIBILITY: const char *...@var{visibility} -> int
clarified current_function_pops_args description and removed comment on
unclear "its arguments" reference.
TARGET_ASM_NAMED_SECTION unsigned int @var{align} -> tree decl
TARGET_ASM_MARK_DECL_PRESERVED tree @var{decl} -> const char *symbol
TARGET_SCHED_ADJUST_COST_2 was undocumented.
TARGET_SCHED_SPECULATE_INSN: Fixed return value description.
TARGET_SCHED_NEEDS_BLOCK_P: int -> bool; rtx @var{insn} -> int dep_status (text 
is still bogus)
TARGET_SCHED_GEN_CHECK -> TARGET_SCHED_GEN_SPEC_CHECK
TARGET_SCHED_SET_SCHED_FLAGS unsigned int *...@var{flags} -> /dev/null
TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION enum built_in_function @var{code} 
-> unsigned
TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST was undocumented.
TARGET_[VECTORIZE_]VECTOR_ALIGNMENT_REACHABLE was undocumented.
TARGET_VECTORIZE_BUILTIN_VEC_PERM was undocumented.
TARGET_VECTORIZE_BUILTIN_VEC_PERM_OK was undocumented.
TARGET_EH_RETURN_FILTER_MODE was undocumented.
TARGET_UNWIND_WORD_MODE was undocumented.
TARGET_BUILTIN_FUNCTION -> TARGET_BUILTIN_DECL
TARGET_RESOLVE_OVERLOADED_BUILTIN addded unsigned int /*location_t*/ loc; tree 
@var{arglist} -> void *arglist
TARGET_BUILTIN_RECIPROCAL enum tree_code @var{fn} -> unsigned fn
TARGET_CANNOT_COPY_INSN_P was undocumented.
TARGET_EXPAND_BUILTIN_VA_START was undocumented.
TARGET_GIMPLIFY_VA_ARG_EXPR tree *...@var{pre_p}, tree *...@var{post_p} -> 
gimple_seq *pre_p, gimple_seq *post_p
TARGET_STDARG_OPTIMIZE_HOOK was undocumented.
TARGET_INTERNAL_ARG_POINTER was undocumented.
TARGET_GET_DRAP_RTX: text was garbled, e.g. confusion macro vs. hook.
TARGET_C_MODE_FOR_SUFFIX was undocumented.
TARGET_VALID_OPTION_ATTRIBUTE_P -> TARGET_OPTION_VALID_ATTRIBUTE_P
TARGET_OPTION_PRINT: new parameters FILE *file, int indent
TARGET_OPTION_PRAGMA_PARSE: (target @var{args}) -> tree, tree
TARGET_EXTRA_LIVE_ON_ENTRY: (bitmap *...@var{regs}) -> bitmap
TARGET_HANDLE_PRAGMA_EXTERN_PREFIX was undocumented.
TARGET_HELP bool -> void
TARGET_BUILTIN_SETJMP_FRAME_VALUE bool -> rtx
TARGET_PRETEND_OUTGOING_VARARGS_NAMED: add (CUMULATIVE_ARGS *...@var{ca})
TARGET_LEGITIMATE_ADDRESS_P: returns bool
TARGET_SCHED_REORDER2 @var{clock} -> int clock
TARGET_SCHED_DFA_PRE_CYCLE_INSN int -> rtx
TARGET_SCHED_DFA_POST_CYCLE_INSN int -> rtx
TARGET_SCHED_DFA_PRE_CYCLE_ADVANCE -> TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE
TARGET_SCHED_DFA_POST_CYCLE_ADVANCE -> TARGET_SCHED_DFA_POST_ADVANCE_CYCLE
TARGET_SCHED_ALLOC_SCHED_CONTEXT, TARGET_SCHED_INIT_SCHED_CONTEXT, 
TARGET_SCHED_SET_SCHED_CONTEXT, TARGET_SCHED_CLEAR_SCHED_CONTEXT, 
TARGET_SCHED_FREE_SCHED_CONTEXT were duplicated.
TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC int -> bool
TARGET_SCHED_GET_INSN_SPEC_DS was undocumented.
TARGET_SCHED_GET_INSN_CHECKED_DS was undocumented.
TARGET_SCHED_SKIP_RTX_P was undocumented.
TARGET_ASM_RELOC_RW_MASK: 'returns' void.
TARGET_MANGLE_DECL_ASSEMBLER_NAME: void -> tree
TARGET_ASM_EMIT_UNWIND_LABEL was missing types.
Why is the TARGET_DWARF_CALLING_CONVENTION documentation nested in the
DWARF2_DEBUGGING_IN

Help-The possible places where insn is splitted in greg pass

[fanqifei]

Hi,
I am working on a micro controller and trying to port gcc(4.3.2) for it.
Not the compiling process runs into the following error:
a.c: In function 'task':
a.c:150: error: unrecognizable insn:
(insn 479 478 320 19 a:381 (set (reg:SI 12 a12)
        (plus:SI (mult:SI (reg:SI 9 a9 [204])
                (const_int 4 [0x4]))
            (reg:SI 12 a12))) -1 (nil))
a.c:150: internal compiler error: in extract_insn, at recog.c:1990
Please submit a full bug report, ...

This insn is generated in greg pass from another insn:
(insn 320 308 309 19 a.c:381 (set (reg:SI 207 [ .wrData ])
(mem/s:SI (plus:SI (mult:SI (reg:SI 204)
(const_int 4 [0x4]))
(reg/f:SI 234)) [5 .wrData+0 S4 A32])) 3 {movsi}
(expr_list:REG_DEAD (reg:SI 204)
(nil)))
I surfed the web a bit and found similar gcc bug report 37436
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436.
But basically they are not same.

Can someone show me the possible places where insn#479 is generated in
reload.c or reload1.c?
Thanks!

Qifei Fan

RE: GCC-How does the coding style affect the insv pattern recognization?

[Bingfeng Mei]

Your instruction is likely too specific to be picked up by GCC. 
You may use an intrinisc for it. 

Bingfeng 

> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On 
> Behalf Of fanqifei
> Sent: 12 January 2010 12:50
> To: gcc@gcc.gnu.org
> Subject: GCC-How does the coding style affect the insv 
> pattern recognization?
> 
> Hi,
> I am working on a micro controller and trying to port 
> gcc(4.3.2) for it.
> There is insv instruction in our micro controller and I have add
> define_insn to machine description file.
> However, the insv instruction can only be generated when the code
> is written like below.  If the code is written using logical shift and
> or operators, the insv instruction will not be generated.
> For the statement: x= (x&0xFF00) | ((i<<16)&0x00FF);
> 6 RTL instructions are generated after combine pass and 8
> instructions are generated in the assembly file.
> Paolo Bonzini said that insv instruction might be synthesized
> later by combine. But combine only works on at most 3 instructions and
> insv is not generated in such case.
> So exactly when will the insv pattern be recognized and how does
> the coding style affect it?
> Is there any open bug report about this?
> 
> struct test_foo {
> unsigned int a:18;
> unsigned int b:2;
> unsigned int c:12;
> };
> 
> struct test_foo x;
> 
> unsigned int foo()
> {
> unsigned int a=x.b;
> x.b=2;
> return a;
> }
> 
> Thanks!
> fanqifei
> 
> 

Re: GCC-How does the coding style affect the insv pattern recognization?

[fanqifei]

2010/1/13 Bingfeng Mei :
> Your instruction is likely too specific to be picked up by GCC.
> You may use an intrinisc for it.
>
> Bingfeng

but insv is a standard pattern name.
the semantics of expression x= (x&0xFF00) | ((i<<16)&0x00FF);
is exactly what insv can do.
I all tried mips gcc cross compiler, and ins is also not generated.
Intrinsic is a way to resolve this though. Maybe there is no other better way.

BTW,
There is a special case(the bit position is 0):
235: f0 97 fc mvi a9 -0x4;  #move immediate to reg
238: ff e9 94 and a9 a14 a9;
23b: f0 95 02 or a9 0x2;
The above three instructions can be replaced by mvi and insv. But the
fact is not in the combine pass.

Qifei Fan

RE: GCC-How does the coding style affect the insv pattern recognization?

[Bingfeng Mei]

OOPs, I don't know that. Anyway, I won't count on GCC to 
reliably pick up these complex patterns.  In our port, we 
implemented clz/ffs/etc as intrinsics though they are present as 
standard patterns. 

Bingfeng

> -Original Message-
> From: fanqifei [mailto:fanqi...@gmail.com] 
> Sent: 13 January 2010 10:26
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: GCC-How does the coding style affect the insv 
> pattern recognization?
> 
> 2010/1/13 Bingfeng Mei :
> > Your instruction is likely too specific to be picked up by GCC.
> > You may use an intrinisc for it.
> >
> > Bingfeng
> 
> but insv is a standard pattern name.
> the semantics of expression x= (x&0xFF00) | ((i<<16)&0x00FF);
> is exactly what insv can do.
> I all tried mips gcc cross compiler, and ins is also not generated.
> Intrinsic is a way to resolve this though. Maybe there is no 
> other better way.
> 
> BTW,
> There is a special case(the bit position is 0):
> 235: f0 97 fc mvi a9 -0x4;  #move immediate to reg
> 238: ff e9 94 and a9 a14 a9;
> 23b: f0 95 02 or a9 0x2;
> The above three instructions can be replaced by mvi and insv. But the
> fact is not in the combine pass.
> 
> Qifei Fan
> 
> 

Re: [discuss] Bug in x86-64 psABI or in gcc?

[Michael Matz]

Hi,

On Wed, 9 Dec 2009, H.J. Lu wrote:

> > So, IMO we have two sensible proposals:
> > (a) specify that bits <7:1> must be zero
> > (b) specify that bits <31:1> must be zero
> 
> I uploaded sources and object files generated by gcc 4.4, icc 11.1
> and Sun Studio 12 Update 1 at -O to:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324
> 
> If we go with (a), no changes are needed for gcc, icc and sun studio.
> All existing object files are OK.
> 
> If we go with (b), gcc 4.3 and 4.4 are broken in function return. Object
> files generated by gcc 4.3 and 4.4 aren't compatible with object files
> which assuming bits 1-31 in _Bool return are zero.
> 
> I think (a) is the safest option.

The ABI now contains this:


When a value of type \code{_Bool} is returned or passed in a register or
on the stack, bit 0 contains the truth value and bits 1 to 7 shall be
zero.



Ciao,
Michael.

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Michael Matz]

Hi,

On Sun, 10 Jan 2010, Dave Korn wrote:

>   Ok.  So if I had four ints, and I wanted to cast the pointers to char 
> and compare them as 16 chars, that would be OK, because the chars would 
> alias the ints; but in this case, where they started as chars and I cast 
> them to ints, those ints don't alias against the original chars.  Is 
> that an accurate precis?

Yes, this is correct.  Many people are surprised by that, as they often 
"learned" that 'char' is the catch-all escape from aliasing problems.  
This is only true in one direction (accessing anything as chars), but not 
in the other (accessing chars as something else).


Ciao,
Michael.

Re: target hooks / plugins

[Joseph S. Myers]

On Wed, 13 Jan 2010, Joern Rennecke wrote:

> Quoting "Joseph S. Myers" :
> > If you want to have documentation extracted from source files, you need to
> > engage with the SC and FSF at an early stage to get suitable license
> > exception wording to permit the relevant text to be used in the manuals as
> > well as the main (GPL) sources.
> 
> I haven't gotten any reply to my proposal from the 5th of January
> http://gcc.gnu.org/ml/gcc/2010-01/msg00082.html
> 
> Is the GCC mailing list no longer the right place to reach the steering
> committee?

It is the right place, but you should start a new thread with just the 
relevant issue and an appropriate subject line marked for the attention of 
the SC.  You should expect it to take at least several months for the FSF 
to prepare an exception (worded as additional permissions under Section 7 
of GPL version 3, like COPYING.RUNTIME, *not* as an old-style "As a 
special exception"), maybe years, if the SC persuades them that there 
should be such an exception.

> > Of course, the ordering and (especially)
> > section divisions in the internals manual are human-designed not arbitrary
> > so you need to retain the ability to put the documentation of each hook in
> > an appropriate position in an appropriate section of the manual.
> 
> I have posted my current patch here:
> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00559.html
> 
> > If you can make this work it should reduce the risk of people not
> > documenting new hooks
> 
> We actually have a number of instances where the target hook documentation is
> out of sync with the sources.  I have attached a file with my notes on this.

Please note that your initial change to implement automatic doc extraction 
should not result in any changes to the Texinfo content of the manual.  
Such fixes should all go in either before or after the automatic doc 
extraction change, but not at the same time; the doc extraction change 
should result in identical text in the manual, but with the Texinfo files 
produced in a different way.  I recommend sending such fixes before the 
automatic doc extraction change, since they do not depend on the FSF doing 
anything.

> > , but for it to work the FSF agreement is critical
> 
> So who do I have to talk to for this?

The SC.  Not in the middle of a technical thread, but a thread on its own 
marked for the SC and indicating exactly what you want them to raise with 
the FSF.

> tm.texi is half a megabyte, so it would be nice not to have it as a generated
> file in the repository.  Also, it'd be annoying to have to regenerate & check
> it in for every target.def change even though the build works fine with
> the generated file in the build directory.
> Will it be acceptable to have update_web_docs build a generator program
> (written in C) to rebuild tm.texi?

It already builds a generator program in Ada for the Ada manual, so yes.

-- 
Joseph S. Myers
jos...@codesourcery.com

Target hook definition licensing problems (GPL vs GFDL)

[Joern Rennecke]

Adding and maintaining target hooks is unnecessarily hard at the moment,
because the definition is spread across three places, and these are supposed
to be kept in sync.  The code is necessarily kept more or less in sync because
it generally fails to compile or work when it isn't - and if someone can't
get it working, a patch will most likely be left unposted; but the
documentation is silently accumulating inconsistencies with the code,
to the point that is useless or worse than useless for some hooks.

Ideally, target hooks should be easy to maintain in a consistent manner,
and also easy to add to experimental GCC versions, so that people who are
new to GCC or who patch GCC only as a side aspect
of their work can work with them in their contributions.

I have a prototype patch that allows to define target hooks in
a single file - there called target.def - to define the structure member,
its initializer, and its documentation:

http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00559.html

Name and types of the hook is shared between code and documentation, and
the member initializer is automatically placed in the right place of the
right initializer, so it takes the worry out getting and keeping this data
consistent.

However, there is a licensing problem.  The code is GPLed, and the
documentation is GFDLed.  The entire file is included for the struct
gcc_target by a number of GCC file, thus a GPL license is required.
For the initializer macro definitions and the documentation, the file
is included by a generator file, which processes the various fields of
each hook to generate the output files:
The initializer macros end up in a header file which is needed with GPL
license.
For the documentation, the generator file reads the GFDLed file tm.texi.in
which contains all the non-hook documentation, documentation about hooks
that does not pertain to any particular hook, and placement information
to arrange the hook documentation from the input file; the output is
written to tm.texi in the build directory.

As far as I can tell, there is no need for the generator program binary
to have a fancy license; GPL should be just fine, as long as the target.def
source file allows use of the pieces that appear in the output under the GFDL.
The generator program is supposed to be used by people who are in possession
of a copy of target.def, so they should be able to rely on the license terms
of that file.
Here is my proposal for the license header of that file:

/* Target hook definitions.
   Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
   Free Software Foundation, Inc.

   This program is free software; you can redistribute it and/or modify it
   under the terms of the GNU General Public License as published by the
   Free Software Foundation; either version 3, or (at your option) any
   later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; see the file COPYING3.  If not see
   .

   In other words, you are welcome to use, share and improve this program.
   You are forbidden to forbid anyone else to use, share and improve
   what you give them.   Help stamp out software-hoarding!  */

/* As a special exception, you may create documentation that contains
   part or all of this target hooks definitions file and distribute that
   work under the copying terms outlined in doc/gcc.texi .
   Alternatively, if you modify or redistribute this target hooks
   definitions file itself, you may (at your option) remove this special
   exception, which will cause the target hooks definitions file (and any
   program output which incorporates parts of this file) to be licensed
   under the GNU General Public License without this special exception.  */

We'd then need the FSF to agree that we can use the existing target hook
structure member definitions, default initializers, and documentation under
this dual license.

Quoting "Joseph S. Myers" :

You should expect it to take at least several months for the FSF
to prepare an exception (worded as additional permissions under Section 7
of GPL version 3, like COPYING.RUNTIME, *not* as an old-style "As a
special exception"), maybe years, if the SC persuades them that there
should be such an exception.


I don't see why something so elaborate is needed.  The file in question is
about 150 KB of structure definition, interface definition, and documentation.
The aim is that this file can be used in a GPLed program (GCC) and that parts
of it (emitted by a generator program) can be used in GFDLed documentation.
So dual-licensing of this file should work just fine.
I find it quite challenging to come up with scenarios where GFDLing some
target h

Re: target hooks / plugins

[Joern Rennecke]

Quoting "Joseph S. Myers" :


Please note that your initial change to implement automatic doc extraction
should not result in any changes to the Texinfo content of the manual.
Such fixes should all go in either before or after the automatic doc
extraction change, but not at the same time; the doc extraction change
should result in identical text in the manual, but with the Texinfo files
produced in a different way.  I recommend sending such fixes before the
automatic doc extraction change, since they do not depend on the FSF doing
anything.


Duplicating all these changes separately by hand seems nigh impossible.
I think the best approach is then to take the auto-generated tm.texi as
the new tm.texi, and packages it up as a patch together with the
struct member / hook name changes that I made for consistency.

There is only one issue with using the current auto-generated tm.texi:
Unless special formatting was in force (e.g. @smallexample), I've removed
intra-paragraph newlines.  This should work in principle just as will
as with these newlines for producing output, but it looks somewhat daft
in tm.texi when you consider it as a source file.
Putting newlines in the input file would make it harder to read & edit,
since the documentation comes as C strings - and the GNU multiline string
extension has been deprecated some time ago.
I could pipe the documentation through fold -s, but that would also fold
extra-long lines outside the hook documentation, e.g.:
@@ -28,7 +28,8 @@
 @menu
 * Target Structure::The @code{targetm} variable.
 * Driver::  Controlling how the driver runs the  
compilation passes.
-* Run-time Target:: Defining @samp{-m} options like  
@option{-m68000} and @option{-m68020}.

+* Run-time Target:: Defining @samp{-m} options like @option{-m68000} and
+...@option{-m68020}.
 * Per-Function Data::   Defining data structures for per-function  
information.

 * Storage Layout::  Defining sizes and alignments of data.
 * Type Layout:: Defining sizes and properties of basic user  
data types.


So I suppose I'll have to add some fold mechanism into the documentation
output code.

Re: target hooks / plugins

[Joseph S. Myers]

On Wed, 13 Jan 2010, Joern Rennecke wrote:

> Duplicating all these changes separately by hand seems nigh impossible.
> I think the best approach is then to take the auto-generated tm.texi as
> the new tm.texi, and packages it up as a patch together with the
> struct member / hook name changes that I made for consistency.
> 
> There is only one issue with using the current auto-generated tm.texi:
> Unless special formatting was in force (e.g. @smallexample), I've removed
> intra-paragraph newlines.  This should work in principle just as will
> as with these newlines for producing output, but it looks somewhat daft
> in tm.texi when you consider it as a source file.

I am not particularly concerned about newlines, if the file is identical 
apart from whitespace.  But your text file lists things such as "was 
undocumented" and "Fixed return value description".  Each such change 
needs its own review, by someone familiar with the relevant part of the 
compiler, and needs its own explanation of the problem posted.  Remember, 
a patch should not contain multiple changes that can logically be 
considered separately, and in this case I expect many different people to 
be appropriate reviewers for changes relating to different hooks, so it's 
important not to mix changes relating to hooks in different areas of the 
compiler.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Request for code review - (ZEE patch : Redundant Zero extension elimination)

[Sriraman Tallam]

Hi Jan,

Can you take a look at this patch when you find the time ? This is
being blocked needing an approval from a x86 backend maintainer and
you are the only one listed in the MAINTAINERS file.

Thanks,
-Sriraman.

On Tue, Oct 6, 2009 at 2:56 PM, Paolo Bonzini  wrote:
> On 10/01/2009 11:37 PM, Sriraman Tallam wrote:
>>
>> Hi,
>>
>>       I moved implicit-zee.c to config/i386. Can you please take another
>> look ?
>
> I think this patch is best reviewed by an x86 backend maintainer now.
>
> Thanks for doing the adjustments, BTW.
>
> Paolo
>

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Laurent GUERBY]

On Sun, 2010-01-10 at 15:46 +0100, Eric Botcazou wrote:
> > The aliasing rules treat "char" specially because char is a bit like a
> > "poor main's void".
> 
> Not symmetrically though, only for the type of the lvalue expression used to 
> access the object (C99 6.5.7).

BTW in Ada if one uses address clause to overlay a 16 character string
and a 4 4-byte integer array (both aliased) which is then accessed what
can we expect GCC-wise? Are we safe from aliasing related optimizations?

FWIW the program below seems to work as expected.

Laurent

procedure P is
  subtype String16 is String (1 .. 16);
  S16 : aliased String16;
  for S16'alignment use Integer'Alignment;
  type Int4 is array (1 .. 4) of Integer;
  I4 : aliased Int4;
  for I4'Address use S16'Address;
  X : constant := 1 + 256 + 256*256 + 256*256*256;
begin
  S16 := (others => Character'Val (1));
  if I4 /= (X, X, X, X) then
 raise Program_Error;
  end if;
end P;

multiple defs. of TLS common symbols?

[Gary Funck]

We use TLS relocated symbols to create thread-local symbols
in the GCC UPC compiler, and have run into an issue illustrated
by the following program, on a test case that defines a
common symbol in several files, and uses it in a single file.

The following program fails to link, with multiple defs:

% head s.c t.c main.c
==> s.c <==
__thread int x;

==> t.c <==
__thread int x;

==> main.c <==
__thread int x;

int main()
{
  x = 1;
}

% gcc s.c t.c main.c
/tmp/ccK5Aj3k.o:(.tbss+0x0): multiple definition of `x'
/tmp/ccm0kY5f.o:(.tbss+0x0): first defined here
/tmp/ccchPiAt.o:(.tbss+0x0): multiple definition of `x'
/tmp/ccm0kY5f.o:(.tbss+0x0): first defined here
collect2: ld returned 1 exit status

But if we don't use TLS storage, it all links just fine:

% gcc -D__thread= s.c t.c main.c

Off-hand this looks like it might be a linker issue, but
perhaps there's an issue with the use of __thread in
in the context above?

Re: Target hook definition licensing problems (GPL vs GFDL)

[Dave Korn]

Joern Rennecke wrote:
> References: <4ae6e471.4020...@starynkevitch.net>
> 
> <4ae70c5e.4050...@starynkevitch.net>
> <84fc9c000910270839v2d9efe0dw829c8647f361c...@mail.gmail.com>
> <4ae7164d.9010...@starynkevitch.net>
> <84fc9c000910270855w736df367qe511d8db280aa...@mail.gmail.com>
> <2dc303d60910271056h17038110ib63c53cfa374f...@mail.gmail.com>
> <20091102074959.p8410ulv28sg0w44-nzly...@webmail.spamcop.net>
> <20091105082557.75c2estyoog8ss0c-nzly...@webmail.spamcop.net>
> <-2186575642631489...@unknownmsgid>

[  Never seen that before, looks as if someone used "%i" when they probably
meant "%u" or "%x"! ]

> <55692dc10911050634y54a5fea7jd2ba773086cda...@mail.gmail.com>
> <00d801ca5e34$e5384160$afa8c4...@fursin@inria.fr>
> <20091223101256.z6a8ug32o8k84o4o-nzly...@webmail.spamcop.net>
> <20091223193244.hqaet9zf488gw844-nzly...@webmail.spamcop.net>
> 
> <20100113032220.pzerwhbtog0w4gsk-nzly...@webmail.spamcop.net>
> 
> <20100113110917.vqaoqpyyc0ck8gso-nzly...@webmail.spamcop.net>

  That didn't "start a new thread"!

cheers,
  DaveK

suggestion for ppl and cloog-ppl configure enhancement

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

IMHO it would be a godd idea to add the following two configure options to ppl
configure:
  --with-gmp-include=DIR  GMP include directory
  --with-gmp-lib=DIR  GMP lib directory

On 64-bit Linux systems you have the libraries in lib64 instead of lib in most
cases. With this additional configure options in place you do not need to fiddle
with LDFLAFS to find the library.
OTOH I think one may drop --with-libgmpxx-prefix because it's very unlikely that
libgmpxx is installed in a different place than libgmp.

I sent this to the ppl-devel list too.


Same holds for cloog-ppl, here --with-ppl-include and --with-ppl-lib is missing.
Sebastian what do you think?


Cheers

Rainer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktOJUkACgkQoUhjsh59BL6+ywCgtTdQ3Ko9iW5nfloG7bcJ+KHU
U2MAoIRw20ISm2zQG+uomjDckT9Wzfzq
=zndb
-END PGP SIGNATURE-

Re: suggestion for ppl and cloog-ppl configure enhancement

[Sebastian Pop]

On Wed, Jan 13, 2010 at 14:55, Rainer Emrich  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> IMHO it would be a godd idea to add the following two configure options to ppl
> configure:
>  --with-gmp-include=DIR  GMP include directory
>  --with-gmp-lib=DIR      GMP lib directory
>
> On 64-bit Linux systems you have the libraries in lib64 instead of lib in most
> cases. With this additional configure options in place you do not need to 
> fiddle
> with LDFLAFS to find the library.
> OTOH I think one may drop --with-libgmpxx-prefix because it's very unlikely 
> that
> libgmpxx is installed in a different place than libgmp.
>
> I sent this to the ppl-devel list too.
>
>
> Same holds for cloog-ppl, here --with-ppl-include and --with-ppl-lib is 
> missing.
> Sebastian what do you think?

I'm fine with these new config flags: patches are welcome, but keep in
mind to post the changes related to PPL to the PPL mailing list, see
http://www.cs.unipr.it/ppl/ and the changes related to CLooG to
http://groups.google.com/group/cloog-development

Sebastian

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

[Eric Botcazou]

> BTW in Ada if one uses address clause to overlay a 16 character string
> and a 4 4-byte integer array (both aliased) which is then accessed what
> can we expect GCC-wise? Are we safe from aliasing related optimizations?

Yes, we use a big hammer to make sure 'Address is immune to these issues.

-- 
Eric Botcazou

Re: multiple defs. of TLS common symbols?

[Ian Lance Taylor]

Gary Funck  writes:

> We use TLS relocated symbols to create thread-local symbols
> in the GCC UPC compiler, and have run into an issue illustrated
> by the following program, on a test case that defines a
> common symbol in several files, and uses it in a single file.

The only way I know to get a TLS common symbol out of gcc is to use an
omp pragma:

int x;
#pragma omp threadprivate (x)

Otherwise TLS variables are generated as definitions rather than as
common variables.  Personally I tend to think that that is a good
thing.  Treating uninitialized variables as common variables is a
non-standard extension even for C90.  We can't get rid of them for
existing code, but __thread code is by definition new.

Why do you want them to be common?

Ian

Re: GCC-How does the coding style affect the insv pattern recognization?

[fanqifei]

2010/1/13 Bingfeng Mei :
> OOPs, I don't know that. Anyway, I won't count on GCC to
> reliably pick up these complex patterns.  In our port, we
> implemented clz/ffs/etc as intrinsics though they are present as
> standard patterns.
>
> Bingfeng
Could you please show me the path of the source code that implement
clz/ffs intrinsics of your processor?
I would like to take it as a reference.
Thank very much!

Qifei Fan

Re: multiple defs. of TLS common symbols?

[Gary Funck]

On 01/13/10 17:15:10, Ian Lance Taylor wrote:
[...]
> Otherwise TLS variables are generated as definitions rather than as
> common variables. 
> 
> Why do you want them to be common?

For GCC/UPC compiled programs there are two compilation modes: 1) Each
UPC thread is implemented as a full process, and these processes might
be distributed across a network.  2) Each UPC thread is implemented as
an OS thread (ie, pthread), and they are created by a single process
and execute within its address spec.

In the "process model", "int x;" has the usual semantics.  It is
defined as a common symbol.  In the "pthread model", each file scoped
variable is "localized" and becomes thread local; this is implemented
by defining the variable using TLS relocation.

Intermixing previously compiled C code that refers to file scoped
variables with GCC/UPC compiled "pthread mode" files will likely not
work well.  But if the C code is compiled with the GCC/UPC compiler in
"pthread mode" all file scoped symbols will be localized and everything
should work as expected.

The "process model" is the more natural and preferred way to compile
UPC programs.  The pthread model can offer some efficiencies and can
make it easier to debug the program.

Given the above, the goal of compiling in pthreads mode is to be able
to compile regular "C" code as is, with the same behavior as when it
was compiled in the normal process model.  Thus, we want to translate
all file scoped variables into localized TLS variables with the fewest
surprises and differences.

> Personally I tend to think that that is a good
> thing.  Treating uninitialized variables as common variables is a
> non-standard extension even for C90.  We can't get rid of them for
> existing code, but __thread code is by definition new.

I agree with your statement above, but for our purposes things
will work better if we do create commonized TLS symbols.

Maybe we can use GOMP's method for creating commonized
TLS variables.  Thanks for pointing it out.

Do you/others on this list have a reference that supports
the statement: "Treating uninitialized variables
as common variables is a non-standard extension even for C90."?
(I did see a thread on this list, late April 1999, that
discussed some of the issues, but nothing definitive.)

thanks.

Re: Help-The possible places where insn is splitted in greg pass

[fanqifei]

2010/1/13 fanqifei :
> Hi,
> I am working on a micro controller and trying to port gcc(4.3.2) for it.
> Not the compiling process runs into the following error:
> a.c: In function 'task':
> a.c:150: error: unrecognizable insn:
> (insn 479 478 320 19 a:381 (set (reg:SI 12 a12)
>         (plus:SI (mult:SI (reg:SI 9 a9 [204])
>                 (const_int 4 [0x4]))
>             (reg:SI 12 a12))) -1 (nil))
> a.c:150: internal compiler error: in extract_insn, at recog.c:1990
> Please submit a full bug report, ...
>
> This insn is generated in greg pass from another insn:
> (insn 320 308 309 19 a.c:381 (set (reg:SI 207 [ .wrData ])
> (mem/s:SI (plus:SI (mult:SI (reg:SI 204)
> (const_int 4 [0x4]))
> (reg/f:SI 234)) [5 .wrData+0 S4 A32])) 3 {movsi}
> (expr_list:REG_DEAD (reg:SI 204)
> (nil)))
> I surfed the web a bit and found similar gcc bug report 37436
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436.
> But basically they are not same.
>
> Can someone show me the possible places where insn#479 is generated in
> reload.c or reload1.c?
> Thanks!
>
> Qifei Fan
>
Is there anyone can help?
Thanks very much!

Qifei Fan