Re: GCC Internals Wikibook
> There is a wikibook that describes the internals of GCC and GEM, an > extensibility framework. Your internals documentation looks pretty good, so I have made a link to it from gcc.gnu.org/readings.html. Thanks, Ben
gcc-4.2-20060304 is now available
Hello, I downloaded the latest snapshot, and it looks like there's a packaging problem. Downloaded and unpacked gcc-core, created an obj build tree, run bootstrap and this is what happens: make[3]: Entering directory `/home/sfilippo/COMPILERS/GFORTRAN/TEMP/obj/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -fno-common -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.2-20060304/gcc -I../../gcc-4.2-20060304/gcc/build -I../../gcc-4.2-20060304/gcc/../include -I../../gcc-4.2-20060304/gcc/../libcpp/include -I../../gcc-4.2-20060304/gcc/../libdecnumber -I../libdecnumber-o build/gengtype-yacc.o gengtype-yacc.c gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gengtype \ build/gengtype.o build/gengtype-lex.o build/gengtype-yacc.o build/errors.o ../build-i686-pc-linux-gnu/libiberty/libiberty.a make[3]: *** No rule to make target `../../gcc-4.2-20060304/gcc/objc/objc-act.c', needed by `s-gtype'. Stop. make[3]: Leaving directory `/home/sfilippo/COMPILERS/GFORTRAN/TEMP/obj/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/sfilippo/COMPILERS/GFORTRAN/TEMP/obj' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/sfilippo/COMPILERS/GFORTRAN/TEMP/obj' make: *** [bootstrap] Error 2 [EMAIL PROTECTED] obj]$ I reproduced this with just gcc-core, I normally also build g++ and gfortran as well. The problem goes away if I unpack the sources for objc, which I am not really interested in. Any takers? How/against what do I report this? Thanks Salvatore
Re: Coverity Open Source Defect Scan of gcc
So I'm basically asking for people who want to play around with some cool new technology to help make source code better. If this interests you, please feel free to reach out to me directly. And of course, if there are other packages you care about that aren't currently on the list, I want to know about those too. I have signed up for access to the tool and did find a few places where the source code was quite obscure. No real bugs so far though. :-) Paolo
Re: gcc-4.2-20060304 is now available
I reproduced this with just gcc-core, I normally also build g++ and
gfortran as well. The problem goes away if I unpack the sources for
objc, which I am not really interested in.
Any takers? How/against what do I report this?
The problem is that now configure is processing config-lang.in files
even for languages that are not active by default.
It is a bit weird that objcp is included in the gcc-core download. It
could be included in the gcc-objc download (or in a separate objcp
download). But we can work around the problem by restricting the
operation of my patch to "allow typing `make cc1plus' on second
thought", to languages that are built by default.
I don't like the attached patch particularly, but if Salvatore confirms
that it works around his issue, I can give the necessary testing to the
patch.
Paolo
Index: configure.ac
===
--- configure.ac(revision 111635)
+++ configure.ac(working copy)
@@ -3328,13 +3328,6 @@ changequote(,)dnl
esac
changequote([,])dnl
- if test -f $srcdir/$subdir/lang.opt; then
- lang_opt_files="$lang_opt_files $srcdir/$subdir/lang.opt"
- fi
- if test -f $srcdir/$subdir/$subdir-tree.def; then
- lang_tree_files="$lang_tree_files $srcdir/$subdir/$subdir-tree.def"
- fi
-
language=
boot_language=
compilers=
@@ -3347,24 +3340,37 @@ changequote([,])dnl
echo "${srcdir}/$subdir/config-lang.in doesn't set \$language."
1>&2
exit 1
fi
- all_lang_makefrags="$all_lang_makefrags \$(srcdir)/$subdir/Make-lang.in"
- if test -f ${srcdir}/$subdir/Makefile.in
- then all_lang_makefiles="$subdir/Makefile"
- fi
- all_languages="$all_languages $language"
- if test "x$boot_language" = xyes
- then
- all_boot_languages="$all_boot_languages $language"
- fi
- all_compilers="$all_compilers $compilers"
- all_stagestuff="$all_stagestuff $stagestuff"
- all_outputs="$all_outputs $outputs"
- all_gtfiles="$all_gtfiles $gtfiles"
-for f in $gtfiles
-do
- all_gtfiles_files_langs="$all_gtfiles_files_langs ${subdir} "
- all_gtfiles_files_files="$all_gtfiles_files_files ${f} "
-done
+
+ # Don't include languages that are not built by default, unless
+ # specified explicitly.
+case "$build_by_default:,$enable_languages," in
+yes:* | no:*,$lang_alias,*)
+ all_lang_makefrags="$all_lang_makefrags
\$(srcdir)/$subdir/Make-lang.in"
+ if test -f $srcdir/$subdir/lang.opt; then
+ lang_opt_files="$lang_opt_files $srcdir/$subdir/lang.opt"
+ fi
+ if test -f $srcdir/$subdir/$subdir-tree.def; then
+ lang_tree_files="$lang_tree_files
$srcdir/$subdir/$subdir-tree.def"
+ fi
+ if test -f ${srcdir}/$subdir/Makefile.in
+ then all_lang_makefiles="$subdir/Makefile"
+ fi
+ all_languages="$all_languages $language"
+ if test "x$boot_language" = xyes
+ then
+ all_boot_languages="$all_boot_languages $language"
+ fi
+ all_compilers="$all_compilers $compilers"
+ all_stagestuff="$all_stagestuff $stagestuff"
+ all_outputs="$all_outputs $outputs"
+ all_gtfiles="$all_gtfiles $gtfiles"
+ for f in $gtfiles
+ do
+ all_gtfiles_files_langs="$all_gtfiles_files_langs
${subdir} "
+ all_gtfiles_files_files="$all_gtfiles_files_files
${f} "
+ done
+ ;;
+ esac
;;
esac
done
Index: configure
===
--- configure (revision 111635)
+++ configure (working copy)
@@ -15845,13 +15748,6 @@ do
;;
esac
- if test -f $srcdir/$subdir/lang.opt; then
- lang_opt_files="$lang_opt_files $srcdir/$subdir/lang.opt"
- fi
- if test -f $srcdir/$subdir/$subdir-tree.def; then
- lang_tree_files="$lang_tree_files $srcdir/$subdir/$subdir-tree.def"
- fi
-
language=
boot_language=
compilers=
@@ -15864,24 +15760,37 @@ do
echo "${srcdir}/$subdir/config-lang.in doesn't set \$language."
1>&2
exit 1
fi
- all_lang_makefrags="$all_lang_makefrags \$(srcdir)/$subdir/Make-lang.in"
- if test -f ${srcdir}/$subdir/Makefile.in
- then all_lang_makefiles="$subdir/Makefile"
- fi
- all_languages="$all_languages $language"
- if test "x$boot_language" = xyes
- then
- all_boot_languages="$all_boot_languages $language"
- fi
- all_compilers="$all_
Is this a bug of gcc ?
Hello,
I cannot compile a code that seems correct to me. I have tried with
gcc 3.3 and gcc 4.0.1 on MacOS X-ppc, and gcc 4.0.1 on Linux i686.
Here is the code, that uses pure virtual functions and simple
inheritance.
//-
struct a
{
virtual int foo() =0;
virtual ~a(){}
};
struct b : public a
{
virtual int foo(int a) =0;
virtual ~b(){}
};
struct c : public b
{
int test()
{
return (foo() + // <--- the compiler claims here that it cannot
find foo()
foo(2));
}
virtual ~c(){}
};
struct d : public c
{
virtual int foo() {return 1;}
virtual int foo(int a) {return a;}
virtual ~d(){}
};
int main()
{
d call;
return call.test();
}
//-
The compiler claims that it cannot find foo. I have found two
possible workarounds :
-repeat the "virtual int foo() =0;" prototype in the declaration of
struct b
or
-change the foo(void) function into a bar(void) function.
I am under the impression that it is a bug of gcc. Should I fill a
bug, or am I the one who is confused ?
Pierre Chatelier
Re: Is this a bug of gcc ?
On Mar 6, 2006, at 8:12 AM, Pierre Chatelier wrote:
Hello,
I cannot compile a code that seems correct to me. I have tried with
gcc 3.3 and gcc 4.0.1 on MacOS X-ppc, and gcc 4.0.1 on Linux i686.
Here is the code, that uses pure virtual functions and simple
inheritance.
//-
struct a
{
virtual int foo() =0;
virtual ~a(){}
};
struct b : public a
{
virtual int foo(int a) =0;
virtual ~b(){}
};
struct c : public b
{
int test()
{
return (foo() + // <--- the compiler claims here that it cannot
find foo()
foo(2));
}
virtual ~c(){}
};
This is not a bug in gcc. foo in b hides the one from a.
You can "fix" the source by:
struct b : public a
{
virtual int foo(int a) =0;
using a::foo;
virtual ~b(){}
};
Which interjects foo from a into b's "namespace".
-- Pinski
Re: Is this a bug of gcc ?
Thanks for the quick answer.
This is ok to fix the source, but I do not understand why it is
normal behaviour that the foo() in b hides the one from a. They have
different prototypes.
Regards,
Pierre Chatelier
This is not a bug in gcc. foo in b hides the one from a.
You can "fix" the source by:
struct b : public a
{
virtual int foo(int a) =0;
using a::foo;
virtual ~b(){}
};
Re: GCC Internals Wikibook
There is a wikibook that describes the internals of GCC and GEM, an extensibility framework. Your internals documentation looks pretty good, so I have made a link to it from gcc.gnu.org/readings.html. Thanks, It describes AST part of GCC source code. We would like to ask developers to work on the intermediate representation and backends. When the book gets comprehensive enough we will generate a PDF from it for a convenient distribution. Alexey
Re: gcc-4.2-20060304 is now available
On Mon, 6 Mar 2006, Paolo Bonzini wrote: > It is a bit weird that objcp is included in the gcc-core download. It could > be included in the gcc-objc download (or in a separate objcp download). But It should go in an objcp download. sourcebuild.texi includes updating the release script as one of the things to do when contributing a new front end. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: GCC 4.0.3 RC1
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> GCC 4.0.3 RC1 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.3-20060303
>
> Please download and test!
There are failures on sh4-*-linux-gnu during libjava build and 65
unusual regressions for C++ testsuite. I don't file PRs for them
because it looks these are the same problems as PR target/22553
and PR target/23706 which are the target issues for the exception
solved at 4.1:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23706
It seems that the recent changes on 4.0 branch reveal these target
problems which are latent on 4.0. There are patches for these PRs,
though the patch for 23706 touches the middle end file. I'm unsure
whether to backport it to 4.0.3 is appropriate or not at this last
stage.
Anyway the attached backport patches are tested with bootstrap and
"make -k check" on i686-pc-linux-gnu with no new failures.
Although bootstrap on sh4-unknown-linux-gnu is on going, the result
of the toplevel "make -k check" on x86 cross sh4-unknown-linux-gnu
looks fine.
Regards,
kaz
--
2006-03-06Kaz Kojima <[EMAIL PROTECTED]>
PR target 23706
Backport from 4.1:
* lcm.c (optimize_mode_switching): Clear transp bit for
block with incomming abnormal edges.
PR target 22553
Backport from 4.1:
* config/sh/sh.h (OPTIMIZATION_OPTIONS): Set flag_schedule_insns
to 2 if it's already non-zero.
(OVERRIDE_OPTIONS): Clear flag_schedule_insns if flag_exceptions
is set and warn about it if flag_schedule_insns is 1.
diff -uprN ORIG/gcc-4.0.3-20060303/gcc/lcm.c TMP/gcc-4.0.3-20060303/gcc/lcm.c
--- ORIG/gcc-4.0.3-20060303/gcc/lcm.c 2005-01-18 20:36:31.0 +0900
+++ TMP/gcc-4.0.3-20060303/gcc/lcm.c2006-03-06 10:07:51.0 +0900
@@ -1223,6 +1223,18 @@ optimize_mode_switching (FILE *file)
REG_SET_TO_HARD_REG_SET (live_now,
bb->global_live_at_start);
+
+ /* Pretend the mode is clobbered across abnormal edges. */
+ {
+ edge_iterator ei;
+ edge e;
+ FOR_EACH_EDGE (e, ei, bb->preds)
+ if (e->flags & EDGE_COMPLEX)
+ break;
+ if (e)
+ RESET_BIT (transp[bb->index], j);
+ }
+
for (insn = BB_HEAD (bb);
insn != NULL && insn != NEXT_INSN (BB_END (bb));
insn = NEXT_INSN (insn))
diff -uprN ORIG/gcc-4.0.3-20060303/gcc/config/sh/sh.h
TMP/gcc-4.0.3-20060303/gcc/config/sh/sh.h
--- ORIG/gcc-4.0.3-20060303/gcc/config/sh/sh.h 2006-01-05 08:07:24.0
+0900
+++ TMP/gcc-4.0.3-20060303/gcc/config/sh/sh.h 2006-03-06 10:30:51.0
+0900
@@ -695,6 +695,10 @@ do {
\
if (! (SIZE))\
target_flags |= SAVE_ALL_TR_BIT;\
} \
+ /* If flag_schedule_insns is 1, we set it to 2 here so we know if\
+ the user explicitly requested this to be on or off. */ \
+ if (flag_schedule_insns > 0) \
+flag_schedule_insns = 2; \
} while (0)
#define ASSEMBLER_DIALECT assembler_dialect
@@ -796,6 +800,17 @@ do {
\
SH3 and lower as they give spill failures for R0. */ \
if (!TARGET_HARD_SH4)\
flag_schedule_insns = 0; \
+ /* ??? Current exception handling places basic block boundaries \
+after call_insns. It causes the high pressure on R0 and gives \
+spill failures for R0 in reload. See PR 22553 and the thread \
+on gcc-patches \
+ . */
\
+ else if (flag_exceptions)
\
+ { \
+ if (flag_schedule_insns == 1) \
+ warning (0, "ignoring -fschedule-insns because of exception
handling bug"); \
+ flag_schedule_insns = 0; \
+ } \
} \
\
if (align_loops == 0)
\
Re: gcc-4.2-20060304 is now available
Paolo Bonzini's patch appears to work. What the best solution is long term, is not really my province. Regards Salvatore
Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
Hello, Le lundi 06 mars 2006 à 13:39 +, Colm O' Flaherty a écrit : > Francois, > > I'm really interested in getting a gcc port (gcc backend) for the Microchip > PIC16F family (14 bit instruction, 8 bit word) up and running. I've seen > various mails to the gcc list that refer to this, the most recent being from > you. It a good question. I think 18F is clearly C-oriented architecture, whereas coding C on 16F is not very efficient. In the other hand, 16F is quite simple,it could be a good example, and I better know 16F assembly than 18F assembly (I always coded 18F in C). > > Can you summarise the current status of your port, or any other active gcc > PIC ports that you are aware of? For the moment, I am only studying internal gcc documentation. I will be quite busy until june month, so I don't planned anything for the moment. About this subject, if a french people know well gcc machine descriptor language, I am interessed in being mailled by him, to learn more about that. > > There is an existing open-source C compiler with PIC support (SDCC) that > I've used, but my experience with this is that it isn't as scalable as I > would like (particularly for device support), whereas gcc is a well known > compiler with a solid code base, great platform support, and comes with > pretty much every Linux distribution I've ever seen. I think so. > > Am I mistaken in thinking that if we got a gcc PIC backend up and running, > that we would be able to code for PICs in C, C++, Fortran, Ada, and Java > (subject to memory limitations, etc)??? Thats a dream... I think so, and it's also the dream of a friend. Really, gcc seems have a different behaviour for C-C++ and the others. I can't tell more about that subject, and as far I am concerned, I don't have the competences and the will to use Java on Pic. > > Colm O' Flaherty Francois Poulain
reload problem in GCC 4.1
Hi,
I was trying to feed the "reload" phase with a different hardware
register assignment to pseudo registers (using reg_renumber array)
than the ones produced by local-alloc or global-alloc. However, I get
problems with the following instruction in post-reload.c:391 in
"reload_cse_simplify_operands" function stating that the "insn does
not satisfy constraint".
Can someone please help me if the following instruction has any
specific constraint requirement during register allocation phase?
(insn:HI 100 99 102 8 (parallel [
(set (reg:SI 108)
(div:SI (reg:SI 75 [ prephitmp.6 ])
(reg:SI 74 [ prephitmp.8 ])))
(set (reg:SI 109)
(mod:SI (reg:SI 75 [ prephitmp.6 ])
(reg:SI 74 [ prephitmp.8 ])))
(clobber (reg:CC 17 flags))
]) 196 {*divmodsi4_cltd} (insn_list:REG_DEP_TRUE 99 (nil))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 109)
(expr_list:REG_DEAD (reg:SI 74 [ prephitmp.8 ])
(expr_list:REG_DEAD (reg:SI 75 [ prephitmp.6 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 109)
(nil
regards,
~R
Re: reload problem in GCC 4.1
The architecture for which I generate code is Intel x86.
On 3/6/06, Rajkishore Barik <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I was trying to feed the "reload" phase with a different hardware
> register assignment to pseudo registers (using reg_renumber array)
> than the ones produced by local-alloc or global-alloc. However, I get
> problems with the following instruction in post-reload.c:391 in
> "reload_cse_simplify_operands" function stating that the "insn does
> not satisfy constraint".
> Can someone please help me if the following instruction has any
> specific constraint requirement during register allocation phase?
>
> (insn:HI 100 99 102 8 (parallel [
> (set (reg:SI 108)
> (div:SI (reg:SI 75 [ prephitmp.6 ])
> (reg:SI 74 [ prephitmp.8 ])))
> (set (reg:SI 109)
> (mod:SI (reg:SI 75 [ prephitmp.6 ])
> (reg:SI 74 [ prephitmp.8 ])))
> (clobber (reg:CC 17 flags))
> ]) 196 {*divmodsi4_cltd} (insn_list:REG_DEP_TRUE 99 (nil))
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (expr_list:REG_UNUSED (reg:SI 109)
> (expr_list:REG_DEAD (reg:SI 74 [ prephitmp.8 ])
> (expr_list:REG_DEAD (reg:SI 75 [ prephitmp.6 ])
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (expr_list:REG_UNUSED (reg:SI 109)
> (nil
>
> regards,
> ~R
>
Request for testsuite regression period
I noticed that some testsuite regressions were not getting fixed. There are 3 failures in the gcc.dg/tree-ssa (PR 26344). And 5 in g++.dg (PR 26115 and PR 26114). All of these testsuite regressions have been there for almost three weeks (the C++ have been there over a month now). The patch which caused them has been identified over 48 hours ago. What is the policy for testsuite regressions that have been there for over 48 hours and effect all targets and have not been fixed yet? Should we cause the mainline to go into stage3 until these regressions have been fixed? Since the testsuite helps people know "instantaneous" if they patch is wrong, having known FAILs stay too long just causes confusion. Thanks, Andrew Pinski
Re: Request for testsuite regression period
On Mon, 2006-03-06 at 12:34 -0500, Andrew Pinski wrote: > I noticed that some testsuite regressions were not getting fixed. > There are 3 failures in the gcc.dg/tree-ssa (PR 26344). > And 5 in g++.dg (PR 26115 and PR 26114). > All of these testsuite regressions have been there for almost > three weeks (the C++ have been there over a month now). The > patch which caused them has been identified over 48 hours ago. > > What is the policy for testsuite regressions that have been > there for over 48 hours and effect all targets and have not > been fixed yet? > > Should we cause the mainline to go into stage3 until these > regressions have been fixed? > > Since the testsuite helps people know "instantaneous" if they > patch is wrong, having known FAILs stay too long just causes confusion. If you're that bothered by the failures, then xfail them until I can fix them. Revering the patch would be a giant PITA and would actually make it *HARDER* to fix the Ada problems. You're really not helping here. I'm dealing with things as quickly as I can and prioritizing the incorrect code issues over minor performance issues. \Jeff
Re: Request for testsuite regression period
> You're really not helping here. I'm dealing with things as > quickly as I can and prioritizing the incorrect code issues > over minor performance issues. If you noticed I pointed out other testsuite regressions than just yours. If I had posted the patch (not being a global write maintainer) and it caused the regressions, people would be on my back right now asking for them to be fixed. I reported the failures 3 weeks ago thinking they would be fixed right away. I did the same for the C++ testsuite failures I saw too. Lets look at this a different way. So you missed a couple of failures while bootstrapping and testing, right. The normal term of action is to fix them within 48 as mentioned on the policy page. Now maybe you don't want to follow the policy as you see your self higher than the Steering committee but that is not true. Testsuite failures are annoying as make people quickly think they patch is causing regressions. I can already point one example with the tree-ssa testsuite failures already. In PR 26406, comment #6 and 7: (In reply to comment #6) > Patch that apart from regressing gcc.dg/tree-ssa/20030807-2.c bootstrapped and > tested ok. There is no regressions here as this test is already failing before your patch, see PR 26344. -- Pinski
Re: GCC 4.0.3 RC1
On Sunday 05 March 2006 17:47, Mark Mitchell wrote: > GCC 4.0.3 RC1 is available here: > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.3-20060303 OK on SPARC/Solaris: http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00347.html http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00346.html http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00345.html http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00344.html http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00343.html http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00342.html -- Eric Botcazou
Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)
On Mon, 2006-03-06 at 00:31 +0100, Eric Botcazou wrote:
>
>
> cxa4025 and cxa4033 are very likely yours, originating in a miscompilation of
> the runtime (a-stwifi.adb) at -O2. They succeed if the aforementioned unit
> is compiled at -O2 -fno-tree-vrp. You can pass -a to gnatmake to cause the
> units to be recompiled locally. Same for cxa4028 but with a-strsup.adb.
Here's the relevant bits from the .original dump for
Ada.Strings.Wide_Fixed.Trim:
Ada.Strings.Wide_Fixed.Trim (source, side)
[ ... ]
if (side - 1 <= 1)
{
<<< Unknown tree: loop_stmt
(integer) high >= (integer) low &&
VIEW_CONVERT_EXPRLB0>:MAX_EXPR <(long int) SAVE_EXPR
UB0>, (long int) SAVE_EXPR LB0> -
1>]>(*source.P_ARRAY)[() (integer) high]{lb: (long int)
SAVE_EXPR LB0> sz: 2} == 32
high = (natural___XDLU_0__2147483647) ((integer) high - 1);
>>>
;
}
Of particular interest is the (side - 1 <= 1) conditional which is
implementing this hunk of code from the Trim function:
if Side = Right or else Side = Both then
while High >= Low and then Source (High) = Wide_Space loop
High := High - 1;
end loop;
end if;
side is an enumerated type with the following values
Symbolic name Integer value
left0
right 1
both2
The min/max values associated with the type specify that side
should have the values [0, 2].
Note carefully that the expression (side - 1) will produce a value
outside the defined min/max values for side's type [0, 2] when side
has the value "left".
Not surprisingly, we turn the .original code into this gimple code:
D.5765 = side - 1;
if (D.5765 <= 1)
Where D.5765 is of type ada__strings_trim_end, ie, it's got a range
of [0, 2]. So the computation will produce a result outside the
defined range of the type in the case where side == left.
Not surprisingly, the VRP code optimizes this test. If we know that
D.5765's type has the values [0, 2], then the test is equivalent to
D.5765 != 2, and it's all downhill from there when side == left.
I think it's time to hand this one to the Ada guys :-0
Jeff
Re: [Ada] Fix problem in convert_with_check
On Mon, 2006-03-06 at 00:31 +0100, Eric Botcazou wrote: > cxa4025 and cxa4033 are very likely yours, originating in a miscompilation of > the runtime (a-stwifi.adb) at -O2. They succeed if the aforementioned unit > is compiled at -O2 -fno-tree-vrp. You can pass -a to gnatmake to cause the > units to be recompiled locally. Same for cxa4028 but with a-strsup.adb. One more note, we see the same kind of conditional and test simplification with for cxa4028 in Ada.Strings.Superbounded.Super_Trim. So I'm pretty confident that if we fix the bogus trees generated for a-stwifi.adb that all three of these regressions will be fixed. Jeff
Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
> Like you, I'm still studying the internals of gcc, but I'm close to > being confident enough to start making some changes. Nice ! Le lundi 06 mars 2006 à 17:17 +, Colm O' Flaherty a écrit : > Francois, > > There are only 35 instructions in the 14 bit instruction set, and given > that, in gcc, the main initial work seems to be in describing the targets > instruction set, it might not take much to find out what implementation > issues will occur, by just taking to the time to describe the instructions. > For me, the things that I suspect to be issues are: > > -8 bit ALU > -small memory space > -limited stack space (8 levels on 16F) > -the number of PIC devices (configurations) that would need to be supported > (with the various number of banks, and memory configs) > > Like you, I'm still studying the internals of gcc, but I'm close to being > confident enough to start making some changes. > > Colm
Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)
On Mar 6, 2006, at 1:39 PM, Jeffrey A Law wrote: I think it's time to hand this one to the Ada guys :-0 I bet this is actually a fold issue rather than an Ada front-end issue. -- Pinski
Re: Request for testsuite regression period
On Mon, Mar 06, 2006 at 12:34:42PM -0500, Andrew Pinski wrote: > What is the policy for testsuite regressions that have been > there for over 48 hours and effect all targets and have not > been fixed yet? In this case, wouldn't removing the patch just move breakage from C++ to Ada? Or do I misunderstand?
Re: Request for testsuite regression period
On Mar 6, 2006, at 2:21 PM, Joe Buck wrote: On Mon, Mar 06, 2006 at 12:34:42PM -0500, Andrew Pinski wrote: What is the policy for testsuite regressions that have been there for over 48 hours and effect all targets and have not been fixed yet? In this case, wouldn't removing the patch just move breakage from C++ to Ada? Or do I misunderstand? You are misunderstanding, there are a couple different sets of testsuite regressions. One in gcc.dg/tree-ssa and one in g++.dg. Ada also has a couple too. Reverting Jeff's patch will fix the gcc.dg/tree-ssa regresions and one of Ada's. Rest of Ada testsuite regressions are due to Roger's fold patch. The C++ testsuite regressions are due to Lee Millward's patch on 2006-02-03. Thanks, Andrew Pinski
Re: GCC 4.0.3 RC1
Kaz Kojima wrote: > It seems that the recent changes on 4.0 branch reveal these target > problems which are latent on 4.0. There are patches for these PRs, > though the patch for 23706 touches the middle end file. I'm unsure > whether to backport it to 4.0.3 is appropriate or not at this last > stage. > > Anyway the attached backport patches are tested with bootstrap and > "make -k check" on i686-pc-linux-gnu with no new failures. > Although bootstrap on sh4-unknown-linux-gnu is on going, the result > of the toplevel "make -k check" on x86 cross sh4-unknown-linux-gnu > looks fine. If these patches show an improvement on SH4, please go ahead and check them in. Please inform me of the status ASAP. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Linking with libgomp (ia64-hp-hpux11.23)
I have run into a couple of linking problems trying to test/use -fopenmp and libgomp and I was hoping for some help on where to look and how to fix these problems. Test failures: I get a lot of test failures with: | FAIL: libgomp.c/appendix-a/a.15.1.c (test for excess errors) | Excess errors: | ld: (Warning) Symbol "__udivsi3" is not exported but is imported by a shared library | ld: (Warning) Symbol "__divsi3" is not exported but is imported by a shared library | 2 warnings. __udivsi3 and __divsi3 are of course the integer divide routines that are in libgcc. I can make the test pass by running it with -shared-libgcc, but I am not sure if I should just be trying to add -shared-libgcc when I run libgomp tests or if -shared-libgcc needs to be used when building libgomp itself. Nor am I sure how to do either. The other thing I found was that when I tried to compile a program with -fopenmp outside of the test harness it fails. | $ gcc -fopenmp loop-3.c -o x < | ld: Can't find library or mismatched ABI for -lgomp | Fatal error. When I add -v I see: | collect2 -z +Accept TypeMismatch -u main -o x -lgomp -L/proj/opensrc/nightly/gcc-ia64-hp-hpux11.23-trunk/lib/gcc/ia64-hp-hpux11.23/4.2.0 -L/usr/ccs/lib -L/proj/opensrc/nightly/gcc-ia64-hp-hpux11.23-trunk/lib/gcc/ia64-hp-hpux11.23/4.2.0/../../.. /var/tmp//ccGr80UQ.o -lgcc -lgcc_eh -lunwind -lpthread -lc -lgcc -lgcc_eh -lunwind Notice that the -lgomp comes in front of the -L flags. With the HP linker this means that those directories will not be searched for libgomp. If I move the -lgomp to after the -L options then I find libgomp. When I do move -lgomp later in the link though I get the messages about __divsi3 and __udivsi3, so I think that means that I need to have libgomp built with the -lgcc_s option. Any Help/Advice? Steve Ellcey [EMAIL PROTECTED]
Re: Request for testsuite regression period
On Mon, 2006-03-06 at 14:26 -0500, Andrew Pinski wrote: > On Mar 6, 2006, at 2:21 PM, Joe Buck wrote: > > > On Mon, Mar 06, 2006 at 12:34:42PM -0500, Andrew Pinski wrote: > >> What is the policy for testsuite regressions that have been > >> there for over 48 hours and effect all targets and have not > >> been fixed yet? > > > > In this case, wouldn't removing the patch just move breakage from C++ > > to Ada? Or do I misunderstand? > > You are misunderstanding, there are a couple different sets of testsuite > regressions. One in gcc.dg/tree-ssa and one in g++.dg. Ada also has a > couple too. Reverting Jeff's patch will fix the gcc.dg/tree-ssa > regresions And note that revering the patch will introduce new minor missed-optimization regressions. I've focused on the Ada regressions as they have caused compile-time hangs and incorrect code generation. I've worked on the tree-ssa missed optimizations anytime I haven't been working on an Ada regression. Reverting the patch is just a (*&@#$ waste of time at this point. Really, it's a waste of time/energy, much like this conversation. I'm working diligently to address the issues and I'm confident they will be resolved. Has it taken longer than I'd like. No doubt, but that's no surprise as the VRP improvements have uncovered at least a dozen distinct latent bugs. Please, let's focus on fixing the problems rather than reverting patches. If the tree-ssa.exp failures are bugging you that freaking much, then xfail them like I've suggested. They're just missed optimizations and I'm actively investigating a good fix rather than bandaid solutions. Jeff
Re: Request for testsuite regression period
On Mar 6, 2006, at 2:36 PM, Jeffrey A Law wrote: Reverting the patch is just a (*&@#$ waste of time at this point. Really, it's a waste of time/energy, much like this conversation. This is a policy conversation which needs to be done as right now from the looks of it, the testsuite is not something which is cared much about as keeping around failures which are regressions just get annoying and cause more harm. Lets learn from this mistake, the Ada failures were not known until after I had filed the bug about the testsuite regression (PR 26344 comes before PR 26348 by about 11 hours). In fact in that bug report you said you caused them and looked at the wrong testsuite results, at that point you should have reverted the patch as it was obvious you did not test the patch correctly and knew that might be other issues. -- Pinski
Re: GCC 4.0.3 RC1
Looks OK for xtensa-elf: http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00356.html --Bob
Re: Is this a bug of gcc ?
On Mar 6, 2006, at 5:21 AM, Pierre Chatelier wrote: This is ok to fix the source, but I do not understand why it is normal behaviour that the foo() in b hides the one from a. They have different prototypes. That's just how C++ is designed/defined, any book on C++ should be able to explain this in more detail. Basically, a designer of a class is expected to think about each overload and decide if they want members from bases classes or not and which ones they want in the overload set. Trying to abdicate this means they just want the ones the explicitly defined in the class to be seen and no others.
Re: Is this a bug of gcc ?
That's just how C++ is designed/defined, any book on C++ should be able to explain this in more detail. Since it was not a bug, I have posted related questions on the gcc- help list, and I have had valuable answers. http://gcc.gnu.org/ml/gcc-help/2006-03/msg00026.html Now I have understood :-) Thanks for taking the time to answer ! Regards, Pierre Chatelier
Pre-Berlin WG14 mailing and updated DRs available
The pre-Berlin WG14 mailing, and the updated C99 DR logs, are now available from the WG14 website. There's an updated decimal float draft TR in there, among other items. http://www.open-std.org/JTC1/SC22/WG14/www/docs/pre-berlin.htm http://www.open-std.org/JTC1/SC22/WG14/www/docs/pre-berlin.tar.gz http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_log-0603.tar.gz -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: GCC 4.0.3 RC1
Mark Mitchell <[EMAIL PROTECTED]> wrote: > If these patches show an improvement on SH4, please go ahead and check > them in. Please inform me of the status ASAP. I've checked it in as 111792. Sorry for the delay. Regards, kaz
Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)
Here's the relevant bits from the .original dump if (side - 1 <= 1) Of particular interest is the (side - 1 <= 1) conditional which is implementing this hunk of code from the Trim function: if Side = Right or else Side = Both then I think it's time to hand this one to the Ada guys :-0 I don't. This sounds like fold is merging the two comparisons above incorrectly into the one upper comparison. It can do the merge, but it needs to convert to base types first.
Update bug 15020: Bugtracking complains unreasonably
When trying to submit further information for gcc bug 15020 I get Not allowed You tried to change the Assignee field from [EMAIL PROTECTED] to __UNKNOWN__, but only the assignee of the bug, or a sufficiently empowered user may change that field. I can not figure which field of the form is causing this message or what I should change to get past the message, thus I burden you with this complaint mail. The submission attempt happened approcimately Tue Mar 7 02:53:17 GMT 2006. Whatever the problem, please add following to bug 15020 titled "[win32] -mcpu=pentium4 generates wrong code": Not sure if this the same bug, but I have observed that gcc 3.4.5 compiled as a cross compiler targetting i586-pc-mingw32 definitely miscompiles. Apparently in a 3000 line C function with nearly 100 local variables the stack for preparing a function call collides (stomps on) with the stack based local variables. Specifically, when push instructions to prepare for function call are executed some of the local variables get overwritten with disastrous consequences later (i.e. a core). Workaround: Using `-g -O2 -fno-defer-pop -fno-strict-aliasing' apparently makes the problem go away, though it might just reduce incidence since the first locals on line to be stomped might not be used in my test case. I think it was the -fno-defer-pop that made the difference. Using just `-g -fno-strict-aliasing' without any optimization still reproduces the problem. If there is interest I can try to prepare a case that reproduces, but this is rather difficult as said 3000 line funcion is in context of a 7 line virtual machine :-) This cropped up in porting the virtual machine to Windows. On Linux, Mac OS X, Solaris, and some BSD platforms the code works OK and passes extensive test suites. Thus this would seem to be specific to MinGW platform or the way the cross compiler is built. Cheers, --Sampo Sampo Kellomaki ---> Chief Architect ---> DirectoryScript M: +351-918.731.007 F: +351-213.422.185 W: www.symlabs.com Customize directories -> LDAP SOAP Liberty SIP -> Directory Extender
