Re: Seeking suggestion

[Georg-Johann Lay]

Jamie Prescott schrieb:


Is the implementation I posted the only one, or there are shorter/better ones?


You could use insn attribute to express insns' effects on cc_status.
Have a look at the avr backend.

Georg-Johann

[RFA] Fix documentation of snprintf and vsnprintf

[Eli Zaretskii]

The current documentation of these two functions is misleading, and can
easily cause off-by-one bugs, if one follows it to the letter and
doesn't double-check with what the source actually does.

I tried to be more accurate in the patch below.

OK?

2009-05-23  Eli Zaretskii  

* snprintf.c: Doc fix.

* vsnprintf.c: Doc fix.

--- libiberty/snprintf.c~0  2005-05-10 21:33:34.0 +0300
+++ libiberty/snprintf.c2009-05-23 16:34:39.265625000 +0300
@@ -27,13 +27,14 @@
 
 @deftypefn Supplemental int snprintf (char *...@var{buf}, size_t @var{n}, 
const char *...@var{format}, ...)
 
-This function is similar to sprintf, but it will print at most @var{n}
-characters.  On error the return value is -1, otherwise it returns the
-number of characters that would have been printed had @var{n} been
-sufficiently large, regardless of the actual value of @var{n}.  Note
-some pre-C99 system libraries do not implement this correctly so users
-cannot generally rely on the return value if the system version of
-this function is used.
+This function is similar to @code{sprintf}, but it will write at most
+var{n} bytes (including the terminating null byte) to @var{buf}.
+On error the return value is -1, otherwise it returns the number of
+bytes, not including the terminating null byte, that would have been
+written had @var{n} been sufficiently large, regardless of the actual
+value of @var{n}.  Note some pre-C99 system libraries do not implement
+this correctly so users cannot generally rely on the return value if
+the system version of this function is used.
 
 @end deftypefn
 
--- libiberty/vsnprintf.c~0 2005-05-10 21:33:34.0 +0300
+++ libiberty/vsnprintf.c   2009-05-23 16:36:07.265625000 +0300
@@ -27,13 +27,14 @@
 
 @deftypefn Supplemental int vsnprintf (char *...@var{buf}, size_t @var{n}, 
const char *...@var{format}, va_list @var{ap})
 
-This function is similar to vsprintf, but it will print at most
-...@var{n} characters.  On error the return value is -1, otherwise it
-returns the number of characters that would have been printed had
-...@var{n} been sufficiently large, regardless of the actual value of
-...@var{n}.  Note some pre-C99 system libraries do not implement this
-correctly so users cannot generally rely on the return value if the
-system version of this function is used.
+This function is similar to @code{vsprintf}, but it will write at most
+...@var{n} bytes (including the terminating null byte) to @var{buf}.
+On error the return value is -1, otherwise it returns the number of
+bytes, not including the terminating null byte, that would have been
+written had @var{n} been sufficiently large, regardless of the actual
+value of @var{n}.  Note some pre-C99 system libraries do not implement
+this correctly so users cannot generally rely on the return value if
+the system version of this function is used.
 
 @end deftypefn
 

Re: [RFA] Fix documentation of snprintf and vsnprintf

[Dave Korn]

Eli Zaretskii wrote:
> The current documentation of these two functions is misleading, and can
> easily cause off-by-one bugs, if one follows it to the letter and
> doesn't double-check with what the source actually does.
> 
> I tried to be more accurate in the patch below.
> 
> OK?

  I think it's still a little bit unclear:

> +This function is similar to @code{sprintf}, but it will write at most
> +var{n} bytes (including the terminating null byte) to @var{buf}.

  It could still be perceived as ambiguous.  That sentence says that the
terminating null byte is included in the count of
"the-most-bytes-it-will-write", but it doesn't explicitly say that it won't be
truncated off like the rest of the characters if the output is too long.  How
about

> +This function is similar to @code{sprintf}, but it will write at most
> +var{n} bytes (truncating the output if necessary, so that there is
> +always guaranteed to be a terminating null byte) to @var{buf}.

  I got this wrong in some code I was writing just the other day, when I
wanted to produce a non-null terminated string in an exact-length buffer, and
had to go back and fix it after reading the documentation three times and
inferring which of the meanings it must have intended from the behaviour I had
observed...

cheers,
  DaveK

Re: Seeking suggestion

[Jamie Prescott]

