Vincent Lefevre | 1 Mar 03:01 2009

Re: Announce: MPFR 2.4.1 is released

Hi Kaveh,

On 2009-02-27 10:40:07 -0500, Kaveh R. GHAZI wrote:
> Thanks for the note.  I grep'ed the gcc sources and I don't see any uses
> of mpfr_snprintf or mpfr_vsnprintf.  So I don't believe any change in the
> minimum mpfr version checks (either "required" version or "recommended"
> version) is necessary in gcc due to this issue in mpfr.

FYI, mpfr_snprintf and mpfr_vsnprintf are new in MPFR 2.4.0 (but were
buggy in MPFR 2.4.0). So, if gcc needs them in the future, the minimum
required version would be 2.4.1.

--

-- 
Vincent Lefèvre <vincent <at> vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Ralf Wildenhues | 1 Mar 08:20 2009
Picon
Picon

gcj -v --help: ecj switches

Hello,

I have a patch (accompanying those other ones on gcc-paches) to fix

--- a/gcc/java/lang.opt
+++ b/gcc/java/lang.opt
 <at>  <at>  -209,212 +209,213  <at>  <at>  Java

 ;
 ; Warnings handled by ecj.
-; FIXME: document them
 ;

but I did start off with the help texts from
<http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm>
which AFAICS falls under the Eclipse Public License - v 1.0
<http://www.eclipse.org/legal/epl-v10.html>.

Now my question, before I blindly post this to {gcc,java}-patches and
thus create potential legal hassles for whoever works on it: was it
OKed (by the SC or FSF) to integrate such material into GCC?
If not, would you think that it suffices if I reformulate the entries
sufficiently, or do we need to start playing the legal game, if the
situation is to be improved?

Thanks!
Ralf

Takis Psarogiannakopoulos | 1 Mar 15:44 2009

ASM_SPECS on recent GCC 4.3.3 (4.X)


Hello,
I want to build 4.3.3 on an SVR4 (obviously port is required as its not a
std target) but I have stumble on the following issue regarding ASM_SPEC
extra switches:

On the host's (*.h) file in gcc/config we define

