FAIL: gcc.target/i386/sse2-vec-5.c on gcc-4.2 branch
Hello H.J.! The testscase gcc.target/i386/sse2-vec-5.c you ported from mainline fails on gcc-4.2 branch because __builtin_ia32_vec_ext_v16qi builtin does not exist in gcc-4.2. This builtin corresponds to pextrb insn that was introduced in SSE4 (gcc-4.3). Also, the definition of __builtin_ia32_vec_ext_v16qi in the mainline should be enabled only for OPTION_MASK_ISA_SSE4_1, as current definition is also enabled for SSE2: def_builtin (OPTION_MASK_ISA_SSE2, "__builtin_ia32_vec_ext_v16qi", ftype, IX86_BUILTIN_VEC_EXT_V16QI); I propose that sse2-vec-5.c is removed from the testsuite in gcc-4_2 branch and mainline. Thanks, Uros.
Re: libgcc fails to compile if DItype is not supported [bswapdi2]
On Jun 20, 2007, at 9:40 PM, Pompapathi V Gadad wrote: Hello Eric, The target I am working on is 16-bit target and cannot support 64- bit data types (DI mode). How about conditionally declare the function? #if LONG_LONG_TYPE_SIZE > 32 extern DItype __bswapdi2 (DItype); #endif You'll want to do it where the function is compiled, see other functions that use DItype. :) Or, I'll probably get to it in a day or two... -eric
Re: libgcc fails to compile if DItype is not supported [bswapdi2]
Hello Eric,
bswapdi2 is implemented in libgcc2.c as follows:
#ifdef L_bswapdi2
DItype
__bswapdi2 (DItype u)
{
...
}
#endif
One way to avoid compilation of this function is to add condition macros
like: #if LONG_LONG_TYPE_SIZE > 32
However, libgcc2.h does not have such facility and declaration will be
included unconditionally. This will cause compilation failure if DItype
is not supported. I guess, libgcc2.h does not declare most of functions
with explicit SItype or DItype, it mostly uses Wtype and DWtype. Please
correct me if I am wrong. It would be very helpful to conditionally
declare such functions in libgcc2.h.
Thanks a lot for looking into this matter. I will be waiting for you
next mail.
Regards,
Pompa
Eric Christopher wrote:
On Jun 20, 2007, at 9:40 PM, Pompapathi V Gadad wrote:
Hello Eric,
The target I am working on is 16-bit target and cannot support 64-bit
data types (DI mode).
How about conditionally declare the function?
#if LONG_LONG_TYPE_SIZE > 32
extern DItype __bswapdi2 (DItype);
#endif
You'll want to do it where the function is compiled, see other
functions that use DItype. :)
Or, I'll probably get to it in a day or two...
-eric
Re: m68k bootstrap problem
Hi,
On Wed, 20 Jun 2007, I wrote:
> Index: gcc/df-problems.c
> ===
> --- gcc/df-problems.c (revision 125811)
> +++ gcc/df-problems.c (working copy)
> @@ -1574,7 +1574,7 @@
>/* Call-clobbered registers die across exception and call edges. */
>/* ??? Abnormal call edges ignored for the moment, as this gets
> confused by sibling call edges, which crashes reg-stack. */
> - if (e->flags & EDGE_EH)
> + if ((e->flags & EDGE_EH) || (e->flags & EDGE_SIBCALL))
> bitmap_ior_and_compl_into (op1, op2, df_invalidated_by_call);
>else
> bitmap_ior_into (op1, op2);
Adding the patch below seems to make reg-stack happy, so this may be a way
to fix the edge information.
bye, Roman
Index: gcc/gcc/reg-stack.c
===
--- gcc.orig/gcc/reg-stack.c
+++ gcc/gcc/reg-stack.c
@@ -2316,6 +2316,12 @@ subst_stack_regs (rtx insn, stack regsta
if (NOTE_P (insn) || INSN_DELETED_P (insn))
return control_flow_insn_deleted;
+ if (SIBLING_CALL_P (insn))
+{
+ CLEAR_HARD_REG_SET (regstack->reg_set);
+ return control_flow_insn_deleted;
+}
+
/* If this a noreturn call, we can't insert pop insns after it.
Instead, reset the stack state to empty. */
if (CALL_P (insn)
Gcc trees
Hello. i am Alberto I work with Gcc trees to modify c++ original code and dont find and i need documentation about trees because the web isnt enought information. Where are docs about gcc trees and macros to access it? Thanks you Alberto
Re: m68k bootstrap problem
Roman Zippel wrote:
> Hi,
>
> On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
>
>
>> If we add the dead note there we are asserting that the value is
>> modified by the caller. however it might not be and someone could write
>> a piece of asm right after the call to use that reg if the person knew
>> that the reg was not modified by that particular call.
>>
>
> I have big problems to see this as a valid example, this sounds just
> broken. First off the user had to know the register was alive before and
> then the user had to magically know the register isn't clobbered by the
> call (e.g. loading the address of the function into that register).
> You could declare the variable as asm register variable, then it might
> work, but then the register wouldn't be available for allocation anyway
> and the whole problem changes.
>
>
>> having the dead note there is asserting to the register allocator that
>> they are free to use that reg after the calll in any way that it wants
>> and there is a (small) possibility that is wrong.
>>
>
> IMO there is nothing wrong with this.
>
> bye, Roman
>
This patch fixes a problem with creating reg_dead notes. The code for
actually creating the note for an insn was correct, but the code to
actually propagate the liveness info thru the block in order to create
the notes was defective. This patch fixes that.
OK to commit?
2007-06-21 Kenneth Zadeck <[EMAIL PROTECTED]>
* df-problems.c (df_note_bb_compute): Made computation of live
info consistent with df_lr.
Index: df-problems.c
===
--- df-problems.c (revision 125898)
+++ df-problems.c (working copy)
@@ -46,6 +46,9 @@ Software Foundation, 51 Franklin Street,
#include "dce.h"
#include "vecprim.h"
+/* Note that turning REG_DEAD_DEBUGGING on will cause
+ gcc.c-torture/unsorted/dump-noaddr.c to fail because it prints
+ addresses in the dumps. */
#if 0
#define REG_DEAD_DEBUGGING
#endif
@@ -3960,8 +3963,8 @@ df_note_bb_compute (unsigned int bb_inde
df_print_regset (dump_file, live);
}
#endif
- /* We only care about real sets for calls. Clobbers only
- may clobbers cannot be depended on. */
+ /* We only care about real sets for calls. Clobbers cannot
+ be depended on to really die. */
mws_rec = DF_INSN_UID_MWS (uid);
while (*mws_rec)
{
@@ -3985,6 +3988,11 @@ df_note_bb_compute (unsigned int bb_inde
= df_create_unused_note (insn, old_unused_notes,
def, live, do_not_gen,
artificial_uses);
+
+ /* However a may or must clobber still still needs to
+ kill the reg. */
+ else
+ bitmap_clear_bit (live, DF_REF_REGNO (def));
}
}
else
Re: Gcc trees
[EMAIL PROTECTED] wrote on 21/06/2007 15:44:27: > Hello. i am Alberto > > I work with Gcc trees to modify c++ original code and dont find and i > need documentation about trees because the web isnt enought information. > > Where are docs about gcc trees and macros to access it? > In GCC wiki you may find useful links: http://gcc.gnu.org/wiki (like GCC internal) Looking at the GCC sources may also help... Revital > Thanks you > > Alberto
Re: m68k bootstrap problem
Kenneth Zadeck <[EMAIL PROTECTED]> writes: > @@ -3985,6 +3988,11 @@ df_note_bb_compute (unsigned int bb_inde > = df_create_unused_note (insn, old_unused_notes, > def, live, do_not_gen, > artificial_uses); > + > + /* However a may or must clobber still still needs to s/still still/still/ Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: FAIL: gcc.target/i386/sse2-vec-5.c on gcc-4.2 branch
On Thu, Jun 21, 2007 at 10:14:55AM +0200, Uros Bizjak wrote:
> Hello H.J.!
>
> The testscase gcc.target/i386/sse2-vec-5.c you ported from mainline
> fails on gcc-4.2 branch because __builtin_ia32_vec_ext_v16qi builtin
> does not exist in gcc-4.2. This builtin corresponds to pextrb insn
> that was introduced in SSE4 (gcc-4.3).
>
> Also, the definition of __builtin_ia32_vec_ext_v16qi in the mainline
> should be enabled only for OPTION_MASK_ISA_SSE4_1, as current
> definition is also enabled for SSE2:
>
> def_builtin (OPTION_MASK_ISA_SSE2, "__builtin_ia32_vec_ext_v16qi",
> ftype, IX86_BUILTIN_VEC_EXT_V16QI);
>
> I propose that sse2-vec-5.c is removed from the testsuite in gcc-4_2
> branch and mainline.
__builtin_ia32_vec_ext_v16qi, like many other vector extra builtins,
is supported by SSE2, but not with single instruction. I don't think
it should be removed from mainline.
bash-3.1$ cat /tmp/v.c
#include
int
foo (__m128i x)
{
return __builtin_ia32_vec_ext_v16qi ((__v16qi) x, 3);
}
bash-3.1$ ./xgcc -B./ -msse2 -O -S /tmp/v.c -m32
bash-3.1$ cat v.s
.file "v.c"
.text
.globl foo
.type foo, @function
foo:
pushl %ebp
movl%esp, %ebp
movdqa %xmm0, -24(%ebp)
movsbl -21(%ebp),%eax
leave
ret
.size foo, .-foo
.ident "GCC: (GNU) 4.3.0 20070619 (experimental) [trunk
revision 125849]"
.section.note.GNU-stack,"",@progbits
bash-3.1$
I will remove sse2-vec-5.c from 4.2 since __builtin_ia32_vec_ext_v16qi
isn't available there.
H.J.
Re: FAIL: gcc.target/i386/sse2-vec-5.c on gcc-4.2 branch
On 6/21/07, H. J. Lu <[EMAIL PROTECTED]> wrote: > Also, the definition of __builtin_ia32_vec_ext_v16qi in the mainline > should be enabled only for OPTION_MASK_ISA_SSE4_1, as current > definition is also enabled for SSE2: > > def_builtin (OPTION_MASK_ISA_SSE2, "__builtin_ia32_vec_ext_v16qi", > ftype, IX86_BUILTIN_VEC_EXT_V16QI); > > I propose that sse2-vec-5.c is removed from the testsuite in gcc-4_2 > branch and mainline. __builtin_ia32_vec_ext_v16qi, like many other vector extra builtins, is supported by SSE2, but not with single instruction. I don't think it should be removed from mainline. I hardly see the point of having builtin for non-existing insn, but if this is the case, we should add missing definition to gcc-4.2 (it is a three-liner patch). I will remove sse2-vec-5.c from 4.2 since __builtin_ia32_vec_ext_v16qi isn't available there. No, a better solution is to add missing builtin definition to gcc-4.2. Uros.
Bootstrap comparison failure on powerpc64 for Ada
Hello, I get the following bootstrap comparison failure on powerpc64 for Ada (--enable-languages=ada) with BOOT_CFLAGS='-O2'. Revital make[2]: Entering directory `/home/revital/mainline_ccp/build' make[3]: Entering directory `/home/revital/mainline_ccp/build' rm -f stage_current make[3]: Leaving directory `/home/revital/mainline_ccp/build' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs Bootstrap comparison failure! ./ada/a-except.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/revital/mainline_ccp/build' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/revital/
Re: m68k bootstrap problem
+ + /* However a may or must clobber still still needs to +kill the reg. */ Add here "so that REG_DEAD notes are later placed appropriately". Ok, thanks! Paolo
Re: GCC Status Report (2007-06-15)
On Mon, Jun 18, 2007 at 04:46:10PM +1000, Ben Elliston wrote: > On Sat, 2007-06-16 at 06:17 -0700, H. J. Lu wrote: > > > BTW, an x86 DFP configure bug was reported 3 months ago. But it still > > hasn't benen fixed. I opened a DFP bug report: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32351 > > > > with a patch. I hope it will be fixed before gcc 4.3 is released :-). > > Sorry about the delay. Yes, I assure you it will be fixed by then and > perhaps by the end of this week .. :-) Hi Ben, Can you take a look at this patch: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01052.html I'd like to TFmode conversion supprot to DFP. Currently libdecnumber doesn't support TFmode conversion. Intel BID library does. I need this patch to enable TFmode conversion. It has no impact on DFP runtime with libdecnumber. Thanks. H.J.
$Revision$ in version string?
Hello! Is there a way to add automatically updated SVN revision number to gcc version string? Something similar to $Revision$ in RCS? I think it would be quite informative if during development phase "gcc --version" would report it like: gcc --version gcc (GCC) 4.3.0 20070621 (experimental) Revision X Perhaps it can also include branch name. Uros.
Re: $Revision$ in version string?
On Thu, Jun 21, 2007 at 05:24:12PM +0200, Uros Bizjak wrote:
> Hello!
>
> Is there a way to add automatically updated SVN revision number to gcc
> version string? Something similar to $Revision$ in RCS?
>
> I think it would be quite informative if during development phase "gcc
> --version" would report it like:
>
> gcc --version
> gcc (GCC) 4.3.0 20070621 (experimental) Revision X
>
> Perhaps it can also include branch name.
>
See
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00966.html
I got
[EMAIL PROTECTED] applied]$ /usr/gcc-4.3/bin/gcc --version
gcc (GCC) 4.3.0 20070612 (experimental) [trunk revision 125661]
...
[EMAIL PROTECTED] result]$ /usr/gcc-4.2/bin/gcc --version
gcc (GCC) 4.2.1 20070619 (prerelease) [gcc-4_2-branch revision 125849]
...
I am enclosing 2 patches I have been using for more than a year.
H.J.
Index: contrib/gcc_update
===
--- contrib/gcc_update (revision 116299)
+++ contrib/gcc_update (working copy)
@@ -255,8 +255,18 @@ if [ $? -ne 0 ]; then
exit 1
fi
+rm -f info.$$ LAST_UPDATED gcc/REVISION
+
+svn info > info.$$
+revision=`grep Revision: info.$$ | awk '{ print $2 }'`
+branch=`grep URL: info.$$ | sed -e "s,.*/gcc/,,g" | sed -e "s,branches/,,"`
{
date
- echo "`TZ=UTC date` (revision `svnversion .`)"
+ echo "`TZ=UTC date` (revision $revision)"
} > LAST_UPDATED
+
+rm -f info.$$
+
+echo "[$branch revision $revision]" > gcc/REVISION
+
touch_files_reexec
2006-01-23 H.J. Lu <[EMAIL PROTECTED]>
* Makefile.in (REVISION): New.
(REVISION_c): New.
(REVISION_s): New.
(version.o): Also depend on $(REVISION). Add
-DREVISION=$(REVISION_s).
* version.c (version_string): Add REVISION.
--- gcc/Makefile.in.rev 2006-01-23 10:00:31.0 -0800
+++ gcc/Makefile.in 2006-01-23 10:29:38.0 -0800
@@ -710,11 +710,18 @@ TM_H = $(GTM_H) insn-constants.h in
BASEVER := $(srcdir)/BASE-VER # 4.x.y
DEVPHASE:= $(srcdir)/DEV-PHASE # experimental, prerelease, ""
DATESTAMP := $(srcdir)/DATESTAMP # MMDD or empty
+REVISION:= $(srcdir)/REVISION # [BRANCH revision XX]
BASEVER_c := $(shell cat $(BASEVER))
DEVPHASE_c := $(shell cat $(DEVPHASE))
DATESTAMP_c := $(shell cat $(DATESTAMP))
+ifeq (,$(wildcard $(REVISION)))
+REVISION:=
+else
+REVISION_c := $(shell cat $(REVISION))
+endif
+
version := $(BASEVER_c)
# For use in version.c - double quoted strings, with appropriate
@@ -726,6 +733,12 @@ BASEVER_s := "\"$(BASEVER_c)\""
DEVPHASE_s := "\"$(if $(DEVPHASE_c), ($(DEVPHASE_c)))\""
DATESTAMP_s := "\"$(if $(DEVPHASE_c), $(DATESTAMP_c))\""
+ifdef REVISION_c
+REVISION_s := "\"$(if $(DEVPHASE_c), $(REVISION_c))\""
+else
+REVISION_s :=
+endif
+
# Shorthand variables for dependency lists.
TARGET_H = $(TM_H) target.h insn-modes.h
MACHMODE_H = machmode.h mode-classes.def insn-modes.h
@@ -1742,9 +1755,10 @@ options.o: options.c $(CONFIG_H) $(SYSTE
dumpvers: dumpvers.c
-version.o: version.c version.h $(DATESTAMP) $(BASEVER) $(DEVPHASE)
+version.o: version.c version.h $(REVISION) $(DATESTAMP) $(BASEVER) $(DEVPHASE)
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) \
-DBASEVER=$(BASEVER_s) -DDATESTAMP=$(DATESTAMP_s) \
+ -DREVISION=$(REVISION_s) \
-DDEVPHASE=$(DEVPHASE_s) -c $(srcdir)/version.c $(OUTPUT_OPTION)
gtype-desc.o: gtype-desc.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \
--- gcc/version.c.rev 2005-11-04 14:14:18.0 -0800
+++ gcc/version.c 2006-01-23 10:30:19.0 -0800
@@ -20,6 +20,7 @@
const char bug_report_url[] = "http://gcc.gnu.org/bugs.html>";
/* The complete version string, assembled from several pieces.
- BASEVER, DATESTAMP, and DEVPHASE are defined by the Makefile. */
+ BASEVER, DATESTAMP, DEVPHASE, and REVISION are defined by the
+ Makefile. */
-const char version_string[] = BASEVER DATESTAMP DEVPHASE VERSUFFIX;
+const char version_string[] = BASEVER DATESTAMP DEVPHASE VERSUFFIX REVISION;
Re: $Revision$ in version string?
Hi,
Uros Bizjak wrote:
> Is there a way to add automatically updated SVN revision number to gcc
> version string? Something similar to $Revision$ in RCS?
Well, the problem with $Revision$ is that it only refects the revision
of that single file.
> I think it would be quite informative if during development phase[...]
> gcc --version
> gcc (GCC) 4.3.0 20070621 (experimental) Revision X
I would like this as well. Maybe something along the following would work:
STRING=""
if [ -d "$CONFIGURE/.svn" -a -n "`svn 2>&1`" ]; then
REV="`svn info "$CONFIGURE"|grep Revi|awk '{print $2}'`"
BRANCH=`svn info "$CONFIGURE"|grep URL|sed -e 's#.*/##'`
STRING=" Revision $REV ($BRANCH)"
end if
Where $CONFIGURE is the directory where "./configure" is. The Revision
should be determined when running make.
Tobias
Re: Bootstrap comparison failure on powerpc64 for Ada
> I get the following bootstrap comparison failure on powerpc64 > for Ada (--enable-languages=ada) with BOOT_CFLAGS='-O2'. > > Revital > > make[2]: Entering directory `/home/revital/mainline_ccp/build' > make[3]: Entering directory `/home/revital/mainline_ccp/build' > rm -f stage_current > make[3]: Leaving directory `/home/revital/mainline_ccp/build' > Comparing stages 2 and 3 > warning: ./cc1-checksum.o differs > Bootstrap comparison failure! > ./ada/a-except.o differs Which revision? The Ada compiler bootstraps fine on i586 and x86-64 at revision 125912:125915M (i.e with structural alias analysis enabled). Unfortunately I'm not sure we have 64-bit PowerPC machines at AdaCore. -- Eric Botcazou
Re: m68k bootstrap problem
Paolo Bonzini wrote: > + > + /* However a may or must clobber still still needs to > + kill the reg. */ > > Add here "so that REG_DEAD notes are later placed appropriately". Ok, > thanks! > > Paolo so is this an ok to commit with this change?
Re: Bootstrap comparison failure on powerpc64 for Ada
> > make[2]: Entering directory `/home/revital/mainline_ccp/build' > > make[3]: Entering directory `/home/revital/mainline_ccp/build' > > rm -f stage_current > > make[3]: Leaving directory `/home/revital/mainline_ccp/build' > > Comparing stages 2 and 3 > > warning: ./cc1-checksum.o differs > > Bootstrap comparison failure! > > ./ada/a-except.o differs > > Which revision? The Ada compiler bootstraps fine on i586 and x86-64 at > revision 125912:125915M (i.e with structural alias analysis enabled). Note that if cc1-checksum.o differs, it likely means the issue is unrelated to Ada. Arno
Re: Bootstrap comparison failure on powerpc64 for Ada
> Which revision? The Ada compiler bootstraps fine on i586 and x86-64 at > revision 125912:125915M (i.e with structural alias analysis enabled). > revision 125915. Thanks, Revital
Re: Bootstrap comparison failure on powerpc64 for Ada
> > > > Which revision? The Ada compiler bootstraps fine on i586 and x86-64 at > > revision 125912:125915M (i.e with structural alias analysis enabled). > > Note that if cc1-checksum.o differs, it likely means the issue is unrelated to > Ada. I am now bootstrapping only c. If that will pass OK I can check Ada on an older revision if you wish. Revital > > Arno
Re: Bootstrap comparison failure on powerpc64 for Ada
> Note that if cc1-checksum.o differs, it likely means the issue is unrelated > to Ada. cc1-checksum.o very offen differs on my machine, it doesn't stop the build. -- Eric Botcazou
Re: $Revision$ in version string?
Uros Bizjak wrote: Hello! Is there a way to add automatically updated SVN revision number to gcc version string? Something similar to $Revision$ in RCS? I think it would be quite informative if during development phase "gcc --version" would report it like: gcc --version gcc (GCC) 4.3.0 20070621 (experimental) Revision X Perhaps it can also include branch name. I have the following in my build script: echo $VERSION > $BLDDIR/gcc/gcc/DEV-PHASE $VERSION shows up in place of "experimental". -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Bootstrap comparison failure on powerpc64 for Ada
> I am now bootstrapping only c. If that will pass OK I can check Ada on > an older revision if you wish. I'm not sure that would really help in this case. The fact that x86 and x86-64 are both clean with structural alias analysis would seem to show that there is no fundamental bad interaction between it and Ada anymore. We cannot really debug on PowerPC 64-bit so I'd suggest to disable Ada in your builds for the time being (unless you have the time to investigate yourself). Maybe the problem will arise on other platforms and we'll be able to debug it. -- Eric Botcazou
Re: Bootstrap comparison failure on powerpc64 for Ada
Eric Botcazou <[EMAIL PROTECTED]> wrote on 21/06/2007 21:10:15: > > I am now bootstrapping only c. If that will pass OK I can check Ada on > > an older revision if you wish. > > I'm not sure that would really help in this case. The fact that x86 and > x86-64 are both clean with structural alias analysis would seem to show > that there is no fundamental bad interaction between it and Ada anymore. > > We cannot really debug on PowerPC 64-bit so I'd suggest to disable Ada in your > builds for the time being (unless you have the time to investigate yourself). > > Maybe the problem will arise on other platforms and we'll be able to debug it. OK. BTW - the c bootstrap passed OK. Thanks, Revital > > -- > Eric Botcazou
Re: GCC 4.3.0 Status Report (2007-06-07)
I submitted the first patch for the function argument infrastructure change over at gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01569.html -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
Re: I'm sorry, but this is unacceptable (union members and ctors)
michael.a wrote: > > Will likely be a good while before I can report whether simply knocking > out the errors cause any run-time issues. Is there some reason why stdarg.h would not be on my system (amd64 ubuntu) I can find it in the various gcc source trees (apparently gcc brings its own) ...is it safe to just copy that one? I'm assuming it belongs in /usr/include. -- View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11242651 Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: I'm sorry, but this is unacceptable (union members and ctors)
On Thu, Jun 21, 2007 at 03:08:00PM -0700, michael.a wrote: > > > > michael.a wrote: > > > > Will likely be a good while before I can report whether simply knocking > > out the errors cause any run-time issues. > > Is there some reason why stdarg.h would not be on my system (amd64 ubuntu) > > I can find it in the various gcc source trees (apparently gcc brings its > own) ...is it safe to just copy that one? I'm assuming it belongs in > /usr/include. > > -- > View this message in context: > http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11242651 > Sent from the gcc - Dev mailing list archive at Nabble.com. > You probably should root around to find out why it isn't installed. I would suspect you did not install the appropriate development packages or somehow your compilation system is messed up. Stdarg.h should be installed in the private diretory the compiler keeps its own include files (different revs of GCC have needed different stdarg.h's in the past, so it is compiler specific). For example on my Fedora 6 system it is in: /usr/lib/gcc/x86_64-redhat-linux/4.1.1/include/stdarg.h -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
Re: I'm sorry, but this is unacceptable (union members and ctors)
Meissner, Michael wrote: > > > You probably should root around to find out why it isn't installed. I > would > suspect you did not install the appropriate development packages or > somehow > your compilation system is messed up. > I rooted thoroughly, not wanting to make this post for fear of reprisal for being offtopic. For one reason or another, it is nearly impossible to find relevant answers to these sorts of matter via google. > Stdarg.h should be installed in the > private diretory the compiler keeps its own include files (different revs > of > GCC have needed different stdarg.h's in the past, so it is compiler > specific). > For example on my Fedora 6 system it is in: > /usr/lib/gcc/x86_64-redhat-linux/4.1.1/include/stdarg.h > That explains a lot. The best sources I could find seemed to think it should be installed by libc6-dev type packages. I doo see some instances in such locations (I should've filtered out the error lines from the find output) I guess I will have to sort out why the compiler isn't finding it (any advice is welcome -- just for the record, I did a straight install from packaged sources with previous gcc installs removed before hand) -- View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11243439 Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: I'm sorry, but this is unacceptable (union members and ctors)
michael.a wrote: > > > I guess I will have to sort out why the compiler isn't finding it (any > advice is welcome -- just for the record, I did a straight install from > packaged sources with previous gcc installs removed before hand) > > Actually, funny story... I was actually looking for vsnprintf, and just assumed stdarg.h was the culprit because it twasn't there (should've looked for a stdarg.h including error - summer is a bit warm) ...actually turned out the Microsoft cruntime libraries declare vsnprintf as _vsnprintf, so I just assumed it would be so. Looks like I out thunked myself this time (learned some things though) -- View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11243667 Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: Type-punning
Herman Geza wrote:
struct A {
float x, y;
};
struct B {
float x, y;
};
int main() {
A a;
B &b = reinterpret_cast(a);
}
I get a type-punned warning for this code. However, A & B is exactly the
same type. Is the warning appropriate here?
Unfortunately gcc 4.3 will likely warn on this as well. To avoid it, we
would need a "prefix" analysis to distinguish between different structs
that are compatible up to a point. As far as I know, GCC does not have
this capability as of now. If it exists, it still needs to be connected
to -Wstrict-aliasing, which is generally not trivial, as it requires
figuring out what field is referenced where. I guess it could be
implemented in a simpler way for the special case when the structs are
identical structurally.
Where can I find the
definition of "almost the same [type]"?
C and C++ standards:
C Standard ISO/IEC 9899:1999, section 6.5, paragraph 7, and the C++
Standard ISO/IEC 14882:1998, section 3.10, paragraph 15. But there are
a couple other references that touch this.
What is the correct way to do this:
void setNaN(float &v) {
reinterpret_cast(v) = 0x7f81;
}
without a type-prunning warning? I cannot use the union trick here
(memcpy works though, but it's not the most efficient solution, I
suppose).
The correct and efficient solution is to use memcpy. GCC should
recognize the memcpy call and transform it into a move or load/store or
such.
You may want to try memcpy, generate the assembly code, and see if you
are happy with it.
RE: [M16C] : 20 bit data access
Hi DJ,
By default all the constant variables will be stored in the far memory
('.frodata' section) and will be accessed using "LDE" instruction. The
non-initialized non-constant variables will be stored in near memory
('.nbss' section) and will be accessed using "MOV" instructions. The
initialized non-constant variables will be stored in near memory
('.ndata' section) and will be accessed using "MOV" instructions.
* By default, all the constant variables will be placed in the far
memory. They will be accessed using LDE instructions ('.frodata'
section)).
* New attribute "near" will be added. This attribute will be used for
the latest M16C targets that have 4K/8K flash in near Memory.
* Constant variables specified with the attribute "near" will be placed
in a section ".nrodata" (near memory) and will be accessed using "MOV"
instruction.
* By default, non-constant initialized variables will be placed in near
memory.
* By default, non-constant non-initialized variables will be placed in
near memory.
* New attribute "far" (to use external memory for non-constant data
storage) will be added.
* Non-constant non-initialized variables specified with the attribute
"far" will be placed in a section ".fbss" (far memory).
* Non-constant initialized variables specified with the attribute "far"
will be placed in a section ".fdata" (far memory).
* LDE/STE instructions will be used to access the non-constant variables
specified with the attribute "far".
* MOV instructions will be used to access the constant variables
specified with the attribute "near".
* Default linker script will be modified for placing the default section
'.nbss', '.ndata' and '.nrodata' in near memory and '.fbss', '.fdata'
and '.frodata' in far Memory.
* Separate libraries will be used for R8C and M16C targets.
* As the libraries will be built without any attribute, all the constant
data in library will be accessed using LDE instructions. Similarly,
non-constant non-initialised and non-constant initialised data in
library will be accessed using MOV instructions.
> I'd prefer just one "far" attribute. GCC knows (usually better than
> the user ;) what data is read-only and what data is not.
Done
> - By default, LDE instructions will be used to access the entire
> constant variables.
Perhaps with a compiler switch? Like -mcpu=m16c? ;-) I wouldn't want
to use LDE on an r8c which doesn't *have* far memory.
We'd need to add a new multilib for that if we did. If we do add an
m16c multilib, perhaps we should make the m16c 16 bit aligned
internally, to speed performance? Currently, it doesn't, because it's
more important to save space on the r8c, which has an 8 bit internal
bus.
> - New attribute "near_rodata" will be added. This attribute will be
> used for the latest M16C targets that have 4K/8K flash in near Memory.
Again, let's just add "near" and let gcc figure out if it's read-only
or not.
> Please comment on above proposed solutions and also let us know the
> possibility of acceptance of any of these by FSF.
From the above, I think I like this plan:
* Add both "near" and "far" attributes. If a variable has one of
these, it overrides whatever gcc's default is. GCC knows what's
read-only and what isn't, and which chips take advantage of which
attributes, but there's no reason to burden the user with that
decision.
* Add an m16c (vs r8c) multilib, and have it default to "far
constants, near data". Pick up word-alignment too, maybe. This
makes the defaults for most chips close to ideal.
* Add .ndata, .nbss, .nrodata, .fdata, .fbss, .frodata to the linker
scripts. Stuff with near/far attributes goes into .n*/.f* sections.
Depending on the chip, these may just get merged with the usual
.data, .bss, .rodata sections (i.e. m32c and most r8c will always
merge them, most m16c won't merge .rodata, etc).
* If we add an m16c multilib, do we want to add an m32c (vs m32cm)
multilib at the same time? That would let us use the extra 32-bit
insns in libgcc. I'm just thinking, if we're going to change the
multilibs anyway, let's use that change to get some other stuff in
also.