> From: Georg-Johann Lay 
> To: Jamie Prescott 
> Cc: Ian Lance Taylor ; gcc@gcc.gnu.org
> Sent: Saturday, May 23, 2009 12:05:09 AM
> Subject: Re: Seeking suggestion
> 
> Jamie Prescott schrieb:
> 
> > Is the implementation I posted the only one, or there are shorter/better 
> > ones?
> 
> You could use insn attribute to express insns' effects on cc_status.
> Have a look at the avr backend.

AVR uses CC0, while I just switched to CCmode.
Is there a reason why something like this would not work?

(define_insn "addsi3_nc"
  [(set (match_operand:SI 0 "fullreg_operand" "=r")
(plus:SI (match_operand:SI 1 "fullreg_operand" "r")
 (match_operand:SI 2 "fullreg_or_imm_operand" "rn")))]
  ""
  "..."
)

(define_expand "addsi3"
  [(set (match_operand:SI 0 "fullreg_operand" "=r")
(plus:SI (match_operand:SI 1 "fullreg_operand" "r")
 (match_operand:SI 2 "fullreg_or_imm_operand" "rn")))]
  ""
  {
if (!TARGET_XXX2)
  emit_clobber(gen_rtx_REG(CCmode, CC_REGNUM));
emit_insn(gen_addsi3_nc(operands[0], operands[1], operands[2]));
DONE;
  }
)

That would limit to two instructions per basic insns, instead of the current 
three.
Thanks,

- Jamie


  

ICE during build of libobjc

[NightStrike]

/bin/sh ./libtool --mode=compile
/home/nightstrike/a/build/gcc/obj/./gcc/xgcc
-B/home/nightstrike/a/build/gcc/obj/./gcc/
-L/home/nightstrike/a/build/gcc/obj/x86_64-w64-mingw32/winsup/mingw
-L/home/nightstrike/a/build/gcc/obj/x86_64-w64-mingw32/winsup/w32api/lib
-isystem /home/nightstrike/a/build/gcc/gcc/winsup/mingw/include
-isystem /home/nightstrike/a/build/gcc/gcc/winsup/w32api/include
-B/home/nightstrike/a/build/root/x86_64-w64-mingw32/bin/
-B/home/nightstrike/a/build/root/x86_64-w64-mingw32/lib/ -isystem
/home/nightstrike/a/build/root/x86_64-w64-mingw32/include -isystem
/home/nightstrike/a/build/root/x86_64-w64-mingw32/sys-include-c
-I. -I/home/nightstrike/a/build/gcc/gcc/libobjc   -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS
-fno-strict-aliasing -fexceptions
-I/home/nightstrike/a/build/gcc/gcc/libobjc/objc
-I/home/nightstrike/a/build/gcc/gcc/libobjc/../gcc
-I/home/nightstrike/a/build/gcc/gcc/libobjc/../gcc/config
-I../.././gcc -I/home/nightstrike/a/build/gcc/gcc/libobjc/../include
/home/nightstrike/a/build/gcc/gcc/libobjc/archive.c
libtool: compile:  /home/nightstrike/a/build/gcc/obj/./gcc/xgcc
-B/home/nightstrike/a/build/gcc/obj/./gcc/
-L/home/nightstrike/a/build/gcc/obj/x86_64-w64-mingw32/winsup/mingw
-L/home/nightstrike/a/build/gcc/obj/x86_64-w64-mingw32/winsup/w32api/lib
-isystem /home/nightstrike/a/build/gcc/gcc/winsup/mingw/include
-isystem /home/nightstrike/a/build/gcc/gcc/winsup/w32api/include
-B/home/nightstrike/a/build/root/x86_64-w64-mingw32/bin/
-B/home/nightstrike/a/build/root/x86_64-w64-mingw32/lib/ -isystem
/home/nightstrike/a/build/root/x86_64-w64-mingw32/include -isystem
/home/nightstrike/a/build/root/x86_64-w64-mingw32/sys-include -c -I.
-I/home/nightstrike/a/build/gcc/gcc/libobjc -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS
-fno-strict-aliasing -fexceptions
-I/home/nightstrike/a/build/gcc/gcc/libobjc/objc
-I/home/nightstrike/a/build/gcc/gcc/libobjc/../gcc
-I/home/nightstrike/a/build/gcc/gcc/libobjc/../gcc/config
-I../.././gcc -I/home/nightstrike/a/build/gcc/gcc/libobjc/../include
/home/nightstrike/a/build/gcc/gcc/libobjc/archive.c  -DDLL_EXPORT
-DPIC -o .libs/archive.o
In file included from
/home/nightstrike/a/build/gcc/gcc/libobjc/objc/runtime.h:38,
 from /home/nightstrike/a/build/gcc/gcc/libobjc/archive.c:26:
