[Bug c++/29252] Strange No matching function for call compilation error with G++ 4.1
--- Comment #4 from bangerth at dealii dot org 2006-09-28 06:06 --- I think the error message is perfectly clear: it says that there is no function foo (X) but that there is a function that provides foo (X) We've gone through this many times that there is no way to say see, you try to bind an rvalue to a reference, this isn't working because the overload set of candidates may be larger than the single function above and there is no way to guess what the user may mean. So closing... W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29252
[Bug preprocessor/29245] want way to #include but still able to finish compiling
--- Comment #7 from bangerth at dealii dot org 2006-09-28 06:09 --- Daniel, would you prefer if we marked this as WONTFIX? I think this thing is so contentious that we're not going to do anything about it until there's some sort of resolutions from the ISO committees. I just don't see any purpose in keeping around lots of PRs that we don't plan to do anything about. We're having enough trouble telling the important PRs from the not so important ones already... W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org, ||drow at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29245
[Bug target/29258] internal compiler error: Segmentation fault
--- Comment #1 from bangerth at dealii dot org 2006-09-28 06:10 --- Can you post preprocessed sources as requested in http://gcc.gnu.org/bugs.html Thanks Wolfgang -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29258
[Bug ada/29262] New: Adding tasking support for arm-linux
I would like to use tasking support for GNAT on an arm-linux target (Intel XSCale PXA 270) to the gcc-4_1-branch The installed runtime library however is using generic dummy package for tasking support (e.g. s-taprop.ads). After having a look at gcc/ada/Makefile.in, I figured there needs to be a couple of changes: 1. need for system-linux-arm.ads - which can be identical to system-linux-x86.ads 2. The Makefile.in needs to be changed as follows: (g-soccon is not in my focus, so I just kicked it out for now) (a-numaux is using the libc bindings) (all the rest of this section is from the x86-linux part) Index: Makefile.in === --- Makefile.in (revision 117213) +++ Makefile.in (working copy) @@ -539,6 +539,33 @@ EXTRA_GNATRTL_TASKING_OBJS=s-vxwork.o endif +ifeq ($(strip $(filter-out arm linux%,$(arch) $(osys))),) + LIBGNAT_TARGET_PAIRS = \ + a-intnam.adsa-intnam-linux.ads \ + a-numaux.adsa-numaux-libc-x86.ads \ + s-inmaop.adbs-inmaop-posix.adb \ + s-intman.adbs-intman-posix.adb \ + s-osinte.adbs-osinte-posix.adb \ + s-osinte.adss-osinte-linux.ads \ + s-osprim.adbs-osprim-posix.adb \ + s-taprop.adbs-taprop-linux.adb \ + s-taspri.adss-taspri-posix.ads \ + s-tpopsp.adbs-tpopsp-posix-foreign.adb \ + s-parame.adbs-parame-linux.adb \ + system.adssystem-linux-arm.ads + + TOOLS_TARGET_PAIRS = \ +mlib-tgt.adbmlib-tgt-linux.adb \ +indepsw.adbindepsw-gnu.adb + + EH_MECHANISM=-gcc + THREADSLIB = -lpthread + GNATLIB_SHARED = gnatlib-shared-dual + GMEM_LIB = gmemlib + PREFIX_OBJS = $(PREFIX_REAL_OBJS) + LIBRARY_VERSION := $(LIB_VERSION) +endif + ifeq ($(strip $(filter-out arm% coff wrs vx%,$(targ))),) LIBGNAT_TARGET_PAIRS = \ a-intnam.adsa-intnam-vxworks.ads \ Did I forget anything? Unfortunately, I don't have a running (native) compiler (yet??), so ACATS tests might be hard to do. -- Summary: Adding tasking support for arm-linux Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: belandor at web dot de GCC target triplet: arm-xscale-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29262
[Bug c++/29261] Hiding constructior is required while no direct invocation to it with G++ 4
--- Comment #1 from bangerth at dealii dot org 2006-09-28 06:15 ---
This is what is listed in the release notes of gcc 3.4:
http://gcc.gnu.org/gcc-3.4/changes.html
They say this:
-
When binding an rvalue of class type to a reference, the copy constructor of
the class must be accessible. For instance, consider the following code:
class A
{
public:
A();
private:
A(const A); // private copy ctor
};
A makeA(void);
void foo(const A);
void bar(void)
{
foo(A()); // error, copy ctor is not accessible
foo(makeA()); // error, copy ctor is not accessible
A a1;
foo(a1);// OK, a1 is a lvalue
}
This might be surprising at first sight, especially since most popular
compilers do not correctly implement this rule (further details).
--
The further references are a link to
http://gcc.gnu.org/bugs.html#cxx_rvalbind
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
Summary|Hiding constructior is |Hiding constructior is
|required while no direct|required while no direct
|invocation to it with G++ 4 |invocation to it with G++ 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29261
[Bug ada/29262] Adding tasking support for arm-linux
--- Comment #1 from belandor at web dot de 2006-09-28 06:37 --- (In reply to comment #0) actually, the Makefile.in needs modifications. a-numaux-x86.ads does not work for arm (error-message is that only 15 digits are allowed for floating point type), therefore the line + a-numaux.adsa-numaux-libc-x86.ads \ should be removed in the section. Compiler is build fine (build=i686-pc-linux-gnu, host=i686-pc-linux-gnu) and the files get installed in adainclude/adalib as expected. I even was able to compile a simple tasking program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29262
[Bug ada/29262] Adding tasking support for arm-linux
--- Comment #2 from belandor at web dot de 2006-09-28 06:49 --- Created an attachment (id=12346) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12346action=view) hello world source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29262
[Bug ada/29262] Adding tasking support for arm-linux
--- Comment #3 from belandor at web dot de 2006-09-28 06:49 --- Created an attachment (id=12347) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12347action=view) simple_tasking source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29262
[Bug ada/29262] Adding tasking support for arm-linux
--- Comment #4 from belandor at web dot de 2006-09-28 06:51 --- ...running the above programs give me the following errors/messages: [EMAIL PROTECTED]:/testprogs/glibc# ./simple_tasking Alignment trap: simple_tasking (1099) PC=0xa670 Instr=0xe5933000 Address=0x0001 FSR 0x0f3 raised STORAGE_ERROR : s-intman.adb:158 explicit raise [EMAIL PROTECTED]:/testprogs/glibc# [EMAIL PROTECTED]:/testprogs/glibc# [EMAIL PROTECTED]:/testprogs/glibc# ls hello hello_threaded hello_world simple_tasking [EMAIL PROTECTED]:/testprogs/glibc# ./hello_world Hello World so it seems, there's something fishy for the tasking setup - any good idea to trace this up? (I don't have a debugger at hand *grrr*) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29262
[Bug target/29258] internal compiler error: Segmentation fault
--- Comment #2 from gobikrishna dot dhanuskodi at wipro dot com 2006-09-28 07:27 --- Created an attachment (id=12348) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12348action=view) Preprocessed file generated using --save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29258
[Bug target/29249] Alignment error with static const variable in inline function
--- Comment #8 from jespdj at hotmail dot com 2006-09-28 07:45 --- Ok, I filed a bug report for binutils about this. http://sourceware.org/bugzilla/show_bug.cgi?id=3276 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29249
[Bug fortran/23060] %VAL construct not implemented
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-09-28 07:58 --- Changing this into a bug, since it was implemented in g77. It might be working soon, since we will soon have ISO_C_BINDING val attribute, which does the same thing, so adding the %val construct will probably be very easy. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|enhancement |normal GCC target triplet|i386-redhat-linux | Last reconfirmed|2006-03-05 03:41:17 |2006-09-28 07:58:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23060
[Bug fortran/23375] show location for runtime errors
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-09-28 07:59 --- Closing, as the error messages have been modified to include source location. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-09-28 08:02 --- Confirmed, and marked as blocking the F2003 meta-PR. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org OtherBugsDependingO||20585 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-28 08:02:35 date|| Summary|Fortran 2003: Support type- |Fortran 2003: Support type- |spec for array constructor, |spec for array constructor |i.e. (/ real :: 1., 2., 3. | |/) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/28655] [F2003] In/output: DECIMAL=/dp/dc; SIGN=/S/SP/SS BLANK=/PAD=; DELIM=; ENCODING=
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-28 08:03:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28655
[Bug c++/29265] New: Type resolving for template class hierarchy
If we have two template classes in hierarchy and try to take type of the
topmost class, gcc shows error message while VC 8.0 and Comeau C/C++ 4.3.3 does
not.
The following exapmle shows code that generates the error:
template typename T
class A
{
public:
typedef int TType;
private:
typedef T tmp;
};
template typename T
class B : public AT
{
public:
typedef char* TType;
private:
typedef T tmp;
};
template typename T
class Test
{
public:
static void test()
{
typename BT::A::TType a = 0;
typename BT::TType b = test;
}
};
int main(int argc, char* argv[])
{
Testint::test();
}
Error message is following:
test.cpp: In static member function `static void TestT:
:test() [with T = int]':
test.cpp:35: instantiated from here
test.cpp:27: error: no type named `A' in `class Bint'
--
Summary: Type resolving for template class hierarchy
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 4ekucT at tut dot by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29265
[Bug c++/29265] Type resolving for template class hierarchy
--- Comment #1 from 4ekucT at tut dot by 2006-09-28 09:05 --- Created an attachment (id=12349) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12349action=view) Type resolving for template class hierarchy -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29265
[Bug c++/29266] New: Rule that binding rvalue to a refernce need a copy ctor don't work
Hi,
I used to open a issue at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29261 and
it's closed as no a bug. Also it says that to bind an rvalue to a reference,
we need to let copy ctor of the class be accessible. However, I found that
this is not the case when the invokcation is happen in intialization list.
See below reproduction code and error message.
Env:
=
G++ 4.1
No compile option is used
Source code:
==
using std::cout;
using std::endl;
class MemPool {
public:
MemPool(){};
protected:
MemPool(const MemPool mempool);
};
template class Type class MemAllocator{
public:
MemAllocator(MemPool pool):m_pool(pool){}
MemPool get_pool() const {
return m_pool;
}
templateclass OtherType
MemAllocatorType operator=(const MemAllocatorOtherType rhs){
m_pool = rhs.get_pool();
return *this;
}
MemAllocator operator=(const MemAllocator rhs){
m_pool = rhs.get_pool();
return *this;
}
MemAllocator(const MemAllocator other)
: m_pool(other.m_pool) {}
templateclass OtherType
MemAllocator(const MemAllocatorOtherType other)
: m_pool(other.get_pool()) {}
private:
MemAllocator();
// MemAllocator(const MemAllocator);
MemPool m_pool;
};
template class _AllocType class tdat_hash_map {
public:
typedef _AllocType _Alloc;
static void func(const _Alloc) {};
_Alloc malloc;
private:
tdat_hash_map();
};
class CacheManager {
public:
typedef tdat_hash_mapMemAllocatorint Map;
Map caches;
MemPool pool;
CacheManager():caches(MemAllocatorint(pool)){};
};
Error message:
==
main.cpp: In constructor CacheManager::CacheManager()
main.cpp:56: error: no matching function for call to
tdat_hash_mapMemAllocatorint
::tdat_hash_map(MemAllocatorint)main.cpp:49: note: candidates are:
tdat_hash_map_AllocType::tdat_hash_map() [with _AllocType =
MemAllocatorint]
main.cpp:42: note: tdat_hash_mapMemAllocatorint
::tdat_hash_map(const tdat_hash_mapMemAllocatorint )
--
Summary: Rule that binding rvalue to a refernce need a copy ctor
don't work
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuanfei8077 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29266
[Bug middle-end/29253] expand_abs wrong default code for floating point
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-28 09:59 --- Confirmed. As expand_copysign, expand_fabs should defer to the library in this case. -- rguenth 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-09-28 09:59:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29253
[Bug fortran/29267] New: ICE in operand_subword_force, at emit-rtl.c:1353
$ cat ice.f90 PROGRAM test_ice CHARACTER(len=255), DIMENSION(1,2) :: a a = reshape((/ x, to_string(1.0) /), (/ 1, 2 /)) CONTAINS CHARACTER(32) FUNCTION to_string(x) REAL, INTENT(in) :: x WRITE(to_string, FMT=(F6.3)) x END FUNCTION END PROGRAM $ gfortran-4.2 -g -Wall ice.f90 ice.f90: In function #8216;MAIN__#8217;: ice.f90:3: internal compiler error: in operand_subword_force, at emit-rtl.c:1353 Please submit a full bug report, $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/home/daniel/nfs/packages/i686-pc-linux-gnu/gcc-4.2-svn --enable-threads=posix --enable-shared --with-system-zlib --enable-languages=c,c++,fortran Thread model: posix gcc version 4.2.0 20060914 (experimental) Initially reported here: http://gcc.gnu.org/ml/fortran/2006-09/msg00335.html (the testcase above is a reduced version of that posted to the ML) -- Summary: ICE in operand_subword_force, at emit-rtl.c:1353 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug middle-end/29268] New: missed optimization: need to generalize realignment support in the vectorizer
details in theis thread: http://gcc.gnu.org/ml/gcc/2006-09/msg00503.html Need to add other ways to handle realignment, that are applicable to targets that can't support the realign_load the way it is currently defined. -- Summary: missed optimization: need to generalize realignment support in the vectorizer Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29268
[Bug middle-end/29269] New: missing documentation for vcond (vector conditional operation)
missing documentation for vcond (vector conditional operation). -- Summary: missing documentation for vcond (vector conditional operation) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29269
[Bug tree-optimization/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-09-28 10:55 --- Confirmed. The warning is correct - we emit it with explicit casts, too. But surprisingly -Wno-cast-qual does not get rid of it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||error-recovery, ice- ||checking, ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-09-28 10:55:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29254
[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-09-28 11:08 --- On x86_64 4.2 decides to unroll 9 times while on 4.1 it unrolls 8 times. This is a code-size regression, but other than that? The 4.2 version runs slightly faster than the 4.1 version, though the difference may be in the noise. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, rakdver at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug c++/29260] Calling member function of const object causes segmentation fault in compiler
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-28 11:14 --- Works for me on i686-linux with all versions. Also the code in question is invalid: t.C:9: error: '::main' must return 'int' t.C: In function 'int main()': t.C:11: error: uninitialized const 'y' t.C:12: error: passing 'const Y' as 'this' argument of 'void Y::f()' discards qualifiers -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|other |c++ Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29260
[Bug driver/29270] New: -- does not end option parsing
$ gcc hello.c -- -MM hello.o: hello.c gcc: ambiguous abbreviation -- -- Summary: -- does not end option parsing Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29270
[Bug driver/29270] -- does not end option parsing
--- Comment #1 from schwab at suse dot de 2006-09-28 11:21 --- See also the thread at http://lists.gnu.org/archive/html/automake/2006-09/msg00081.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29270
[Bug target/29258] internal compiler error: Segmentation fault
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-09-28 11:21 --- Works for me with 3.4.6 (x86_64) and 3.4.3 (i686). Did not try a cross-compiler though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29258
[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-09-28 11:34 --- (In reply to comment #4) On x86_64 4.2 decides to unroll 9 times while on 4.1 it unrolls 8 times. This is a code-size regression, but other than that? The 4.2 version runs slightly faster than the 4.1 version, though the difference may be in the noise. Choosing 9 instead of 8 looks weird, though :-). The reason is following: jump threading in vrp2 pass peels one iteration of the loop. With this change, unrolling by factor of 9 creates smaller code (only one extra iteration needs to be peeled to make the number of iterations divisible by 9, while one would need to peel 7 more iterations to make it divisible by 8). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug fortran/25087] Error for missing explicit interface needed.
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-09-28 11:35
---
There's a TODO about this in front-end resolve.c. It's a good point to start...
static void
resolve_formal_arglist (gfc_symbol * proc)
{
gfc_formal_arglist *f;
gfc_symbol *sym;
int i;
/* TODO: Procedures whose return character length parameter is not constant
or assumed must also have explicit interfaces. */
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
Last reconfirmed|2005-11-29 12:06:22 |2006-09-28 11:35:17
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25087
[Bug other/29260] Calling member function of const object causes segmentation fault in compiler
--- Comment #2 from leg0 at hot dot ee 2006-09-28 11:38 --- The compiler that does this is not a C nor C++ compiler. It's D compiler (gdc). -- leg0 at hot dot ee changed: What|Removed |Added Component|c++ |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29260
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-28 13:09 --- Confirmed. (gdb) bt #0 fancy_abort ( file=0xc80d78 /space/rguenther/src/svn/trunk/gcc/emit-rtl.c, line=1353, function=0xc80ef0 operand_subword_force) at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:642 #1 0x0061cc08 in operand_subword_force (op=0x2b22e2375be0, offset=0, mode=QImode) at /space/rguenther/src/svn/trunk/gcc/emit-rtl.c:1353 #2 0x006351a6 in store_bit_field (str_rtx=0x2b22e2375ba0, bitsize=256, bitnum=0, fieldmode=QImode, value=0x2b22e2362f40) at /space/rguenther/src/svn/trunk/gcc/expmed.c:582 #3 0x0065441b in store_field (target=0x2b22e2375ba0, bitsize=256, bitpos=0, mode=BLKmode, exp=0x2b22e23639a0, type=0x2b22e2359d10, alias_set=0) at /space/rguenther/src/svn/trunk/gcc/expr.c:5591 #4 0x0064d0e2 in expand_assignment (to=0x2b22e235a300, from=0x2b22e23639a0) at /space/rguenther/src/svn/trunk/gcc/expr.c:4141 #5 0x0066d9cf in expand_expr_real_1 (exp=0x2b22e235b870, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /space/rguenther/src/svn/trunk/gcc/expr.c:8603 #6 0x0065a675 in expand_expr_real (exp=0x2b22e235b870, target=0x2b22e2284400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /space/rguenther/src/svn/trunk/gcc/expr.c:6700 (gdb) up #1 0x0061cc08 in operand_subword_force (op=0x2b22e2375be0, offset=0, mode=QImode) at /space/rguenther/src/svn/trunk/gcc/emit-rtl.c:1353 1353 gcc_assert (result); (gdb) list 1348 else 1349op = force_reg (mode, op); 1350} 1351 1352 result = operand_subword (op, offset, 1, mode); 1353 gcc_assert (result); 1354 1355 return result; 1356} 1357^L We're asking for a QImode subword at offset 0 of (mem/s/j:BLK (plus:DI (reg:DI 112) (reg:DI 96 [ D.1297 ])) [0 S32 A8]) in expansion of (*D.1297)[S.20D.1298] = D.1302 4.0 fails differently: gcc40-g/gcc ./f951 -quiet ../../gcc41-g/gcc/t.f90 ../../gcc41-g/gcc/t.f90: In function 'MAIN__': ../../gcc41-g/gcc/t.f90:8: internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2006-09-28 13:09:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug other/29260] Calling member function of const object causes segmentation fault in compiler
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-28 13:29 --- The D front-end is not part of the FSF GCC right now, you should report this to the place where you got the compiler. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29260
[Bug c++/29266] Rule that binding rvalue to a refernce need a copy ctor don't work
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-28 13:39 --- There is no tdat_hash_map(_Alloc) in the sources. Adding one makes it get past that error and then we get: t.cc: In constructor tdat_hash_map_AllocType::tdat_hash_map(const _AllocType) [with _AllocType = MemAllocatorint]: t.cc:64: instantiated from here t.cc:38: error: MemAllocatorType::MemAllocator() [with Type = int] is private t.cc:49: error: within this context So this is invalid still. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29266
[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-28 13:47 --- (In reply to comment #4) On x86_64 4.2 decides to unroll 9 times while on 4.1 it unrolls 8 times. This is a code-size regression, but other than that? The 4.2 version runs slightly faster than the 4.1 version, though the difference may be in the noise. No, no, no, I and Edmar are not complaining about how many times it unrolled but the use of index addressing mode instead of offset addressing mode for the stores and the extra adds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug c++/29265] Type resolving for template class hierarchy
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-28 14:02 --- *** This bug has been marked as a duplicate of 9937 *** -- 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=29265
[Bug c++/9937] [DR 176] Base class template name is not injected properly into derived class
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-28 14:02 --- *** Bug 29265 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||4ekucT at tut dot by http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9937
[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-09-28 14:02 --- Oh, but those do not happen on x86_64. So this is a target issue really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug libfortran/23889] behaviour of random_seed()
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-09-28 14:05 --- After a year and not patch has been proposed for that enhancement, it looks like it won't be implemented in gfortran. Still, feel free to reopen this PR (or file a new one) if you have a patch ready. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23889
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #27 from pault at gcc dot gnu dot org 2006-09-28 14:06 --- Created an attachment (id=12350) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12350action=view) The latest version, incorporating all fixes so far. This latest has an increasingly complete set of testcases and fixes for the problems found by Salvatore Filippone. What is missing is the setting of scalar assignment flags for WHERE blocks/statements and another attempt to understand what is broken with zero length strings (for iso_varying_string). A ChangeLog exists, which is about two days behind. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Attachment #12320|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug libfortran/27046] [mingw32] mixed C-Fortran I/O doesn't flush
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-20 07:50:15 |2006-09-28 14:08:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-28 14:08 --- D.1563 = -a; MEM[base: (int *) D.1563 + c, index: D.1562] = MEM[base: D.1562]; WTFFF -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-09-28 14:11 --- Oh, didn't I fix this? See PR26726. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug middle-end/29256] [4.2 regression] loop unrolling performance regression
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-09-28 14:15 --- (In reply to comment #8) D.1563 = -a; MEM[base: (int *) D.1563 + c, index: D.1562] = MEM[base: D.1562]; WTFFF ivopts are having fun :-) On the other hand, this is (one of several possible) cheapest ways how to express the code, and it should not affect creation of offsetted modes on RTL, so although this is indeed somewhat curious (well, bug in fact, from reasons unrelated to the problem covered by this PR), it is not the cause of this problem. On x86, tree optimizers seem to do just fine, producing MEM[symbol: c, index: D.1569, step: 8B] = MEM[symbol: a, index: D.1569, step: 8B]; However, on RTL, we fail to create offsetted version of this addressing mode after unrolling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug middle-end/29256] [4.2 regression] loop performance regression
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-28 14:16 --- (In reply to comment #9) Oh, didn't I fix this? See PR26726. This is unrelated to that as the trees produced is defined but just looks weird and really the one IV selection is messed up. It should have chosen two IVs for this loop instead of just one. Actually unrolling is not need to produced the bad code: .L2: lwz 0,0(9) stwx 0,11,9 addi 9,9,4 bdnz .L2 I bet a beer that loop.c actually fixed this crap up before. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2 regression] loop |[4.2 regression] loop |unrolling performance |performance regression |regression | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug middle-end/29256] [4.2 regression] loop performance regression
--- Comment #12 from rakdver at gcc dot gnu dot org 2006-09-28 14:21 --- (In reply to comment #11) (In reply to comment #9) Oh, didn't I fix this? See PR26726. This is unrelated to that as the trees produced is defined but just looks weird and really the one IV selection is messed up. It should have chosen two IVs for this loop instead of just one. Actually unrolling is not need to produced the bad code: .L2: lwz 0,0(9) stwx 0,11,9 addi 9,9,4 bdnz .L2 I bet a beer that loop.c actually fixed this crap up before. I am bad at reading ppc assembler; could you please explain what exactly is wrong with the code you present? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug middle-end/29256] [4.2 regression] loop performance regression
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-09-28 14:34 --- (In reply to comment #12) (In reply to comment #11) (In reply to comment #9) Oh, didn't I fix this? See PR26726. This is unrelated to that as the trees produced is defined but just looks weird and really the one IV selection is messed up. It should have chosen two IVs for this loop instead of just one. Actually unrolling is not need to produced the bad code: .L2: lwz 0,0(9) stwx 0,11,9 addi 9,9,4 bdnz .L2 I bet a beer that loop.c actually fixed this crap up before. I am bad at reading ppc assembler; could you please explain what exactly is wrong with the code you present? One, there are two adds still there (just one is implicated) so why not do the loop as: .L2: lwz r0,0(r9) stw r0,0(r11) addi r9,r9,4 addi r11,r11,4 bdnz .L2 Or: .L2: lwxz r0,r9,r12 stwx r0,r11,r12 addi r12,r12,4 bdnz .L2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug middle-end/29256] [4.2 regression] loop performance regression
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-09-28 14:40 --- for this loop instead of just one. Actually unrolling is not need to produced the bad code: .L2: lwz 0,0(9) stwx 0,11,9 addi 9,9,4 bdnz .L2 I bet a beer that loop.c actually fixed this crap up before. I am bad at reading ppc assembler; could you please explain what exactly is wrong with the code you present? One, there are two adds still there (just one is implicated) so why not do the loop as: there is only one add, as far as I can see. .L2: lwz r0,0(r9) stw r0,0(r11) addi r9,r9,4 addi r11,r11,4 bdnz .L2 Otoh, this seems worse to me (one more add). Or: .L2: lwxz r0,r9,r12 stwx r0,r11,r12 addi r12,r12,4 bdnz .L2 Yes, this would be about the same. Still, ivopts chose one of the best possible ways, so I do not see what you are complaining about so much. The unrolled case is something different -- of course we should use offsetted modes there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug libstdc++/29217] locale confusion with time/collate categories
--- Comment #5 from paolo at gcc dot gnu dot org 2006-09-28 14:40 --- Subject: Bug 29217 Author: paolo Date: Thu Sep 28 14:40:12 2006 New Revision: 117282 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117282 Log: 2006-09-28 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/29217 * include/bits/locale_classes.h: Fix (swap) numerical encodings of time and collate categories. * src/locale_init.cc: Consistently reorder locale::_Impl::_S_id_time and _S_id_collate. * src/locale.cc: Tweak. Modified: branches/libstdcxx_so_7-branch/libstdc++-v3/include/bits/locale_classes.h branches/libstdcxx_so_7-branch/libstdc++-v3/src/locale.cc branches/libstdcxx_so_7-branch/libstdc++-v3/src/locale_init.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29217
[Bug libstdc++/29217] locale confusion with time/collate categories
--- Comment #6 from paolo at gcc dot gnu dot org 2006-09-28 14:40 --- Subject: Bug 29217 Author: paolo Date: Thu Sep 28 14:40:46 2006 New Revision: 117283 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117283 Log: 2006-09-28 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/29217 * include/bits/locale_classes.h: Fix (swap) numerical encodings of time and collate categories. * src/locale_init.cc: Consistently reorder locale::_Impl::_S_id_time and _S_id_collate. * src/locale.cc: Tweak. Modified: branches/libstdcxx_so_7-branch/libstdc++-v3/ChangeLog.libstdcxx_so_7-branch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29217
[Bug middle-end/29256] [4.2 regression] loop performance regression
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-28 02:59:57 |2006-09-28 14:44:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug middle-end/29256] [4.2 regression] loop performance regression
--- Comment #15 from rakdver at gcc dot gnu dot org 2006-09-28 14:50 --- (In reply to comment #8) D.1563 = -a; MEM[base: (int *) D.1563 + c, index: D.1562] = MEM[base: D.1562]; WTFFF This is caused by my change to ivopts in http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00198.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug driver/29270] -- does not end option parsing
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-28 14:59 --- Hmm, one problem is that we need to know when we should pass -- on to cc1, etc. also. For an example: gcc t.c -- -l.c is that -l.c a c source or a library for ld to have at and how do we invoke ld then: with -- -l.c or just -l.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29270
[Bug middle-end/29269] missing documentation for vcond (vector conditional operation)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-28 15:00 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||documentation Last reconfirmed|-00-00 00:00:00 |2006-09-28 15:00:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29269
[Bug driver/29270] -- does not end option parsing
--- Comment #3 from joseph at codesourcery dot com 2006-09-28 15:04 --- Subject: Re: -- does not end option parsing On Thu, 28 Sep 2006, pinskia at gcc dot gnu dot org wrote: Hmm, one problem is that we need to know when we should pass -- on to cc1, etc. also. For an example: gcc t.c -- -l.c is that -l.c a c source or a library for ld to have at and how do we invoke ld then: with -- -l.c or just -l.c It's a source file - everything after -- should be a source or object file according to the suffix. -lfoo would mean that an object file called literally -lfoo is to be linked, not libfoo.a. You could either pass -- to ld or change -lfoo to ./-lfoo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29270
[Bug other/29271] New: Incorrect -fdump-rtl-sched and -fdump-rtl-sched2 document
There are @itemx -fdump-rtl-sched2 @opindex dR @opindex fdump-rtl-sched2 Dump after the second scheduling pass, to @[EMAIL PROTECTED] @item -dS @itemx -fdump-rtl-sched @opindex dS @opindex fdump-rtl-sched Dump after the first scheduling pass, to @[EMAIL PROTECTED] in invoke.texi. But I got [EMAIL PROTECTED] slow-9]$ /usr/gcc-4.2/bin/gcc --version gcc (GCC) 4.2.0 20060913 (experimental) [trunk revision 116922] Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED] slow-9]$ /usr/gcc-4.2/bin/gcc -fdump-rtl-sched -S slow.c cc1: error: unrecognized command line option -fdump-rtl-sched [EMAIL PROTECTED] slow-9]$ /usr/gcc-4.2/bin/gcc -fdump-rtl-sched2 -S slow.c [EMAIL PROTECTED] slow-9]$ ls -l slow.c.149r.sched2 -rw-r--r-- 1 hjl hjl 16119 Sep 28 08:44 slow.c.149r.sched2 -- Summary: Incorrect -fdump-rtl-sched and -fdump-rtl-sched2 document Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29271
[Bug middle-end/29272] New: [4.2 Regression] memcpy optimization causes wrong-code
With the following testcase lowering memcpy to pointer assignment causes
wrong alias information to be generated.
struct Foo {
int a;
int b;
};
struct Node;
struct Node {
struct Node *next;
};
struct Node *pool;
void grow (void)
{
char *mem = __builtin_malloc (4096);
struct Node *node = (struct Node *)mem;
struct Foo *foo;
__builtin_memcpy (node-next, pool, sizeof(struct Node*));
pool = node;
}
static inline void *alloc_one (void)
{
struct Node *node = pool;
__builtin_memcpy (pool, node-next, sizeof(struct Node*));
return node;
}
static inline void dealloc_one (void *p)
{
struct Node *node = p;
__builtin_memcpy (node-next, pool, sizeof(struct Node*));
pool = node;
}
int bar(void)
{
grow();
struct Foo* foo = alloc_one();
foo-a = 0;
foo-b = -1;
dealloc_one (foo);
return foo-a;
}
while we have in .optimized
bb 2:
grow ();
node = pool;
D.1928 = node-next;
pool = D.1928;
foo = (struct Foo *) node;
foo-a = 0;
foo-b = -1;
node = (struct Node *) foo;
node-next = D.1928;
pool = node;
return foo-a;
asm generates:
bar:
.LFB5:
subq$8, %rsp
.LCFI1:
callgrow
movqpool(%rip), %rax
movl$0, (%rax)
movl$-1, 4(%rax)
xorl%eax, %eax
addq$8, %rsp
ret
which is wrong.
--
Summary: [4.2 Regression] memcpy optimization causes wrong-code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code, alias
Severity: blocker
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug c++/29273] New: error on dynamic_castT(array)
Gcc gives an error for the dynamic_cast below. During the discussion of bug
29185 with EDG it turned out that according to 5, p8, the code is well-formed
and should not be diagnosed.
$ cat t.cpp gcc t.cpp
struct A { virtual ~A () { } };
struct B: A { } b [1];
void foo ()
{
dynamic_castB*(b);
}
t.cpp: In function 'void foo()':
t.cpp:6: error: cannot dynamic_cast 'b' (of type 'struct B [1]') to type
'struct B*' (source is not a pointer)
--
Summary: error on dynamic_castT(array)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29273
[Bug c++/29185] inconsistent warning: deleting array
--- Comment #8 from sebor at roguewave dot com 2006-09-28 16:16 --- The EDG guys don't think this is worth spending the committee's time on so I won't be proposing any change to the standard. Issuing just a warning rather than an error is good enough for me. Also, I opened bug 29273 to remove the error from the dynamic_cast expression with an array argument since that one is well-formed as well (see comment 2), according to the same paragraph. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
[Bug c/29274] New: 4.1, 4.2 (possibly 4.0?) not using mulsidi3
GCC 4.x tree optimization decides to put int values into long long int temporaries. When RTL expansion comes around, the expander sees only a DImode multiply and so generates three SImode multiplies to deal with the problem. GCC 3.x sees that the source values are SImode and uses mulsidi3 to generate 32x32-64 multiplies, which are much more efficient. It also picks up the accumulation. (using -O3 for all compilations) GCC 3.4 has an 84-byte stack frame, and a body of 372 instructions. GCC 4.1 has a 1416-byte stack frame, and a body of 1668 instructions. GCC 4.2 has a 1320-byte stack frame, and a body of 1565 instructions. -- Summary: 4.1, 4.2 (possibly 4.0?) not using mulsidi3 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eplondke at gmail dot com GCC host triplet: x86_64-suse-linux GCC target triplet: arm-unkown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29274
[Bug c/29274] 4.1, 4.2 (possibly 4.0?) not using mulsidi3
--- Comment #1 from eplondke at gmail dot com 2006-09-28 16:45 --- Created an attachment (id=12351) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12351action=view) Test case showing mulsidi problem Multimedia processing It's not self-running, but you can see plainly from the assembly output. If you want a self-running test I can modify it a bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29274
[Bug c/29274] 4.1, 4.2 (possibly 4.0?) not using mulsidi3
--- Comment #2 from eplondke at gmail dot com 2006-09-28 16:46 --- Forgot to say: I'm seeing this on an ARM cross-compilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29274
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #1 from jakub at gcc dot gnu dot org 2006-09-28 17:57 --- I think after we want to look through handled_component_p's of destvar/srcvar (in fold_builtin_memory_op) resp. var (in fold_builtin_memset) and see if inside is a VAR_DECL or not. If it is a VAR_DECL, then I believe the optimization is always safe, if it is INDIRECT_REF of a pointer, then it would be only safe if we can make the read resp. write use forcibly alias set 0. If we e.g. made a copy of the pointer and set DECL_POINTER_ALIAS_SET on it, would that work and not be optimized out? -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org, ||dnovillo at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #2 from jakub at gcc dot gnu dot org 2006-09-28 18:17 --- Created an attachment (id=12352) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12352action=view) gcc42-pr29272.patch Untested patch to just bail for non-vars. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug fortran/29275] New: fortran added to language build list even when known buggy version of mpfr found
Configured with ../configure --prefix=/pkgs/gcc-test --with-gmp=/pkgs/gmp-4.1.4/ --with-mpfr=/pkgs/gmp-4.1.4/ The following messages come up during configure: checking for correct version of gmp.h... yes checking for correct version of mpfr.h... buggy version of MPFR detected checking for any version of mpfr.h... yes The following languages will be built: c,c++,fortran,java,objc *** This configuration is not supported in the following subdirectories: target-libmudflap target-libada gnattools (Any other directories should still work fine.) In /pkgs/gmp-4.1.4/include/mpfr.h we find /* Define MPFR version number */ #define MPFR_VERSION_MAJOR 2 #define MPFR_VERSION_MINOR 1 #define MPFR_VERSION_PATCHLEVEL 1 which is indeed insufficient to build gfortran, but gfortran is still configured in and make bootstrap fails with /Users/gcc-test/programs/gcc/mainline/objdir-64/./prev-gcc/xgcc -B/Users/gcc-test/programs/gcc/mainline/objdir-64/./prev-gcc/ -B/pkgs/gcc-test/powerpc-apple-darwin8.7.0/bin/ -c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -Ifortran -I../../gcc -I../../gcc/fortran -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include -I/pkgs/gmp-4.1.4//include -I/pkgs/gmp-4.1.4//include -I../../gcc/../libdecnumber -I../libdecnumber../../gcc/fortran/arith.c -o fortran/arith.o cc1: warnings being treated as errors ../../gcc/fortran/arith.c: In function 'gfc_check_real_range': ../../gcc/fortran/arith.c:445: warning: implicit declaration of function 'mpfr_subnormalize' make[3]: *** [fortran/arith.o] Error 1 [descartes:gcc/mainline/objdir-64] gcc-test% cat ../LAST_UPDATED Thu Sep 28 09:43:25 EDT 2006 Thu Sep 28 13:43:25 UTC 2006 (revision 117281M) -- Summary: fortran added to language build list even when known buggy version of mpfr found Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.7.0 GCC host triplet: powerpc-apple-darwin8.7.0 GCC target triplet: powerpc-apple-darwin8.7.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29275
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-09-28 18:32 --- Excerpts from IRC session with jakub discussing this: 13:28 dnovillo 1grow (); 13:28 dnovillo 2node = pool; 13:28 dnovillo 3D.1928 = node-next; 13:28 dnovillo 4pool = D.1928; 13:28 dnovillo 5foo = (struct Foo *) node; 13:28 dnovillo 6foo-a = 0; 13:28 dnovillo 7foo-b = -1; 13:28 dnovillo 8node = (struct Node *) foo; - redundant. node == foo already. 13:28 dnovillo 9node-next = D.1928; - redundant. node-next == D.1928 already 13:28 dnovillo 10pool = node; - redundant. node == pool already. 13:28 dnovillo 11return foo-a; 13:33 jakub line 9 is not redundant, because node-next occupies the same memory as foo-a and foo-b 13:34 jakub I think we have 2 options with this optimization 13:35 jakub 1) for each memcpy etc. operand, look through all handled components and if it is an actual VAR_DECL, we can surely optimize it, with the native alias set 13:36 jakub but if it is a pointer, we can't be sure 13:37 jakub now, either we figure out some way how to express that operation in an alias friendly way if it is a pointer, or we just bail and don't optimize 13:37 dnovillo but, my point was that i don't see where the RTL optimizers may be screwing up. what's the exact operation that they remove that they shouldn't have? 13:37 dnovillo it all looks removable to me. 13:39 jakub RTL optimizers remove the node-next = D.1928 line 13:40 jakub which means 1) pool-next is in the end 0 rather than old pool-next 13:40 jakub and 2) 0 is returned rather than (int) pool-next 13:40 dnovillo but D.1928 and node-next have the same value according to the tree dump. or am i misreading something? 14:03 jakub foo == node, so foo-a and node-next occupy the same memory 14:03 dnovillo oh, crap. 14:03 jakub and eventhough those 2 have aliasing incompatible types, the use of memcpy makes it ok 14:03 dnovillo i had missed that. 14:04 jakub guess I'll now write just a quick patch to only do it for VAR_DECLs and components thereof 14:05 jakub so that the bug is fixed and we can then keep discussing how even pointers can be safely optimized 14:05 dnovillo so, going back to not apply this on pointers then? 14:05 dnovillo yeah, for now that would be the safe approach. 14:10 jakub /* If var is a VAR_DECL or a component thereof, 14:10 jakub we can use its alias set, otherwise we'd need to make 14:10 jakub sure we go through alias set 0. */ 14:10 jakub inner = srcvar; 14:10 jakub while (handled_component_p (inner)) 14:10 jakub inner = TREE_OPERAND (inner, 0); 14:10 jakub if (TREE_CODE (inner) != VAR_DECL) 14:10 jakub return 0; 14:11 jakub or should I use SSA_VAR_P (inner) instead? 14:12 jakub I guess at least PARM_DECL or RESULT_DECL would be ok, not sure about SSA names 14:22 dnovillo the reason we don't screw up in the trees is the presence of points-to information, most likely. i got tricked because i wasn't following who was pointing to who. 14:22 dnovillo the store foo-a changes node-next. 14:23 dnovillo bah. 14:23 dnovillo RTL misses that because the stores have different alias sets. 14:23 dnovillo the transformation we do on trees is invalid for RTL because we don't keep points-to info in RTL, only type info. 14:23 dnovillo the Real Fix would tag the stores so that gimple-RTL changes the alias sets. 14:24 dnovillo something along the lines of what you suggest may work. 14:26 jakub yeah, now to find a way to force the alias set... -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug other/29271] Incorrect -fdump-rtl-sched and -fdump-rtl-sched2 document
--- Comment #1 from dberlin at gcc dot gnu dot org 2006-09-28 18:39 --- Subject: Re: New: Incorrect -fdump-rtl-sched and -fdump-rtl-sched2 document This is because on your platofrm, sched1 doesn't run. On 28 Sep 2006 15:51:05 -, hjl at lucon dot org [EMAIL PROTECTED] wrote: There are @itemx -fdump-rtl-sched2 @opindex dR @opindex fdump-rtl-sched2 Dump after the second scheduling pass, to @[EMAIL PROTECTED] @item -dS @itemx -fdump-rtl-sched @opindex dS @opindex fdump-rtl-sched Dump after the first scheduling pass, to @[EMAIL PROTECTED] in invoke.texi. But I got [EMAIL PROTECTED] slow-9]$ /usr/gcc-4.2/bin/gcc --version gcc (GCC) 4.2.0 20060913 (experimental) [trunk revision 116922] Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED] slow-9]$ /usr/gcc-4.2/bin/gcc -fdump-rtl-sched -S slow.c cc1: error: unrecognized command line option -fdump-rtl-sched [EMAIL PROTECTED] slow-9]$ /usr/gcc-4.2/bin/gcc -fdump-rtl-sched2 -S slow.c [EMAIL PROTECTED] slow-9]$ ls -l slow.c.149r.sched2 -rw-r--r-- 1 hjl hjl 16119 Sep 28 08:44 slow.c.149r.sched2 -- Summary: Incorrect -fdump-rtl-sched and -fdump-rtl-sched2 document Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29271 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29271
[Bug fortran/29275] fortran added to language build list even when known buggy version of mpfr found
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-28 18:40 --- gfortran will work with the buggy mpfr. You simply will not get the bug fixes for 27021 and 28276. You have not installed gmp-4.1.4 as distributed by the GMP developers. The mpfr.h header file in the version of mpfr included in gmp-4.1.4 does included /* Define MPFR version number */ #define MPFR_VERSION_MAJOR 2 #define MPFR_VERSION_MINOR 1 #define MPFR_VERSION_PATCHLEVEL 1 In fact it does not include any of these. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29275
[Bug other/29271] Incorrect -fdump-rtl-sched documentation
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-28 18:45 --- -fdump-rtl-sched should be -fdump-rtl-sched1. The numbering system is a different story and is wrong for most rtl dumps now because someone forgot to update them when they changed the numbering system and/or added a pass. -- pinskia 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-09-28 18:45:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29271
[Bug fortran/29275] fortran added to language build list even when known buggy version of mpfr found
--- Comment #2 from kargl at gcc dot gnu dot org 2006-09-28 18:48 --- Crap. Re-open. mpfr_subnormalized() first appeared in 2.2.0. I'll fix this in a few minutes. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29275
[Bug target/29206] [4.2 regression] gcj-dbtool segfaults
--- Comment #2 from debian-gcc at lists dot debian dot org 2006-09-28 19:30 --- (In reply to comment #1) Either show that it is a regression, or dont put the regression marker in the subject. rechecked, that it is a regression on hppa-linux-gnu, compared to 4.1.2 SVN. Matthias -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Known to fail||4.2.0 Known to work||4.1.2 Summary|gcj-dbtool segfaults|[4.2 regression] gcj-dbtool ||segfaults http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206
[Bug target/29206] [4.2 regression] gcj-dbtool segfaults
--- Comment #3 from debian-gcc at lists dot debian dot org 2006-09-28 19:31 --- attached the stacktrace for arm-linux-gnu Matthias (gdb) run Starting program: /home/doko/gcc/4.2/install/usr/bin/gcj-dbtool-4.2 -n foo.db 64 [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 18291)] [New Thread 32769 (LWP 20685)] [New Thread 16386 (LWP 20790)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 18291)] 0x41bf6434 in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1 (gdb) bt #0 0x41bf6434 in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1 #1 0x40b988c0 in _Jv_StackTrace::UnwindTraceFn (context=0xbfffebcc, state_ptr=value optimized out) at ../../../src/libjava/stacktrace.cc:141 #2 0x41bf6a04 in _Unwind_Backtrace () from /lib/libgcc_s.so.1 #3 0x40b987cc in _Jv_StackTrace::GetStackTrace () at ../../../src/libjava/stacktrace.cc:170 #4 0x40bd9bd0 in java::lang::VMThrowable::fillInStackTrace () at ../../../src/libjava/java/lang/natVMThrowable.cc:33 #5 0x40f9aee4 in java.lang.Throwable.fillInStackTrace()java.lang.Throwable (this=0xbfffebcc) at ../../../src/libjava/classpath/java/lang/Throwable.java:498 #6 0x40f9a8d4 in java.lang.Throwable.Throwable(java.lang.String) (this=0x41ef2220, message=0x41f6ed98) at ../../../src/libjava/classpath/java/lang/Throwable.java:159 #7 0x40f846d8 in java.lang.Exception.Exception(java.lang.String) (this=0xbfffebcc, s=0xbfffebac) at ../../../src/libjava/classpath/java/lang/Exception.java:77 #8 0x40f8219c in java.lang.ClassNotFoundException.ClassNotFoundException(java.lang.String) (this=0xbfffebcc, s=0xbfffebac) at ../../../src/libjava/classpath/java/lang/ClassNotFoundException.java:83 #9 0x40fc7870 in java.net.URLClassLoader.findClass(java.lang.String)java.lang.Class (this=0x41edb2d8, className=0x41f0fb90) at ../../../src/libjava/java/net/URLClassLoader.java:1080 #10 0x40bfdb48 in gnu.gcj.runtime.BootClassLoader.bootLoadClass(java.lang.String)java.lang.Class (this=0xbfffebcc, name=0x41f0fb90) at ../../../src/libjava/gnu/gcj/runtime/BootClassLoader.java:55 #11 0x40bd9788 in java::lang::VMClassLoader::loadClass (name=0x41f0fb90, resolve=0 '\0') at ../../../src/libjava/java/lang/natVMClassLoader.cc:208 #12 0x40bd2d90 in _Jv_FindClass (name=0x41f0d730, loader=0x0) at ../../../src/libjava/java/lang/natClassLoader.cc:407 #13 0x40bd1a40 in java::lang::Class::forName (className=0x41f6ee88, initialize=1 '\001', loader=0x0) at ../../../src/libjava/java/lang/natClass.cc:88 #14 0x40bf8f90 in gnu.gcj.convert.BytesToUnicode.getDecoder(java.lang.String)gnu.gcj.convert.BytesToUnicode (encoding=0x41edcaf0) at ../../../src/libjava/gnu/gcj/convert/BytesToUnicode.java:101 #15 0x40bd7a40 in java::lang::String::init (this=0x3, bytes=0x41efad30, offset=0, count=2, encoding=0x41edcaf0) at ../../../src/libjava/java/lang/natString.cc:490 #16 0x40f91210 in java.lang.String.String(byte[], int, int) (this=0x41f6eeb8, data=0x41efad30, offset=0, count=2) at ../../../src/libjava/java/lang/String.java:345 #17 0x40b83f24 in JvConvertArgv (argc=3, argv=0xa398) at ../../../src/libjava/prims.cc:953 #18 0x40b84e58 in _Jv_RunMain (vm_args=0x0, klass=0x16460, name=0x0, argc=4, argv=0xba64, is_jar=false) at ../../../src/libjava/prims.cc:1537 #19 0x40b85190 in _Jv_RunMain (klass=0xbfffebac, name=0x41714e90 (d#65533;#65533;#65533;Ah\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@h\036#65533;#65533;#65533;@..., argc=1085821328, argv=value optimized out, is_jar=false) at ../../../src/libjava/prims.cc:1597 #20 0x40b851bc in JvRunMain (klass=0xbfffebcc, argc=1097944720, argv=0x0) at ../../../src/libjava/prims.cc:1603 #21 0x41c14e44 in __libc_start_main () from /lib/libc.so.6
[Bug fortran/29275] fortran added to language build list even when known buggy version of mpfr found
--- Comment #3 from kargl at gcc dot gnu dot org 2006-09-28 19:36 --- This should be fixed by the patch I just committed. Note, you'll see two gfortran testsuite programs fail because your version of mpfr is too old. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29275
[Bug target/29206] [4.2 regression] gcj-dbtool segfaults
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-28 20:53 --- Subject: Re: [4.2 regression] gcj-dbtool segfaults Starting program: /home/doko/gcc/4.2/install/usr/bin/gcj-dbtool-4.2 -n foo.db 64 [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 18291)] [New Thread 32769 (LWP 20685)] [New Thread 16386 (LWP 20790)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 18291)] 0x41bf6434 in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1 (gdb) bt #0 0x41bf6434 in _Unwind_GetIPInfo () from /lib/libgcc_s.so.1 The following patch introduced _Unwind_GetIPInfo: 2006-02-27 Jakub Jelinek [EMAIL PROTECTED] PR other/26208 ... Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206
[Bug preprocessor/29276] New: C preprocessor run on Objective C code
Everytime I try to compile the libFoundation sources the preprocessor complains with error messages like these: NSObject.m:382:1: error: pasting ( and [ does not give a valid preprocessing token NSObject.m:513:1: error: pasting ( and [ does not give a valid preprocessing token I had to preprocess the source with the -x objective-c flags, forcing cpp to process the file in Objective C mode and it worked fine. I would have attached the preprocessed file, if there would have been an option to make the preprocessor only include files and not expand macros but I couldn't find it in your documentation. I might have overlooked it. Sources can be found here: http://prdownloads.sourceforge.net/libfoundation/libFoundation-0.9.0.tar.gz?download GCC was invoked like this: gcc -fPIC -fgnu-runtime -I.. -g -O2 -fobjc-exceptions -Wall -DDEBUG -c NSObject.m -o shared_obj/NSObject.o Adding the -x objective-c flags to the gcc command line did not work. -- Summary: C preprocessor run on Objective C code Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: roberthensing at hotmail dot com 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=29276
[Bug preprocessor/29276] C preprocessor run on Objective C code
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-28 22:15 --- ([ will never make a valid token even in Objective-C mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29276
[Bug libfortran/27046] [mingw32] mixed C-Fortran I/O doesn't flush
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-09-28 22:34
---
(In reply to comment #7)
Changing main() in ctesti.c to start with:
int main(int argc, char** argv) {
setvbuf(stdout, NULL, _IOLBF, 0);
fixes the redirection problem.
After some more testing, this fix doesn't work in all cases (e.g. in a shell of
MSYS window). I'm closing this PR: after all, this is not a bug in the
compiler, mixed-languages code is supposed to correctly flush both I/O systems
after operations. I would have liked to provide a workaround, only there
doesn't appear to be anythink general and robust enough.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug fortran/28813] gfortran.dg/direct_io_6.f90 can exhaust system disk space
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-09-28 22:39 --- Closing, test not needed. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28813
[Bug fortran/29277] New: Formated stream output: Translate \n / achar(10) into \r\n on some platforms
See http://gcc.gnu.org/ml/fortran/2006-09/msg00415.html Brooks Moses wrote: when a file is connected for stream access, the runtime library could very easily do a s/\n/\r\n/ on the output stream before writing it to the file. In fact, if we consider \r\n to be a record marker (on a given system), and we do wish to implement the behavior described in this paragraph [10.6.3] then it would be required to do so. Actually, now that I read section 9.2.2.3 (and particularly note 9.9) on the Fortran 2003 Standard, I'm pretty sure it was the intent of the standard committee that this sort of substitution be done. Note 9.9 states: There may be some character positions in the file that do not correspond to characters written; this is because on some processors a record marker may be written to the file as a carriage-return/linefeed or other sequence. The means of determining the position in a file connected for stream access is via the POS= specifier in an INQUIRE statement (9.9.1.21). Note, in particular, that this whole matter only applies to _formatted_ stream files -- that is, files which are expected to contain human-readable text that could be edited in a text editor. For unformatted stream files -- which are the only ones that should be containing binary data that would be corrupted by the substitution -- this doesn't apply, and no substitution would be made. Thus, I think it's pretty clear that NEW_LINE should return ACHAR(10), and that for formatted stream-access files, the runtime library should convert that character to the appropriate system-specific line-ending string when writing to files. (This substitution would not be a regression against g77, because files opened for stream access do not exist in g77 code, and the substitution would not be made for non-stream files.) -- Summary: Formated stream output: Translate \n / achar(10) into \r\n on some platforms Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement 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=29277
[Bug fortran/19261] continuation character illegal as first non-blank character in statement
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-09-28 22:40 --- I have this one fixed and will combine it with the pathes for 19260 and 19262. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19261
[Bug libgcj/29278] New: [ecj] libjava Makefile has -j bug
I believe the libjava Makefile.am on the gcj-eclipse branch has a bug with -j builds, where it may try to build the CNI header files multiple times. -- Summary: [ecj] libjava Makefile has -j bug Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org OtherBugsDependingO 28067 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29278
[Bug libgcj/29278] [ecj] libjava Makefile has -j bug
-- tromey 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-09-28 23:03:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29278
[Bug fortran/29277] Formated stream output: Translate \n / achar(10) into \r\n on some platforms
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-09-28 23:23 --- Please note that with formatted stream I/O we implicitly write a /n or /r/n in the next_record_w () function in transfer.c depending on the system. I think this meets the intent. Now an issue I see is what if we want to explicitly write a /n on this system? There would be no way to do that if we translate it to /n/r. I am not sure the intent of the committee was to restrict this in this way, but allow it in the case of formatted end of record. I have not tried this, but if I write out a formatted string with one character /n I wonder if we we get /n/r/n with current gfortran. I am not agreeing or diagreeing here. You have raised a good question here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29277
[Bug c++/29266] Rule that binding rvalue to a refernce need a copy ctor don't work
--- Comment #2 from yuanfei8077 at gmail dot com 2006-09-28 23:25 --- Subject: Re: Rule that binding rvalue to a refernce need a copy ctor don't work Hi Andrew, You are right, I am omitting the code, however, my question is: 1) t.cc:38: error: 'MemAllocatorType::MemAllocator() [with Type = int]' is private t.cc:49: error: within this context However, MemAllocator is only invoked by class data member cache's intialization list, and MemAllocator's copy constructor is already provided, so you mean I am forced to offer default constructor too to make it pass, right ? 2) There is no tdat_hash_map(_Alloc) in the sources. ::tdat_hash_map(MemAllocatorint)main.cpp:49: note: candidates are: tdat_hash_map_AllocType::tdat_hash_map() [with _AllocType = MemAllocatorint] main.cpp:42: note: tdat_hash_mapMemAllocatorint ::tdat_hash_map(const tdat_hash_mapMemAllocatorint ) But from the original error output, comiler have added a default tdat_hash_map in line 42, and its format is same as what you added to make no matching error disappear. Can you explain explain why the default can't work ? Thanks for your help! -Kelvin On 28 Sep 2006 13:39:16 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-28 13:39 --- There is no tdat_hash_map(_Alloc) in the sources. Adding one makes it get past that error and then we get: t.cc: In constructor 'tdat_hash_map_AllocType::tdat_hash_map(const _AllocType) [with _AllocType = MemAllocatorint]': t.cc:64: instantiated from here t.cc:38: error: 'MemAllocatorType::MemAllocator() [with Type = int]' is private t.cc:49: error: within this context So this is invalid still. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29266 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29266
[Bug fortran/29277] Formated stream output: Translate \n / achar(10) into \r\n on some platforms
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-09-28 23:36 --- Another thought occurs to me. With formatted stream I/O the newline is handled automatically for the user. However, there is nothing to say someone would not want to use unformatted stream I/O to write human readable files. In that case, you would want the result of newline to give the /r/n or /n on the respective systems. Based on this thinking, the translation, if any, should be done for unformatted I/O and only when the NEWLINE function is explicitly used. Clealy we have a case where the standard may not be all that clear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29277
[Bug middle-end/29256] [4.2 regression] loop performance regression
--- Comment #16 from rakdver at gcc dot gnu dot org 2006-09-28 23:48 --- Patch for the induction variable selection (that however does not fix the problem with offsetted addressing modes not being created after unrolling): http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01308.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug fortran/29147] Bad overflow check in DATA statements
--- Comment #2 from kargl at gcc dot gnu dot org 2006-09-29 00:25 --- (In reply to comment #1) Created an attachment (id=12299) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12299action=view) [edit] Legacy code example Compiles fine with every other compiler out there. That's because every other compiler out there is broken :-) The standard is quite clear that the BOZ is converted to an integer with the kind type with the largest decimal range. In your case that integer is kind=8, and Z'' = 4294967295 which over flows the range of an integer(kind=4) constant. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29147
[Bug c++/29279] New: ICE
const char nullstr[1] = (const char [1]) {0};
int main()
{
}
--
Summary: ICE
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philippe at fornux dot com
GCC build triplet: Mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29279
[Bug fortran/25818] Problem with handling optional and entry master arguments
--- Comment #8 from kargl at gcc dot gnu dot org 2006-09-29 00:30 --- Paul, Jakub, Is the patch in comment #7 considered to be the right approach? I tried applying to my local tree, but a few chunks were rejected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
[Bug tree-optimization/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)
--- Comment #4 from lopezibanez at gmail dot com 2006-09-29 00:37 --- Not so surprising if you check gcc/c-typeck.c line 3980. The warning is not conditionalised to any option. What is the criteria for a warning to be emitted always or be conditional to a given option? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29254
[Bug tree-optimization/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)
--- Comment #5 from lopezibanez at gmail dot com 2006-09-29 00:53 --- (In reply to comment #4) Not so surprising if you check gcc/c-typeck.c line 3980. The warning is not conditionalised to any option. What is the criteria for a warning to be emitted always or be conditional to a given option? Argh! I meant line 4100 (although perhaps it is the same warning, not sure). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29254
[Bug c/29280] New: misleading warning for assignment used as truth construct
For code of the form: if (var = 0) gcc recommends adding parentheses around the construct. This is intended to disambiguate code of the form: if (ptr = get_ptr()) by coercing people to write it in the form: if ((ptt = get_ptr()) != NULL) However, in many cases, especially for novice C developers, the code was intended to mean: if (ptr == get_ptr()) or if (var == 0) I'm submitting this bug report because I just saw yet another case of a novice developer posting on a forum that he had been trying to get some code to work, and the code he posted included: if (( var = 0 )) I asked and found that he had done what the gcc warning had kindly suggested, not really understanding what the warning meant. The warning is warning: suggest parentheses around assignment used as truth value I suggest several possibilities to improve the situation. The first is to simply alter or expand the warning slightly. Perhaps something like, warning: use == for testing equality; suggest parentheses around assignment used as truth value The second is to use two separate warning message with some heuristics to determine which to prefer. For example, an assignment to a constant is very rarely used as a truth value. Code of the form 'if ( var = 0 )' should produce a warning that == must be used to test equality. I won't try to make concrete suggestions on the best set of heuristics for these cases, but that one at least is obvious. I would wager that using any non-function expression in an assignment rvalue as a truth value is very rare; that is, 'if ( (foo = bar) != 0 )' is far rarer than 'if ( (foo = baz()) != 0 )'. -- Summary: misleading warning for assignment used as truth construct Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: elanthis at awesomeplay dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29280
[Bug target/28617] ___divti3 and ___umodti3 undefined for -m64 on powerpc-apple-darwin8
--- Comment #3 from mrs at gcc dot gnu dot org 2006-09-29 01:21 --- Subject: Bug 28617 Author: mrs Date: Fri Sep 29 01:21:14 2006 New Revision: 117296 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117296 Log: PR target/28617 * config/rs6000/rs6000.h [IN_LIBGCC2] (TARGET_POWERPC64): Define to 1 when __ppc64__ is defined. * config/rs6000/t-darwin (LIB2FUNCS_EXTRA): Add ppc64-fp.c and darwin-64.c. * config/rs6000/ppc64-fp.c: Also compile when __ppc64__ is defined. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/ppc64-fp.c trunk/gcc/config/rs6000/rs6000.h trunk/gcc/config/rs6000/t-darwin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28617
[Bug target/28617] ___divti3 and ___umodti3 undefined for -m64 on powerpc-apple-darwin8
--- Comment #4 from mrs at apple dot com 2006-09-29 01:29 --- This should be fixed by the last checkin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28617
[Bug c/29281] New: natPlainDatagramSocketImpl.cc:148: internal compiler error
i'm a korean embedded linux engineer. i'm making a cross tool-chain. (gcc-3.4.1 / glibc-2.3.2 / binutils-2.15 / linux-2.6.17) i used some configuration like below. ../binutils-2.15/configure --target=arm-linux --prefix=/usr/local/arm --disable-nls ../gcc-3.4.5/configure --target=arm-linux --prefix=/usr/local/arm/ --with-cpu=arm9 --disable-threads --disable-shared --enable-languages=c i had some patches... å vi sysdeps/unix/sysv/linux/arm/ioperm.c å change BUS_ISA to be CTL_BUS_ISA lines 103 and 104 å vi Makeconfig å change all occurrances of O2 to O å remove any occurrances of -lgcc_eh å vi configure å change all occurrances of O2 to O å touch sysdeps/arm/framestate.c å Rm ¡Vrf nptl å vi sysdeps/generic/wordexp.c å /* Function called by child process in exec_comm() */ å -static void å +static inline void å internal_function __attribute__ ((always_inline)) ../glibc-2.3.6/configure --target=arm-linux --host=arm-linux --prefix=/usr/local/arm/arm-linux/ --enable-add-ons=linuxthreads --with-headers=/usr/src/linux/include/ but, i got some errors like below === error start = gnu/java/net/natPlainDatagramSocketImpl.cc: In member function `virtual void gnu::java::net::PlainDatagramSocketImpl::bind(jint, java::net::InetAddress*)': gnu/java/net/natPlainDatagramSocketImpl.cc:148: internal compiler error: in arm_print_operand, at config/arm/arm.c:9810 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. = error end = i've known that you got similar error and you fixed it through http://gcc.gnu.org/bugzilla/. so, i wonder how you fixed that bug?? help me plz... -- Summary: natPlainDatagramSocketImpl.cc:148: internal compiler error Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sangsu at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29281
[Bug c++/29266] Rule that binding rvalue to a refernce need a copy ctor don't work
--- Comment #3 from yuanfei8077 at gmail dot com 2006-09-29 03:02 ---
Plesae seee Comment #2 From Kelvin 2006-09-28 23:25 [reply].
In addition 2 questions I raised in the Commet2. I also have one more question
about the rule bind an rvalue to a reference,
we need to let copy ctor of the class be accessible., I found that this rule
only effective when the reference is delcared as const , but if we remove
keyword const, then no matching happen again.
using std::cout;
using std::endl;
class MemPool {
public:
MemPool(){};
protected:
MemPool(const MemPool mempool);
};
template class Type class MemAllocator{
public:
MemAllocator(MemPool pool):m_pool(pool){}
MemPool get_pool() const {
return m_pool;
}
templateclass OtherType
MemAllocatorType operator=(const MemAllocatorOtherType rhs){
m_pool = rhs.get_pool();
return *this;
}
MemAllocator operator=(const MemAllocator rhs){
m_pool = rhs.get_pool();
return *this;
}
MemAllocator(const MemAllocator other)
: m_pool(other.m_pool) {}
templateclass OtherType
MemAllocator(const MemAllocatorOtherType other)
: m_pool(other.get_pool()) {}
private:
MemAllocator();
// MemAllocator(const MemAllocator);
MemPool m_pool;
};
template class _AllocType class tdat_hash_map {
public:
typedef _AllocType _Alloc;
static void func(const _Alloc) {};
tdat_hash_map(const _Alloc); // there will be error if const is removed
_Alloc malloc;
private:
tdat_hash_map();
};
class CacheManager {
public:
typedef tdat_hash_mapMemAllocatorint Map;
Map caches;
MemPool pool;
CacheManager():caches(MemAllocatorint(pool)){};
};
--
yuanfei8077 at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29266
[Bug c/29281] natPlainDatagramSocketImpl.cc:148: internal compiler error
--- Comment #1 from sangsu at gmail dot com 2006-09-29 03:03 ---
before configuring glibc...
i had some patches, too
start ===
--- gcc-3.4.1/gcc/flow.c.old2004-02-27 19:39:19.0 -0800
+++ gcc-3.4.1/gcc/flow.c2004-08-26 07:29:46.0 -0700
@@ -1878,6 +1878,7 @@
rtx set_src = SET_SRC (pc_set (BB_END (bb)));
rtx cond_true = XEXP (set_src, 0);
rtx reg = XEXP (cond_true, 0);
+ enum rtx_code inv_cond;
if (GET_CODE (reg) == SUBREG)
reg = SUBREG_REG (reg);
@@ -1886,11 +1887,13 @@
in the form of a comparison of a register against zero.
If the condition is more complex than that, then it is safe
not to record any information. */
- if (GET_CODE (reg) == REG
+ inv_cond = reversed_comparison_code (cond_true, BB_END (bb));
+ if (inv_cond != UNKNOWN
+ GET_CODE (reg) == REG
XEXP (cond_true, 1) == const0_rtx)
{
rtx cond_false
- = gen_rtx_fmt_ee (reverse_condition (GET_CODE (cond_true)),
+ = gen_rtx_fmt_ee (inv_cond,
GET_MODE (cond_true), XEXP (cond_true, 0),
XEXP (cond_true, 1));
#61557; if (GET_CODE (XEXP (set_src, 1)) == PC)
= end
(In reply to comment #0)
i'm a korean embedded linux engineer.
i'm making a cross tool-chain.
(gcc-3.4.1 / glibc-2.3.2 / binutils-2.15 / linux-2.6.17)
i used some configuration like below.
../binutils-2.15/configure --target=arm-linux --prefix=/usr/local/arm
--disable-nls
../gcc-3.4.5/configure --target=arm-linux --prefix=/usr/local/arm/
--with-cpu=arm9 --disable-threads --disable-shared --enable-languages=c
i had some patches...
å vi sysdeps/unix/sysv/linux/arm/ioperm.c
å change BUS_ISA to be CTL_BUS_ISA lines 103 and 104
å vi Makeconfig
å change all occurrances of O2 to O
å remove any occurrances of -lgcc_eh
å vi configure
å change all occurrances of O2 to O
å touch sysdeps/arm/framestate.c
å Rm ¡Vrf nptl
å vi sysdeps/generic/wordexp.c
å /* Function called by child process in exec_comm() */
å -static void
å +static inline void
å internal_function __attribute__ ((always_inline))
../glibc-2.3.6/configure --target=arm-linux --host=arm-linux
--prefix=/usr/local/arm/arm-linux/ --enable-add-ons=linuxthreads
--with-headers=/usr/src/linux/include/
but, i got some errors like below
=== error start
=
gnu/java/net/natPlainDatagramSocketImpl.cc: In member function `virtual void
gnu::java::net::PlainDatagramSocketImpl::bind(jint,
java::net::InetAddress*)':
gnu/java/net/natPlainDatagramSocketImpl.cc:148: internal compiler error: in
arm_print_operand, at config/arm/arm.c:9810
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
= error end
=
i've known that you got similar error and you fixed it through
http://gcc.gnu.org/bugzilla/.
so, i wonder how you fixed that bug??
help me plz...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29281
[Bug c/29281] natPlainDatagramSocketImpl.cc:148: internal compiler error
--- Comment #2 from sangsu at gmail dot com 2006-09-29 03:05 ---
and i used a gcc configuration below...
= start =
../gcc-3.4.5/configure --target=arm-linux --prefix=/usr/local/arm/
--with-headers=/ojt/kernel/linux-2.6.17/include/
= end =
(In reply to comment #1)
before configuring glibc...
i had some patches, too
start ===
--- gcc-3.4.1/gcc/flow.c.old2004-02-27 19:39:19.0 -0800
+++ gcc-3.4.1/gcc/flow.c2004-08-26 07:29:46.0 -0700
@@ -1878,6 +1878,7 @@
rtx set_src = SET_SRC (pc_set (BB_END (bb)));
rtx cond_true = XEXP (set_src, 0);
rtx reg = XEXP (cond_true, 0);
+ enum rtx_code inv_cond;
if (GET_CODE (reg) == SUBREG)
reg = SUBREG_REG (reg);
@@ -1886,11 +1887,13 @@
in the form of a comparison of a register against zero.
If the condition is more complex than that, then it is safe
not to record any information. */
- if (GET_CODE (reg) == REG
+ inv_cond = reversed_comparison_code (cond_true, BB_END (bb));
+ if (inv_cond != UNKNOWN
+ GET_CODE (reg) == REG
XEXP (cond_true, 1) == const0_rtx)
{
rtx cond_false
- = gen_rtx_fmt_ee (reverse_condition (GET_CODE (cond_true)),
+ = gen_rtx_fmt_ee (inv_cond,
GET_MODE (cond_true), XEXP (cond_true, 0),
XEXP (cond_true, 1));
#61557; if (GET_CODE (XEXP (set_src, 1)) == PC)
= end
(In reply to comment #0)
i'm a korean embedded linux engineer.
i'm making a cross tool-chain.
(gcc-3.4.1 / glibc-2.3.2 / binutils-2.15 / linux-2.6.17)
i used some configuration like below.
../binutils-2.15/configure --target=arm-linux --prefix=/usr/local/arm
--disable-nls
../gcc-3.4.5/configure --target=arm-linux --prefix=/usr/local/arm/
--with-cpu=arm9 --disable-threads --disable-shared --enable-languages=c
i had some patches...
å vi sysdeps/unix/sysv/linux/arm/ioperm.c
å change BUS_ISA to be CTL_BUS_ISA lines 103 and 104
å vi Makeconfig
å change all occurrances of O2 to O
å remove any occurrances of -lgcc_eh
å vi configure
å change all occurrances of O2 to O
å touch sysdeps/arm/framestate.c
å Rm ¡Vrf nptl
å vi sysdeps/generic/wordexp.c
å /* Function called by child process in exec_comm() */
å -static void
å +static inline void
å internal_function __attribute__ ((always_inline))
../glibc-2.3.6/configure --target=arm-linux --host=arm-linux
--prefix=/usr/local/arm/arm-linux/ --enable-add-ons=linuxthreads
--with-headers=/usr/src/linux/include/
but, i got some errors like below
=== error start
=
gnu/java/net/natPlainDatagramSocketImpl.cc: In member function `virtual void
gnu::java::net::PlainDatagramSocketImpl::bind(jint,
java::net::InetAddress*)':
gnu/java/net/natPlainDatagramSocketImpl.cc:148: internal compiler error: in
arm_print_operand, at config/arm/arm.c:9810
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
= error end
=
i've known that you got similar error and you fixed it through
http://gcc.gnu.org/bugzilla/.
so, i wonder how you fixed that bug??
help me plz...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29281
[Bug fortran/29147] Bad overflow check in DATA statements
-- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-29 03:26:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29147
