[Bug c/29409] New: Avr-gcc 4.1.1 build fails
I tried to build avr-gcc 4.1.1 but i got an error message: ../gcc-4.1.1/gcc/. -I../../gcc-4.1.1/gcc/../include -I../../gcc-4.1.1/gcc/../libcpp/include -DL_fixunssfsi -c ../../gcc-4.1.1/gcc/libgcc2.c -o libgcc/./_fixunssfsi.o ../../gcc-4.1.1/gcc/libgcc2.c: In function '__fixunssfsi': ../../gcc-4.1.1/gcc/libgcc2.c:1499: internal compiler error: in compute_frame_pointer_to_cfa_displacement, at dwarf2out.c:10446 binutils 2.17 was build in another directory. I use Mandriva 2006 with gcc 4.0.1 The configure string for building avr-gcc 4.1.1 was: "../gcc-4.1.1/configure --prefix=usr/local/avr411 --target=avr --enable-languages=c --disable-nls --disable-libssp --with-dwarf2" -- Summary: Avr-gcc 4.1.1 build fails Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rumjantsev at papillon dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29409
[Bug c++/29048] [4.0/4.1/4.2 Regression] "`x' is private" error duplicated when scope specified
--- Comment #2 from steven at gcc dot gnu dot org 2006-10-10 06:48 --- I'll look into this. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-12 22:32:01 |2006-10-10 06:48:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29048
[Bug c++/29408] [4.1 regression] parse error for valid code
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-10 05:00 ---
I don't think this is valid code, reduced testcase:
template class a
{
~a();
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
[Bug target/29384] internal compiler error: in insn_default_length, at insn-attrtab.c:1134
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-10 04:57 --- Works in 4.0.x and above so closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29384
[Bug c++/15795] No way to teach operator new anything about alignment requirements
--- Comment #37 from mrs at apple dot com 2006-10-10 04:54 --- Additionally, you can petition ISO/C++ to provide a more elegant solution for you. VxWorks also does 16-byte alignment on ppc (for altivec) as I recall. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
[Bug bootstrap/29402] Parallel make fails with --disable-bootstrap
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-10 04:51 --- ALL_GTFILES_H should have included gt-c-pragma.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29402
[Bug c++/28349] [4.0 regression] ICE with "undefined" va_arg and references
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-10 04:38 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28349
[Bug c++/28349] [4.0 regression] ICE with "undefined" va_arg and references
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-10 04:38 --- Subject: Bug 28349 Author: pinskia Date: Tue Oct 10 04:38:25 2006 New Revision: 117595 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117595 Log: 2006-10-09 Andrew Pinski <[EMAIL PROTECTED]> PR C++/28349 * call.c (build_x_va_arg): Remove the reference type from the type before creating the pointer type. 2006-10-09 Andrew Pinski <[EMAIL PROTECTED]> PR c++/28349 * testsuite/g++.dg/warn/var-args1.C: New test Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/warn/var-args1.C - copied unchanged from r116577, trunk/gcc/testsuite/g++.dg/warn/var-args1.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/call.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28349
[Bug c++/29236] [4.0/4.1/4.2? regression] Bogus ambiguity with templates + friend
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-10 04:31 --- foo should not have been injected by the friend. Note the Priority should be only changed by the release manager. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.2.3 3.3.5 3.4.6 4.0.1 |3.2.3 3.3.5 3.4.6 4.0.1 |4.1.1 4.2.0 |4.1.1 4.2.0 3.0.4 Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29236
gcc-bugs@gcc.gnu.org
--- Comment #5 from bangerth at dealii dot org 2006-10-10 04:27 --- Here's the right combination of flags that warns (for f3() only): g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -Winit-self -Wuninitialized -O2 -c x.cc x.cc: In function ‘void f3()’: x.cc:42: warning: ‘d3$c$v’ is used uninitialized in this function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29117
gcc-bugs@gcc.gnu.org
--- Comment #4 from bangerth at dealii dot org 2006-10-10 04:24 ---
Your expectations are wrong. You probably believe that here
-
void f3()
{
D d3;
printf("3) getValue() -> %d,", d3.getValue());
{
D d3 = d3;
printf("getValue() -> %d\n", d3.getValue());
}
}
--
the initialization of the inner d3 should happen with the outer d3, but
that isn't so: in the initialization clause, the outer d3 is already no
longer visible. You therefore initialize a variable with itself. This is
a documented way to generate uninitialized variables and at the same time
circumvent the warning that would usually results from this action.
There is a warning -Winit-self in more recent releases that warns about this
specific case. Now, of course the fact that it doesn't trigger on this code
is not very helpful. Have to investigate this...
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29117
[Bug c++/29236] [4.0/4.1/4.2? regression] Bogus ambiguity with templates + friend
--- Comment #4 from bangerth at dealii dot org 2006-10-10 04:13 --- btw, this only happens if Q is really a template template argument. As noted by the original reporter, the problem goes away if Q is simply a template argument. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29236
[Bug c++/29236] [4.0/4.1/4.2? regression] Bogus ambiguity with templates + friend
--- Comment #3 from bangerth at dealii dot org 2006-10-10 04:11 ---
Confirmed:
--
template struct A {};
template class P>
struct B {
template class Q>
friend bool foo (const B& a);
};
template class Q>
bool foo (const B& a);
void bar () {
B a;
foo (a);
}
--
g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc
x.cc: In function ‘void bar()’:
x.cc:14: error: call of overloaded ‘foo(B&)’ is ambiguous
x.cc:10: note: candidates are: bool foo(const B&) [with Q = A]
x.cc:6: note: bool foo(const B&) [with Q = A, P = A]
icc accepts the code. I believe we simply forget to unify the tentative
declaration from the friend declaration with the real template once we
encounter it, and end up with two declarations instead of one. We then
get confused when we have to pick one of the two.
This is a regression introduced in 3.2 over 2.95.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||rejects-valid
Known to fail||3.2.3 3.3.5 3.4.6 4.0.1
||4.1.1 4.2.0
Known to work||2.95
Priority|P3 |P2
Last reconfirmed|-00-00 00:00:00 |2006-10-10 04:11:45
date||
Summary|Friend operators for class |[4.0/4.1/4.2? regression]
|with template in template |Bogus ambiguity with
|argument does not compile |templates + friend
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29236
[Bug c++/29008] Fails to accept templated constructor
--- Comment #3 from bangerth at dealii dot org 2006-10-10 04:00 --- The standard does not provide to explicitly specify the template arguments of a constructor invocation. The syntax name refers to a template class 'name' with template argument 'type', not to a template constructor 'name::name'. This is just how the language works, nothing we can do about. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29008
[Bug c++/29297] Segmentation fault on "invalid use of `::'"
--- Comment #1 from bangerth at dealii dot org 2006-10-10 03:56 --- Indeed can't reproduce on x86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29297
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #6 from bangerth at dealii dot org 2006-10-10 03:54 --- Confirmed. The code makes sense and we shouldn't unconditionally warn. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-10 03:54:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug c++/29234] Call to operator() of temporary object wrongly parsed
--- Comment #1 from bangerth at dealii dot org 2006-10-10 03:51 ---
Confirmed:
--
struct S { void operator () (); };
void foo ()
{
( S()() );
}
--
g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc
x.cc: In function ‘void foo()’:
x.cc:5: error: ‘type name’ declared as function returning a
function
x.cc:5: error: ‘type name’ declared as function returning a
function
The error message also isn't particularly enlightening, and is duplicated
on top of that.
I think what is happening is that we parse the expression as the beginning
of a C-style cast to type
S (*) ()
but when we don't find an argument for the cast, we should backtrack.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||rejects-valid
Priority|P3 |P2
Last reconfirmed|-00-00 00:00:00 |2006-10-10 03:51:44
date||
Summary|Cannot put temporary member |Call to operator() of
|functor calls inside|temporary object wrongly
|brackets|parsed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29234
[Bug c++/29188] undocumented extension with ambiguous between conversion function/constructor. related to const
--- Comment #3 from bangerth at dealii dot org 2006-10-10 03:44 ---
Confirmed. Not a useful extension because confusing:
-
struct A;
struct B {
B (const A&);
};
struct A {
operator B() const;
};
A a;
B b1 = a;// xpass
---
g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc
g/x> /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc -pedantic
x.cc:12: error: conversion from ‘A’ to ‘B’ is ambiguous
x.cc:8: note: candidates are: A::operator B() const
x.cc:4: note: B::B(const A&)
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-10-10 03:44:52
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29188
[Bug c++/20039] uninitialized const in `new' of `const struct'
--- Comment #2 from bangerth at dealii dot org 2006-10-10 03:36 --- *** Bug 28990 has been marked as a duplicate of this bug. *** -- bangerth at dealii dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20039
[Bug c++/28990] const new: Inherited constructor accepted in lieu of user-defined constructor
--- Comment #2 from bangerth at dealii dot org 2006-10-10 03:36 --- This is in fact a duplicate of PR 20039. *** This bug has been marked as a duplicate of 20039 *** -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28990
[Bug middle-end/29390] Bogus symbol inserted into valid C++ code at low optimization level
--- Comment #9 from bangerth at dealii dot org 2006-10-10 03:26 --- (In reply to comment #8) > (In reply to comment #7) > > 3.4.4 (or 3.4.6) are the system compilers on FreeBSD-5.x and FreeBSD-6.x > So what, we are talking about the FSF GCC and not freebsd and 3.4.x is no > longer maintained by the FSF. Maybe slightly more diplomatic than Andrew's answer: we try to maintain current development mainline + two older release branches (presently 4.0.x and 4.1.x). Our limited resources do not allow to support older releases. That said, since you have access to a FreeBSD system, finding the relevant patch using a binary search of the subversion archive between the revision numbers of the 3.4 branchpoint and the 4.0 release shouldn't be too hard. Of course, whether the relevant patch applies cleanly is another matter. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29390
[Bug c++/29408] [4.1 regression] parse error for valid code
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-10-10 01:18 --- Created an attachment (id=12401) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12401&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
[Bug c++/29408] New: [4.1 regression] parse error for valid code
works with 4.0.4, 4.1.1, 4.2.0, fails with 4.1 branch 20061008 $ g++ -c -Wall -fPIC -fexceptions -frtti -I/usr/include/python2.3 -I/usr/share/python2.3/CXX -I/usr/include/subversion-1 -I/usr/include/apr-1.0 -I. -DNDEBUG -o pysvn.o pysvn.cpp /usr/include/python2.3/CXX/Objects.hxx:1932: error: parse error in template argument list -- Summary: [4.1 regression] parse error for valid code Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
[Bug target/29384] internal compiler error: in insn_default_length, at insn-attrtab.c:1134
--- Comment #2 from rpx at wp dot pl 2006-10-10 00:20 --- Created an attachment (id=12400) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12400&action=view) the output of preprocessor the bug appears with -mips16 compilation option; the compiler seams to be sensitive on the number of lines generated by the macro (the lines starting with strId = eMMISTR_GENRE_XXX); If I comment some of them the problem disapears. The number of lines the compiler behaves OK is 120. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29384
[Bug libstdc++/29095] [4.0/4.1/4.2 Regression] cxxabi.h __cxa_cdtor_type not declared when included from "C"
--- Comment #8 from bkoz at gcc dot gnu dot org 2006-10-09 23:53 --- Subject: Bug 29095 Author: bkoz Date: Mon Oct 9 23:53:35 2006 New Revision: 117589 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117589 Log: 2006-10-09 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/29095 * libsupc++/cxxabi.h (__cxa_cdtor_type): Explicit "C" linkage. * config/cpu/arm/cxxabi_tweaks.h: Same. * config/cpu/generic/cxxabi_tweaks.h: Same. * testsuite/abi: Add. * testsuite/abi/header_cxxabi.cc: New. * testsuite/demangle: Move... * testsuite/abi/demangle: ...here. * testsuite/libstdc++-dg/conformance.exp: Adjust testsuite file calculation. * scripts/create_testsuite_files: Same. * testsuite/lib/libstdc++.exp (v3_target_compile_as_c): New. (libstdc++-dg-test): Use it. Added: trunk/libstdc++-v3/testsuite/abi/ trunk/libstdc++-v3/testsuite/abi/demangle/ - copied from r117575, trunk/libstdc++-v3/testsuite/demangle/ trunk/libstdc++-v3/testsuite/abi/header_cxxabi.c Removed: trunk/libstdc++-v3/testsuite/demangle/ Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/cpu/arm/cxxabi_tweaks.h trunk/libstdc++-v3/config/cpu/generic/cxxabi_tweaks.h trunk/libstdc++-v3/libsupc++/cxxabi.h trunk/libstdc++-v3/scripts/create_testsuite_files trunk/libstdc++-v3/testsuite/lib/libstdc++.exp trunk/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29095
[Bug c/29406] code generation / optimisation bug
--- Comment #2 from fox at crisp dot demon dot co dot uk 2006-10-09 22:02 --- Sorry guys - yes a hopelessly stupid bug on my behalf. Feel free to remove this report! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29406
[Bug testsuite/28870] [4.2 Regression] configuring, over-riding timeout values in testsuite
--- Comment #8 from bkoz at gcc dot gnu dot org 2006-10-09 21:45 --- Note this issue is not c++ or libstdc++ specific. I see timeouts on old hardware all over the testsuite on gcc-testresults. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug middle-end/29406] code generation / optimisation bug
--- Comment #1 from pcarlini at suse dot de 2006-10-09 21:22 --- Undefined behavior, i.e., anything can happen: array sq has got positions 0..8 whereas d = n % 10 spans 0..9, thus the code writes beyond the end of sq. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29406
[Bug target/28185] SIGBUS on IA64 maybe caused by memcpy I
--- Comment #3 from sje at cup dot hp dot com 2006-10-09 20:58 --- William, can you reproduce this problem with a newer GCC? I have tried several versions of GCC and all I get is an error from shmget (Invalid argument). Given that the shmget fails, the memcpy is obviously going to be bogus because we don't have a valid address in shmid[0], which means we don't get a valid address in addr[0] and, of course, that makes the memcpy abort. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28185
[Bug fortran/29312] Errors in subnormal calculation
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-09 20:58 --- Fixed on trunk (until someone tells me ldexp doesn't exist) -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29312
[Bug fortran/15441] RRSPACING broken for denormals
--- Comment #11 from kargl at gcc dot gnu dot org 2006-10-09 20:57 --- Fixed on trunk (until someone tells me ldexp doesn't exist). -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15441
[Bug fortran/15441] RRSPACING broken for denormals
--- Comment #10 from kargl at gcc dot gnu dot org 2006-10-09 20:55 --- Subject: Bug 15441 Author: kargl Date: Mon Oct 9 20:55:29 2006 New Revision: 117584 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117584 Log: 2006-10-06 Steven G. Kargl <[EMAIL PROTECTED]> * gfortran.h: Define GFC_MPFR_TOO_OLD via mpfr version info. * arith.c (arctangent, gfc_check_real_range): Use it. * simplify.c (gfc_simplify_atan2, gfc_simplify_exponent, gfc_simplify_log, gfc_simplify_nearest): Use it. PR fortran/15441 PR fortran/29312 * iresolve.c (gfc_resolve_rrspacing): Give rrspacing library routine hidden precision argument. (gfc_resolve_spacing): Give spacing library routine hidden precision, emin - 1, and tiny(x) arguments. * simplify.c (gfc_simplify_nearest): Remove explicit subnormalization. (gfc_simplify_rrspacing): Implement formula from Fortran 95 standard. (gfc_simplify_spacing): Implement formula from Fortran 2003 standard. * trans-intrinsic.c (gfc_intrinsic_map_t) Declare rrspacing and spacing via LIBF_FUNCTION (prepare_arg_info, call_builtin_clz, gfc_conv_intrinsic_spacing, gfc_conv_intrinsic_rrspacing): Remove functions. (gfc_conv_intrinsic_function): Remove calls to gfc_conv_intrinsic_spacing and gfc_conv_intrinsic_rrspacing. * f95-lang.c (gfc_init_builtin_functions): Remove __builtin_clz, __builtin_clzl and __builtin_clzll 2006-10-06 Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/15441 PR fortran/29312 * configure.ac: Add HAVE_LDEXPF, HAVE_LDEXP, and HAVE_LDEXPL * m4/spacing.m4: New file. Use new HAVE_* defines. * m4/rrspacing.m4: Ditto. * Makefile.am: Handle new files. * configure: Regenerated. * Makefile.in: Ditto. * config.h.in: Ditto. * generated/spacing_r4.c: Generated. * generated/spacing_r8.c: Ditto. * generated/spacing_r10.c: Ditto. * generated/spacing_r16.c: Ditto. * generated/rrspacing_r4.c: Ditto. * generated/rrspacing_r8.c: Ditto. * generated/rrspacing_r10.c: Ditto. * generated/rrspacing_r16.c: Ditto. Added: trunk/libgfortran/generated/rrspacing_r10.c trunk/libgfortran/generated/rrspacing_r16.c trunk/libgfortran/generated/rrspacing_r4.c trunk/libgfortran/generated/rrspacing_r8.c trunk/libgfortran/generated/spacing_r10.c trunk/libgfortran/generated/spacing_r16.c trunk/libgfortran/generated/spacing_r4.c trunk/libgfortran/generated/spacing_r8.c trunk/libgfortran/m4/rrspacing.m4 trunk/libgfortran/m4/spacing.m4 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-intrinsic.c trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15441
[Bug fortran/29312] Errors in subnormal calculation
--- Comment #3 from kargl at gcc dot gnu dot org 2006-10-09 20:55 --- Subject: Bug 29312 Author: kargl Date: Mon Oct 9 20:55:29 2006 New Revision: 117584 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117584 Log: 2006-10-06 Steven G. Kargl <[EMAIL PROTECTED]> * gfortran.h: Define GFC_MPFR_TOO_OLD via mpfr version info. * arith.c (arctangent, gfc_check_real_range): Use it. * simplify.c (gfc_simplify_atan2, gfc_simplify_exponent, gfc_simplify_log, gfc_simplify_nearest): Use it. PR fortran/15441 PR fortran/29312 * iresolve.c (gfc_resolve_rrspacing): Give rrspacing library routine hidden precision argument. (gfc_resolve_spacing): Give spacing library routine hidden precision, emin - 1, and tiny(x) arguments. * simplify.c (gfc_simplify_nearest): Remove explicit subnormalization. (gfc_simplify_rrspacing): Implement formula from Fortran 95 standard. (gfc_simplify_spacing): Implement formula from Fortran 2003 standard. * trans-intrinsic.c (gfc_intrinsic_map_t) Declare rrspacing and spacing via LIBF_FUNCTION (prepare_arg_info, call_builtin_clz, gfc_conv_intrinsic_spacing, gfc_conv_intrinsic_rrspacing): Remove functions. (gfc_conv_intrinsic_function): Remove calls to gfc_conv_intrinsic_spacing and gfc_conv_intrinsic_rrspacing. * f95-lang.c (gfc_init_builtin_functions): Remove __builtin_clz, __builtin_clzl and __builtin_clzll 2006-10-06 Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/15441 PR fortran/29312 * configure.ac: Add HAVE_LDEXPF, HAVE_LDEXP, and HAVE_LDEXPL * m4/spacing.m4: New file. Use new HAVE_* defines. * m4/rrspacing.m4: Ditto. * Makefile.am: Handle new files. * configure: Regenerated. * Makefile.in: Ditto. * config.h.in: Ditto. * generated/spacing_r4.c: Generated. * generated/spacing_r8.c: Ditto. * generated/spacing_r10.c: Ditto. * generated/spacing_r16.c: Ditto. * generated/rrspacing_r4.c: Ditto. * generated/rrspacing_r8.c: Ditto. * generated/rrspacing_r10.c: Ditto. * generated/rrspacing_r16.c: Ditto. Added: trunk/libgfortran/generated/rrspacing_r10.c trunk/libgfortran/generated/rrspacing_r16.c trunk/libgfortran/generated/rrspacing_r4.c trunk/libgfortran/generated/rrspacing_r8.c trunk/libgfortran/generated/spacing_r10.c trunk/libgfortran/generated/spacing_r16.c trunk/libgfortran/generated/spacing_r4.c trunk/libgfortran/generated/spacing_r8.c trunk/libgfortran/m4/rrspacing.m4 trunk/libgfortran/m4/spacing.m4 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-intrinsic.c trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29312
[Bug fortran/29407] New: namelist: overriding the host association does not work (rejects valid code)
--- program main implicit none contains subroutine my end subroutine my subroutine bar integer :: my namelist /ops/ my end subroutine bar end program main --- gives in gfortran the error message: namelist /ops/ my 1 Error: PROCEDURE attribute conflicts with NAMELIST attribute in 'my' at (1) With other compilers it works and Brooks Moses writes: "Gfortran is wrong. The INTEGER declaration in BAR declares MY as a local variable, thus overriding the host association of MY as the subroutine from the main program. Thus, as far as NAMELIST is concerned, this is an ordinary integer variable." -- Summary: namelist: overriding the host association does not work (rejects valid code) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29407
[Bug fortran/29373] implicit type declaration and contained function clash
--- Comment #3 from paulthomas2 at wanadoo dot fr 2006-10-09 20:11 --- Subject: Re: implicit type declaration and contained function clash tobi at gcc dot gnu dot org wrote: >(BTW I added you to the CC list, it is kinda hard to answer in the right place >otherwise) > > Oh s**t - next thing is that you'll want me to fix it too? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
[Bug libgcj/29205] lib/pkgconfig/libgcj.pc needs to become version dependent
--- Comment #2 from gerald at pfeifer dot com 2006-10-09 19:46 --- Making the major.minor number (4.1, 4.2,...) part of the name sounds quite fine to me! (Sorry for the delay in responding to your question, Tom. I've been out last week.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29205
[Bug c/29406] New: code generation / optimisation bug
I was writing a magic squares program for my sons homework and somewhat
surprised/annoyed that gcc-4.1.1 and 4.0.3 have a horrible code generation bug.
Compiled with -O or -O2 on gcc-4.0.3 the following code infinitely loops.
gcc-4.1.1 with no optimisation works, but -O2 fails. Local variable "n" in
main() is modified by the try function when it cannot be.
# include
# include
int nums[] = {15, 9, 3, 7, 13, 17, 11, 5, 19};
void try_sq(int n);
int main(int argc, char **argv)
{
int n;
for (n = 0; n < 9; n++) {
if ((n % 1000) == 0)
printf("%d\n", n);
try_sq(n);
}
return 0;
}
void try_sq(int n)
{ int sq[9], sq2[9];
int i, s;
memcpy(sq, nums, sizeof nums);
for (i = 0; i < 9; i++) {
int d = n % 10;
n /= 10;
if (sq[d] == 0)
return;
sq2[i] = sq[d];
sq[d] = 0;
}
/***/
/* Rows. */
/***/
s = sq2[0] + sq2[1] + sq2[2];
if (s != 33)
return;
s = sq2[3] + sq2[4] + sq2[5];
if (s != 33)
return;
s = sq2[6] + sq2[7] + sq2[8];
if (s != 33)
return;
/***/
/* Columns. */
/***/
s = sq2[0] + sq2[3] + sq2[6];
if (s != 33)
return;
s = sq2[1] + sq2[4] + sq2[8];
if (s != 33)
return;
s = sq2[2] + sq2[5] + sq2[8];
if (s != 33)
return;
/***/
/* Diagonal. */
/***/
s = sq2[0] + sq2[4] + sq2[8];
if (s != 33)
return;
s = sq2[2] + sq2[4] + sq2[6];
if (s != 33)
return;
printf("%2d %2d %2d\n", sq2[0], sq2[1], sq2[2]);
printf("%2d %2d %2d\n", sq2[3], sq2[4], sq2[5]);
printf("%2d %2d %2d\n", sq2[6], sq2[7], sq2[28]);
printf("\n===\n");
}
--
Summary: code generation / optimisation bug
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fox at crisp dot demon dot co dot uk
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=29406
[Bug target/27880] [4.2 regression] undefined reference to `_Unwind_GetIPInfo'
--- Comment #14 from sje at cup dot hp dot com 2006-10-09 18:31 --- With the patch I just checked in, I believe that this defect is now fixed. The uses of GetIPInfo in libstdc++ and libjava were fixed earlier, this latest patch fixes the use in unwind-c.c and that should be it. -- sje at cup dot hp dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
[Bug target/28490] [4.0/4.1 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #22 from sje at cup dot hp dot com 2006-10-09 18:27 --- Backported the change to 4.1 and 4.0 branches. Closing as fixed. -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/28490] [4.0/4.1 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #21 from sje at gcc dot gnu dot org 2006-10-09 18:26 --- Subject: Bug 28490 Author: sje Date: Mon Oct 9 18:26:35 2006 New Revision: 117583 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117583 Log: PR target/28490 Backport from mainline 2006-09-15 Jim Wilson <[EMAIL PROTECTED]> 2006-09-19 Steve Ellcey <[EMAIL PROTECTED]> * config/ia64/ia64.c (ia64_legitimate_constant_p): Allow function pointers as legitimate constants. Handle symbol offsets same as they are handled in ia64_expand_move and move_operand. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/ia64/ia64.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/28490] [4.0/4.1 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #20 from sje at gcc dot gnu dot org 2006-10-09 18:24 --- Subject: Bug 28490 Author: sje Date: Mon Oct 9 18:24:32 2006 New Revision: 117582 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117582 Log: PR target/28490 Backport from mainline 2006-09-15 Jim Wilson <[EMAIL PROTECTED]> 2006-09-19 Steve Ellcey <[EMAIL PROTECTED]> * config/ia64/ia64.c (ia64_legitimate_constant_p): Allow function pointers as legitimate constants. Handle symbol offsets same as they are handled in ia64_expand_move and move_operand. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/ia64/ia64.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug libstdc++/28277] __builtin_alloca with no limit in libstdc++
--- Comment #13 from paolo at gcc dot gnu dot org 2006-10-09 18:04 --- Subject: Bug 28277 Author: paolo Date: Mon Oct 9 18:04:18 2006 New Revision: 117581 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117581 Log: 2006-10-09 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/28277 (partial: __add_grouping) * include/bits/locale_facets.tcc (__add_grouping<>(_CharT*, _CharT, const char*, size_t, const _CharT*, const _CharT*)): Rewrite in non-recursive form. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/locale_facets.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28277
[Bug c++/11407] [DR 115] Function cannot be resolved
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-09 17:57 --- *** Bug 28793 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||suzev dot kirill at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11407
[Bug c++/28793] Error while deducting template arg
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-09 17:57 --- Mark as a dup of bug 11407. *** This bug has been marked as a duplicate of 11407 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28793
[Bug c++/28793] Error while deducting template arg
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-09 17:57 --- Reopening for a second to ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28793
[Bug testsuite/29404] "make check" fails to compile library testcases
--- Comment #4 from ghazi at gcc dot gnu dot org 2006-10-09 17:28 --- (In reply to comment #2) > --disable-bootstrap is not really supported and really has not been tested any > more besides cross builds. Andrew please reread my initial report, I specifically talked about "three-stage bootstrap" and differences between stage1 and stage3 compiler. This is *not* a --disable-bootstrap related bug. Perhaps you're referring to my other submission today? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29404
[Bug testsuite/29404] "make check" fails to compile library testcases
--- Comment #3 from ghazi at gcc dot gnu dot org 2006-10-09 17:25 --- (In reply to comment #1) > What platform are you compiling on? sorry, it's on sparc-sun-solaris2.10, using vendor's cc for stage1. You probably won't see this problem if stage1 cc is any version of gcc, whether vendor supplied or user-built, because it'll have it's own copy of compatible libgcc bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29404
[Bug testsuite/29404] "make check" fails to compile library testcases
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-09 17:22 --- --disable-bootstrap is not really supported and really has not been tested any more besides cross builds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29404
[Bug other/29405] GCC should include latest GMP/MPFR sources and always build libgmp.a/libmpfr.a
--- Comment #1 from ghazi at gcc dot gnu dot org 2006-10-09 17:18 --- Initial patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00416.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29405
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #9 from ghazi at gcc dot gnu dot org 2006-10-09 17:16 --- I decided to explore including GMP/MPFR in the GCC tree. Dependency PR 29405 opened to track that enhancement. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||29405 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug other/29405] New: GCC should include latest GMP/MPFR sources and always build libgmp.a/libmpfr.a
I'm using this to track issues related to including GMP/MPFR in the GCC source tree and building these libraries as part of the bootstrap process. Initial discussion started here: http://gcc.gnu.org/ml/gcc/2006-10/msg00136.html -- Summary: GCC should include latest GMP/MPFR sources and always build libgmp.a/libmpfr.a Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29405
[Bug testsuite/29404] "make check" fails to compile library testcases
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2006-10-09 17:00 --- What platform are you compiling on? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29404
[Bug testsuite/29404] New: "make check" fails to compile library testcases
When I run "make check" on a three-stage bootstrapped tree, I get errors from libiberty's testsuite: cc -DHAVE_CONFIG_H -g -I.. -I../../../egcc-SVN20061008/libiberty/testsuite/../../include -DHAVE_CONFIG_H -I.. -o test-pexecute ../../../egcc-SVN20061008/libiberty/testsuite/test-pexecute.c ../libiberty.a Undefined first referenced symbol in file __umoddi3 ../libiberty.a(mkstemps.o) __udivdi3 ../libiberty.a(mkstemps.o) ld: fatal: Symbol referencing errors. No output written to test-pexecute make[3]: *** [test-pexecute] Error 1 The problem appears to be that the libiberty library was three-staged using the new top-level bootstrap mechanism and therefore was compiled more recently by stage3 gcc, but the testcase driver is compiled and linked against this library with the stage1 compiler (cc). Therefore symbols from libgcc (if any are needed) won't be resolved. We need to use the same compiler for the tests as was used to compile the library we're testing. That changes depending on whether we use --disable-bootstrap or not. This will become much more serious if we include other libraries in the GCC tree such as GMP/MPFR where testsuite results are more important. -- Summary: "make check" fails to compile library testcases Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29404
[Bug rtl-optimization/29294] 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM
--- Comment #7 from ramana dot radhakrishnan at codito dot com 2006-10-09 16:33 --- (In reply to comment #5) flow.c is responsible for generating POST_INCs and POST_MODIFY's in 3.4 / 4.0 / 4.1 / 4.2 . I believe this is being replaced by the new data flow bits in the data flow branch. This might not be ready until 4.3 . We have hit similar issues in a private port that I maintain. 2 options are either to fix flow.c or use some of Joern's auto increment patches for 4.1 / 4.2 to fix this issue. This doesn't really take care of POST_MODIFY but I don't think that affects ARM that much. > Here's what's going on in this case: > > CSE changes an address if: >A) The cost of the address is lower > or >B) The cost of the address is the same and the cost of the RTX would be > higher outside of an address > > So, CSE changes (R) to (R+4) because it is lower cost as specified by the > address_costs hook. > > It doesn't change beyond (R+4) because (R+8) is the same cost as (R+4). > > Once the address (R+4) gets in the RTL sequence, it never gets converted to > a postincrement form. > > So by adding the cost of a simple REG RTX as being lower than (+ (REG) > (CONST)) > in the addressing modes, CSE doesn't convert the address to base+offset, and > we get the postincrement code back again in 4.x. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294
[Bug fortran/29403] New: print ('(a)') not working, print '(a) works
>From http://gcc.gnu.org/ml/fortran/2006-10/msg00274.html
gfortran shows:
print ('(z20.8)'), i
1
Error: Syntax error in PRINT statement at (1)
The (optional) parentheses are allow (see below) and it works in ifort, NAG f95
and g95.
>From Fortran 2003 standard Section 9.5 and 9.5.1.1:
R911 write-stmt is WRITE (io-control-spec-list) [output-item list]
R912 print-stmt is PRINT format[, output-item-list]
where "format" is:
R914 format is default-char-expr
or label
or *
Note that "default-char-expr" is:
R726 default-char-expr is expr
C707 (R726) default-char-expr shall be of type default character.
If one goes through all the "expr", "level-5-expr", ... one ends up at
R701 primary is constant
[...]
or ( expr )
In other words: A default-char-expr may have parentheses around.
--
Summary: print ('(a)') not working, print '(a) works
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29403
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-09 16:27 --- Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites > Hey Dave. Thanks for your persistence on this one: I think it's paid off. I > can > see what you are talking about WRT mutex initialization, and have high hopes > for the attached patch. If you can try it, and let me know the results I'd > appreciate it. I rebuilt libstdc++ with the patch and ran through most of the testsuite without seeing any timeouts. I'm now doing a complete bootstrap and check on a couple of systems with todays source. Thanks, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug bootstrap/29402] New: Parallel make fails with --disable-bootstrap
When I configure with --disable-bootstrap and I try a parallel make -j4, I get the following error inside the gcc directory: make[2]: *** No rule to make target `gt-c-pragma.h', needed by `c-pragma.o'. Stop. make[2]: *** Waiting for unfinished jobs If I do a "make -j4 -k" it still gets the error, but after that a "make -j4" works. So gt-c-pragma.h is getting generated but no dependency exists. There may be other gt- files missing dependencies too. I'm using sparc-sun-solaris2.10 and gnumake-3.80, but I don't think that matters. -- Summary: Parallel make fails with --disable-bootstrap Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29402
[Bug middle-end/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-09 16:11 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29254
[Bug middle-end/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-09 16:10 --- Subject: Bug 29254 Author: rguenth Date: Mon Oct 9 16:10:38 2006 New Revision: 117577 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117577 Log: 2006-10-09 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/29254 * cgraphunit.c (verify_cgraph_node): Bail out on earlier errors. * gcc.dg/pr29254.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr29254.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29254
[Bug rtl-optimization/29323] [4.0/4.1/4.2 Regression] set_nothrow_function_flags does invalid analysis on weak functions
--- Comment #6 from patchapp at dberlin dot org 2006-10-09 16:10 --- Subject: Bug number PR29323 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-10/msg00458.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29323
[Bug middle-end/29241] [4.0/4.1/4.2 Regression] [non unit-at-a-time] ICE with always inline
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-10-09 16:06 --- Mine. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-27 02:47:49 |2006-10-09 16:06:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29241
[Bug target/27880] [4.2 regression] undefined reference to `_Unwind_GetIPInfo'
--- Comment #13 from sje at gcc dot gnu dot org 2006-10-09 15:55 --- Subject: Bug 27880 Author: sje Date: Mon Oct 9 15:55:38 2006 New Revision: 117576 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117576 Log: PR target/27880 * unwind-c.c (PERSONALITY_FUNCTION): Ifdef use of _Unwind_GetIPInfo. * configure.ac (HAVE_GETIPINFO): Check for _Unwind_GetIPInfo. * configure: Regenerate. * config.in: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/unwind-c.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
[Bug target/29401] [4.0/4.1/4.2 Regression] missed-optimization (in unneeded code elimination)
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-09 14:58 ---
Confirmed. Ok for x86_64:
f:
.LFB2:
movslq %edi,%rdi
movslq %esi,%rsi
imulq %rdi, %rsi
sarq$15, %rsi
movl%esi, %eax
ret
We are expanding (int) ((long long int) b * (long long int) a >> 15).
We split
(insn:HI 11 31 12 2 (parallel [
(set (reg:DI 0 ax [62])
(mult:DI (sign_extend:DI (reg/v:SI 0 ax [orig:60 b ] [60]))
(sign_extend:DI (mem/c/i:SI (plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])) [2 a+0 S4 A32]
(clobber (reg:CC 17 flags))
]) 265 {*mulsidi3_insn} (insn_list:REG_DEP_TRUE 7 (nil))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn:HI 12 11 17 2 (parallel [
(set (reg:DI 0 ax [62])
(ashiftrt:DI (reg:DI 0 ax [62])
(const_int 15 [0xf])))
(clobber (reg:CC 17 flags))
]) 437 {*ashrdi3_1} (insn_list:REG_DEP_TRUE 11 (nil))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 1 dx)
(nil
into
(insn:TI 11 31 37 2 (parallel [
(set (reg:DI 0 ax [62])
(mult:DI (sign_extend:DI (reg/v:SI 0 ax [orig:60 b ] [60]))
(sign_extend:DI (mem/c/i:SI (plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])) [2 a+0 S4 A32]
(clobber (reg:CC 17 flags))
]) 265 {*mulsidi3_insn} (nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn:TI 37 11 38 2 (parallel [
(set (reg:SI 0 ax [62])
(ior:SI (ashiftrt:SI (reg:SI 0 ax [62])
(const_int 15 [0xf]))
(ashift:SI (reg:SI 1 dx [+4 ])
(minus:QI (const_int 32 [0x20])
(const_int 15 [0xf])
(clobber (reg:CC 17 flags))
]) 438 {x86_shrd_1} (nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn:TI 38 37 26 2 (parallel [
(set (reg:SI 1 dx [+4 ])
(ashiftrt:SI (reg:SI 1 dx [+4 ])
(const_int 15 [0xf])))
(clobber (reg:CC 17 flags))
]) 443 {*ashrsi3_1} (nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 1 dx [+4 ])
(nil
note the problematic partially dead DI ax:dx which flow does not handle,
so the redundant instruction does not get deleted. A peephole might be
able to fix this until new dataflow maybe handles this case(?).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org, hubicka at gcc dot gnu
||dot org
Severity|enhancement |normal
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC host triplet|i486|
GCC target triplet||i?86-*-*
Known to fail|4.0.3 4.1.1 |4.0.3 4.1.1 4.2.0
Last reconfirmed|-00-00 00:00:00 |2006-10-09 14:58:01
date||
Summary|[regression] missed-|[4.0/4.1/4.2 Regression]
|optimization (in unneeded |missed-optimization (in
|code elimination) |unneeded code elimination)
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29401
[Bug rtl-optimization/29323] [4.0/4.1/4.2 Regression] set_nothrow_function_flags does invalid analysis on weak functions
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-09 14:25 ---
The frontend marks foo () TREE_STATIC in start_preparsed_function () and later
TREE_NOTHROW in finish_function () because
/* If this function can't throw any exceptions, remember that. */
if (!processing_template_decl
&& !cp_function_chain->can_throw
&& !flag_non_call_exceptions)
TREE_NOTHROW (fndecl) = 1;
where cp_function_chain->can_throw is 0 (its initial value(?)).
Fixing that and the RTL problem fixes the testcase. I am, of course, not
sure if the C++ frontend fix is ok.
Index: except.c
===
--- except.c(revision 117569)
+++ except.c(working copy)
@@ -2787,6 +2787,9 @@ set_nothrow_function_flags (void)
{
rtx insn;
+ if (!targetm.binds_local_p (current_function_decl))
+return 0;
+
TREE_NOTHROW (current_function_decl) = 1;
/* Assume cfun->all_throwers_are_sibcalls until we encounter
Index: cp/decl.c
===
--- cp/decl.c (revision 117569)
+++ cp/decl.c (working copy)
@@ -11081,7 +11081,8 @@ finish_function (int flags)
/* If this function can't throw any exceptions, remember that. */
if (!processing_template_decl
&& !cp_function_chain->can_throw
- && !flag_non_call_exceptions)
+ && !flag_non_call_exceptions
+ && targetm.binds_local_p (fndecl))
TREE_NOTHROW (fndecl) = 1;
/* This must come after expand_function_end because cleanups might
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2006-10-03 05:26:42 |2006-10-09 14:25:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29323
[Bug c++/5458] address of overloaded template function as argument for template
--- Comment #10 from v dot haisman at sh dot cvut dot cz 2006-10-09 14:16 --- Shouldn't the "Known to fail" field get all the versions from its duplicates copied? Maybe that is why this rejects-valid bug is still not fixed even though most other rejects-valid bugs get a lot of attention and get fixed usually pretty fast, IMHO. 2.95.3 3.0.4 4.0.0 4.1.0 4.2.0 3.3.3 3.2.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5458
[Bug middle-end/29299] [4.2 Regresion] gcc "used" attribute has no effect on local-scope static variables
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-09 13:04 ---
We have
bool
decide_is_variable_needed (struct cgraph_varpool_node *node, tree decl)
{
/* If the user told us it is used, then it must be so. */
if (node->externally_visible || node->force_output)
return true;
if (!flag_unit_at_a_time
&& lookup_attribute ("used", DECL_ATTRIBUTES (decl)))
return true;
with "used" set on bar...
Now, the handler for attribute "used" sets DECL_PRESERVE_P on the decl, so
we might as well check that.
Index: cgraph.c
===
*** cgraph.c(revision 117569)
--- cgraph.c(working copy)
*** bool
*** 939,948
decide_is_variable_needed (struct cgraph_varpool_node *node, tree decl)
{
/* If the user told us it is used, then it must be so. */
! if (node->externally_visible || node->force_output)
! return true;
! if (!flag_unit_at_a_time
! && lookup_attribute ("used", DECL_ATTRIBUTES (decl)))
return true;
/* ??? If the assembler name is set by hand, it is possible to assemble
--- 939,947
decide_is_variable_needed (struct cgraph_varpool_node *node, tree decl)
{
/* If the user told us it is used, then it must be so. */
! if (node->externally_visible
! || node->force_output
! || DECL_PRESERVE_P (decl))
return true;
/* ??? If the assembler name is set by hand, it is possible to assemble
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2006-09-30 19:40:21 |2006-10-09 13:04:55
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29299
[Bug target/29401] [regression] missed-optimization (in unneeded code elimination)
--- Comment #2 from pluto at agmk dot net 2006-10-09 12:59 --- (In reply to comment #1) > looks similar to PR26674. > oops, please ignore this comment. -- pluto at agmk dot net changed: What|Removed |Added CC|pluto at agmk dot net | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29401
[Bug target/29401] [regression] missed-optimization (in unneeded code elimination)
--- Comment #1 from pluto at agmk dot net 2006-10-09 12:57 --- looks similar to PR26674. -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29401
[Bug target/29401] New: [regression] missed-optimization (in unneeded code elimination)
Hi.
There is a regression on i386 platforms.
int f(int a, int b)
{return (((long long) a) * b) >> 15;}
The gcc 4.0/4.1 generates with "-O3 -fomit-frame-pointer"
movl8(%esp), %eax
imull 4(%esp)
shrdl $15, %edx, %eax
sarl$15, %edx
ret
While gcc-3.3/3.4 generates equal and faster
movl8(%esp), %eax
imull 4(%esp)
shrdl $15, %edx, %eax
ret
--
Summary: [regression] missed-optimization (in unneeded code
elimination)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Petr dot Salinger at seznam dot cz
GCC host triplet: i486
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29401
[Bug fortran/29400] ANY and COUNT used on parameter arrays
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-09 12:44 --- And while I'm there, a few possibly related bugs: $ cat pr29400-2.f90 integer,parameter :: i(1,1) = 0 logical :: l(2) l = any(i==1,2) end $ gfortran pr29400-2.f90 && ./a.out Fortran runtime error: rank of return array incorrect $ cat pr29400-3.f90 integer,parameter :: i(1,1) = 0 logical :: l l = any(i==1) end $ gfortran pr29400-3.f90 && ./a.out pr29400-3.f90: In function MAIN__: pr29400-3.f90:1: internal compiler error: in gfc_conv_intrinsic_anyall, at fortran/trans-intrinsic.c:1339 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.2 4.2.0 Last reconfirmed|2006-10-09 12:36:31 |2006-10-09 12:44:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29400
[Bug fortran/29400] ANY and COUNT used on parameter arrays
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-09 12:36
---
The generated code for:
integer,parameter :: i(1,1) = 0
integer :: j(1)
j = lbound(any(i==1,2))
end
is weird:
MAIN__ ()
{
int4 j[1];
_gfortran_set_std (70, 127, 0);
{
int8 S.0;
S.0 = 1;
while (1)
{
if (S.0 > 1) goto L.1; else (void) 0;
{
struct array1_logical4 atmp.1;
int8 C.1248 = 2;
logical4 C.1247 = 0;
atmp.1.dtype = 273;
atmp.1.data = 0B;
atmp.1.offset = 0;
_gfortran_any_l4 (&atmp.1, &C.1247, &C.1248);
j[NON_LVALUE_EXPR + -1] = (int4) atmp.1.dim[S.0 - 1].lbound;
_gfortran_internal_free (atmp.1.data);
}
S.0 = S.0 + 1;
}
L.1:;
}
}
Why are we passing a pointer to a logical4 as a second argument to
_gfortran_any_l4, and not an array descriptor.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-10-09 11:53:37 |2006-10-09 12:36:31
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29400
[Bug middle-end/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-09 12:24 --- The minimal fix is to not verify_cgraph_node if errorcount || sorrycount. Bailing out earlier has interesting side-effects it seems. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-28 10:55:21 |2006-10-09 12:24:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29254
[Bug fortran/29400] ANY and COUNT used on parameter arrays
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-09 11:53:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29400
[Bug fortran/29400] New: ANY and COUNT used on parameter arrays
I found that bug while reducing PR29391, so it might be related (but I doubt it). $ cat a6.f90 integer,parameter :: i(1,1) = 0 write(*,*) lbound(any(i==1,2)), ubound(any(i==1,2)) write(*,*) lbound(count(i==1,2)), ubound(count(i==1,2)) write(*,*) lbound(matmul(i,i)) end $ gfortran a6.f90 && ./a.out Operating system error: Cannot allocate memory Memory allocation failed If I remove the line with matmul, I get another error: $ gfortran a6.f90 && ./a.out 0 1 0 1 zsh: segmentation fault ./a.out -- Summary: ANY and COUNT used on parameter arrays Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29400
[Bug target/26560] [4.0/4.1 regression] mips: unable to find a register to spill in class 'FP_REGS'
--- Comment #4 from tbm at gcc dot gnu dot org 2006-10-09 11:46 --- Confirmed. gcc 3.4 and 4.2 work, 4.0 and 4.1 fail. -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.2 4.1.0 Known to work||3.4.6 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-10-09 11:46:07 date|| Summary|mips: unable to find a |[4.0/4.1 regression] mips: |register to spill in class |unable to find a register to |'FP_REGS' |spill in class 'FP_REGS' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26560
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-09 11:39 --- The same thing is true for all the array manipulation functions: integer :: i(-1:1,-1:1) = 0 integer :: j(-1:2) = 0 ! This is working correctly write(*,*) lbound(i(-1:1,-1:1)), ubound(i(-1:1,-1:1)) write(*,*) lbound(i(:,:)), ubound(i(:,:)) write(*,*) lbound(i(0:,-1:)), ubound(i(0:,-1:)) write(*,*) lbound(i(:0,:1)), ubound(i(:0,:1)) ! None of the following is working write(*,*) lbound(transpose(i)), ubound(transpose(i)) write(*,*) lbound(reshape(i,(/2,2/))), ubound(reshape(i,(/2,2/))) write(*,*) lbound(cshift(i,-1)), ubound(cshift(i,-1)) write(*,*) lbound(eoshift(i,-1)), ubound(eoshift(i,-1)) write(*,*) lbound(spread(i,1,2)), ubound(spread(i,1,2)) write(*,*) lbound(maxloc(i)), ubound(maxloc(i)) write(*,*) lbound(minloc(i)), ubound(minloc(i)) write(*,*) lbound(maxval(i,2)), ubound(maxval(i,2)) write(*,*) lbound(minval(i,2)), ubound(minval(i,2)) write(*,*) lbound(product(i,2)), ubound(product(i,2)) write(*,*) lbound(sum(i,2)), ubound(sum(i,2)) write(*,*) lbound(any(i==1,2)), ubound(any(i==1,2)) write(*,*) lbound(count(i==1,2)), ubound(count(i==1,2)) write(*,*) lbound(matmul(i,i)), ubound(matmul(i,i)) write(*,*) lbound(lbound(i)), ubound(lbound(i)) write(*,*) lbound(ubound(i)), ubound(ubound(i)) write(*,*) lbound(shape(i)), ubound(shape(i)) write(*,*) lbound(pack(i,.true.)), ubound(pack(i,.true.)) write(*,*) lbound(unpack(j,(/.true./),(/2/))), & ubound(unpack(j,(/.true./),(/2/))) write(*,*) lbound(merge(i,i,.true.)), ubound(merge(i,i,.true.)) end The results for all write statements below the second comment are off. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/29373] implicit type declaration and contained function clash
--- Comment #2 from tobi at gcc dot gnu dot org 2006-10-09 11:34 --- As I said, I ran into this when playing around with PR29267, and it was ugly enough to warrant a PR of its own. Glad you share my opinion :-) Just to make this clear: I would never do something this ugly outside bugzilla! (BTW I added you to the CC list, it is kinda hard to answer in the right place otherwise) -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #7 from tobi at gcc dot gnu dot org 2006-10-09 11:14 --- (In reply to comment #6) > please try the testcase in the orignal PR with idental string lengths. It will > crash gfortran as well. Works for me. Please provide a testcase. [EMAIL PROTECTED]:~/src/pr/29267> cat t.f90 ! implicit character*32 (b-z) CHARACTER(len=255), DIMENSION(2) :: a a = reshape((/ "12345678901234567890123456789012", to_string(1.0) /), shape(a)) print *, a CONTAINS CHARACTER(32) FUNCTION to_string(x) REAL, INTENT(in) :: x WRITE(to_string, FMT="(F6.3)") x END FUNCTION END PROGRAM [EMAIL PROTECTED]:~/src/pr/29267> ~/src/gcc/build/gcc/f951 t.f90 MAIN__ to_string Execution times (seconds) parser: 0.01 (100%) usr 0.00 ( 0%) sys 0.01 (100%) wall 132 kB (18%) ggc TOTAL : 0.01 0.00 0.01 740 kB Extra diagnostic checks enabled; compiler may run slowly. Configure with --disable-checking to disable checks. [EMAIL PROTECTED]:~/src/pr/29267> > so, why is an equivalent assignment through the array constructor invalid? Because the standard says so, I already quoted the relevant part. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug libstdc++/28277] __builtin_alloca with no limit in libstdc++
--- Comment #12 from paolo at gcc dot gnu dot org 2006-10-09 10:50 --- Subject: Bug 28277 Author: paolo Date: Mon Oct 9 10:49:50 2006 New Revision: 117571 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117571 Log: 2006-10-09 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/28277 (partial: money_put bits) * include/bits/locale_facets.tcc (money_put<>::_M_insert(iter_type, ios_base&, char_type, const string_type&)): Avoid __builtin_alloca with no limit, do the work in place. * include/bits/locale_facets.tcc (money_put<>::do_put(iter_type, bool, ios_base&, char_type, long double)): Avoid unnecessary __builtin_alloca, do the work in place. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/locale_facets.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28277
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #24 from bkoz at gcc dot gnu dot org 2006-10-09 10:32 --- Hey Dave. Thanks for your persistence on this one: I think it's paid off. I can see what you are talking about WRT mutex initialization, and have high hopes for the attached patch. If you can try it, and let me know the results I'd appreciate it. We can't just remove the mutex in locale::locale. This rationale for this mutex is libstdc++/12658, sadly there is no testcase in the libstdc++ testsuite to check for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug target/29347] i386 mode switching clobbers fp exception handling bits
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-09 10:28 --- Can you provide a testcase where something goes wrong? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29347
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #23 from bkoz at gcc dot gnu dot org 2006-10-09 10:26 --- Created an attachment (id=12399) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12399&action=view) patch for mutex init Can you try this? thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug ada/29262] Adding tasking support for arm-linux
--- Comment #7 from charlet at adacore dot com 2006-10-09 08:28 --- Subject: Re: Adding tasking support for arm-linux > ... well, I can see differences, but is there any definite way of finding out, > how the C structures actually look like? Do I have to hunt this up in the > glibc source code? You need to retrieve the values and struct definitions from the include files present on your system. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29262
[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-10-09 08:22 --- One point to remember is that C does not allow re-using of storage with a different type (which is what PR29272 is about and why that testcase is invalid). The storage type is either the declared one or the one assigned by virtue of the first assignment (or memcpy). So, int i; float f; memcpy(&f, &i, sizeof(f)); is valid, it doesn't change fs dynamic type but assigns it the bit-pattern of i. What the C++ standard seems to imply is that the storage type of a bunch of memory (or an object with automatic storage) changes on "assignment". So, indeed for C++ re-ordering writes is not allowed, and escaping pointers must be assumed to change dynamic type. So for C++ and 4.2 the best solution looks like to disable type based aliasing completely. For C I'm not sure the behavior the standard mandates is very appealing - at least changing dynamic type via the use of memcpy should be allowed as a GCC extension (like we allow type-punning via the union trick). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
