gcc/testsuite incorrect checking of compiler's retval in dg-compile
Hi,
I need to check for a non-0 return value in dg-compile testcases in
gcc.
A simple testcase from richi shows the problem i'm facing:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.dg/pr29254.c?view=markup&pathrev=117577
In this testcase, he checks for
/* { dg-warning "warnings being treated as errors" "" {target "*-*-*"} 0 } */
which is not really accurate, since it doesn't check that the compiler
did exit with !0 but only if that warn_once string was emitted. In
gfortran, i currently do not emit such a introductory message at all,
and even if i would, checking for the message instead of checking the
actual return-code of the compilation would be incorrect.
A simple testcase that i want to expect to fail to compile would be e.g.:
$ cat c.c
/* { dg-do compile } */
/* { dg-options "-W -Werror" } */
/* { dg-return != 0 } */ // Perhaps also check for ld, as failure
int main(void) {0;} /* { dg-warning "no effect" } */
What do people think about a way to properly check that dg-compile did
indeed return non-0?
PS:
Also see http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00551.html
for the proposed gfortran.dg testcase that comes along a simple fix
that is blocked by this alleged missing feature in dejagnu.
TIA,
Bernhard
Re: New option: -fstatic-libgfortran
On Fri, Apr 20, 2007 at 10:15:34AM +0200, François-Xavier Coudert wrote:
>Hi all,
>
>Attached is a first draft of a patch to add a -fstatic-libgfortran
>option. This new option is recognized by the driver and instead of
>adding "-lgfortran" to the various subprocesses, it adds "-Wl,-Bstatic
>-lgfortran -Wl,-Bdynamic". I have two questions about this:
> + linkers other than the GNU linker might have problems with that.
>is there a more general way of doing this? or should it be conditional
>on some macro, like HAVE_LD_STATIC_DYNAMIC?
> + when -static is used later in the command line, this trick doesn't
>work; would "%{!static:-Wl,-Bstatic} -lgfortran
>%{!static:-Wl,-Bdynamic}" be a good replacement?
>
>Thanks for the help, I'm a bit a loss with non-GNU linkers... :(
Perhaps looking at how stuff is done for libgcc.a in
gcc/{Makefile.in,gccspec.c} would help?
Re: [gfortran] gfortran options and cc1 warnings
On Mon, Oct 31, 2005 at 12:51:40AM +0100, FX Coudert wrote: >This is a patch proposal about PR fortran/18452. In short, to preprocess >fortran source files, gfortran calls cc1 with its own options, which >gives warnings like: > >$ gfortran -fdollar-ok a.F90 >cc1: warning: command line option "-fdollar-ok" is valid for F95 but not >for C > >A few (two exactly) options were already handled right (-ffixed-form and >-ffixed-line-length-n), so I applied the method used for those to all >gfortran options. Questions that need adressing are: > > 1. can we get that patch in during the short period when 4.1 will >unfreeze before branching? it concerns the common code of GCC, and does >not fix a regression strictly speaking. But that problem is very >annoying to both users (which make compiling very noisy and errors >difficult to spot) and developers (preventing libgfortran to be built >with -Werror), and working around it while changing only gfortran code >would be *ugly*. > > 2. what should be the behaviour of "gfortran -fdollar-ok a.f b.c"? is >this supposed to be allowed, or not? > > 3. if the answer to point 2 is "this isn't allowed", then the >testsuite framework should be somehow modified :) > > 4. in the case it is allowed, we then need some very clever way to >get options go where they need (C-only options for b.c and Fortran-only >options to a.f) > >gfortran developers, C front-end maintainers, specs gurus, release >managers, please speak up! :) Neither of them.. I didn't look closely, but when i added -ffree-line-length- i thought if it would be ok/possible to fill lang.opts into a new compiler->opts and match against those instead. That way each option passed in by the user could be matched against all involved languages -- setting something like compiler->given_args -- and one could warn about the unknown rest and/or mutual exclusive flags per language.
[patch, RFC] add attribute externally_visible to ansidecl.h
[please keep me CC'ed]
Hi,
In 4.1, -fwhole-program was introduced. Unfortunately it currently looks
like it won't work in the 4.1-release (due to PR 25795).
Would it make sense to add a define for this attribute to ansidecl.h
like in the attached proposed patch against mainline?
thank you,
Bernhard
2006-01-18 Bernhard Fischer <[EMAIL PROTECTED]>
* ansidecl.h (ATTRIBUTE_EXTERNALLY_VISIBLE): New.
Index: gcc-4.2/include/ansidecl.h
===
--- gcc-4.2/include/ansidecl.h (revision 109894)
+++ gcc-4.2/include/ansidecl.h (working copy)
@@ -165,7 +165,7 @@
#define VA_OPEN(AP, VAR) { va_list AP; va_start(AP, VAR); { struct Qdmy
#define VA_CLOSE(AP) } va_end(AP); }
#define VA_FIXEDARG(AP, T, N) struct Qdmy
-
+
#undef const
#undef volatile
#undef signed
@@ -352,7 +352,6 @@
# endif /* GNUC >= 3.5 */
#endif /* ATTRIBUTE_SENTINEL */
-
#ifndef ATTRIBUTE_ALIGNED_ALIGNOF
# if (GCC_VERSION >= 3000)
# define ATTRIBUTE_ALIGNED_ALIGNOF(m) __attribute__ ((__aligned__
(__alignof__ (m
@@ -361,6 +360,16 @@
# endif /* GNUC >= 3.0 */
#endif /* ATTRIBUTE_ALIGNED_ALIGNOF */
+/* Attribute `externally_visible' was usable as of gcc 4.2. */
+#ifndef ATTRIBUTE_EXTERNALLY_VISIBLE
+# if (GCC_VERSION >= 4002)
+# define ATTRIBUTE_EXTERNALLY_VISIBLE __attribute__ ((__externally_visible__))
+# else
+# define ATTRIBUTE_EXTERNALLY_VISIBLE
+# endif /* GNUC >= 4.2 */
+#endif /* ATTRIBUTE_EXTERNALLY_VISIBLE */
+
+
/* We use __extension__ in some places to suppress -pedantic warnings
about GCC extensions. This feature didn't work properly before
gcc 2.8. */
[PATCH] fix PR/27501 [4.2 Regression] Shell compatibility problem
Hi,
Attached patch fixes PR/27501. The regression was introduced
in r113432 by dj.
Patch tested on alphaev56-dec-osf5.1a and i686-linux-uclibc.
Please apply.
2006-05-13 Bernhard Fischer <[EMAIL PROTECTED]>
PR/27501
* mkconfig.sh: Use operator '=' for test
Index: gcc-4.2/gcc/mkconfig.sh
===
--- gcc-4.2/gcc/mkconfig.sh (revision 113625)
+++ gcc-4.2/gcc/mkconfig.sh (working copy)
@@ -43,7 +43,7 @@
# A special test to ensure that build-time files don't blindly use
# config.h.
-if test x"$output" == x"config.h"; then
+if test x"$output" = x"config.h"; then
echo "#ifdef GENERATOR_FILE" >> ${output}T
echo "#error config.h is for the host, not build, machine." >> ${output}T
echo "#endif" >> ${output}T
[PATCH] fix PR/27516 install failure due to unconditional invocation of makeinfo
Hi, Fixes PR/27516. makeinfo was executed unconditionally resulting in an error during make install. All other parts of the documentation do not treat a missing or old makeinfo as hard error but continue withoug building info pages. Tested on alphaev56-dec-osf5.1a where a makeinfo is installed but too old, and on i686-linux-gnu with a sufficiently current makeinfo installed. Please apply. 2006-05-13 Bernhard Fischer <[EMAIL PROTECTED]> PR/27516 * Make-lang.in (doc/treelang.info): If configure says makeinfo is too old then do not build nor install Info documentation. Index: gcc-4.2/gcc/treelang/Make-lang.in === --- gcc-4.2/gcc/treelang/Make-lang.in (revision 113625) +++ gcc-4.2/gcc/treelang/Make-lang.in (working copy) @@ -168,7 +168,10 @@ gcc-vers.texi doc/treelang.info: $(TEXI_TREELANG_FILES) - $(MAKEINFO) $(MAKEINFOFLAGS) -I $(gcc_docdir)/include -o $@ $< + if [ x$(BUILD_INFO) = xinfo ]; then \ + $(MAKEINFO) $(MAKEINFOFLAGS) -I $(gcc_docdir)/include \ + -o $@ $< ; \ + fi doc/treelang.dvi: $(TEXI_TREELANG_FILES) $(TEXI2DVI) -I $(abs_docdir)/include -o $@ $<
[PATCH] correct typo in fixincludes/README
Hi, s/exercize/exercise/ in fixincludes/README Please apply. 2006-05-13 Bernhard Fischer <[EMAIL PROTECTED]> * README: Fix typo. Index: gcc-4.2/fixincludes/README === --- gcc-4.2/fixincludes/README (revision 113737) +++ gcc-4.2/fixincludes/README (working copy) @@ -292,7 +292,7 @@ EXAMPLES OF FIXES: To do this, you *must* have autogen installed on your system. The "check" step will proceed to construct a shell script that -will exercize all the fixes, using the sample test_text +will exercise all the fixes, using the sample test_text provided with each fix. Once done, the changes made will be compared against the changes saved in the source directory. If you are changing the tests or fixes, the change will likely
Re: GCC 4.1.1 RC1
Hi, [sorry for breaking the threading, not subscribed..] gcc-4_1-branch will fail in the install target on systems where makeinfo is too old -- or missing. See http://gcc.gnu.org/PR27516 for details and a patch which is still awaiting approval for both trunk and 4.1 Please fix this before releasing 4.1.1, TIA.
[patch, applied] fix contrib/dg-cmp-results.sh
Hi,
The recently added dg-cmp-results.sh did error out when it tried to
reference a local non-array variable as an array variable.
I've applied the following obvious fix as r117006.
2006-09-18 Bernhard Fischer <[EMAIL PROTECTED]>
* dg-cmp-results.sh (compare-$$.awk): Print name[old]
and not non-existing nm[old].
thanks,
Bernhard
Index: dg-cmp-results.sh
===
--- dg-cmp-results.sh (revision 116995)
+++ dg-cmp-results.sh (working copy)
@@ -135,7 +135,7 @@
# Compare this new test to the first queued old one.
if (verbose >= 4) {
printf("Comparing two lines:\n O:%s:%s\n N:%s:%s\n",
-status[old], nm[old], st, nm)
+status[old], name[old], st, nm)
}
if (name[old] != nm) {
# The old test wasn't run this time and
Re: Memory leaks in compiler
On Fri, Jan 11, 2008 at 11:30:12AM -0800, Jerry DeLisle wrote: > With the Fortran test case I am using for PR34722. I did a valgrind check > with the following command: > > valgrind --leak-check=full f951 inquire_12.f90 > > The possible problem in mpfr has been around a while. > > The other two problems look like middle-end or back-end problems. Does > this warrant a PR? Against what component? > > Using built-in specs. > Target: x86_64-unknown-linux-gnu > Configured with: ../gcc43/configure --prefix=/home/jerry/gcc/usr > --enable-languages=c,fortran --disable-libmudflap --enable-libgomp > --with-mpfr-lib=/home/jerry/gcc/usr/lib > --with-mpfr-include=/home/jerry/gcc/usr/include --disable-bootstrap > Thread model: posix > gcc version 4.3.0 20080111 (experimental) [trunk revision 131004] (GCC) > > I get the following: > > ==14240== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1) > ==14240== malloc/free: in use at exit: 310,961 bytes in 1,036 blocks. > ==14240== malloc/free: 2,207 allocs, 1,171 frees, 1,296,169 bytes allocated. > ==14240== For counts of detected errors, rerun with: -v > ==14240== searching for pointers to 1,036 not-freed blocks. > ==14240== checked 2,346,928 bytes. > ==14240== > ==14240== 64 bytes in 2 blocks are possibly lost in loss record 1 of 8 > ==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149) > ==14240==by 0xB2F778: __gmp_default_allocate (in /mnt/sdb2/obj43/gcc/f951) > ==14240==by 0x4C2B62D: mpfr_init2 (init2.c:53) > ==14240==by 0x4C34424: mpfr_cache (cache.c:57) > ==14240==by 0x4C18E48: mpfr_log (log.c:133) > ==14240==by 0x4C2A4D1: mpfr_log10 (log10.c:111) > ==14240==by 0x40A29F: gfc_arith_init_1 (arith.c:165) > ==14240==by 0x443BC2: gfc_init_1 (misc.c:259) > ==14240==by 0x47684D: gfc_init (f95-lang.c:288) > ==14240==by 0x6D74F4: toplev_main (toplev.c:2128) > ==14240==by 0x3B7EC1E073: (below main) (in /lib64/libc-2.7.so) > ==14240== > ==14240== > ==14240== 408 bytes in 3 blocks are definitely lost in loss record 2 of 8 > ==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149) > ==14240==by 0xB1B4DB: xrealloc (xmalloc.c:177) > ==14240==by 0x8B1265: vec_heap_o_reserve_1 (vec.c:176) > ==14240==by 0x4FC09D: insn_locators_alloc (vecprim.h:27) > ==14240==by 0xA759F8: tree_expand_cfg (cfgexpand.c:1862) > ==14240==by 0x65C925: execute_one_pass (passes.c:1118) > ==14240==by 0x65CAEB: execute_pass_list (passes.c:1171) > ==14240==by 0x735345: tree_rest_of_compilation (tree-optimize.c:404) > ==14240==by 0x8E55E1: cgraph_expand_function (cgraphunit.c:1152) > ==14240==by 0x8E73C3: cgraph_assemble_pending_functions (cgraphunit.c:523) > ==14240==by 0x8E6894: cgraph_finalize_function (cgraphunit.c:640) > ==14240==by 0x49368B: gfc_generate_function_code (trans-decl.c:3403) Didn't look, but perhaps something like this? I don't see where locations_locators_locs and locations_locators_vals are freed either, but they seem to still be in use after locators_finalize... Index: gcc-4.3/gcc/cfglayout.c === --- gcc-4.3/gcc/cfglayout.c (revision 131470) +++ gcc-4.3/gcc/cfglayout.c (working copy) @@ -274,6 +274,9 @@ insn_locators_finalize (void) if (curr_rtl_loc >= 0) epilogue_locator = curr_insn_locator (); curr_rtl_loc = -1; + + VEC_free (int, heap, block_locators_locs); + VEC_free (tree, gc, block_locators_blocks); } /* Set current location. */ > ==14240== > ==14240== > ==14240== 5,672 (5,224 direct, 448 indirect) bytes in 71 blocks are > definitely lost in loss record 4 of 8 > ==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149) > ==14240==by 0xB1B567: xmalloc (xmalloc.c:147) > ==14240==by 0x51E842: df_install_refs (df-scan.c:2425) > ==14240==by 0x51EADA: df_refs_add_to_chains (df-scan.c:2551) > ==14240==by 0x52029F: df_record_exit_block_uses (df-scan.c:3808) > ==14240==by 0x5218D0: df_scan_blocks (df-scan.c:597) > ==14240==by 0x51499D: rest_of_handle_df_initialize (df-core.c:742) > ==14240==by 0x65C925: execute_one_pass (passes.c:1118) > ==14240==by 0x65CAEB: execute_pass_list (passes.c:1171) > ==14240==by 0x65CAFD: execute_pass_list (passes.c:1172) > ==14240==by 0x735345: tree_rest_of_compilation (tree-optimize.c:404) > ==14240==by 0x8E55E1: cgraph_expand_function (cgraphunit.c:1152) > ==14240== > ==14240== LEAK SUMMARY: > ==14240==definitely lost: 5,632 bytes in 74 blocks. > ==14240==indirectly lost: 448 bytes in 2 blocks. > ==14240== possibly lost: 64 bytes in 2 blocks. > ==14240==still reachable: 304,817 bytes in 958 blocks. > ==14240== suppressed: 0 bytes in 0 blocks. > ==14240== Reachable blocks (those to which a pointer was found) are not shown. > ==14240== To see them, rerun with: --leak-check=full --show-reachable=yes >
Re: Mainline is now regression and documentation fixes only
On Wed, Jan 23, 2008 at 12:06:22PM +0100, Richard Guenther wrote: > >As we now reached the goal of less than 100 open serious regressions >against GCC 4.3, we are as of now in regression and documentation fixes >only mode. This means that for patches going on the trunk the same >rules as for release branches apply. While not strictly a regression, is there any chance that we could get this reviewed an applied? http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00995.html cheers,
Re: Mainline is now regression and documentation fixes only
On Fri, Jan 25, 2008 at 03:51:27PM +0100, Paolo Bonzini wrote: > Jakub Jelinek wrote: >> On Wed, Jan 23, 2008 at 06:50:02PM +0100, Bernhard Fischer wrote: >>> On Wed, Jan 23, 2008 at 12:06:22PM +0100, Richard Guenther wrote: >>>> As we now reached the goal of less than 100 open serious regressions >>>> against GCC 4.3, we are as of now in regression and documentation fixes >>>> only mode. This means that for patches going on the trunk the same >>>> rules as for release branches apply. >>> While not strictly a regression, is there any chance that we could get >>> this reviewed an applied? >>> >>> http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00995.html >> >> I think an exception could be made for this, the risks are small >> and it should impact just uclibc. But you'd need one of the configury >> maintainers to ack it. > > Ok in 48 hours if no one will have objected. Applied to trunk as revision 131884. Thanks!
Re: Ongoing bootstrap failures on ppc64 since 2007-07-02
On Fri, Jul 06, 2007 at 10:08:44AM -0700, Steve Kargl wrote: >On Fri, Jul 06, 2007 at 12:07:43PM -0400, Diego Novillo wrote: >Dorit has isolated the problem to the ISO C Binding import. See >for example > >http://gcc.gnu.org/ml/gcc/2007-07/msg00133.html > >AFAIK, ppc64 is the only target that is failing. I'll send you m68hc11 seems to also exhibit a problem around there, fwiw. Not sure if it is related. gcc.gnu.org/PR32262
[RFC] pr11832 - add switch hoisting pass
Hi, The attached RFC-patch adds a pass to hoist common code that is found in all case labels of a switch expression (PR11832). I get an ICE in tree_redirect_edge_and_branch() though, so my question is if i forgot some kind of needed fixup? TIA for any pointers.. The ICE (against r127248 in case that matters) looks like: - 8< - /scratch/obj/gcc-4.3/./prev-gcc/xgcc -B/scratch/obj/gcc-4.3/./prev-gcc/ -B/opt/gcc-4.3//i686-linux-gnu/bin/ -c -DHAVE_CONFIG_H -Os -march=i386 -mtune=i386 -finline-limit=0 -g3 -ggdb3 -I. -I../../../src/gcc-4.3/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -fpic ../../../src/gcc-4.3/libiberty/cp-demangle.c -o pic/cp-demangle.o; \ else true; fi ../../../src/gcc-4.3/libiberty/cp-demangle.c: In function 'd_make_comp': ../../../src/gcc-4.3/libiberty/cp-demangle.c:745: internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4835 - 8< - PS: The patch below may contain a few completely unrelated edits, mostly cleanups and a comment. Please disregard all such unrelated hunks for now. gcc-4.3-switchhoisting.01c.diff.bz2 Description: BZip2 compressed data
libbid and floatingpoint exception access funcs
Hi, My libc is configured to omit any FP support (UCLIBC_HAS_FLOATS is not set) but the recent libbid updates seems to unconditionally pull in floatingpoint accessor functions thus breaking bootstrap. My notes on this read: 8< Follows: Precedes: do not pull in allegedly unneeded floatingpoint exception access funcs HJL's recent update of libbid would pull in Floating-point exception handling, although __GCC_FLOAT_NOT_NEEDED is defined. Prevent pulling in feclearexcept, feraiseexcept et al for now. FIXME: revisit 8< H.J., please advise. PS: I currently do: libgcc/ChangeLog: 2007-10-13 Bernhard Fischer <> * config/libbid/bid_conf.h: Do not define DECIMAL_GLOBAL_EXCEPTION_FLAGS_ACCESS_FUNCTIONS if __GCC_FLOAT_NOT_NEEDED is defined. Index: gcc-4.3.0/libgcc/config/libbid/bid_conf.h === --- gcc-4.3.0/libgcc/config/libbid/bid_conf.h (revision 129202) +++ gcc-4.3.0/libgcc/config/libbid/bid_conf.h (working copy) @@ -535,7 +535,9 @@ Software Foundation, 51 Franklin Street, #define DECIMAL_GLOBAL_ROUNDING 1 #define DECIMAL_GLOBAL_ROUNDING_ACCESS_FUNCTIONS 1 #define DECIMAL_GLOBAL_EXCEPTION_FLAGS 1 +#ifndef __GCC_FLOAT_NOT_NEEDED #define DECIMAL_GLOBAL_EXCEPTION_FLAGS_ACCESS_FUNCTIONS 1 +#endif #define BID_HAS_GCC_DECIMAL_INTRINSICS 1 #endif /* IN_LIBGCC2 */
