[Bug debug/38101] dbxout_expand_expr() doesn't check return value of DECL_VALUE_EXPR()
--- Comment #4 from d dot g dot gorbachev at gmail dot com 2008-11-19 04:37 --- Created an attachment (id=16720) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16720&action=view) Example Disregard the previous comment. Segmentation fault in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38101
[Bug c++/38174] New: Missing some built-in candidates for operator overloading
GCC fails to compile the following example, because it isn't generating all of
the necessary built-in candidates for operator== and operator-:
struct VolatileIntPtr {
operator int volatile *();
};
struct ConstIntPtr {
operator int const *();
};
void test_with_ptrs(VolatileIntPtr vip, ConstIntPtr cip) {
bool b1 = (vip == cip);
long p1 = vip - cip;
}
Note that in the (first) error message:
/Users/dgregor/op.cpp: In function void test_with_ptrs(VolatileIntPtr,
ConstIntPtr):
/Users/dgregor/op.cpp:10: error: no match for operator== in vip == cip
/Users/dgregor/op.cpp:10: note: candidates are: operator==(const int*, const
int*)
/Users/dgregor/op.cpp:10: note: operator==(volatile int*,
volatile int*)
we're missing the built-in candidate
operator==(const volatile int*, const volatile int*)
that would be picked.
--
Summary: Missing some built-in candidates for operator
overloading
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doug dot gregor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38174
[Bug fortran/38171] [regression] equivalence and nested modules broken
--- Comment #5 from pault at gcc dot gnu dot org 2008-11-19 03:49 --- Fixed on trunk and 4.3. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38171
[Bug fortran/38171] [regression] equivalence and nested modules broken
--- Comment #4 from pault at gcc dot gnu dot org 2008-11-19 03:47 --- Subject: Bug 38171 Author: pault Date: Wed Nov 19 03:46:12 2008 New Revision: 141992 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141992 Log: 2008-11-19 Paul Thomas <[EMAIL PROTECTED]> PR fortran/38171 * module.c (load_equiv): Regression fix; check that equivalence members come from the same module only. 2008-11-19 Paul Thomas <[EMAIL PROTECTED]> PR fortran/38171 * gfortran.dg/module_equivalence_6.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/module_equivalence_6.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38171
[Bug fortran/38171] [regression] equivalence and nested modules broken
--- Comment #3 from pault at gcc dot gnu dot org 2008-11-19 03:43 --- Subject: Bug 38171 Author: pault Date: Wed Nov 19 03:41:57 2008 New Revision: 141991 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141991 Log: 2008-11-19 Paul Thomas <[EMAIL PROTECTED]> PR fortran/38171 * ChangeLog: Correct PR number. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38171
[Bug fortran/38119] [4.4 Regression] character ICE in gfc_trans_create_temp_array
--- Comment #6 from pault at gcc dot gnu dot org 2008-11-19 03:37 --- (In reply to comment #5) > Subject: Bug 38119 > > Author: pault > Date: Wed Nov 19 03:25:00 2008 > New Revision: 141990 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141990 > Log: > 2008-11-19 Paul Thomas <[EMAIL PROTECTED]> > > PR fortran/38119 > * module.c (load_equiv): Regression fix; check that equivalence > members come from the same module only. > > 2008-11-19 Paul Thomas <[EMAIL PROTECTED]> > > * gfortran.dg/module_equivalence_6.f90: New test. > > Added: > trunk/gcc/testsuite/gfortran.dg/module_equivalence_6.f90 > Modified: > trunk/gcc/fortran/ChangeLog > trunk/gcc/fortran/module.c > trunk/gcc/testsuite/ChangeLog > Spurious - wrong PR number. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38119
[Bug fortran/38119] [4.4 Regression] character ICE in gfc_trans_create_temp_array
--- Comment #5 from pault at gcc dot gnu dot org 2008-11-19 03:26 --- Subject: Bug 38119 Author: pault Date: Wed Nov 19 03:25:00 2008 New Revision: 141990 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141990 Log: 2008-11-19 Paul Thomas <[EMAIL PROTECTED]> PR fortran/38119 * module.c (load_equiv): Regression fix; check that equivalence members come from the same module only. 2008-11-19 Paul Thomas <[EMAIL PROTECTED]> * gfortran.dg/module_equivalence_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/module_equivalence_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38119
[Bug c++/38173] New: Mistake in Russian translation of error text "functional cast expression list treated as compound expression"
Hello I've found that there is mistake in translation of this error message: LANG=C make ... error: functional cast expression list treated as compound expression ... [EMAIL PROTECTED]:~/Spectra_Project/libspectra$ echo "Current LANG: "$LANG && make Current LANG: ru_RU.UTF-8 ... îøèáêà: functional cast - ñïèñîå âûðàæåíèé ðàññìàòðèâàåòñÿ êàê ñîñòàâíîå âûðàæåíèå ... Here in word "ñïèñîå", last symbol must be 'ê', someone mistaked while typed in this text My system: Debian lenny gcc version: [EMAIL PROTECTED]:~/Spectra_Project/libspectra$ LANG=C gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1) -- Summary: Mistake in Russian translation of error text "functional cast expression list treated as compound expression" Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rilium at mail dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38173
[Bug c++/36410] [4.2/4.3/4.4 Regression] ICE with transparent union
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|WAITING |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-19 00:24:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
[Bug c++/37563] [4.3/4.4 regression] Trouble calling qualified member function
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-20 14:51:40 |2008-11-19 00:21:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37563
[Bug debug/27574] [4.2/4.3 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor
--- Comment #29 from dodji at gcc dot gnu dot org 2008-11-19 00:21 --- Fixed in trunk, 4.3 and 4.2 branch. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug debug/27574] [4.2/4.3 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor
--- Comment #28 from dodji at gcc dot gnu dot org 2008-11-19 00:17 --- Subject: Bug 27574 Author: dodji Date: Wed Nov 19 00:15:52 2008 New Revision: 141984 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141984 Log: gcc/ChangeLog: 2008-11-14 Dodji Seketeli <[EMAIL PROTECTED]> PR c++/27574 * gcc/cgraph.c (cgraph_remove_node): Do not remove the body of abstract functions. It might be useful to emit debugging information. This is a patch from Ian Lance Taylor. * cgraphunit.c (cgraph_optimize): Do not cry when bodies of abstract functions are still around. They are useful to output debug info. gcc/testsuite/ChangeLog 2008-11-14 Dodji Seketeli <[EMAIL PROTECTED]> PR c++/27574 * testsuite/g++.dg/debug/dwarf2/dwarf2.exp: Backport this here from gcc-4_3-branch. * g++.dg/debug/dwarf2/local-var-in-contructor.C: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/debug/dwarf2/ branches/gcc-4_2-branch/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2.exp branches/gcc-4_2-branch/gcc/testsuite/g++.dg/debug/dwarf2/local-var-in-contructor.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/cgraph.c branches/gcc-4_2-branch/gcc/cgraphunit.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug c++/37256] [4.4 Regression] extern template / explicit instantiation broken in 4.4.0-pre
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-08-27 19:36:05 |2008-11-19 00:10:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37256
[Bug tree-optimization/36038] [4.4 Regression] miscompiled loop in perlbmk for -Os
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-11-18 23:47 --- (In reply to comment #7) > trunk/gcc/testsuite/gcc.c-torture/compile/pr36038.c Isn't this really a run testcase and not just a compile one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36038
[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
--- Comment #10 from sje at cup dot hp dot com 2008-11-18 23:25 --- If you only get slow compilation at -O2 and above then your problem is probably due to PR 37790. The original problem affected -O1 compiles as well as -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
[Bug testsuite/28870] [4.2/4.3/4.4 Regression] configuring, over-riding timeout values in testsuite
--- Comment #22 from sje at cup dot hp dot com 2008-11-18 23:21 --- Your plan sounds good to me. I am thinking that using the timeout-factor on g++.dg/torture/pr31863.C, gcc.c-torture/compile/20001226-1.c, and gcc.dg/20020425-1.c to deal with the compiler timeouts on these long compiles will help remove spurious failures from my nightly runs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug testsuite/37326] gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized "conststaticvariable" 1
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-18 23:17 --- IMHO if a target generates position independent code by default, but not flag_shlib by default, then it should define __pie__ and/or __PIE__ macro, but not __pic__ and/or __PIC__, as the latter implies both flag_pic and flag_shlib, while the former only pic code, which can't be overridden. Clearing "4.4 Regression", as per #c4 and #c5. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression]|gcc.dg/tree-ssa/ssa-store- |gcc.dg/tree-ssa/ssa-store- |ccp-3.c scan-tree-dump-times |ccp-3.c scan-tree-dump-times|optimized |optimized |"conststaticvariable" 1 |"conststaticvariable" 1 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37326
[Bug tree-optimization/38051] [4.4 Regression] Miscompilation of glibc's memcmp
--- Comment #14 from jakub at gcc dot gnu dot org 2008-11-18 23:03 --- Subject: Bug 38051 Author: jakub Date: Tue Nov 18 23:01:35 2008 New Revision: 141983 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141983 Log: PR tree-optimization/38051 * gcc.c-torture/execute/pr38051.c (buf): Remove aligned attribute. (buf2): Removed. (main): Only run on little endian targets with sizeof (long) == sizeof (void *). Use just one buffer, align the pointers at runtime. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/pr38051.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38051
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #13 from tkoenig at gcc dot gnu dot org 2008-11-18 22:44 --- Subject: Bug 38135 Author: tkoenig Date: Tue Nov 18 22:43:05 2008 New Revision: 141982 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141982 Log: 2008-11-18 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/38135 * m4/reshape.m4: Correct bounds checking when PAD is present. Treat PAD as if it were SOURCE when SOURCE is empty. * intrinsics/reshape_generic.c: Likewise. * generated/reshape_c10.c Regenerated. * generated/reshape_c16.c Regenerated. * generated/reshape_c4.c Regenerated. * generated/reshape_c8.c Regenerated. * generated/reshape_i16.c Regenerated. * generated/reshape_i4.c Regenerated. * generated/reshape_i8.c Regenerated. * generated/reshape_r10.c Regenerated. * generated/reshape_r16.c Regenerated. * generated/reshape_r4.c Regenerated. * generated/reshape_r8.c Regenerated. 2008-11-18 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/38135 * gfortran.dg/reshape_pad_1.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/reshape_pad_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/reshape_c10.c trunk/libgfortran/generated/reshape_c16.c trunk/libgfortran/generated/reshape_c4.c trunk/libgfortran/generated/reshape_c8.c trunk/libgfortran/generated/reshape_i16.c trunk/libgfortran/generated/reshape_i4.c trunk/libgfortran/generated/reshape_i8.c trunk/libgfortran/generated/reshape_r10.c trunk/libgfortran/generated/reshape_r16.c trunk/libgfortran/generated/reshape_r4.c trunk/libgfortran/generated/reshape_r8.c trunk/libgfortran/intrinsics/reshape_generic.c trunk/libgfortran/m4/reshape.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug testsuite/28870] [4.2/4.3/4.4 Regression] configuring, over-riding timeout values in testsuite
--- Comment #21 from janis at gcc dot gnu dot org 2008-11-18 22:48 --- Interesting that you should ask, I modified the patch yesterday and intend to submit it as soon as I've done some more testing. The current version adds dg-timeout, which sets the timeout for running the compiler in gcc and libstdc++ tests to a specified number of seconds, or dg-timeout-factor, which multiplies the usual timeout by the specified factor. The "usual timeout" is the value for the target board, which can be overridden by gcc_timeout or v3_timeout defined in $HOME/.dejagnurc. Let me know if you've got suggestions for improvement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug testsuite/28870] [4.2/4.3/4.4 Regression] configuring, over-riding timeout values in testsuite
--- Comment #20 from sje at cup dot hp dot com 2008-11-18 22:39 --- I see there were some patches submitted for this issue http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01098.html http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00267.html I get timeouts on my slow hppa system and would be interested in being able to extend the timeout value on some slower tests like g++.dg/torture/pr31863.C and gcc.c-torture/compile/20001226-1.c. Janice, are you still looking at this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug preprocessor/38161] [4.4 regression] #elif breaks
--- Comment #3 from neil at gcc dot gnu dot org 2008-11-18 22:18 --- The standard talks about the groups controlled by conditionals being skipped. There is no conditional controlling the #elif - it is at the top level - so I see nothing permitting its non-evaluation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161
[Bug c++/31742] warn_unused_result prints no warning for return value with destructor
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-18 22:15 --- PR 38172 has a simple example. *** This bug has been marked as a duplicate of 38172 *** -- 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=31742
[Bug c++/38172] warn_unused_result does not work with structs not containing a copy constructor
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-18 22:15 --- *** Bug 31742 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mec at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38172
[Bug c++/38172] warn_unused_result does not work with structs not containing a copy constructor
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-18 22:14 --- *** Bug 31063 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||fletcherdunn at yahoo dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38172
[Bug c++/31063] Spurious/missing warn_unused_result warnings affected by presence/absense of copy constructor
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-11-18 22:14 --- PR 38172 has the better example. *** This bug has been marked as a duplicate of 38172 *** -- 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=31063
[Bug c++/38172] New: warn_unused_result does not work with structs not containing a copy constructor
Take:
struct MyClass
{
};
typedef struct MyClass MyClass;
int Bar1( void ) __attribute__((warn_unused_result)) __attribute__((noinline));
MyClass Bar2( void ) __attribute__((warn_unused_result))
__attribute__((noinline));
int Bar1( void )
{
return 0;
}
MyClass Bar2( void )
{
}
void Foo( void )
{
Bar1(); // Warns
Bar2(); // Does not warn
}
--- CUT ---
In Foo, Bar1 and Bar2 should cause a warning, only Bar1 causes a warning with
the C++ front-end. While both cause a warning to show up with the C front-end.
--
Summary: warn_unused_result does not work with structs not
containing a copy constructor
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38172
[Bug target/37640] __sync_lock_test_and_set on PPC64 causes ICE
--- Comment #7 from bje at gcc dot gnu dot org 2008-11-18 22:09 --- Subject: Bug 37640 Author: bje Date: Tue Nov 18 22:07:58 2008 New Revision: 141980 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141980 Log: Backport from mainline: PR target/37640 2008-09-28 Andrew Pinski <[EMAIL PROTECTED]> * config/rs6000/rs6000.c (rs6000_expand_compare_and_swapqhi): Force address to a register before taking the lower part. testsuite/ * gcc.c-torture/compile/sync-3.c: New testcase to check that addresses of non zero offset works. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/sync-3.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37640
[Bug target/37362] [4.4 Regression] Bootstrap broken on mipsisa64r2-linux-gcc
--- Comment #10 from ubizjak at gmail dot com 2008-11-18 22:06 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg00920.html Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37362
[Bug target/37362] [4.4 Regression] Bootstrap broken on mipsisa64r2-linux-gcc
--- Comment #9 from uros at gcc dot gnu dot org 2008-11-18 22:01 --- Subject: Bug 37362 Author: uros Date: Tue Nov 18 22:00:12 2008 New Revision: 141978 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141978 Log: PR target/37362 * config/mips/mips.md (move_doubleword_fpr): Check that "high" is a register or zero operand in the correct mode before generating mtch1 insn or a register operand in the correct mode before generating mfch1 insn. (mtch1): Correct operand 1 predicate to reg_or_0_operand. testsuite/ChangeLog: PR target/37362 * gcc.target/mips/pr37362.c: New test. Added: trunk/gcc/testsuite/gcc.target/mips/pr37362.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37362
[Bug rtl-optimization/36758] [4.3/4.4 Regression] addition moved out of the loop when used with an argument
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-11-18 21:34 --- (In reply to comment #13) > Are things moving forward on the fwprop issue? I stoped working on it for now but I should be able to pick it up next week when I am on vaction :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #7 from steven at gcc dot gnu dot org 2008-11-18 21:34 --- P1 bug with a pending patch... maybe a reviewer could take a look at this (seemingly trivial) patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00180.html ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug rtl-optimization/36758] [4.3/4.4 Regression] addition moved out of the loop when used with an argument
--- Comment #13 from steven at gcc dot gnu dot org 2008-11-18 21:31 --- Are things moving forward on the fwprop issue? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-18 21:31:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*
--- Comment #29 from ebotcazou at gcc dot gnu dot org 2008-11-18 20:39 --- Jakub, what's the status of this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
[Bug fortran/38171] [regression] equivalence and nested modules broken
--- Comment #2 from pault at gcc dot gnu dot org 2008-11-18 20:26 --- Ah, yes. The module name check only pertains to the module being read. Instead, it should check that the equivalence members are from the same module - this might itself be use associated into the module being read. Many thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-11-18 19:41:26 |2008-11-18 20:26:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38171
[Bug c/36113] fix C enumerators
--- Comment #5 from mrs at apple dot com 2008-11-18 20:26 --- The C standard mandates that all enumeration constants have the same type, gcc violates this requirement. -- mrs at apple dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer
--- Comment #18 from jakub at gcc dot gnu dot org 2008-11-18 20:13 --- Created an attachment (id=16719) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16719&action=view) incremental patch This fixed matmul_i2.c, DR_BASE_ADDRESS wasn't in this case TYPE_RESTRICT, nor SSA_NAME, but POINTER_PLUS_EXPR, yet in the end was based on a restrict pointer. Unfortunately other matmul*.c stuff in libgfortran is still broken. I'm wondering if the strict alias checking introduced in r140781 isn't too eager when restricted pointers are used... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug fortran/38115] unneeded temp
--- Comment #2 from pault at gcc dot gnu dot org 2008-11-18 20:11 --- Another tough one, I think. Thanks Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-18 20:11:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38115
[Bug fortran/38114] unneeded temp
--- Comment #1 from pault at gcc dot gnu dot org 2008-11-18 20:09 ---
This produces the code:
s (struct array1_integer(kind=4) & b, integer(kind=4) & i, integer(kind=4) & j)
{
integer(kind=8) ubound.0;
integer(kind=8) stride.1;
integer(kind=8) offset.2;
integer(kind=8) size.3;
integer(kind=4)[0:D.1562] * b.0;
integer(kind=8) D.1562;
bit_size_type D.1563;
D.1564;
{
integer(kind=8) D.1561;
D.1561 = b->dim[0].stride;
stride.1 = D.1561 != 0 ? D.1561 : 1;
b.0 = (integer(kind=4)[0:D.1562] *) b->data;
ubound.0 = (b->dim[0].ubound - b->dim[0].lbound) + 1;
size.3 = stride.1 * NON_LVALUE_EXPR ;
offset.2 = -stride.1;
D.1562 = size.3 + -1;
D.1563 = (bit_size_type) size.3 * 32;
D.1564 = () size.3 * 4;
}
{
struct __st_parameter_dt dt_parm.4;
dt_parm.4.common.filename = &"pr38114.f90"[1]{lb: 1 sz: 1};
dt_parm.4.common.line = 4;
dt_parm.4.common.flags = 128;
dt_parm.4.common.unit = 6;
_gfortran_st_write (&dt_parm.4);
{
integer(kind=4) A.7[1];
struct array1_integer(kind=4) atmp.6;
integer(kind=8) D.1554;
integer(kind=8) D.1553;
struct array1_integer(kind=4) parm.5;
integer(kind=8) D.1551;
integer(kind=8) D.1550;
D.1550 = (integer(kind=8)) *i;
D.1551 = (integer(kind=8)) *j;
parm.5.dtype = 265;
D.1553 = offset.2;
D.1554 = stride.1;
parm.5.dim[0].lbound = 1;
parm.5.dim[0].ubound = (1 - D.1550) + D.1551;
parm.5.dim[0].stride = NON_LVALUE_EXPR ;
parm.5.data = (void *) &(*b.0)[(D.1550 + -1) * D.1554];
parm.5.offset = (1 - D.1550) * stride.1 + D.1553;
atmp.6.dtype = 265;
atmp.6.dim[0].stride = 1;
atmp.6.dim[0].lbound = 0;
atmp.6.dim[0].ubound = 0;
atmp.6.data = (void *) &A.7;
atmp.6.offset = 0;
_gfortran_minloc0_4_i4 (&atmp.6, &parm.5);
{
integer(kind=8) S.8;
S.8 = 0;
while (1)
{
if (S.8 > 0) goto L.1;
{
integer(kind=4) D.1559;
D.1559 = (*(integer(kind=4)[1] *) atmp.6.data)[S.8];
_gfortran_transfer_integer (&dt_parm.4, &D.1559, 4);
}
S.8 = S.8 + 1;
}
L.1:;
}
}
_gfortran_st_write_done (&dt_parm.4);
}
}
This does indeed produce a temporary for the result. The argument is a
descriptor with 'b' as the 'data'. The result, being rank 1, is a stack array
of size = 1. I think that this is not a missed optimisation.
For
SUBROUTINE S(b,i,j)
INTEGER, DIMENSION(:) :: b
integer res(1)
INTEGER :: i,j
res = MINLOC(b(i:j))
END SUBROUTINE S
No temporary is produced.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38114
[Bug fortran/38112] unneeded temporary
--- Comment #2 from pault at gcc dot gnu dot org 2008-11-18 20:00 --- Nice catch! Thanks Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-18 20:00:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38112
[Bug fortran/38111] unneeded temporary
--- Comment #1 from pault at gcc dot gnu dot org 2008-11-18 19:57 --- Joost, Do you know of any compilers that catch this? As you say, it is not so easy to fix. BTW you say that this another case where an unneeded temp is created. I can see your PRs after this. Which ones come before? Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-18 19:57:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38111
[Bug fortran/38152] ICE for procedure pointer assignment
--- Comment #4 from dominiq at lps dot ens dot fr 2008-11-18 19:54 --- With the patches in comment #2 and #3, compiling the test in comment #0 on i686-apple-darwin9 in 32 bit mode gives: /var/tmp//ccMx60VC.s:13:non-relocatable subtraction expression, "_procptr" minus "L001$pb" /var/tmp//ccMx60VC.s:13:symbol: "_procptr" can't be undefined in a subtraction expression Note that g95 compiles the test while ifort 11 returns: pr38152.f90(4): error #8169: The specified interface is not declared. [TEST] PROCEDURE(test), POINTER :: procptr ^ pr38152.f90(11): error #6437: A subroutine or function is calling itself recursively. [TEST] CALL bar (test) --^ pr38152.f90(12): error #8191: The procedure target must be a procedure or a procedure pointer. [TEST] procptr => test ---^ compilation aborted for pr38152.f90 (code 1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/38171] [regression] equivalence and nested modules broken
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-18 19:41 --- This is a regression that appears to be caused by r140879 | pault | 2008-10-04 22:50:00 -0700 (Sat, 04 Oct 2008) | 12 lines 2008-10-04 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37706 * module.c (load_equiv): Check the module before negating the unused flag. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Severity|major |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-11-18 19:41:26 date|| Summary|equivalence and nested |[regression] equivalence and |modules broken |nested modules broken http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38171
[Bug fortran/34871] Flavor VARIABLE vs. FUNCTION: Accepts invalid
--- Comment #3 from pault at gcc dot gnu dot org 2008-11-18 19:35 --- Yes indeed - confirmed. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-18 19:35:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34871
[Bug testsuite/37326] [4.4 Regression] gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized "conststaticvariable" 1
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-18 19:27 --- Subject: Re: [4.4 Regression] gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized "conststaticvariable" 1 > --- Comment #4 from sje at cup dot hp dot com 2008-11-18 17:11 --- > A dg-options to set -fpic would fix the test on hppa64 but I think we might > want to xfail it instead and fix it after 4.4. Technically, I don't think > this > is a 4.4 Regression since the test is new and the behaviour of the compiler > has > not changed so we might want to remove the 4.4 Regression tag from this > defect. Agree with 4.4 Regression tag. With respect to the test, I don't care which fix is selected. The compiler behaves as expected, so I believe the PR can be closed when the test is fixed. The hppa64 target has always set flag_pic. The overloading of flag_shlib on the -fpic/-fPIC options was introduced here: 2003-06-03 Jakub Jelinek <[EMAIL PROTECTED]> * configure.in (HAVE_LD_PIE): Check for ld -pie. * config.in: Rebuilt. * configure: Rebuilt. * toplev.c (flag_pie, flag_shlib): New variables. (f_options): Add -fpie and -fPIE. (parse_options_and_default_flags): Set flag_pic if -fpie/-fPIE. Set flag_shlib if flag_pic and not -fpie/-fPIE. ... As you noted, flag_shlib affects inlining, so we don't want this enabled by default. Supplying -fpic on the command line sets flag_shlib and I believe most people use it when building shared libraries on hppa64. Thus, there's no major problem with with setting flag_pic in override options. The documentation indicates that -fpic should be specified to generate position-independent code (PIC) suitable for use in a shared library. The documentation also indicates that the code generated for the IBM RS/6000 is always position-independent. However, this is not mentioned for ia64 or hppa64. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37326
[Bug ada/38131] [4.4 regression] ACATS cc70a01 and cxa4016 segv on exception
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-11-18 18:48 --- *** This bug has been marked as a duplicate of 37610 *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38131
[Bug target/37362] [4.4 Regression] Bootstrap broken on mipsisa64r2-linux-gcc
--- Comment #8 from g0dsowncountry at yahoo dot com 2008-11-18 18:52 --- With Uros's patch in Comment #7, GCC Builds Fine..! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37362
[Bug target/37610] [4.4 Regression] FAIL: g++.dg/eh/pr29166.C execution test
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-11-18 18:51 --- Likewise on SPARC. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-18 18:51:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37610
[Bug c++/15745] exception specification incorrectly changes the type of the exception thrown
--- Comment #6 from jason at gcc dot gnu dot org 2008-11-18 18:50 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15745
[Bug target/37610] [4.4 Regression] FAIL: g++.dg/eh/pr29166.C execution test
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-11-18 18:48 --- *** Bug 38131 has been marked as a duplicate of this bug. *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||laurent at guerby dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37610
[Bug libstdc++/25191] exception_defines.h #defines try/catch
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-06-02 11:48:51 |2008-11-18 18:45:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer
--- Comment #17 from jakub at gcc dot gnu dot org 2008-11-18 18:26 --- Created an attachment (id=16718) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16718&action=view) gcc44-pr37742.patch Testcase #c7 can be fixed by this patch. Without it, alias sets in presence of restricted pointers act weirdly - if it is called on an INDIRECT_REF with a SSA_NAME, it will return one alias set, but if a new INDIRECT_REF is constructed from the SSA_NAME's var decl, then a different alias set is returned. Unfortunately this patch breaks bootstrap in matmul_i2.c, ICE in vectorizable_store. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug fortran/38171] New: equivalence and nested modules broken
The following code worked for version 4.3 and 4.4 as of 9-28: MODULE HDF5 USE H5GLOBAL END MODULE HDF5 MODULE H5GLOBAL IMPLICIT NONE INTEGER :: H5P_flags INTEGER :: H5P_DEFAULT_F EQUIVALENCE(H5P_flags, H5P_DEFAULT_F) END MODULE H5GLOBAL PROGRAM fortranlibtest USE HDF5 IMPLICIT NONE INTEGER :: ii ii = H5P_DEFAULT_F END PROGRAM fortranlibtest The current version of 4.4 and 4.3 (Nov. 11) fails to compile the code with the error: gfortran43 H5f90global.o HDF5.o fortranlib_test.o -o test fortranlib_test.o(.text+0x19): In function `MAIN__': : undefined reference to `__h5global_MOD_h5p_default_f' collect2: ld returned 1 exit status *** Error code 1 4.2 compiles the code without a problem. NOTE: (1) If I remove the line EQUIVALENCE(H5P_flags, H5P_DEFAULT_F) it compiles fine. (2) If I move the contents of H5GLOBAL into the HDF5 module i.e. MODULE HDF5 IMPLICIT NONE INTEGER :: H5P_flags INTEGER :: H5P_DEFAULT_F EQUIVALENCE(H5P_flags, H5P_DEFAULT_F) END MODULE HDF5 it compiles fine. -- Summary: equivalence and nested modules broken Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brtnfld at hdfgroup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38171
[Bug c++/37962] [4.4 regression] ICE with (auto*) casts
--- Comment #9 from jason at gcc dot gnu dot org 2008-11-18 18:14 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37962
[Bug tree-optimization/38051] [4.4 Regression] Miscompilation of glibc's memcmp
--- Comment #13 from jakub at gcc dot gnu dot org 2008-11-18 18:19 --- See http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00905.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38051
[Bug c++/37962] [4.4 regression] ICE with (auto*) casts
--- Comment #8 from jason at gcc dot gnu dot org 2008-11-18 18:12 --- Subject: Bug 37962 Author: jason Date: Tue Nov 18 18:11:32 2008 New Revision: 141970 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141970 Log: PR c++/37962 cp/ * parser.c (cp_parser_type_id): Complain about auto. * decl.c (grokdeclarator): Complain about parameters and conversion functions declared with auto. * call.c (standard_conversion): Use CLASS_TYPE_P instead of MAYBE_CLASS_TYPE_P. * cp-tree.h (TYPE_NON_AGGREGATE_CLASS): Likewise. testsuite/ * g++.dg/cpp0x/auto[38].C: Adjust expected errors. * g++.dg/cpp0x/auto9.C: New test. * g++.dg/cpp0x/auto10.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto10.C trunk/gcc/testsuite/g++.dg/cpp0x/auto9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/auto3.C trunk/gcc/testsuite/g++.dg/cpp0x/auto8.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37962
[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585
--- Comment #6 from cfairles at gcc dot gnu dot org 2008-11-18 17:53
---
Even more reduced:
template class W>
struct A{};
template
struct B{};
int main() { A a; }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
[Bug tree-optimization/38051] [4.4 Regression] Miscompilation of glibc's memcmp
--- Comment #12 from sje at cup dot hp dot com 2008-11-18 17:31 --- The new test is also failing on IA64 HP-UX and PA HP-UX (32 and 64 bits). It is not failing on IA64 Linux. Could the test have a big-endian/little-endian issue? -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38051
[Bug testsuite/37326] [4.4 Regression] gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized "conststaticvariable" 1
--- Comment #4 from sje at cup dot hp dot com 2008-11-18 17:11 --- A dg-options to set -fpic would fix the test on hppa64 but I think we might want to xfail it instead and fix it after 4.4. Technically, I don't think this is a 4.4 Regression since the test is new and the behaviour of the compiler has not changed so we might want to remove the 4.4 Regression tag from this defect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37326
[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585
--- Comment #5 from dodji at gcc dot gnu dot org 2008-11-18 16:52 --- With the reduced test case, the error message on svn trunk is now: 8: internal compiler error: in dependent_type_p, at cp/pt.c:15922 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585
--- Comment #4 from dodji at gcc dot gnu dot org 2008-11-18 16:49 ---
Here is a reduced testcase:
1 template class W>
struct A {};
2
3 template struct B {};
4
5 int
6 main ()
7 {
8A a;
9return 0;
10 }
11
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
CC||dodji at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
[Bug middle-end/38133] xgcc: Internal error: Killed (program cc1) by compiling gcc 4.3.2
--- Comment #3 from jan at jans-seite dot de 2008-11-18 16:24 ---
By compile doxygen, came this error:
g++ -c -pipe -fno-exceptions -fno-rtti -Wall -W -fno-exceptions -O2 -I../qtools
-I../libpng -I../libmd5 -o ../objects/doxygen.o doxygen.cpp
{standard input}: Assembler messages:
{standard input}:17108: Warning: partial line at end of file ignored
{standard input}:16898: Error: undefined local label `.L2645'
{standard input}:16922: Error: undefined local label `.L2645'
{standard input}:16944: Error: undefined local label `.L2645'
{standard input}:16967: Error: undefined local label `.L2645'
{standard input}:16979: Error: undefined local label `.L2645'
{standard input}:16995: Error: undefined local label `.L2645'
{standard input}:17007: Error: undefined local label `.L2645'
{standard input}:17033: Error: undefined local label `.L2645'
{standard input}:17044: Error: undefined local label `.L2645'
{standard input}:17061: Error: undefined local label `.L2645'
{standard input}:17073: Error: undefined local label `.L2645'
{standard input}:17085: Error: undefined local label `.L2645'
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See for instructions.
make[2]: *** [../objects/doxygen.o] Error 1
make[2]: Leaving directory `/home/Download/Xorg/doxygen-1.5.7.1/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/Download/Xorg/doxygen-1.5.7.1/src'
make: *** [all] Error 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38133
[Bug middle-end/36902] Array bound warning with dead code after optimization
--- Comment #33 from manu at gcc dot gnu dot org 2008-11-18 16:05 --- (In reply to comment #32) > (In reply to comment #31) > > I submitted the patch long ago. We are in regressions-only mode. This is > > not a > > regression. Not sure what else you want me to do. > > I'm not sure either ;) Maybe you could just work on the complete solution (per > your posted scheme), fixing also the other known issues in this area, and > submit it again for mainline after we branched... Or maybe I can just wait until this patch is reviewed, so I can get the official answer to my approach before wasting my free time foolishly in a futile endeavour. ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
[Bug boehm-gc/38162] [4.4 Regression] FAIL: gctest
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-18 15:59 --- If you manage to reproduce it again, please reopen. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38162
[Bug middle-end/36902] Array bound warning with dead code after optimization
--- Comment #32 from paolo dot carlini at oracle dot com 2008-11-18 15:47 --- (In reply to comment #31) > I submitted the patch long ago. We are in regressions-only mode. This is not a > regression. Not sure what else you want me to do. I'm not sure either ;) Maybe you could just work on the complete solution (per your posted scheme), fixing also the other known issues in this area, and submit it again for mainline after we branched... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
[Bug middle-end/36902] Array bound warning with dead code after optimization
--- Comment #31 from manu at gcc dot gnu dot org 2008-11-18 15:43 --- (In reply to comment #30) > Thanks Manuel. I'm not sure that this is technically a regression, but in any > case I consider it a serious problem and really hope we can have a fix for > 4.4.0. I submitted the patch long ago. We are in regressions-only mode. This is not a regression. Not sure what else you want me to do. (It doesn't fix PR37921, though. I haven't tested PR35392.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
[Bug ada/37543] Assembler error during compilation
--- Comment #6 from anhvofrcaus at gmail dot com 2008-11-18 15:32 --- Subject: Re: Assembler error during compilation The problem does not exist any longer starting with gcc-4.4.0-20081031. Thus, it is considered fixed. On Mon, Nov 17, 2008 at 11:40 AM, sam at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #5 from sam at gcc dot gnu dot org 2008-11-17 19:40 --- > Please open a separate bug if you still experience build problems. This one > (problem with generated assembler when compiling Ada code) should be closed as > it has been resolved by yourself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37543
[Bug middle-end/36902] Array bound warning with dead code after optimization
--- Comment #30 from paolo dot carlini at oracle dot com 2008-11-18 15:25 --- Thanks Manuel. I'm not sure that this is technically a regression, but in any case I consider it a serious problem and really hope we can have a fix for 4.4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
[Bug middle-end/36902] Array bound warning with dead code after optimization
--- Comment #29 from manu at gcc dot gnu dot org 2008-11-18 15:21 --- There is a patch here: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01117.html -- manu at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2008-07-22 21:18:28 |2008-11-18 15:21:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
[Bug libgcj/16923] -D* Options passed to JNI_CreateJavaVM are ignored
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2008-11-18 15:01 --- This test case is failing on i686-apple-darwin9 at -m64 (but not -m32). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16923
[Bug target/37610] [4.4 Regression] FAIL: g++.dg/eh/pr29166.C execution test
--- Comment #6 from danglin at gcc dot gnu dot org 2008-11-18 14:56 --- The binutils patch is here: http://sourceware.org/ml/binutils/2008-11/msg00200.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37610
[Bug middle-end/36902] Array bound warning with dead code after optimization
--- Comment #28 from hjl dot tools at gmail dot com 2008-11-18 14:42 --- (In reply to comment #27) > Isn't this a regression? > The warning is new. But the same code won't compile with -Wall while gcc 4.1 has no problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
[Bug boehm-gc/38162] [4.4 Regression] FAIL: gctest
--- Comment #2 from hjl dot tools at gmail dot com 2008-11-18 14:39 --- It is gone now. It may be a timing issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38162
[Bug c++/38124] gcc fails to compile with Internal error, aborting at dw2gencfi.c line 1267 errror
--- Comment #2 from kamaraju at gmail dot com 2008-11-18 14:28 --- I filed this bug against binutils as http://sourceware.org/bugzilla/show_bug.cgi?id=7032 . The conclusion there is that it is a compiler bug (since the abort is an unhandled case in a switch). Could some one take a second look at this again? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38124
[Bug target/37610] [4.4 Regression] FAIL: g++.dg/eh/pr29166.C execution test
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-18 14:06 --- Subject: Re: [4.4 Regression] FAIL: g++.dg/eh/pr29166.C execution test > Can you submit the trivial fix (replace 3 times (delta) with (scaled) in > dw2gencfi.c to binutils? On the GCC side we'll need to write a configury test > which will fail if this bug is detected and the target has code alignment > factor bigger than 1. Will submit the dw2gencfi.c fix. Tested last night. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37610
[Bug c++/37105] stackalign failures
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-11-18 14:05 --- Dominique, Yes this is a duplicate of PR37012. We had numerous stack-align failures originally but are now done to just these c++ failures. Note that these failures only occur with -O3 -g but not -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37105
[Bug tree-optimization/38051] [4.4 Regression] Miscompilation of glibc's memcmp
--- Comment #11 from dominiq at lps dot ens dot fr 2008-11-18 13:38 --- The test fails on powerpc-apple-darwin9 (revision 141945, 32 and 64 bit modes): FAIL: gcc.c-torture/execute/pr38051.c execution, -O0 FAIL: gcc.c-torture/execute/pr38051.c execution, -O1 FAIL: gcc.c-torture/execute/pr38051.c execution, -O2 FAIL: gcc.c-torture/execute/pr38051.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/pr38051.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/pr38051.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/pr38051.c execution, -O3 -g FAIL: gcc.c-torture/execute/pr38051.c execution, -Os -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38051
[Bug target/29987] libgomp.c++/ctor-9.C failure
--- Comment #8 from ro at techfak dot uni-bielefeld dot de 2008-11-18 13:32 --- Subject: Re: libgomp.c++/ctor-9.C failure ro at techfak dot uni-bielefeld dot de writes: > > Does i?86-sun-solaris* as have the same bug or not? > > I'll have to check this. Currently, one cannot use Sun as for x86_64, so > the default config will use gas instead. I'll try the non-multilib config > and see if it is affected as well. Bootstrap on Solaris 10/x86 with Sun as already breaks when building the stage1 libgcc now: Assembler: libgcov.c "/var/tmp//ccRimvP4.s", line 116 : Syntax error Near line: "repnz scasb" and many more. I have no idea what as complains about: a quick strings on the binary reveals that it seems to support the instruction, and the x86 Assembly Language Reference Manual at http://docs.sun.com/app/docs/doc/817-5477/enmzx?a=view suggests likewise in the `String Instructions' table (table 3-8). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29987
[Bug fortran/36463] [4.4 regression] gfc_get_default_type(): Bad symbol
--- Comment #17 from mikael at gcc dot gnu dot org 2008-11-18 13:23 --- (In reply to comment #16) > Btw it also makes comment #12 compile, while the resulting executable produces > a segfault. But I guess this is due to the weird things which this program > does(?). Not really. The problems comes from the assignment to my_message, which is allocatable and should be (implicitly) reallocated. This is PR35810. Allocating my_message separately fixes the segfault, but I still get a valgrind error. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug target/29987] libgomp.c++/ctor-9.C failure
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2008-11-18 13:16 --- Subject: Re: libgomp.c++/ctor-9.C failure jakub at gcc dot gnu dot org writes: > Anyway, the following patch fixes this in a cross from x86_64-linux to > sparc*-sun-solaris10. Can somebody please bootstrap/regtest it? will do, thanks. > Does i?86-sun-solaris* as have the same bug or not? I'll have to check this. Currently, one cannot use Sun as for x86_64, so the default config will use gas instead. I'll try the non-multilib config and see if it is affected as well. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29987
[Bug libfortran/32784] [win32] Using 'CONOUT$', 'CONIN$', or 'CONERR$' as assigned file generates Fortran runtime error: Bad file descriptor
--- Comment #30 from steve dot chapel at a2pg dot com 2008-11-18 12:59 --- Although bug 38122 causes NONMEM to not run as is, all it takes is a simple one-line change to get it to run normally on Linux. This bug, on the other hand, makes it effectively impossible to run NONMEM normally on Windows, that is, sending output to the console output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
[Bug c++/35405] [4.2/4.3/4.4 Regression] Internal compiler error
--- Comment #7 from dodji at gcc dot gnu dot org 2008-11-18 12:57 --- Okay, patch updated and sent to http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00873.html. Fingers crossed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35405
[Bug c++/35405] [4.2/4.3/4.4 Regression] Internal compiler error
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-02-29 12:48:25 |2008-11-18 12:56:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35405
[Bug boehm-gc/38162] [4.4 Regression] FAIL: gctest
--- Comment #1 from jakub at gcc dot gnu dot org 2008-11-18 12:51 --- Is it reproduceable? I've never seen it, and between 141923 and 141928 revisions there is certainly nothing that might affect it (on trunk only mips and fortran changes). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38162
[Bug target/38130] [4.4 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32
--- Comment #7 from jakub at gcc dot gnu dot org 2008-11-18 12:37 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130
[Bug target/38130] [4.4 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-18 12:34 ---
Subject: Bug 38130
Author: jakub
Date: Tue Nov 18 12:33:38 2008
New Revision: 141965
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141965
Log:
PR target/38130
* config/i386/i386.md (allocate_stack_worker_32,
allocate_stack_worker_64): Don't use match_dup between input and
output operand.
(allocate_stack): Adjust gen_stack_worker_{32,64} caller.
* config/i386/i386.c (ix86_expand_prologue): Likewise.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130
[Bug target/29987] libgomp.c++/ctor-9.C failure
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-18 12:31 --- Created an attachment (id=16717) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16717&action=view) gcc44-pr29987.patch Anyway, the following patch fixes this in a cross from x86_64-linux to sparc*-sun-solaris10. Can somebody please bootstrap/regtest it? Does i?86-sun-solaris* as have the same bug or not? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29987
[Bug ada/38127] [4.4 Regression] ACATS cd1c04e fails on sparc, hppa
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-11-18 12:11 --- Subject: Bug 38127 Author: ebotcazou Date: Tue Nov 18 12:10:18 2008 New Revision: 141964 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141964 Log: PR ada/38127 * gcc-interface/decl.c (make_type_from_size) : Propagate the name. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38127
[Bug tree-optimization/38169] Wrong string constant optimizing
--- Comment #4 from holger dot hopp at sap dot com 2008-11-18 11:01 --- Indeed, the newest trunk rev. fixed that issue. Great! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38169
[Bug middle-end/36902] Array bound warning with dead code after optimization
--- Comment #27 from paolo dot carlini at oracle dot com 2008-11-18 10:16 --- Isn't this a regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
[Bug fortran/36526] pointer in pure function
--- Comment #5 from pault at gcc dot gnu dot org 2008-11-18 10:01 --- (In reply to comment #4) > this bug seems fixed in 4.4.0, should it be closed? > Joost, I forgot the PR and missed your prompt - I'll apply it to 4.3 and close it. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36526
[Bug target/38118] gcc emits non-TLS data as TLS on Solaris 11/SPARC
--- Comment #4 from jakub at gcc dot gnu dot org 2008-11-18 09:39 --- If you don't want to call it a bug, call it at least a misfeature. Given that Solaris as supports .tls_common directive, having .common directive behave differently depending on whether current section is .tbss (apparently comparison by name, flags don't matter and when in .tdata .common behaves normally) or not is very surprising. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38118
[Bug c++/37105] stackalign failures
--- Comment #1 from dominiq at lps dot ens dot fr 2008-11-18 09:26 --- This is probably a duplicate of pr37012. Still here at revision 141951. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37105
[Bug target/37610] [4.4 Regression] FAIL: g++.dg/eh/pr29166.C execution test
--- Comment #4 from jakub at gcc dot gnu dot org 2008-11-18 09:19 --- On the GCC configury side (and in gas testsuite too) it is just a matter of: cat > conftest.s
[Bug target/37610] [4.4 Regression] FAIL: g++.dg/eh/pr29166.C execution test
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-18 09:03 ---
libunwind also scales all of DW_CFA_advance_loc{,1,2,4} by code alignment
factor and IMHO it matches the standard wording too:
DW_CFA_advance_loc
The DW_CFA_advance instruction takes a single operand (encoded with the
opcode) that represents a constant delta. The required action is to create a
new table row with a location value that is computed by taking the current
entry's location value and adding the value of delta * code_alignment_factor.
All other values in the new row are initially identical to the current row.
DW_CFA_advance_loc1
The DW_CFA_advance_loc1 instruction takes a single ubyte operand that
represents a constant delta. This instruction is identical to
DW_CFA_advance_loc except for the encoding and size of the delta operand.
Can you submit the trivial fix (replace 3 times (delta) with (scaled) in
dw2gencfi.c to binutils? On the GCC side we'll need to write a configury test
which will fail if this bug is detected and the target has code alignment
factor bigger than 1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37610
[Bug ada/38131] [4.4 regression] ACATS cc70a01 and cxa4016 segv on exception
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-11-18 08:31 --- OK, if you tell me how to log in on the SPARC/Linux box as well as where I can find the already built compiler, I'll look into the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38131
[Bug target/38118] gcc emits non-TLS data as TLS on Solaris 11/SPARC
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-11-18 08:24 --- > I'm not completely sure this is a bug in Sun as. If you consider the > assembler code for my testcase produced by gcc: > > .global tsd > .section".tbss",#alloc,#write,#tls > .align 4 > .type tsd, #tls_object > .size tsd, 4 > tsd: > .skip 4 > .common non_tsd,4,4 > > versus what Studio 12 cc produces: > > .section".bss",#alloc,#write > .common non_tsd,4,4 > .section".tbss",#alloc,#write,#tls > .common tsd,4,4 > > you see that gcc lacks the section switching between non_tsd and tsd. OK, this makes sense, but I'd suggest discussing that under PR 29987. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38118
[Bug target/37362] [4.4 Regression] Bootstrap broken on mipsisa64r2-linux-gcc
--- Comment #7 from ubizjak at gmail dot com 2008-11-18 08:09 --- Created an attachment (id=16716) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16716&action=view) Patch with a testcase This patch solves all issues with mthc1 and mfhc1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37362
