[Bug fortran/32580] iso_c_binding c_f_procpointer / procedure pointers
--- Comment #6 from jv244 at cam dot ac dot uk 2007-10-16 08:30 --- (In reply to comment #5) > (In reply to comment #4) > > SoC is over, I assume this has been put on ice ? > > Yes, there was unfortunately no patch before GCC entered stage 3 (12 > September) > and in stage 3 merging new features is allowed. (Besides, there is not yet a > ready patch for procedure pointers.) > In any case, before GCC 4.4 enters stage 1, at least the core developers will > concentrate on fixing bugs. > Since adding c_f_procpointer might change the fortran runtime library, will this addition be OK for 4.4 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32580
[Bug rtl-optimization/33791] [4.1/4.2/4.3 Regression] x86 out of registers ICE with -fschedule-insns -march=core2
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-16 08:55 ---
Confirmed. Reduced testcase:
typedef unsigned char uint8_t;
typedef unsigned long long uint64_t;
typedef struct SPS {
uint8_t(*top_borders[2])[16 + 2 * 8];
int neighbor_transform_size;
} H264Context;
static void fill_caches(H264Context * h, int mb_type, int for_deblock)
{
h->neighbor_transform_size = 0;
}
static inline void backup_pair_border(H264Context * h, uint8_t * src_y, int
linesize)
{
*(uint64_t *) (h->top_borders[1][linesize]) = *(uint64_t *) (src_y +
linesize);
}
void hl_decode_mb_internal(H264Context * h, int simple, int *linesize)
{
if (!simple) {
uint8_t *pair_dest_y;
backup_pair_border(h, pair_dest_y, *linesize);
fill_caches(h, 1, 1);
(*linesize)++;
fill_caches(h, 1, 1);
}
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|target |rtl-optimization
Ever Confirmed|0 |1
GCC host triplet|i386-apple-darwin8.10.1 |
GCC target triplet|i386-apple-darwin8.10.1 |i?86-*-*
Keywords||ice-on-valid-code
Known to fail||4.3.0 4.2.2 4.1.2 4.1.0
Known to work||4.0.3
Last reconfirmed|-00-00 00:00:00 |2007-10-16 08:55:32
date||
Summary|x86 out of registers ICE|[4.1/4.2/4.3 Regression] x86
|with -fschedule-insns - |out of registers ICE with -
|march=core2 |fschedule-insns -march=core2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33791
[Bug rtl-optimization/33791] [4.1/4.2/4.3 Regression] x86 out of registers ICE with -fschedule-insns -march=core2
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-10-16 09:18
---
This is a known problem, -fschedule-insns should be avoided on x86.
config/i386/i386.c:2884
void
optimization_options (int level, int size ATTRIBUTE_UNUSED)
{
/* For -O2 and beyond, turn off -fschedule-insns by default. It tends to
make the problem with not enough registers even worse. */
#ifdef INSN_SCHEDULING
if (level > 1)
flag_schedule_insns = 0;
#endif
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33791
[Bug c++/33754] Default argument of type list < pair < A, B > > compiles only when typedef is used
--- Comment #7 from photon at seznam dot cz 2007-10-16 09:23 ---
(In reply to comment #6)
>
> What are your thoughts about the other issues raised by 325?
>
The suggested resolution disregards the syntactical needs of templates and
makes 'int Foo (int i = T<1, int>::i);' invalid. The current standard is
inconsistent and should be fixed. For example, the following code is invalid:
class A
{
void f (T a);
typedef int T;
};
Yet, this one is not:
class B
{
void f (int a = (T) 1);
typedef int T;
};
This inconsistency is unexpected and confusing. Default arguments should be
strictly required to be parsed at the point of appearance. Deferred parsing
brings very little benefit here, yet the price paid for it is high: template
argument separator does not work as expected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33754
[Bug rtl-optimization/33791] x86 out of registers ICE with -fschedule-insns -march=core2
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-10-16 10:54 --- How can this be a regression if -march=core2 support is new? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.0.3 | Summary|[4.1/4.2/4.3 Regression] x86|x86 out of registers ICE |out of registers ICE with - |with -fschedule-insns - |fschedule-insns -march=core2|march=core2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33791
[Bug target/27432] -fschedule-insns -O2 -march=athlon cause compilation error
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-10-16 10:54 --- *** Bug 33791 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||astrange at ithinksw dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27432
[Bug rtl-optimization/33791] x86 out of registers ICE with -fschedule-insns -march=core2
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-16 10:54 --- *** This bug has been marked as a duplicate of 27432 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33791
[Bug rtl-optimization/33791] [4.1/4.2/4.3 Regression] x86 out of registers ICE with -fschedule-insns -march=core2
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-10-16 11:08 --- Because it fails on x86_64 with just -O -fschedule-insns -m32 -mtune=pentiumpro but works with 4.0.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.0.3 Summary|x86 out of registers ICE|[4.1/4.2/4.3 Regression] x86 |with -fschedule-insns - |out of registers ICE with - |march=core2 |fschedule-insns -march=core2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33791
[Bug rtl-optimization/33791] [4.1/4.2/4.3 Regression] x86 out of registers ICE with -fschedule-insns -march=core2
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-10-16 11:09 --- Re-open, as this fails with -O, not -O2 and so is not an exact duplicate of PR27432 (which is also not a regression). Lowering severity as avoiding -fschedule-insns for x86 still holds. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33791
[Bug rtl-optimization/33791] x86 out of registers ICE with -fschedule-insns -march=core2
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-10-16 11:12 --- The problem is exactly the same, the ra sucks. *** This bug has been marked as a duplicate of 27432 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Keywords||ra Resolution||DUPLICATE Summary|[4.1/4.2/4.3 Regression] x86|x86 out of registers ICE |out of registers ICE with - |with -fschedule-insns - |fschedule-insns -march=core2|march=core2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33791
[Bug target/27432] -fschedule-insns -O2 -march=athlon cause compilation error
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-10-16 11:12 --- *** Bug 33791 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27432
[Bug fortran/32580] iso_c_binding c_f_procpointer / procedure pointers
--- Comment #7 from burnus at gcc dot gnu dot org 2007-10-16 11:26 --- > Since adding c_f_procpointer might change the fortran runtime library, will > this addition be OK for 4.4 ? Additions of functions is no problem; also modifying functions arguments/functionality is no problem. However, obsolete (i.e. unused) functions remain in the library (for old programs). If the function interface is changed, the old function remains in the library (with the old version number) and the new version of the function is added. If symbol versioning is supported (e.g. under Linux), old programs continue to work flawlessly with new libraries. Thus: Library interface changes before 4.3.0 is released are nice, because one will not need to carry obsolete functions along; otherwise the development is not hampered at all. For procedure pointers, I expect that one doesn't need to touch the library at at all (but I might be wrong). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32580
[Bug tree-optimization/24001] Simple redundancy not eliminated
--- Comment #7 from steven at gcc dot gnu dot org 2007-10-16 13:32 --- I would expect that tail merging (cross-jumping in gcc jargon) would merge the two paths. Better yet would be to optimize this earlier, and for that we need code hoisting (re. comment #1, I think it is eliminated because we run code hoisting at -Os). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24001
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #12 from steven at gcc dot gnu dot org 2007-10-16 13:33 --- Does not really "block" 24001, but the test case for that bug would be fixed if code hoisting would be implemented properly. -- steven at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||24001 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug middle-end/30905] [4.3 Regression] Fails to cross-jump
--- Comment #7 from steven at gcc dot gnu dot org 2007-10-16 13:34 --- Does not really "block" 24001, but the test case for that bug would be fixed if code hoisting would be implemented properly. -- steven at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||24001 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug c++/33793] New: global scoping for htons/htohs fails (::htons)
GCC version: 3.2.3
Host: Linux
Sample code.
#include
int main()
{
unsigned short t;
::htons(t);
return 0;
}
/usr/bin/g++ -O2 t.cpp
t.cpp: In function `int main()':
t.cpp:10: syntax error before `__extension__'
t.cpp:10: `__x' undeclared (first use this function)
t.cpp:10: (Each undeclared identifier is reported only once for each function
it appears in.)
t.cpp:10: `__v' undeclared (first use this function)
t.cpp: At global scope:
t.cpp:10: syntax error before `)' token
If I don't use -O2 the code compiles. If I change ::htons to htons the code
compiles even with -O2. Why does it fail for ::htons()
--
Summary: global scoping for htons/htohs fails (::htons)
Product: gcc
Version: 3.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amit dot khandelwal at lehman dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33793
[Bug middle-end/33794] New: [Regression 4.3.0] Wrong code w/ -m32 -ffast-math -march=opteron
This is on x86_64-unknown-linux-gnu (AMD Athlon64 X2 4800+)
with 4.3.0 20071016 [trunk revision 129377].
Working: 4.3.0 20071015 [trunk revision 129311].
induct.f90 is part of the polyhedron test suite.
For
gfortran -m32 -march=opteron -ffast-math -O1 induct.f90
the program ("induct") immediately aborts with:
"bad mutual inductance between quad 1 and the wand transmit coil, abort."
The program works with "-m64" and with "-m32 -mfpmath=sse".
The Polyhedron test case can be obtained from:
http://www.polyhedron.co.uk/MFL6VW74649
--
Summary: [Regression 4.3.0] Wrong code w/ -m32 -ffast-math -
march=opteron
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug c++/33793] global scoping for htons/htohs fails (::htons)
--- Comment #1 from schwab at suse dot de 2007-10-16 15:46 --- htons is a macro, use parens or #undef to suppress it. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33793
[Bug target/27880] [4.2/4.3 regression] undefined reference to `_Unwind_GetIPInfo'
--- Comment #19 from patchapp at dberlin dot org 2007-10-16 16:19 --- Subject: Bug number PR target/27880 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01023.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
[Bug middle-end/33794] Wrong code w/ -m32 -ffast-math -march=opteron
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-16 16:20 --- Since this is using -ffast-math, i suspect this is not a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[Regression 4.3.0] Wrong|Wrong code w/ -m32 -ffast- |code w/ -m32 -ffast-math - |math -march=opteron |march=opteron | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug fortran/33795] New: Environment variable GFORTRAN_UNBUFFERED_ not working
As found by Harald Anlauf, http://gcc.gnu.org/ml/fortran/2007-10/msg00239.html , the GFORTRAN_UNBUFFERED_ environment variables are not effective, only GFORTRAN_UNBUFFERED_ALL affects the buffering. Francois-Xavier replied: Currently, GFORTRAN_UNBUFFERED_ALL is implemented but GFORTRAN_UNBUFFERED_n (where n is not ALL) isn't. This should either be implemented, or the documentation for that feature should be removed (as well as the unused code providing partial support for it). I think the second choice is simplest, because 1. people who want unbuffered output can use GFORTRAN_UNBUFFERED_ALL, and 2. if they really need partial unbuffered output, they can use FLUSH. -- Summary: Environment variable GFORTRAN_UNBUFFERED_ not working Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33795
[Bug libstdc++/33578] __gnu_parallel::yield means what?
--- Comment #8 from bkoz at gcc dot gnu dot org 2007-10-16 17:24 --- Changing this summary now that the mingw32 issue is fixed. Now, opening this out to the implementation issues... -- bkoz at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|i686-pc-mingw32 |all GCC target triplet|i686-pc-mingw32 |all Summary|__gnu_parallel::yield broken|__gnu_parallel::yield means |on mingw32 |what? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33578
[Bug target/33168] [4.3 Regression] GCC Boot failure, building libstc++
--- Comment #12 from janis at gcc dot gnu dot org 2007-10-16 18:24 ---
Segher has a patch for related PR 31490 that fixed the original 32-bit
bootstrap problem. Yesterday I confirmed that it also fixes the 64-bit
powerpc64-linux bootstrap for all languages but Ada. The only test differences
between a 64-bit build with his patch and a 32-bit build without it are
gcc.dg/20051207-3.c, which he earlier said is expected to behave differently
with this patch, and cc1 segfaults with some of the
gcc.c-torture/compile/limits-*.c tests, which also fail with a C-only 64-bit
bootstrap without the patch.
Here's the patch I tested:
Index: gcc/varasm.c
===
--- gcc/varasm.c(revision 129361)
+++ gcc/varasm.c(working copy)
@@ -536,10 +536,20 @@
else
{
sect = *slot;
+
+ /* Sanity check user variables for flag changes. */
if ((sect->common.flags & ~SECTION_DECLARED) != flags
&& ((sect->common.flags | flags) & SECTION_OVERRIDE) == 0)
{
- /* Sanity check user variables for flag changes. */
+ /* Allow mixed writable and read-only objects in named sections. */
+ if ((sect->common.flags & SECTION_NAMED) != 0
+ && ((sect->common.flags ^ flags) & ~SECTION_DECLARED)
+ == SECTION_WRITE)
+ {
+ sect->common.flags |= SECTION_WRITE;
+ return sect;
+ }
+
if (decl == 0)
decl = sect->named.decl;
gcc_assert (decl);
When I first tested this patch a month ago (with a 32-bit bootstrap) there was
a discussion between Segher and Dinar Temirbulatov about the best way to fix
this; I've copied both of them.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
CC||segher at kernel dot
||crashing dot org,
||dtemirbulatov at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
[Bug target/32961] GCC 4.2 has different requirements for x86 shift xmm intrinsics
--- Comment #2 from mrs at apple dot com 2007-10-16 19:29 --- I can confirm the bug and that Intel's documentation does not have a immediate restriction on any of the epi functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics
--- Comment #3 from hjl at lucon dot org 2007-10-16 20:02 --- pslld[wdq] takes an xmm register as shift count. It is a bug in gcc. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-16 20:02:50 date|| Summary|GCC 4.2 has different |[4.2/4.3 Regression]: Gcc |requirements for x86 shift |has different requirements |xmm intrinsics |for x86 shift xmm intrinsics http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug target/33594] [4.0/4.1/4.2/4.3 regression] stack arrays not aligned on word boundaries
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-10-16 20:43 --- Subject: Bug 33594 Author: ebotcazou Date: Tue Oct 16 20:43:02 2007 New Revision: 129385 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129385 Log: PR target/33594 * config/sparc/sparc.h (LOCAL_ALIGNMENT): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33594
[Bug target/33594] [4.0/4.1/4.2 regression] stack arrays not aligned on word boundaries
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-10-16 20:46 --- Will be fixed in the future 4.3.x releases. Thanks for reporting this. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||10/msg00951.html Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.0/4.1/4.2/4.3 regression]|[4.0/4.1/4.2 regression] |stack arrays not aligned on |stack arrays not aligned on |word boundaries |word boundaries Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33594
[Bug c/33796] New: valgrind error with -O2 for linux kernel code
I just tried to compile the Linux kernel 2.6.23.1 with the GNU C compiler version 4.3 snapshot 20071012 under valgrind. valgrind said gcc -Wp,-MD,scripts/genksyms/.genksyms.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o scripts/genksyms/genksyms.o scripts/genksyms/genksyms.c ==22718== Conditional jump or move depends on uninitialised value(s) ==22718==at 0xA7ECC3: global_conflicts (sparseset.h:90) ==22718==by 0xA52856: rest_of_handle_global_alloc (global.c:533) ==22718==by 0x643328: execute_one_pass (passes.c:1117) ==22718==by 0x6434FF: execute_pass_list (passes.c:1170) ==22718==by 0x643514: execute_pass_list (passes.c:1171) ==22718==by 0x71EA9F: tree_rest_of_compilation (tree-optimize.c:404) ==22718==by 0x89B7E1: cgraph_expand_function (cgraphunit.c:1060) ==22718==by 0x89DC4B: cgraph_optimize (cgraphunit.c:1123) ==22718==by 0x4160CD: c_write_global_declarations (c-decl.c:8077) ==22718==by 0x6C41DF: toplev_main (toplev.c:1052) ==22718==by 0x52BAAE3: (below main) (in /lib64/libc-2.5.so) ==22718== Preprocessed source code attached. Flag -O2 required. -- Summary: valgrind error with -O2 for linux kernel code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: sue-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug c/33796] valgrind error with -O2 for linux kernel code
--- Comment #1 from dcb314 at hotmail dot com 2007-10-16 20:49 --- Created an attachment (id=14361) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14361&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug fortran/33795] Environment variable GFORTRAN_UNBUFFERED_ not working
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-10-16 21:09 --- I will wok this one. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-16 21:09:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33795
[Bug c++/31446] [4.2/4.3 regression] ICE with invalid template parameter
--- Comment #10 from paolo at gcc dot gnu dot org 2007-10-16 22:22 --- Subject: Bug 31446 Author: paolo Date: Tue Oct 16 22:21:59 2007 New Revision: 129391 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129391 Log: /cp 2007-10-16 Paolo Carlini <[EMAIL PROTECTED]> PR c++/31446 * pt.c (current_template_args): Do not change TREE_LIST elements with a TREE_VALUE of error_mark_node. /testsuite 2007-10-16 Paolo Carlini <[EMAIL PROTECTED]> PR c++/31446 * g++.dg/template/void11.C: New. * g++.dg/template/void2.C: Adjust error markers. * g++.dg/template/void10.C: Likewise. * g++.dg/template/crash55.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/template/void11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/crash55.C trunk/gcc/testsuite/g++.dg/template/void10.C trunk/gcc/testsuite/g++.dg/template/void2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31446
[Bug c++/31446] [4.2 regression] ICE with invalid template parameter
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.2/4.3 regression] ICE|[4.2 regression] ICE with |with invalid template |invalid template parameter |parameter | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31446
[Bug c++/30299] [4.2/4.3 regression] ICE with broken template and inheritance
--- Comment #5 from paolo at gcc dot gnu dot org 2007-10-16 22:41 --- Subject: Bug 30299 Author: paolo Date: Tue Oct 16 22:41:32 2007 New Revision: 129392 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129392 Log: 2007-10-16 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28639 PR c++/30299 * g++.dg/template/void12.C: New. * g++.dg/template/void13.C: New. Added: trunk/gcc/testsuite/g++.dg/template/void12.C trunk/gcc/testsuite/g++.dg/template/void13.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30299
[Bug c++/28639] [4.2/4.3 regression] ICE trying to print error on invalid template parameter
--- Comment #11 from paolo at gcc dot gnu dot org 2007-10-16 22:41 --- Subject: Bug 28639 Author: paolo Date: Tue Oct 16 22:41:32 2007 New Revision: 129392 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129392 Log: 2007-10-16 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28639 PR c++/30299 * g++.dg/template/void12.C: New. * g++.dg/template/void13.C: New. Added: trunk/gcc/testsuite/g++.dg/template/void12.C trunk/gcc/testsuite/g++.dg/template/void13.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
[Bug c++/30299] [4.2 regression] ICE with broken template and inheritance
--- Comment #6 from pcarlini at suse dot de 2007-10-16 22:44 --- Fixed in mainline. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.2/4.3 regression] ICE|[4.2 regression] ICE with |with broken template and|broken template and |inheritance |inheritance http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30299
[Bug c++/28639] [4.2 regression] ICE trying to print error on invalid template parameter
--- Comment #12 from pcarlini at suse dot de 2007-10-16 22:44 --- Fixed in mainline. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.2/4.3 regression] ICE|[4.2 regression] ICE trying |trying to print error on|to print error on invalid |invalid template parameter |template parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
[Bug middle-end/33335] [4.3 Regression] FAIL: 26_numerics/complex/inserters_extractors/wchar_t/1.cc
--- Comment #7 from danglin at gcc dot gnu dot org 2007-10-16 23:11 --- I'm also seeing this on hppa2.0w-hp-hpux11.11 (__addtf3). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
[Bug other/33797] New: Enable zlib for x86_64-pc-mingw32 64-bit targets
Currently, when building gcc, building is disabled for zlib. If this is enabled, we can further the progress of the 64-bit windows target platform. -- Summary: Enable zlib for x86_64-pc-mingw32 64-bit targets Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nightstrike at gmail dot com GCC target triplet: x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33797
[Bug other/33797] Enable zlib for x86_64-pc-mingw32 64-bit targets
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-17 02:19 --- I think it is only disable because libjava support is disabled because libffi has not been ported yet. So really libffi support needs to be added and then libjava support can be added and in turn zlib can be enabled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33797
[Bug fortran/33760] Bind(C): Using C_PTR as structure constructor gives an ICE
--- Comment #1 from patchapp at dberlin dot org 2007-10-17 04:01 --- Subject: Bug number PR 33760 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00925.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33760
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
-- bergner at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-17 04:01:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #2 from bergner at gcc dot gnu dot org 2007-10-17 04:46 --- Although valgrind is correct that we are doing an uninitialized read, the code is actually working as designed and is correct. When we allocate a sparseset, we only need to set set->members to 0 to clear the set. The arrays set->sparse[] and set->dense[] are not and do not need to be initialized. To test a value "n" for membership in "set", it needs to statisfy two properties: set->sparse[n] < set->members and set->dense[set->sparse[n]] == n The uninitialized read occurs when "n" is not (and never has been) a member of "set". In this case, set->sparse[n] will be uninitialized and could be any value. If set->sparse[n] happens to be >= set->members, we luckily (but correctly) return that "n" is not a member of the set. If the uninitialized set->sparse[n] is < set->members, we continue on to verify that set->dense[set->sparse[n]] == n. This test cannot be true since all set->dense[i] entries for i < set->members are initialized and "n" is not a member of the set. So yes we do some uninitialized accesses to the sparse array, but that's ok. It's also a benefit of sparseset, given that we don't have to memset/clear the whole sparseset data structure before using it, so it's fast. -- bergner at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug c/33798] New: tree-dse / -ftree-dse behavior not documented
While there is a reference to -ftree-dse being turned on with -O optimization in both the manpage and the online docs (see e.g. http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Optimize-Options.html#Optimize-Options), that is the only reference to this option. The specific behavior of this option does not appear in either the manpage or the online docs. Confirmed to exist in 4.2.0 and 4.2.2 docsets. Maybe more? -- Summary: tree-dse / -ftree-dse behavior not documented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: metallurge at gmail dot com GCC build triplet: 4.2.0 GCC host triplet: 4.2.0 GCC target triplet: 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33798
[Bug fortran/33760] Bind(C): Using C_PTR as structure constructor gives an ICE
--- Comment #3 from burnus at gcc dot gnu dot org 2007-10-17 06:57 --- FIXED on the trunk (4.3.0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33760
[Bug fortran/33760] Bind(C): Using C_PTR as structure constructor gives an ICE
--- Comment #2 from burnus at gcc dot gnu dot org 2007-10-17 06:57 --- Subject: Bug 33760 Author: burnus Date: Wed Oct 17 06:57:06 2007 New Revision: 129402 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129402 Log: 2007-10-17 Christopher D. Rickett <[EMAIL PROTECTED]> PR fortran/33760 * symbol.c (gen_special_c_interop_ptr): Remove code to create constructor for c_null_ptr and c_null_funptr with value of 0. * expr.c (check_init_expr): Prevent check on constructors for iso_c_binding derived types. * resolve.c (resolve_structure_cons): Verify that the user isn't trying to invoke a structure constructor for one of the iso_c_binding derived types. 2007-10-17 Christopher D. Rickett <[EMAIL PROTECTED]> PR fortran/33760 * gfortran.dg/c_ptr_tests_13.f03: New test case. Added: trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_13.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33760
