[Bug target/34451] Typo in gcc/config/i386.c (ix86_rtx_costs)
--- Comment #1 from tege-gcc at swox dot com 2007-12-13 07:21 --- This bug is present also in the svn head. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34451
[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input
--- Comment #26 from jvdelisle at gcc dot gnu dot org 2007-12-13 06:06 --- Tobias, I know why the weird case in the namelist_42.f90 fails. We just are not addressing the need to eat spaces or separators at the right places. I started working up an updated patch tonight, but have not got it yet. If your patch as-is passes all regression tests and spec its OK to commit. Its very close and we can follow with an update. Its just a time issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug target/34451] New: Typo in gcc/config/i386.c (ix86_rtx_costs)
In gcc/config/i386.c, there is a typo in the function ix86_rtx_costs. Code snippet: /* Compute costs correctly for widening multiplication. */ if ((GET_CODE (op0) == SIGN_EXTEND || GET_CODE (op1) == ZERO_EXTEND) It should use op0 for both these tests. -- Summary: Typo in gcc/config/i386.c (ix86_rtx_costs) Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tege-gcc at swox dot com GCC target triplet: i386-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34451
[Bug libstdc++/34449] use_facet(locale::classic()) returns true
--- Comment #1 from sebor at roguewave dot com 2007-12-13 05:41 ---
FWIW, it looks like you need a dynamic_cast in use_facet (it's not enough to
check the id and then downcast using static_cast). Something like this:
--- locale_facets.tcc 2007-10-21 08:33:43.0 -0600
+++ locale_facets.tcc 2007-12-12 22:28:07.0 -0700
@@ -111,9 +111,13 @@
{
const size_t __i = _Facet::id._M_id();
const locale::facet** __facets = __loc._M_impl->_M_facets;
+
+ const locale::facet* __pf;
if (!(__i < __loc._M_impl->_M_facets_size && __facets[__i]))
-__throw_bad_cast();
- return static_cast(*__facets[__i]);
+__pf = 0;
+ else
+__pf = __facets[__i];
+ return dynamic_cast(*__pf);
}
// Routine to access a cache for the facet. If the cache didn't
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34449
[Bug bootstrap/34144] [4.3 Regression] Revision 130005 causes bootstrap failure with --disable-checking
--- Comment #10 from daney at gcc dot gnu dot org 2007-12-13 05:28 --- Currently testing on x86_64-pc-linux-gnu. I will commit if all OK. -- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-11-18 20:51:33 |2007-12-13 05:28:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
[Bug middle-end/34450] [4.3 Regression] compile takes up 1.8 GB RAM at -O1
--- Comment #1 from tbm at cyrius dot com 2007-12-13 05:24 --- Created an attachment (id=14741) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14741&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34450
[Bug middle-end/34450] New: [4.3 Regression] compile takes up 1.8 GB RAM at -O1
Compile the attached source with -O1 and it will take roughly 1.8 GB RAM on x86_64 and over a minute with current trunk. 4.2 took a few seconds and less than 200 MB RAM. Granted, this is with checking on because I haven't had a chance to compile a version without checking, but this still looks like a regression. Hopefully someone (Richi?) can take a look. -- Summary: [4.3 Regression] compile takes up 1.8 GB RAM at -O1 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34450
[Bug libstdc++/34449] New: use_facet(locale::classic()) returns true
The test case below is expected to pass. With gcc 4.1.2 it aborts in the second
assert.
$ cat t.cpp && g++ t.cpp && ./a.out
#include
#include
struct DerivedCtype: std::ctype_byname {
DerivedCtype (): std::ctype_byname("") { }
};
template
bool check_use_facet (const std::locale &locale)
{
try {
std::use_facet(locale);
}
catch (...) {
return false;
}
return true;
}
int main ()
{
const std::locale classic = std::locale::classic ();
const std::locale named ("en_US.ISO-8859-1");
const std::locale user (classic, new DerivedCtype);
assert (check_use_facet >(classic));
assert (!check_use_facet >(classic));
assert (!check_use_facet(classic));
assert (check_use_facet >(named));
assert (check_use_facet >(named));
assert (!check_use_facet(named));
assert (check_use_facet >(user));
assert (check_use_facet >(user));
assert (check_use_facet(user));
}
a.out: t.cpp:28: int main(): Assertion
`!check_use_facet
>(classic)' failed.
--
Summary: use_facet(locale::classic()) returns true
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34449
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #9 from tbm at cyrius dot com 2007-12-13 03:03 --- I thought Mark told you two months ago to revert this patch and you didn't object. Has anything changed since then? At this point, I no longer care whether these headers are removed or not but I'd like to know for sure so I can start filing bugs. Given that gcc 4.3 will require almost all C++ code to be updated and we have several hundred bugs already, filing those ~70 bugs on packages that use old .h headers isn't that big a deal... -- tbm at cyrius dot com changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug tree-optimization/34043] Missed optimization causing extra loads and stores when using x86_64 builtin function together with aggregate types.
--- Comment #8 from jsjodin at gcc dot gnu dot org 2007-12-13 01:56 --- (In reply to comment #7) > >+static tree get_generic_type_node_from_size(int size) > > This function needs lots of improvement because the size of the modes is based > on UNIT_BIT_SIZE (I think that is the macro name) and really you can go from a > size to a mode and then to a tree type. > > Note this patch really fixes my bug (PR 32964) if PRE is extended to handle > this too. > Yes I rewrote the patch to always use the first member of a union that match a specific size. When the expression was extracted (queried from VN function) a VIEW_CONVERT_EXPR would be insterted if the expected type did not match the stored expression type. This caused some problems (assertions) in the compiler that I have not been able to track down yet, although it fixed both my test cases and for constants it doesn't cause any problems since the expression gets folded. To avoid introducing VIEW_CONVERT_EXPR it may be possible to return an expression (from VN) that refers to a union member with a matching type instead. It would mean that the value number would be the same, but the returned expression might be different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34043
[Bug bootstrap/34144] [4.3 Regression] Revision 130005 causes bootstrap failure with --disable-checking
--- Comment #9 from pinskia at gmail dot com 2007-12-13 01:18 --- Subject: Re: [4.3 Regression] Revision 130005 causes bootstrap failure with --disable-checking On 13 Dec 2007 01:12:13 -, daney at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > --- Comment #8 from daney at gcc dot gnu dot org 2007-12-13 01:12 --- > Andrew proposed a patch (which was then approved) here: > > http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01511.html Except I have not tested it at all :). I was just showing what it would look like :). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
[Bug bootstrap/34144] [4.3 Regression] Revision 130005 causes bootstrap failure with --disable-checking
--- Comment #8 from daney at gcc dot gnu dot org 2007-12-13 01:12 --- Andrew proposed a patch (which was then approved) here: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01511.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
[Bug target/30192] [arm] Wrong sp value on exit after calling __floatdidf or __floatundidf
--- Comment #6 from pbrook at gcc dot gnu dot org 2007-12-13 01:04 --- Subject: Bug 30192 Author: pbrook Date: Thu Dec 13 01:03:53 2007 New Revision: 130800 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130800 Log: 2007-12-13 Richard Earnshaw <[EMAIL PROTECTED]> PR target/30192 * config/arm/ieee754-df.S (floatundidf): Fix for wrong sp value on exit when using hard FPA. * config/arm/ieee754-df.S (floatdidf): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/ieee754-df.S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
[Bug tree-optimization/34448] [4.3 Regression] ICE in declare_inline_vars, at tree-inline.c:3243
--- Comment #5 from jakub at gcc dot gnu dot org 2007-12-13 00:08 ---
ret = GS_OK; } ret = GS_UNHANDLED; looks suspicious, but
@@ -3492,6 +3492,7 @@ gimplify_modify_expr_rhs (tree *expr_p,
{
*from_p = DECL_INITIAL (*from_p);
ret = GS_OK;
+ break;
}
ret = GS_UNHANDLED;
break;
doesn't cure this. But if you prevent this optimization whenever
gimplify_init_constructor would:
if (valid_const_initializer
&& num_nonzero_elements > 1
&& TREE_READONLY (object)
&& TREE_CODE (object) == VAR_DECL)
or
if (size > 0 && !can_move_by_pieces (size, align))
then this bug will go away.
BTW, in addition to the volatile check suggested by Mark, shouldn't it test
also
!TREE_SIDE_EFFECTS (DECL_INITIAL (...)))? Otherwise:
struct A { int i, j; };
static struct A a, b;
int foo (int x, int y)
{
const struct A i = { x++, y++ };
a = i;
b = i;
return x + y;
}
could evaluate multiple times. Actually this is a wrong example, because i
here
was already gimplified and while for constant initializer
gimplify_init_constructor puts DECL_INITIAL back (valid_const_initializer &&
&& num_nonzero_elements > 1 && TREE_READONLY (object) && TREE_CODE (object) ==
VAR_DECL case), for non-constant DECL_INITIAL will be NULL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34448
[Bug bootstrap/32101] xgcc invokes as with invalid -m option while assembling crtbegin.o
--- Comment #5 from acornejo at gmail dot com 2007-12-12 23:43 --- I have a similar bug, so I am posting here (otherwise I can open a new bug). I run: ./configure --target=mipsel-semb-elf --prefix=/scratch/semb/semb/ --disable-libssp --with-newlib --enable-languages=c --disable-threads --disable-shared --without-include-headers Then make fails with the following: MULTILIB_CFLAGS="" T= crtbegin.o crtend.o crti.o crtn.o make[4]: Entering directory `/scratch/semb/gcc-4.2.2/host-i686-pc-linux-gnu/gcc' /scratch/semb/gcc-4.2.2/host-i686-pc-linux-gnu/gcc/xgcc -B/scratch/semb/gcc-4.2.2/host-i686-pc-linux-gnu/gcc/ -B/scratch/semb/semb//mipsel-semb-elf/bin/ -B/scratch/semb/semb//mipsel-semb-elf/lib/ -isystem /scratch/semb/semb//mipsel-semb-elf/include -isystem /scratch/semb/semb//mipsel-semb-elf/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -Dinhibit_libc -G 0 \ -c ../.././gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o exec: 2: -G: not found make[4]: *** [crtbegin.o] Error 1 I am running on Ubuntu (in case that maters). This seems to be a bug, since this command runs properly on gcc-4.1 (just downloaded a fresh copy and tested it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32101
[Bug tree-optimization/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec
--- Comment #8 from janis at gcc dot gnu dot org 2007-12-12 23:34 --- Ira, it seems I've wasted your time; it's a well-known problem (except to me) that -maltivec without -mabi=altivec doesn't work in the general case because vector registers are not saved and restored. That explains why this test passes with either reload.c or reload1.c is compiled without vectorization. Meanwhile there are discussions happening about how to fix this so that someone using "-O3 -mcpu=970" won't run into failures when they don't even realize they're using vector registers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34038
[Bug tree-optimization/34448] [4.3 Regression] ICE in declare_inline_vars, at tree-inline.c:3243
--- Comment #4 from aldyh at gcc dot gnu dot org 2007-12-12 23:33 --- I'll take care of this. -- aldyh at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34448
[Bug tree-optimization/34437] several test failures for gcc.dg/vect/no-scevccp-*
--- Comment #7 from janis at gcc dot gnu dot org 2007-12-12 23:28 --- I had assumed that -maltivec -mabi=no-altivec was supposed to work in the general case, then had some discussions about it on #gcc today and learned that it doesn't and is a known problem. Given that, we ought to add "-mabi=altivec" to the options used in vect.exp. I've got some other testsuite fixes to test, I'll test that at the same time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34437
[Bug tree-optimization/34448] [4.3 Regression] ICE in declare_inline_vars, at tree-inline.c:3243
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34448
[Bug c++/24791] ICE on invalid instantiation of template's static member
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-12-12 23:24 --- *** Bug 34447 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||keelar at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24791
[Bug c++/34447] internal compiler error: in import_export_decl, at cp/decl2.c:1715
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-12 23:24 --- >template const string Interface::cConfItem = "Handler.FileXferH"; The above code is incorrect and it should be: template <> const string Interface::cConfItem = "Handler.FileXferH"; And that removes the ICE. This is also fixed on the trunk for 4.3.0. *** This bug has been marked as a duplicate of 24791 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34447
[Bug tree-optimization/34448] [4.3 Regression] ICE in declare_inline_vars, at tree-inline.c:3243
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-12-12 23:08 --- Ok, I see it on x86_64 with r130795 and it didn't reproduce before SVN update so it identified 2007-12-12 Aldy Hernandez <[EMAIL PROTECTED]> PR tree-optimization/32901 * gimplify.c (gimplify_modify_expr_rhs): Handle the case when we are assigning from a constant constructor. Fix wrapping in function comment. Aldy, please have a look. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aldyh at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-12 23:08:33 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34448
[Bug tree-optimization/34448] [4.3 Regression] ICE in declare_inline_vars, at tree-inline.c:3243
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-12 23:03 --- (your trunk revision reporting is broken) On which architecture? This works for me on i686 with r130793. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34448
[Bug c++/33887] [4.1/4.2/4.3 Regression] Reference to bitfield gets wrong value when optimizing
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-12-12 22:47 --- Great. That doesn't make too much sense ;) Because the testcase in comment #7 cannot be "optimized" on the tree level, but I see it is wrongly expanded to RTL instead. Now, the revisions are 103956: make tree-PRE smarter, looking through loads 119760: mem-ssa merge (my favorite) 126149: SCCVN merge nothing expansion related or FE specific. Bah. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
[Bug libstdc++/34095] parallel mode: segfault in std::sort
--- Comment #3 from bangerth at dealii dot org 2007-12-12 22:44 --- (In reply to comment #2) > Let's just close it if you can't reproduce now. I'll just try to run > everything > again some time from now and if I have the same problem again I'll re-open. Hm, so I got around to check this out again and in fact the same happens with today's svn version: examples/step-14> c++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/tmp/bangerth/bin/gcc-mainline --with-mpfr=/tmp/bangerth/bin --with-gmp=/tmp/bangerth/bin --disable-multilib --enable-languages=c,c++ Thread model: posix gcc version 4.3.0 20071212 (experimental) (GCC) examples/step-14> c++ -D_GLIBCXX_PARALLEL -fopenmp -march=native -mtune=native a.cc -g -O2 examples/step-14> ./a.out Segmentation fault examples/step-14> uname -a Linux bloc640b 2.6.22.9-0.4-default #1 SMP 2007/10/05 21:32:04 UTC i686 i686 i386 GNU/Linux This is with the program posted before, with pretty much the same backtrace. Johannes, does the program work for you? Best Wolfgang -- bangerth at dealii dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34095
[Bug tree-optimization/34448] [4.3 Regression] ICE in declare_inline_vars, at tree-inline.c:3243
--- Comment #1 from tbm at cyrius dot com 2007-12-12 22:33 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
typedef struct chunk_t chunk_t;
struct chunk_t
{
unsigned char *ptr;
long unsigned int len;
};
extern chunk_t asn1_wrap (chunk_t c, ...);
typedef struct linked_list_t linked_list_t;
chunk_t ietfAttr_list_encode (linked_list_t * list);
extern linked_list_t *groups;
static unsigned char ASN1_group_oid_str[] = {
0x06
};
static const chunk_t ASN1_group_oid = {
ASN1_group_oid_str, sizeof (ASN1_group_oid_str)
};
static chunk_t
build_attribute_type (const chunk_t type, chunk_t content)
{
return type;
}
static chunk_t
build_attributes (void)
{
return asn1_wrap (build_attribute_type (ASN1_group_oid,
ietfAttr_list_encode (groups)));
}
void build_attr_cert (void)
{
asn1_wrap (build_attributes ());
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34448
[Bug tree-optimization/34448] New: [4.3 Regression] ICE in declare_inline_vars, at tree-inline.c:3243
With current trunk: (sid)3201:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O -Wall strongswan-build.c strongswan-build.c: In function 'build_attr_cert': strongswan-build.c:27: internal compiler error: in declare_inline_vars, at tree-inline.c:3243 Please submit a full bug report, with preprocessed source if appropriate. This happens with gcc version 4.3.0 20071212 (experimental) [trunk revision 127646] (Debian 20071212-1) but didn't happen with gcc version 4.3.0 20071207 (experimental) [trunk revision 127646] (Debian 20071206-1) -- Summary: [4.3 Regression] ICE in declare_inline_vars, at tree- inline.c:3243 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34448
[Bug bootstrap/34414] unrecognized command line option "-Wc++-compat"
--- Comment #3 from andry at inbox dot ru 2007-12-12 22:32 ---
> No, this should not happen, nothing should be rebuilding while doing a "make
> install".
>
> Can you attach the output of doing a "clean" make and then a "make install"
> (please put them into two seperate output files)?
>
I try reinstall cygwin and remake, but now i catched another error:
host-i686-pc-cygwin\intl\config.log:
///
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.59. Invocation command line was
$ /cygdrive/e/work/gcc_4_2_2_release/intl/configure
--cache-file=./config.cache --build=i686-pc-cygwin --host=i686-pc-cygwin
--target=i686-pc-cygwin --enable-languages=c,c++,objc
--program-transform-name=s,y,y, --srcdir=../.././intl
--with-build-libsubdir=host-i686-pc-cygwin
## - ##
## Platform. ##
## - ##
hostname = andry_host
uname -m = i686
uname -r = 1.5.25(0.156/4/2)
uname -s = CYGWIN_NT-5.1
uname -v = 2007-12-09 09:47
/usr/bin/uname -p = unknown
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/X11R6/bin
PATH: /cygdrive/c/Program Files/PC Connectivity Solution/
PATH: /cygdrive/c/Programs/Dev/www.ruby-lang.org/Ruby v1.8.6/bin
PATH: /cygdrive/c/WINXP/system32
PATH: /cygdrive/c/WINXP
PATH: /cygdrive/c/WINXP/System32/Wbem
PATH: /cygdrive/c/Programs/Tools/Console/Console v2.00b130
PATH: /cygdrive/c/Programs/Dev/CollabNet/Subversion v1.4.3/bin
PATH: /cygdrive/c/Programs/Dev/Perforce/Perforce v2006.2
PATH: /cygdrive/c/Programs/Dev/CVSHome/cvsnt
PATH: /cygdrive/c/Program Files/Microsoft Visual Studio 2008
SDK/VisualStudioIntegration/Tools/Sandcastle/ProductionTools/
## --- ##
## Core tests. ##
## --- ##
configure:1228: creating cache ./config.cache
configure:1323: checking whether make sets $(MAKE)
configure:1343: result: yes
configure:1390: checking for a BSD-compatible install
configure:1445: result: /usr/bin/install -c
configure:1470: checking whether NLS is requested
configure:1479: result: yes
configure:1517: checking for msgfmt
configure:1551: result: no
configure:1557: checking for gmsgfmt
configure:1588: result: :
configure:1627: checking for xgettext
configure:1661: result: no
configure:1698: checking for msgmerge
configure:1731: result: no
configure:1771: checking for i686-pc-cygwin-gcc
configure:1797: result:
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc
-B/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/
-B/usr/local/i686-pc-cygwin/bin/
configure:2079: checking for C compiler version
configure:2082:
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc
-B/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/
-B/usr/local/i686-pc-cygwin/bin/ --version &5
/cygdrive/e/work/gcc_4_2_2_release/intl/configure: line 2083:
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc: No such
file or directory
configure:2085: $? = 127
configure:2087:
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc
-B/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/
-B/usr/local/i686-pc-cygwin/bin/ -v &5
/cygdrive/e/work/gcc_4_2_2_release/intl/configure: line 2088:
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc: No such
file or directory
configure:2090: $? = 127
configure:2092:
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc
-B/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/
-B/usr/local/i686-pc-cygwin/bin/ -V &5
/cygdrive/e/work/gcc_4_2_2_release/intl/configure: line 2093:
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc: No such
file or directory
configure:2095: $? = 127
configure:2118: checking for C compiler default output file name
configure:2121:
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc
-B/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/
-B/usr/local/i686-pc-cygwin/bin/ -g -O2 conftest.c >&5
/cygdrive/e/work/gcc_4_2_2_release/intl/configure: line 2122:
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc: No such
file or directory
configure:2124: $? = 127
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2163: error: C compiler cannot create executables
See `config.log' for more details.
## ##
## Cache variables. ##
## -
[Bug c++/33887] [4.1/4.2/4.3 Regression] Reference to bitfield gets wrong value when optimizing
--- Comment #13 from janis at gcc dot gnu dot org 2007-12-12 22:04 --- Additional regression hunts on trunk discovered that the test starts failing with: http://gcc.gnu.org/viewcvs?view=rev&rev=103956 r103956 | steven | 2005-09-06 18:51:26 + (Tue, 06 Sep 2005) and starts passing with: http://gcc.gnu.org/viewcvs?view=rev&rev=119760 r119760 | dnovillo | 2006-12-12 01:48:51 + (Tue, 12 Dec 2006) Comment #12 reports when it starts failing again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
[Bug target/34435] [4.3 Regression] SSE2 intrinsics - emmintrin with optimisations off and type conversion error
--- Comment #2 from ubizjak at gmail dot com 2007-12-12 21:39 --- (In reply to comment #1) > My suggestion is to force the same "argument" > type by doing > > #define _mm_shuffle_epi32(__A, __B) \ > ((__m128i)__builtin_ia32_pshufd ((__v4si)(__m128i)__A, (int)__B)) > > and adjust all !__OPTIMIZE__ macro variants this way. (at least this makes > this testcase work properly) Thanks for the suggestion, the patch at http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00560.html implements suggested approach. > -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||12/msg00560.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2007-12-12 09:55:10 |2007-12-12 21:39:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34435
[Bug fortran/34305] ICE with array(real) declaration
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-12-12 21:09 --- Might as well fix another one, this is easy... Front end, here I come again! -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-12 21:09:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34305
[Bug c++/34447] internal compiler error: in import_export_decl, at cp/decl2.c:1715
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-12-12 21:02 --- Please provide a compilable testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34447
[Bug target/34435] [4.3 Regression] SSE2 intrinsics - emmintrin with optimisations off and type conversion error
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34435
[Bug c++/34399] [4.3 regression] ICE on invalid friend declaration of variadic template
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34399
[Bug c++/34357] [4.2/4.3 Regression] internal compiler error: in layout_type, at stor-layout.c:1864
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34357
[Bug c++/34447] New: internal compiler error: in import_export_decl, at cp/decl2.c:1715
My Header file Interface.h has the following piece of code
template
class Interface {
...
protected:
static const std::string cConfItem;
};
typedef Interface InterfaceFileXfer;
In my source file Interface.cxx
I have the following:
const string InterfaceFileXfer::cConfItem = "Handler.FileXferH";
The above gets compiled without any errors on Sun Studio11.
But I get the following error when I compile using gcc (gcc-4.1.3-29 openSUSE
10.2)
Interface.cxx:31: error: too few template-parameter-lists
I don't know how should be the initialization for cConfItem like...
So I tried the following:
template const string Interface::cConfItem =
"Handler.FileXferH";
But I got the following error:
internal compiler error: in import_export_decl, at cp/decl2.c:1715
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.opensuse.org> for instructions.
make: *** [Interface.o] Error 1
--
Summary: internal compiler error: in import_export_decl, at
cp/decl2.c:1715
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: keelar at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34447
[Bug c++/34314] [4.3 Regression] ICE on invalid code (with variadic templates): tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in template_class_depth
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34314
[Bug c++/34274] [4.3 regression] Broken diagnostic: 'template_template_parm' not supported by dump_decl
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34274
[Bug c++/34269] [4.1/4.2/4.3 regression] Incomplete __decltype/__typeof expressions accepted
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34269
[Bug c++/34094] [4.2/4.3 Regression] Undefined static data member in anonymous namespace can acquire a definition anyway
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #21 from jakub at gcc dot gnu dot org 2007-12-12 20:55 --- The 3.12+ requirement documented, marking as fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug c++/33959] [4.1/4.2/4.3 Regression] ICE in instantiate_class_template, at cp/pt.c:6649
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33959
[Bug ada/34446] New: gnatprep evaluating "not" operator at incorrect precidence
The following is evaluated incorrectly with gnatprep 3.4.6 # if not VAR_TRUE or VAR_TRUE then ans := Good; # else ans := Wrong; # end if; Using command: gnatprep -r -DVAR_TRUE=true thing.in thing.out generates following results --! # if not VAR_TRUE or VAR_TRUE then --!ans := Good; --! # else ans := Wrong; --! # end if; An earlier version(3.3.3) of gnatprep produced correct results. -- Summary: gnatprep evaluating "not" operator at incorrect precidence Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: repucul at link dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34446
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #20 from jakub at gcc dot gnu dot org 2007-12-12 20:54 --- Subject: Bug 30589 Author: jakub Date: Wed Dec 12 20:54:10 2007 New Revision: 130794 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130794 Log: PR bootstrap/30589 * doc/install.texi: Document that for MinGW only runtime 3.12 and later is supported. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug c++/33916] [4.2/4.3 Regression] Default constructor fails to initialize array members
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33916
[Bug c++/33887] [4.1/4.2/4.3 Regression] Reference to bitfield gets wrong value when optimizing
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
[Bug c++/33819] [4.2/4.3 Regression] Miscompiled shift of C++ bitfield
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33819
[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute
--- Comment #4 from burnus at gcc dot gnu dot org 2007-12-12 20:29 --- > Error: Fortran 2003: PUBLIC variable 'foo' at (1) of PRIVATE derived type > 'myint' > which seems unrelated to me and for which I probably should submit a new bug > report. It is unrelated, but simple to fix; patch: http://gcc.gnu.org/ml/fortran/2007-12/msg00153.html (I think the first example is standard conform and should be enough, though I am glad that you created the other example and found a diagnostics bug.) Thanks for your two-in-one bugreport. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34438
[Bug libfortran/34370] file positioning after nonadvancing i/o
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-12-12 20:08 --- Created an attachment (id=14740) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14740&action=view) an improved version Sanity checking found bugs :-) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #14715|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34370
[Bug tree-optimization/34445] [4.3 Regression] internal compiler error: in cost_for_stmt, at tree-vect-transform.c:98
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-12 20:00 ---
Confirmed. Breaks with -O -ftree-vectorize -msse2 because we don't have a cost
for
(gdb) call debug_generic_expr (stmt)
th_lsm.41_62 = th.6_55
(gdb) print *stmt_info
$2 = {type = undef_vec_info_type, stmt = 0xb7cfbb98, loop_vinfo = 0x8c640f0,
relevant = vect_unused_in_loop, live = 1 '\001', vectype = 0xb7cd3750,
vectorized_stmt = 0x0, data_ref_info = 0x0, dr_base_address = 0x0,
dr_init = 0x0, dr_offset = 0x0, dr_step = 0x0, dr_aligned_to = 0x0,
in_pattern_p = 0 '\0', related_stmt = 0x0, same_align_refs = 0x8c5f130,
def_type = vect_loop_def, first_dr = 0x0, next_dr = 0x0, size = 0,
store_count = 0, gap = 0, same_dr_stmt = 0x0, read_write_dep = 0 '\0',
cost = {outside_of_loop = 0, inside_of_loop = 0}, slp_type = loop_vect}
(gdb) up
#2 0x086a46d8 in vect_estimate_min_profitable_iters (loop_vinfo=0x8c640f0)
at /home/richard/src/trunk/gcc/tree-vect-transform.c:206
199 for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si))
200 {
201 tree stmt = bsi_stmt (si);
202 stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
203 if (!STMT_VINFO_RELEVANT_P (stmt_info)
204 && !STMT_VINFO_LIVE_P (stmt_info))
205 continue;
206 scalar_single_iter_cost += cost_for_stmt (stmt) * factor;
so, the stmt is unused but live.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target triplet|i386-apple-darwin8.11.1 |i?86-*-*
Last reconfirmed|-00-00 00:00:00 |2007-12-12 20:00:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34445
[Bug tree-optimization/34445] [4.3 Regression] internal compiler error: in cost_for_stmt, at tree-vect-transform.c:98
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dorit at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org Component|fortran |tree-optimization GCC host triplet|i386-apple-darwin8.11.1 | GCC target triplet||i386-apple-darwin8.11.1 Keywords||ice-on-valid-code Summary|internal compiler error: in |[4.3 Regression] internal |cost_for_stmt, at tree-vect-|compiler error: in |transform.c:98 |cost_for_stmt, at tree-vect- ||transform.c:98 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34445
[Bug tree-optimization/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec
--- Comment #7 from janis at gcc dot gnu dot org 2007-12-12 19:22 --- The failure goes away with -mabi=altivec, which is not the default with -m32. I had never seen this failure in my earlier testing on powerpc64-linux because whenever I used -maltivec I also used -mabi=altivec. It's not clear to me if it's legitimate to use -maltivec, or -mcpu with machines that imply -maltivec, without also using -mabi=altivec when the code will use AltiVec registers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34038
[Bug fortran/34445] internal compiler error: in cost_for_stmt, at tree-vect-transform.c:98
--- Comment #1 from dir at lanl dot gov 2007-12-12 19:18 --- It has no problem with this program on a PowerPC Macintosh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34445
[Bug fortran/34445] New: internal compiler error: in cost_for_stmt, at tree-vect-transform.c:98
A new build of gfortran on the Intel Macintosh now gets this error - [dir-2:~/junk/ad] dir% gfortran -O3 -c derv.f derv.f: In function 'derv': derv.f:1: internal compiler error: in cost_for_stmt, at tree-vect-transform.c:98 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. [dir-2:~/junk/ad] dir% cat derv.f subroutine derv (xx,b,bv,det,r,s,t,ndopt,cosxy,thick,edis, 1 vni,vnt) implicit real*8 (a-h,o-z) save c common /shell1/ disd(9),ield,ielp,npt,idw,ndrot common /shell4/xji(3,3),p(3,32),h(32) c dimension xx(3,*),ndopt(*),bv(*),vni(*),cosxy(6,*),vnt(*), 1 edis(*),thick(*),b(*) c kk=0 k2=0 do 130 k=1,ield k2=k2 + 3 if (ndopt(k)) 127,127,130 127 kk=kk + 1 do 125 i=1,3 b(k2+i)=b(k2+i) + (xji(i,1)*p(1,k) + xji(i,2)*p(2,k))*t 1 + xji(i,3)*h(k) th=0.5*thick(kk) b(k2+i+3)=b(k2+i+3) - th*cosxy(i+3,kk) 125 b(k2+i+6)=b(k2+i+6) + th*cosxy(i,kk) k2=k2 + 9 130 continue return end [dir-2:~/junk/ad] dir% gfortran --v Using built-in specs. Target: i386-apple-darwin8.11.1 Configured with: ../gcc/configure --disable-bootstrap --enable-multilib --prefix=/usr/local/gfortran --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20071212 (experimental) (GCC) -- Summary: internal compiler error: in cost_for_stmt, at tree-vect- transform.c:98 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: i386-apple-darwin8.11.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34445
[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input
--- Comment #25 from burnus at gcc dot gnu dot org 2007-12-12 19:11 --- Created an attachment (id=14739) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14739&action=view) Improved patch > > Maybe reverting and proceeding then quickly w/o time pressure is best. > Right now we can't run SPEC CPU since gfortran runtime is broken [...] > I think it should be reverted for now so that we can work on it without > pressure. Which is what I suggested this morning, but had no time to actually do so. I meanwhile updated the patch based on Jerry's comments. The following seems work for most but the weirdest input files. Please test/have a look; I intent to submit that patch in a moment. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #14736|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug fortran/34254] "character(kind=c_char) function" fails if c_char is not host associated
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-12 18:54 --- Subject: Bug 34254 Author: burnus Date: Wed Dec 12 18:54:26 2007 New Revision: 130793 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130793 Log: 2007-12-12 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34254 * decl.c (match_char_kind): Support use-associated/imported kind parameters. (gfc_match_kind_spec): Support als BT_CHARACTER, when re-scanning kind spec. 2007-12-12 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34254 * gfortran.dg/function_kinds_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/function_kinds_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34254
[Bug rtl-optimization/23726] Missed optimizations for divmod
--- Comment #8 from bjoern dot m dot haase at web dot de 2007-12-12 18:14 --- Created an attachment (id=14738) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14738&action=view) patch My new analysis leads me to the result that the key problem of this missed optimization is a target problem: Presently we expand a divmod4 pattern that implements the support funciton calls directly. This pattern refers directly to hard registers. The resulting RTL is too complex for CSE and we don't identify this optimization. The attached patch uses the same RTL for the support function calls. Only this RTL is now generated only after combine by a define_insn_and_split pattern. The insn part of this pattern is valid only for pseudos so that until split. In order to assure this, I have added a new predicate. I have tested the patch against the atmega128 simulation target without regressions. 2007-12-11 Bjoern Haase <[EMAIL PROTECTED]> PR target/23726 * config/avr/predicates.md (pseudo_register_operand): Add new predicate for pseudos * config/avr/avr.md (divmodqi4,udivmodqi4): replace define_expand by define_insn_and_split, delay expansion of call patterns to split pass. (divmodhi4,udivmodhi4,divmodsi4,udivmodsi4): likewise. -- bjoern dot m dot haase at web dot de changed: What|Removed |Added Attachment #9665 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23726
[Bug tree-optimization/34437] several test failures for gcc.dg/vect/no-scevccp-*
--- Comment #6 from jakub at gcc dot gnu dot org 2007-12-12 17:51 --- As -m32 -maltivec without -mabi=altivec has the VMX regs effectively neither fixed, nor call saved, nor call used, it simply can't work reliably. Registers really need to have some rules for using them, while -m32 -maltivec means complete anarchy. The compiler is told calls won't clobber values stored in them, but nothing saves the registers, so things work only as long as no calls are crossed with live VMX registers, or with pure luck that the callee clobbers different VMX registers than the parent has live accross the call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34437
[Bug tree-optimization/34437] several test failures for gcc.dg/vect/no-scevccp-*
--- Comment #5 from janis at gcc dot gnu dot org 2007-12-12 17:44 --- It's legitimate to use -maltivec without -mabi=altivec unless linking against objects that were compiled with -mabi=altivec, so adding the option to vect.exp is merely hiding the problem. Is there a reason why only these particular tests would need the AltiVec ABI, and only with -fno-tree-scev-cprop? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34437
[Bug libobjc/34315] libobjc warnings with Win64 target=x86_64-pc-mingw32
--- Comment #2 from nightstrike at gmail dot com 2007-12-12 17:33 --- Does anyone know why the %ld formats are not recognized as valid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34315
[Bug bootstrap/34316] Operand 1 missing mode - x86_64-pc-mingw32
--- Comment #2 from nightstrike at gmail dot com 2007-12-12 17:33 --- What do they mean? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34316
[Bug java/34444] Class.getEnclosingClass() returns null on enclosed class
--- Comment #1 from tromey at gcc dot gnu dot org 2007-12-12 16:28 ---
Here's a complete test case.
The .class file does have the InnerClasses attribute,
we just don't seem to read it properly.
public class p
{
public interface DBI { }
public interface Local extends DBI {
public class Disconnected
{
public Disconnected()
{
}
}
}
public static void main(String[] args) throws Throwable {
Class c = Local.Disconnected.class;
System.out.println(c.getEnclosingClass());
}
}
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-12-12 16:28:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute
--- Comment #3 from jv244 at cam dot ac dot uk 2007-12-12 16:11 --- (In reply to comment #2) I had confirmed the bug already on the first testcase, which is fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34438
[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input
--- Comment #24 from hjl at lucon dot org 2007-12-12 15:26 --- (In reply to comment #23) > > Tobias. do as you > > please. We can either revert the original patch and get back to this > > without > > time pressure or proceed quickly. > Maybe reverting and proceeding then quickly w/o time pressure is best. > Right now we can't run SPEC CPU since gfortran runtime is broken. which means other Fortran bugs may get in without notice. I think it should be reverted for now so that we can work on it without pressure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
[Bug fortran/34438] gfortran not compliant w.r.t default initialization of derived type component and implicit SAVE attribute
--- Comment #2 from sven dot buijssen at math dot uni-dortmund dot de 2007-12-12 15:04 --- Having reread the Fortran 95 language spec I don't see why the initial testcase violates the standard. But I managed to distill a testcase that does not need recursive functions and still triggers the bug of 'foo' getting implicitly the SAVE attribute: --- cut here --- module demo implicit none private type myint integer :: bar = 42 end type myint public :: func contains subroutine func(ivalue) integer, intent(in) :: ivalue type(myint) :: foo print *, foo%bar foo%bar = ivalue end subroutine func end module demo program main use demo implicit none call func(1) call func(2) end program main --- cut here --- In case this piece of code still violates the standard, I would very much appreciate a hint where and why exactly it does. (Sorry to waste your time.) gfortran 4.[1-2].x gives: $ gfortran -W -Wall -pedantic -std=f95 demo3.f90 && ./a.out 42 1 while one would expect two times '42' as do Intel Fortran 9.x/10.x, PGI 7.x, Pathscale 3.x, recent g95 versions, Compaq Fortran X5.4A-1684 and Sun Fortran 95 8.3 2007/07/18. Without the private/public statements gfortran 4.3.x exhibits the same behaviour. The test case above, however, gives type(myint) :: foo 1 Error: Fortran 2003: PUBLIC variable 'foo' at (1) of PRIVATE derived type 'myint' which seems unrelated to me and for which I probably should submit a new bug report. I added this information here nonetheless as it might help to trace the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34438
[Bug target/34436] Illegal assembly on ARM/Thumb
--- Comment #6 from joel at gcc dot gnu dot org 2007-12-12 14:05 --- RTEMS had a default implementation of the method in question that was in C. So for the Thumb, I changed things to use it until the Thumb maintainer adds a better version. Thanks. I wasn't even finished adding the test cases when I spotted the real problem. I am sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34436
[Bug libstdc++/33832] hash_set moved to backwards
--- Comment #10 from olafvdspek at gmail dot com 2007-12-12 12:29 --- > Just use It'd be nice if the deprecated warning mentioned that file. -- olafvdspek at gmail dot com changed: What|Removed |Added CC||olafvdspek at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33832
[Bug tree-optimization/32901] [4.1/4.2/4.3 Regression] bitfield constants with multiple bitfields take up space in .data
--- Comment #12 from aldyh at gcc dot gnu dot org 2007-12-12 11:18 --- http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00525.html -- aldyh at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
[Bug java/34444] New: Class.getEnclosingClass() returns null on enclosed class
Class.getEnclosingClass() returns null on enclosed class.
Specifically:
c = class org.freedesktop.DBus$Local$Disconnected
c.getEnclosingClass() = null
(followed by a null pointer exception on the next line)
Code which prints that:
if (Debug.debug) Debug.print(Debug.VERBOSE, "c = "+c);
if (Debug.debug) Debug.print(Debug.VERBOSE, "c.getEnclosingClass() =
"+c.getEnclosingClass());
if (Debug.debug) Debug.print(Debug.VERBOSE,
"c.getEnclosingClass().getAnnotation(DBusInterfaceName.class) =
"+c.getEnclosingClass().getAnnotation(DBusInterfaceName.class));
if (null !=
c.getEnclosingClass().getAnnotation(DBusInterfaceName.class))
Source for DBus$Local$Disconnected:
public interface DBus extends DBusInterface
{
/**
* Messages generated locally in the application.
*/
public interface Local extends DBusInterface
{
public class Disconnected extends DBusSignal
{
public Disconnected(String path) throws DBusException
{
super(path);
}
}
}
}
GCC version:
gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
(Also happens in 4.2.2)
This code works as expected in Sun JDK 5 and 6
Matt
--
Summary: Class.getEnclosingClass() returns null on enclosed class
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at matthew dot ath dot cx
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug ada/34440] 4.3.0 SVN r130768 Bug box: Assert_Failure einfo.adb:5625
--- Comment #2 from sam at gcc dot gnu dot org 2007-12-12 10:29 --- Confirmed -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-12 10:29:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34440
[Bug web/34443] New: The GCC manual about section variable attribute is incorrect
Since at least 3.4, the GCC manual says:
Use the `section' attribute with an _initialized_ definition of a
_global_ variable, as shown in the example. GCC issues a warning
and otherwise ignores the `section' attribute in uninitialized
variable declarations.
but this doesn't seem correct.
For example compiling the following tiny program:
int foo __attribute__ ((__section__ (".init.data")));
int main(int argc, char **argv)
{
foo = 4;
return 0;
}
produces no warning and the section attribute is not ignored at all:
$ readelf -S a.out | grep -A1 init.data
[24] .init.dataPROGBITS 0060080c 080c
0004 WA 0 0 4
This is with 4.1.2 from fedora, but I guess other GCC give the same result.
I would be nice to have all manuals reflecting this too.
Thanks !
--
Summary: The GCC manual about section variable attribute is
incorrect
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fbuihuu at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34443
[Bug target/34435] [4.3 Regression] SSE2 intrinsics - emmintrin with optimisations off and type conversion error
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-12-12 09:55 ---
Without optimization main() preprocesses to
int main() {
((__m128i)__builtin_ia32_pshufd ((__v4si)Vec(5), (((3) << 6) | ((3) << 4) |
((3) << 2) | (3;
}
with optimization we get instead
int main() {
_mm_shuffle_epi32(Vec(5), (((3) << 6) | ((3) << 4) | ((3) << 2) | (3)));
}
because with optimization we use an inline function instead of a macro.
Uros - it was you who changed that (and I see it may not be too easy to
make all parties happy here). My suggestion is to force the same "argument"
type by doing
#define _mm_shuffle_epi32(__A, __B) \
((__m128i)__builtin_ia32_pshufd ((__v4si)(__m128i)__A, (int)__B))
instead of
#define _mm_shuffle_epi32(__A, __B) \
((__m128i)__builtin_ia32_pshufd ((__v4si)__A, __B))
to match the prototype of _mm_shuffle_epi32 which reads
static __inline __m128i __attribute__((__always_inline__, __artificial__))
_mm_shuffle_epi32 (__m128i __A, const int __mask)
{
return (__m128i)__builtin_ia32_pshufd ((__v4si)__A, __mask);
}
and adjust all !__OPTIMIZE__ macro variants this way. (at least this makes
this testcase work properly)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||uros at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||rejects-valid
Last reconfirmed|-00-00 00:00:00 |2007-12-12 09:55:10
date||
Summary|SSE2 intrinsics - emmintrin |[4.3 Regression] SSE2
|with optimisations off and |intrinsics - emmintrin with
|type conversion error |optimisations off and type
||conversion error
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34435
[Bug spam/34441] PDM
--- Comment #2 from steven at gcc dot gnu dot org 2007-12-12 08:12 --- spam -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|web |spam Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34441
[Bug c++/34397] [4.3 regression] ICE on invalid default template parameter
--- Comment #9 from reichelt at gcc dot gnu dot org 2007-12-12 08:11
---
> Are you sure you don't have a modified compiler?
Pretty sure. I bootstrapped a really clean one ("svn diff --no-ignore" showed
nothing) last night on i686-pc-linux-gnu. It still shows the segfault.
The x86_64-unknown-linux-gnu compiler was bootstrapped without modifications
from a snapshot. It's a little older, though (2007-11-16).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397