#undef  ASM_SPEC
#define ASM_SPEC " \
%{mno-legend:-Wc,off} \
%{g:%{!mno-legend:-Wc,-fix-bb,-s\"%i\" \
%{traditional:,-lc}%{!traditional:,-lansi-c} \
%{mstandard:,-keep-std} \
%{mexternal-legend:,-external}} \
%{mno-legend: -Wc,off}}"

These are switches they should be passed to the native assembler. Eg
wihtout -Wc,off (aka -mno-legend switch on the cc1) the compiler
cannot produce executables. (The native assembler will complain)

Seems that on the latest GCC 4.3.x tree the argumnet asmspecs has
been dropped from the function rest_of_decl_compilation in gcc/toplev.c
(see also make_decl_rtl procedure).
Hence even if ASM_SPEC is clearly "custom defined" on the gcc/config/.h
file still it is completely ignored with result that the bootstaped resulting
cc1 stil complains that it doesnt know what -mno-legend is and aborts
any further compilition.
Am I missing something here? Is there is another define I can use in .h
file that would pass the new (extra) switches I want to the newly build
(Continue reading)

Georg-Johann Lay | 1 Mar 19:10 2009
Picon

avr.md: best practice to optimize bit manipulations?

In order to improve bit manipulations for avr, patterns like the following can be used:

+;; [0].log[4] |= [2].log[4]+[3]
+(define_insn "*iorqi2_shiftrt_bit"
+  [(set (match_operand:QI 0 "register_operand" "=d,r")
+        (ior:QI (and:QI (match_operator:QI 1 "shiftrt_operator"
+                                           [(match_operand:QI 2 "register_operand" "r,r")
+                                            (match_operand:QI 3 "const_int_operand" "n,n")])
+                        (match_operand:QI 4 "single_one_operand" "n,n"))
+                (match_operand:QI 5 "register_operand" "0,0")))]
+  ""
+  {
+      HOST_WIDE_INT to_bit = exact_log2 (GET_MODE_MASK (QImode) & INTVAL(operands[4]));
+      HOST_WIDE_INT from_bit = to_bit + INTVAL(operands[3]);
+
+      operands[3] = GEN_INT (from_bit);
+      operands[4] = GEN_INT (to_bit);
+
+      if (0 == which_alternative)
+          return "sbrc %2,%3\;ori %0,(1<<%4)";
+
+      return "bst %2,%3\;sbrs %0,%4\;bld %0,%4";
+  }
+  [(set_attr "length" "2,3")
+   (set_attr "adjust_len" "no,no")
+   (set_attr "cc" "clobber,none")])
+
+;; needs the above pattern as combiner bridge
+;; [0].log[4] = [2].log[4]+[3]
+(define_insn "*movebit_shiftrt"
(Continue reading)

Takis Psarogiannakopoulos | 1 Mar 19:29 2009

SUBTARGET_SWITCES


Hi,

Also another thing I dont see in GCC 4.x.x but I know it was alive and
kicking on the GCC 3.4.6 branch is the subtarget switches custom macro.

Eg in the gcc.config/.h OS specific file we could define something like
that:

#define MASK_STANDARD        0x40000000 /* Retain standard information */
#define MASK_NOLEGEND        0x20000000 /* Discard legend information */
etc ...

#define TARGET_STANDARD           (target_flags & MASK_STANDARD)
#define TARGET_NOLEGEND           (target_flags & MASK_NOLEGEND)
etc ...

and then do a define as

#undef  SUBTARGET_SWITCHES
#define SUBTARGET_SWITCHES \
    { "standard",               MASK_STANDARD,                  \
      N_("Retain standard MXDB information") },                 \
    { "legend",                 -MASK_NOLEGEND,                 \
      N_("Retain legend information") },                        \
    { "warn-passed-structs",    MASK_WARN_PASS_STRUCT,          \
      N_("Warn when a function arg is a structure") },

That could cause cc1 --help as well as gcc --help to list those extra
OS specific added options (two -m above and one -W, an examble).
(Continue reading)

Georg-Johann Lay | 1 Mar 19:32 2009
Picon

Re: avr.md: best practice to optimize bit manipulations?

Georg-Johann Lay schrieb:
> source, or if they are dead and just pollute backend. Introducing extzv 
> and insv could bring some effort (I didn't try what impact they have) 

Sorry for the typo. Please replace "effort" with "improvement" or "relief".

Mark Mitchell | 1 Mar 19:41 2009

Re: ASM_SPECS on recent GCC 4.3.3 (4.X)

Takis Psarogiannakopoulos wrote:

> #undef  ASM_SPEC
> #define ASM_SPEC " \

> Seems that on the latest GCC 4.3.x tree the argumnet asmspecs has
> been dropped from the function rest_of_decl_compilation in gcc/toplev.c
> (see also make_decl_rtl procedure).

I think there's some confusion here.  There is no relationship between
the ASM_SPEC definition in a config *.h file regarding options to be
passed to the assembler and the old "asmspec" parameter to
rest_of_decl_compilation, which related to uses of the "__asm__(...)"
extension in the source code.

--

-- 
Mark Mitchell
CodeSourcery
mark <at> codesourcery.com
(650) 331-3385 x713

Takis Psarogiannakopoulos | 1 Mar 19:55 2009

Re: ASM_SPECS on recent GCC 4.3.3 (4.X)


Hi Mark,
Thanks for answering.

On Sun, 1 Mar 2009, Mark Mitchell wrote:

> I think there's some confusion here.  There is no relationship between
> the ASM_SPEC definition in a config *.h file regarding options to be
> passed to the assembler and the old "asmspec" parameter to
> rest_of_decl_compilation, which related to uses of the "__asm__(...)"
> extension in the source code.
>
Are you sure about that? From a brief look on the code over the 3.4.6
branch I assumed that this is the issue.
Well in the ASM_SPEC def as I ve described it in my previous message, in
3.4.6 branch works fine and even if gcc.c is not linked over cc1 still
toplev.o contains the ASM_SPEC extra commands. On GCC  4.x.x branch
cc1 doesnt get at all those extra options. I also used to document
those options in the --help line with SUBTARGET_SWITCHES macro which is
also not present anymore.
It is my guess that if I pass the above ASM_SPECS as CC1_SPECS it will
work but thats not the right thing!
ASM_SPECS were always custom extra command line commands to be been passed
to the assembler right? So re-stating my question:
1) the old way to do that (3.4.X branch ASM_SPEC) doesnt seem to work
anymore
2) How do you do it in the 4.X.X branch...

Regards,

(Continue reading)

Mark Mitchell | 1 Mar 19:58 2009

Re: ASM_SPECS on recent GCC 4.3.3 (4.X)

Takis Psarogiannakopoulos wrote:

>> I think there's some confusion here.  There is no relationship between
>> the ASM_SPEC definition in a config *.h file regarding options to be
>> passed to the assembler and the old "asmspec" parameter to
>> rest_of_decl_compilation, which related to uses of the "__asm__(...)"
>> extension in the source code.
>>
> Are you sure about that? 

Yes.

> ASM_SPECS were always custom extra command line commands to be been passed
> to the assembler right? So re-stating my question:
> 1) the old way to do that (3.4.X branch ASM_SPEC) doesnt seem to work
> anymore
> 2) How do you do it in the 4.X.X branch...

The same basic mechanisms will work.  Probably something is #undef'ing
the macro after you define it, or you are confused about which header
files are being used in your configuration.  You will have to get out
the debugger and preprocessor to work out what's going on.

--

-- 
Mark Mitchell
CodeSourcery
mark <at> codesourcery.com
(650) 331-3385 x713

(Continue reading)

Dave Korn | 1 Mar 21:41 2009

Re: GNAT vs DW2/ZCX EH.

Arnaud Charlet wrote:
>>> I doubt that this can be deemed an experiment, we know that it works.
>> We know that it works with our sources and GCC 4.3. We have no idea how
>> well it works with GCC 4.4: we don't do mingw builds there.
> 
> BTW, we have local patches not yet integrated that are needed for proper
> ZCX support, in particular the need of a libgcc_s.dll becomes important when
> you enable ZCX. 

  That should all be working nicely right now, since Aaron's patch last
autumn.  Care to post your work-in-progress patches for us all to put our
heads together over?

    cheers,
      DaveK


Gmane