/home/nightstrike/a/build/gcc/gcc/libobjc/objc/objc-api.h:365:
internal compiler error: tree check: expected function_decl, have
var_decl in handle_dll_attribute, at tree.c:4172
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [archive.lo] Error 1
make[2]: Leaving directory
`/home/nightstrike/a/build/gcc/obj/x86_64-w64-mingw32/libobjc'
make[1]: *** [all-target-libobjc] Error 2
make[1]: Leaving directory `/home/nightstrike/a/build/gcc/obj'
make: *** [all] Error 2
nightstr...@gcc16:~/a/build/gcc/obj$

What does zero-length array mean at file scope?

[Dave Korn]

Hi everyone,

  I found something rather odd in testcase gcc.c-torture/execute/20030811-1.c:

> /* Origin: PR target/11535 from H. J. Lu  */
> 
> void vararg (int i, ...)
> {
>   (void) i;
> }
> 
> int i0[0], i1;

  Huh?

> void test1 (void)
> {
>   int a = (int) (long long) __builtin_return_address (0);
>   vararg (0, a);
> }
> 
> void test2 (void)
> {
>   i0[0] = (int) (long long) __builtin_return_address (0);
> }

  Nasal demons?

> void test3 (void)
> {
>   i1 = (int) (long long) __builtin_return_address (0);
> }
> 
> void test4 (void)
> {
>   volatile long long a = (long long) __builtin_return_address (0);
>   i0[0] = (int) a;
> }

  And again.

  ELF GAS/LD seem happy enough when presented with a ".comm foo,0" directive,
but PE does rather literally what you asked, and gives you no data object,
leading to i0 in the above being an undefined reference at link time.

  What is supposed to happen here?  How much space is the compiler meant to
allocate to i0?  Where does the data go when it gets stored to i0[0]?

  I've read http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html about six times
and can't see anywhere it even hints that you can use this syntax anywhere
except as the trailing member of a struct.  When I look at the original
PR11535, the testcases in there are all similar but have array size [1] and
try to assign the builtin_return_address result to array[0] - that's clearly
valid, and quite different from how this testcase ended up.

  So, is the testcase invalid, and should the compiler be warning about this
declaration?  I couldn't get any complaint out of it even with "-W -Wall
-Wextra -pedantic -std=c89"?  Or should the linker be allocating some space
for this zero-sized common?

cheers,
  DaveK

Re: What does zero-length array mean at file scope?

[Dave Korn]

Dave Korn wrote:

>   ELF GAS/LD seem happy enough when presented with a ".comm foo,0" directive,
> but PE does rather literally what you asked, and gives you no data object,
> leading to i0 in the above being an undefined reference at link time.

  After a bit further digging, it turns out that this is because PE uses the
same representation for an external symbol as would represent a common of size
0, so if you define such a common, it magically becomes an undefined external
symbol instead!

  Owing to lack of support for alignment of common symbols in PE, we've been
rounding all sizes up to a multiple of 16 until now, including zero, which has
hidden this problem from arising.  In the patch I just posted at

http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01528.html

we can now align common symbols, so we don't round any more - and thus get an
actual zero-sized symbol definition passed to the assembler for the first time.

  I do think we probably ought to be erroring about this on both platforms,
shouldn't we?  I can always hack the output routine to (for example) use one
unit of the alignment size as the minimum to work around this problem and let
the testcase run, but I wonder if a warning is getting lost somewhere owing to
array->pointer flattening?

cheers,
  DaveK

Re: What does zero-length array mean at file scope?

[Dave Korn]

Dave Korn wrote:
> Dave Korn wrote:
> 
>>   ELF GAS/LD seem happy enough when presented with a ".comm foo,0" directive,
>> but PE does rather literally what you asked, and gives you no data object,
>> leading to i0 in the above being an undefined reference at link time.
> 
>   After a bit further digging, it turns out that this is because PE uses the
> same representation for an external symbol as would represent a common of size
> 0, so if you define such a common, it magically becomes an undefined external
> symbol instead!

  And testing it on Linux, I see that the linker goes ahead and assigns zero
bytes of the common area to i0, then assigns four bytes of common space to i1
at the same address, so writing to i0[0] aliases and alters i1.  That
certainly sounds like undefined behaviour to me!

cheers,
  DaveK