[Bug c++/49136] New: [C++0x][constexpr] Incorrect constexpr c'tor evaluation with bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49136
Summary: [C++0x][constexpr] Incorrect constexpr c'tor
evaluation with bitfields
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
gcc 4.7.0 20110521 (experimental) in C++0x mode fires a static assertion at the
line marked with #:
//
struct day {
unsigned d : 5;
unsigned n : 3;
constexpr explicit day(int dd) : d(dd), n(7) {}
};
struct date {
int d;
constexpr date(day dd) : d((dd.n != 7) ? 7 : dd.d) {}
};
constexpr day d(0);
constexpr date dt(d);
static_assert(dt.d == 0, "Error"); // #
//
Further testing shows, that dt.d has the value 7 instead of 0. The error only
occurs, if the day object d is defined as constexpr variable. E.g. given the
above shown types day and date the following program
//---
extern "C" int printf(const char*, ...);
int main()
{
constexpr day d(0);
date dt(d);
printf("%d\n", d.d); // Prints 0
printf("%d", dt.d); // Prints 7
}
//---
still produces the calculation error. If we remove the constexpr specifier of
the local object d (or if we replace it by a const specifier), the calculation
is correct, the output is
0
0
as expected. Interestingly, the internal value of the object d itself is always
correct. The defect seems to happen if a constexpr day object is used in
another constexpr constructor. It seems that the type date itself is required
as well, I could not replace the constexpr date constructor call by a constexpr
function like this
constexpr int date_func(day dd) { return (dd.n != 7) ? 7 : dd.d; }
to produce the same error. While trying to simplify the test case I found that
the struct day must contain at least two such bitfields.
Let me add that this problem occurred while trying to "constexpressify" an
existing date library of Howard Hinnant, so this is not just a theoretical
case.
[Bug tree-optimization/49121] [4.7 Regression] FAIL: gcc.dg/tree-ssa/ivopt_infer_2.c scan-tree-dump-times ivopts "Replacing" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49121 --- Comment #4 from vries at gcc dot gnu.org 2011-05-24 08:09:03 UTC --- Author: vries Date: Tue May 24 08:09:00 2011 New Revision: 174103 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174103 Log: 2011-05-24 Tom de Vries PR tree-optimization/49121 * gcc.dg/tree-ssa/ivopt_infer_2.c: Adapt test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_infer_2.c
[Bug target/49133] [4.6/4.7 Regression] modification of aliased __m128d miscompiles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49133
Uros Bizjak changed:
What|Removed |Added
Target||x86-*-*
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.05.24 08:22:04
AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com
|gnu.org |
Target Milestone|--- |4.6.1
Summary|[4.6 Regression]|[4.6/4.7 Regression]
|modification of aliased |modification of aliased
|__m128d miscompiles |__m128d miscompiles
Ever Confirmed|0 |1
--- Comment #1 from Uros Bizjak 2011-05-24 08:22:04
UTC ---
Confirmed, proposed patch to sse2_loadhpd:
Index: sse.md
===
--- sse.md(revision 174102)
+++ sse.md(working copy)
@@ -4284,7 +4284,7 @@
vmovhpd\t{%2, %1, %0|%0, %1, %2}
unpcklpd\t{%2, %0|%0, %2}
vunpcklpd\t{%2, %1, %0|%0, %1, %2}
- shufpd\t{$1, %1, %0|%0, %1, 1}
+ shufpd\t{$0, %1, %0|%0, %1, 0}
#
#
#"
[Bug tree-optimization/49121] [4.7 Regression] FAIL: gcc.dg/tree-ssa/ivopt_infer_2.c scan-tree-dump-times ivopts "Replacing" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49121 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from vries at gcc dot gnu.org 2011-05-24 08:15:49 UTC --- Testcase has been adapted. Marking fixed.
[Bug c++/10200] Weird clash with same names in different scopes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200 Jay Foad changed: What|Removed |Added CC||jay.foad at gmail dot com --- Comment #16 from Jay Foad 2011-05-24 09:17:21 UTC --- > This is almost the same as the case discussed in DR 141. > > In particular, we must determine whether "node.foo <" is the start of a > template, or not. [basic.lookup.classref] says that we look in the class of > the > object expression, i.e., X::node. However, that's a dependent type. So, > we > don't actually try to lookup there. Thus, we then go on to do lookup in the > scope of the containing postfix-expression, which finds the global template > function. DR 141 suggests that we should not do the second lookup. However, > this DR is still in the "open" state; the committee has taken no action as of > yet. DR 141 was resolved in CD1: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#141 It seems like we should still do the second lookup.
[Bug fortran/48955] [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48955 --- Comment #11 from paul.richard.thomas at gmail dot com 2011-05-24 09:43:32 UTC --- Dear Thomas, > With your patch, what is the difference between GFC_CAN_REVERSE > and GFC_REVERSE_NOT_SET? Perhaps GFC_REVERSE_ENABLED and GFC_REVERSE_INHIBITED would be better. > > And why do you initialize loop.reverse close to line 6052 and > close to line 6070 of trans-expr.c? Is something in between > changing this? Pure cock-up, I think. Clearly we only need one instance of this. However, when I monitored the beviour of the code in dependency.c, I noticed that the reversing was disabled and so added the second block, whilst failing to notice the first. Either I screwed up or your last question is pertinent. I will look this afternoon. Many thanks Paul PS I will post the patch this afternoon.
[Bug target/49133] [4.6/4.7 Regression] modification of aliased __m128d miscompiles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49133
--- Comment #2 from Matthias Kretz 2011-05-24 10:16:41
UTC ---
I applied the patch to the latest 4.6 snapshot. I confirm that it fixes the
bug. Also, there are no regressions in my testsuite.
Just for confirmation, the patched sse.md looks like this for me now (starting
from line 4952):
(define_insn "sse2_loadhpd"
[(set (match_operand:V2DF 0 "nonimmediate_operand" "=x,x,x,o,o,o")
(vec_concat:V2DF
(vec_select:DF
(match_operand:V2DF 1 "nonimmediate_operand" " 0,0,x,0,0,0")
(parallel [(const_int 0)]))
(match_operand:DF 2 "nonimmediate_operand" " m,x,0,x,*f,r")))]
"TARGET_SSE2 && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
"@
movhpd\t{%2, %0|%0, %2}
unpcklpd\t{%2, %0|%0, %2}
shufpd\t{$0, %1, %0|%0, %1, 0}
#
Question, why not use unpcklpd instead of shufpd $0? On older CPUs unpcklpd
should be slightly faster than shufpd.
[Bug tree-optimization/49135] ICE in gcc.c-torture/execute/920302-1.c on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49135 --- Comment #1 from Richard Guenther 2011-05-24 10:17:47 UTC --- There is no assert around in that routine and the file doesn't call operand_equal_p anywhere ... so?
[Bug debug/49130] discrepancies between DW_AT_name and demangler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49130 --- Comment #1 from Richard Guenther 2011-05-24 10:14:57 UTC --- I think it would be nicer if there were a DW_AT_mangled_name we could use instead because it's shorter. This also would avoid inconsistencies.
[Bug c++/49136] [C++0x][constexpr] Incorrect constexpr c'tor evaluation with bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49136 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.24 10:03:34 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2011-05-24 10:03:34 UTC --- The problem is that fold optimizes dd.n != 7 comparison into (bit_field_ref & 224) != 224 - see optimize_bit_field_compare - and cxx_eval_bit_field_ref doesn't expect a bit_field_ref which covers more than one bit field. One possible fix would be to check also the size in cxx_eval_bit_field_ref and or in at the right position all the bit fields in the range, another would be make sure such folding doesn't happen during constexpr processing.
[Bug other/49137] New: build fails when gmp/mpfr already installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49137
Summary: build fails when gmp/mpfr already installed
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sl...@blue.cft.edu.pl
When gmp/mpfr are already installed _and_ their sources have been unpacked into
the gcc source directory, building mpfr fails due to gmp.h not found.
I would expect such a scenario when building and using the supplied gmp/mpfr
sources is preferred over the installed (system) libraries, which typically are
outdated (but cannot be uninstalled due to dependencies).
FreeBSD 8.1 i386
the configure command line was
../gcc-4.5.3/configure --prefix=${HOME}/opt/gcc/4.5.3
--enable-languages=c,c++,fortran
[Bug target/49133] [4.6/4.7 Regression] modification of aliased __m128d miscompiles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49133 --- Comment #4 from Uros Bizjak 2011-05-24 10:53:10 UTC --- (In reply to comment #3) > > I applied the patch to the latest 4.6 snapshot. I confirm that it fixes the > > bug. Also, there are no regressions in my testsuite. > OTOH, it looks that this alternative is wrong entirely. Unmodified operand can > only be passed in lower half (operand 1 in the pattern above). GCC will then > generate unpcklpd, as suggested. Forgot to say, that unpcklpd will be generated with removed referred alternative.
[Bug c++/49136] [C++0x][constexpr] Incorrect constexpr c'tor evaluation with bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49136
--- Comment #2 from Jakub Jelinek 2011-05-24
10:49:09 UTC ---
Another testcase, this one ICEs:
// PR c++/49136
// { dg-do compile }
// { dg-options "-std=c++0x" }
struct S
{
unsigned : 1; unsigned s : 27; unsigned : 4;
constexpr S (unsigned int x) : s(x) {}
};
struct T
{
unsigned int t;
constexpr T (S s) : t(s.s != 77 ? 0 : s.s) {}
};
constexpr S s (77);
constexpr T t (s);
static_assert (t.t == 77, "Error");
[Bug target/49133] [4.6/4.7 Regression] modification of aliased __m128d miscompiles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49133
--- Comment #3 from Uros Bizjak 2011-05-24 10:51:25
UTC ---
(In reply to comment #2)
> I applied the patch to the latest 4.6 snapshot. I confirm that it fixes the
> bug. Also, there are no regressions in my testsuite.
>
> Just for confirmation, the patched sse.md looks like this for me now (starting
> from line 4952):
> (define_insn "sse2_loadhpd"
> [(set (match_operand:V2DF 0 "nonimmediate_operand" "=x,x,x,o,o,o")
> (vec_concat:V2DF
> (vec_select:DF
> (match_operand:V2DF 1 "nonimmediate_operand" " 0,0,x,0,0,0")
> (parallel [(const_int 0)]))
> (match_operand:DF 2 "nonimmediate_operand" " m,x,0,x,*f,r")))]
> "TARGET_SSE2 && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
> "@
>movhpd\t{%2, %0|%0, %2}
>unpcklpd\t{%2, %0|%0, %2}
>shufpd\t{$0, %1, %0|%0, %1, 0}
>#
>
> Question, why not use unpcklpd instead of shufpd $0? On older CPUs unpcklpd
> should be slightly faster than shufpd.
OTOH, it looks that this alternative is wrong entirely. Unmodified operand can
only be passed in lower half (operand 1 in the pattern above). GCC will then
generate unpcklpd, as suggested.
[Bug lto/48947] 4.6.0 fails to link ffmpeg with LTO and gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48947 --- Comment #9 from Vadim Markovtsev 2011-05-24 11:23:43 UTC --- Here they are
[Bug lto/48947] 4.6.0 fails to link ffmpeg with LTO and gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48947 --- Comment #8 from Vadim Markovtsev 2011-05-24 11:23:22 UTC --- Created attachment 24339 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24339 Objects which cause the error (2) Last 2 (of 4) binaries
[Bug lto/48947] 4.6.0 fails to link ffmpeg with LTO and gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48947 --- Comment #7 from Vadim Markovtsev 2011-05-24 11:22:34 UTC --- Created attachment 24338 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24338 Objects which cause the error First 2 (of 4) binaries
[Bug objc/47682] unused-but-set-variabled warning when using fast enumeration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47682 Nicola Pero changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #3 from Nicola Pero 2011-05-24 11:56:54 UTC --- 3 months have passed with no reply; assuming resolved. It certainly works for me. :-) Thanks
[Bug fortran/49138] New: Add /usr/include/fortran/{,gcc-} to the file/module search path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138
Summary: Add /usr/include/fortran/{,gcc-} to the
file/module search path
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
There is a serious lack of a default-searched location for Fortran include
files - and in particular for Fortran .mod files. The latter is particularly
important as different compilers/different versions have different .mod files.
Currently, Linux distributions usually either do not ship .mod files or they
ship them simply in /usr/include.
The /usr/{local/,}include/fortran/ directory should be used (and searched) for
Fortran INCLUDE / #include files.
Module files (or arch-dependent include files) should be searched for in an
compiler/architecture-dependent subdirectory, which can be queried with
-print-mod-dir-suffix:
gfortran $(FFLAGS) -print-mod-dir-suffix
(Note: -m... flags in the $(FFLAGS) might change the result.)
Thus, the search order is:
LOCAL_INCLUDE_DIR/fortran/$(gfortran -print-mod-dir-suffix) # .mod files
LOCAL_INCLUDE_DIR/fortran # include files
LOCAL_INCLUDE_DIR # For backward compatibility
followed by the same order for SYSTEM_INCLUDE_DIR and then STANDARD_INCLUDE_DIR
The result of -print-mod-dir-suffix should be
gcc-/lib{,}
The reason for "lib{,}" is to allow for architecture-defined directories;
using directly the target (e.g. x86_64-unknown-linux-gnu) instead of the lib
won't work as for x86_64 one can have -m32 and -m64 but target remains the
same, while for i686 and x86_64 -m32, the target changes but the produced
binaries are the same. Additionally, for PowerPC, the default can be 32 or 64
bit.
For the FHS standard tacking, see:
http://bugs.linux-foundation.org/show_bug.cgi?id=757
(The proposal was discussed with Jakub, Richard and Matthias.)
[Bug regression/49139] New: always_inline attribute inconsistencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139
Summary: always_inline attribute inconsistencies
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ch...@gcc.gnu.org
Created attachment 24340
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24340
fails even without -Winline
Hello,
I'm wondering whether or not the always_inline in PIC must prevails over the
general preemption rules. Apparently not accordingly to the default behavior
for the compilation in -O2 -fpic of
__attribute((always_inline)) void bar() { }
void test(void)
{
bar();
}
foo.c:1:35: sorry, unimplemented: inlining failed in call to 'bar': function
body can be overwriten at linktime
foo.c:5:6: sorry, unimplemented: called from here
First (1): inlining cannot be done, So without -Werror, this should be a
warning, not a "sorry error".
Or (2): The function could be inlined, despite the preemption rule. But it is
just not yet implemented. In this case.
In case of (1), I'm attaching here a C++ reduced piece of code that triggers
this error even without using -Winline, making the error quite unpredictable,
since this depends of the presence of another inlined call (here, "Alloc"),
forcing a call to "expand_call_inline" producing the same effect than -Winline
(as shown with a breakpoint in ipa-inline-transform:306 on trunk)
So which one of the strategies is good: Fixing the warning, and make sure that
it only (and consistently) occurs when -Winline is used, or always honoring the
always_inline attribute despite visibility potential issues, considering that a
user directive bypass the defaults ?
Thanks,
Christian
[Bug c++/19351] operator new[] can return heap blocks which are too small
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351 Jonathan Wakely changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #23 from Jonathan Wakely 2011-05-24 12:31:34 UTC --- Florian, your patch seems to have gone unreviewed, could you ping it? GCC is getting (fairly) criticised on the LLVM blog about this ;)
[Bug tree-optimization/49135] ICE in gcc.c-torture/execute/920302-1.c on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49135 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson 2011-05-24 12:38:28 UTC --- I see the same ICE and test suite FAIL as Janis does, on armv5tel-linux-gnueabi, except I see it on line 11950 which is gcc_assert (fix->forwards || fix->backwards); 4.7-20110423 was OK, 4.7-20110430 and newer show the ICE and FAIL. My config is /mnt/scratch/gcc-4.7-20110521/configure --prefix=/mnt/scratch/install47 --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,java,fortran --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --disable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --disable-sjlj-exceptions --with-arch=armv5te --with-tune=xscale --build=armv5tel-brewer-linux-gnueabi --with-gmp=/home/mikpe/pkgs/linux-armv5l/gmp-4.3.2 --with-mpfr=/home/mikpe/pkgs/linux-armv5l/mpfr-2.4.2 --with-mpc=/home/mikpe/pkgs/linux-armv5l/mpc-0.8.2 --disable-plugin --disable-lto --disable-libmudflap
[Bug bootstrap/49078] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49078 --- Comment #3 from Richard Guenther 2011-05-24 12:40:31 UTC --- Author: rguenth Date: Tue May 24 12:40:28 2011 New Revision: 174113 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174113 Log: 2011-05-24 Richard Guenther PR bootstrap/49078 * gimple.c (gimple_register_canonical_type): Revert previous change. * alias.c (get_alias_set): Only assert that TYPE_CANONICAL does not for a tree for the case where it matters. Cache pointer-type alias-sets. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/gimple.c
[Bug c++/48292] [C++0x] "sorry, unimplemented: use of 'type_pack_expansion' in template"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48292 Jonathan Wakely changed: What|Removed |Added CC||marc.hofmann at gmail dot ||com --- Comment #4 from Jonathan Wakely 2011-05-24 12:44:35 UTC --- *** Bug 44167 has been marked as a duplicate of this bug. ***
[Bug c++/48292] [C++0x] "sorry, unimplemented: use of 'type_pack_expansion' in template"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48292 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jonathan Wakely 2011-05-24 12:50:45 UTC --- (In reply to comment #3) > CC-ing Jason about this one too. By the way, isn't the first time this sorry > message surfaces, eg, Comment #4 in PR44167. ... actually adding Jason to the CC list ;) I've marked the other as a dup after comparing the results for both testcases with G++ 4.4 and later versions. Jason, is this likely to be easy to fix? I've been hitting this and PR 47335 while implementing std::allocator_traits. If they aren't likely to be fixed in the near future I'll look into workarounds
[Bug c++/44167] [C++0x] ICE in tsubst_copy at cp/pt.c:10077
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44167 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #6 from Jonathan Wakely 2011-05-24 12:44:35 UTC --- this is the same as PR 48292, with g++ 4.4 both test cases ICE at the same place in tsubst_copy and with later versions both give the same "sorry, unimplemented" message *** This bug has been marked as a duplicate of bug 48292 ***
[Bug regression/49139] always_inline attribute inconsistencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek 2011-05-24 12:54:20 UTC --- You forgot to add inline keyword, always_inline attribute makes no sense on functions without inline keyword (or C++ methods defined in class).
[Bug c++/49136] [C++0x][constexpr] Incorrect constexpr c'tor evaluation with bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49136 --- Comment #3 from Jakub Jelinek 2011-05-24 12:50:10 UTC --- Created attachment 24341 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24341 gcc47-pr49136.patch WIP patch, works on little-endian, but doesn't on big endian, so some correction somewhere is needed.
[Bug debug/49131] destructors missing DW_AT_vtable_elem_location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49131 Tom Tromey changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Tom Tromey 2011-05-24 13:10:12 UTC --- Duplicate. *** This bug has been marked as a duplicate of bug 37237 ***
[Bug bootstrap/49078] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49078 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther 2011-05-24 12:40:53 UTC --- Fixed.
[Bug regression/49139] always_inline attribute inconsistencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther 2011-05-24 13:05:51 UTC --- And for 1), with always_inline you indicate that it is a bug to not inline this function and inlining is required for correctness. So we can't just warn.
[Bug tree-optimization/49140] New: [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49140 Summary: [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@ubuntu.com Created attachment 24342 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24342 preprocessed source [forwarded from http://bugs.debian.org/627084] seen with r174102 from the 4.6 branch, works with r173903 from the trunk Step to reproduce: wget 'http://pari.math.u-bordeaux.fr/~bill/pari-2.4.3.12000.tar.gz' tar xf pari-2.4.3.12000.tar.gz cd pari-2.4.3.alpha ./Configure make gp make bench Result: all test suite fail. Cause: The function pari_init_parser() in the file src/language/parsec.h is miscompiled. (This file is included by src/language/parse.y). If you replace the line 43: s_node.n=OPnboperator; by parsestate_reset(); (which does the same thing), then all test pass. It seems that the issue is that the function stack_alloc() is not inlined correctly, which cause pari_tree to be NULL (or maybe the call to pari_inline inside stack_alloc() is not inlined correctly. The command line used is gcc-4.6 -c -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer-I. -I../src/headers -fPIC -o parse.o ../src/language/parse.c It also happens with -O2, but not with -O3 -fno-inline. It works fine with gcc 4.3, 4.4 and 4.5.
[Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237 --- Comment #7 from Tom Tromey 2011-05-24 13:10:13 UTC --- *** Bug 49131 has been marked as a duplicate of this bug. ***
[Bug c++/49129] confusing diagnostic for missing semi-colon after member template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49129 --- Comment #1 from Nathan Froyd 2011-05-24 13:30:16 UTC --- I believe I tried to do that at one point; you can see the comment in cp/parser.c:class_specifier_1 about handling user-defined types. I might not have been clever enough, though. It'd certainly be helpful.
[Bug libstdc++/49141] New: 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141 Summary: 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: paolo.carl...@oracle.com Host: alpha-dec-osf5.1b, *-*-solaris2.[89] Target: alpha-dec-osf5.1b, *-*-solaris2.[89] Build: alpha-dec-osf5.1b, *-*-solaris2.[89] On platforms without (at least Tru64 UNIX V5.1B, Solaris 8 and 9), two tests FAIL: FAIL: 26_numerics/complex/cons/48760.cc (test for excess errors) WARNING: 26_numerics/complex/cons/48760.cc compilation failed to produce executable FAIL: 26_numerics/complex/cons/48760.cc (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/26_numerics/complex/cons/48760.cc:31:2: error: 'isnan' is not a member of 'std' /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/26_numerics/complex/cons/48760.cc:31:2: note: suggested alternative: /var/gcc/regression/trunk/9-gcc/build/./gcc/include-fixed/math.h:145:12: note: 'isnan' FAIL: 26_numerics/complex/cons/48760_c++0x.cc (test for excess errors) WARNING: 26_numerics/complex/cons/48760_c++0x.cc compilation failed to produce executable Rainer
[Bug fortran/49138] Add /usr/include/fortran/{,gcc-} to the file/module search path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138
--- Comment #1 from joseph at codesourcery dot com 2011-05-24 14:05:58 UTC ---
On Tue, 24 May 2011, burnus at gcc dot gnu.org wrote:
> The /usr/{local/,}include/fortran/ directory should be used (and searched) for
> Fortran INCLUDE / #include files.
The Fortran directories should be searched within the sysroot when there
is one (the same conditions under which such C directories are searched
within the sysroot).
> The result of -print-mod-dir-suffix should be
> gcc-/lib{,}
>
> The reason for "lib{,}" is to allow for architecture-defined
> directories;
By "lib{,}" do you mean lib/$(gcc -print-multi-os-directory) ?
(Inventing yet another system for distinguishing multilibs, when there's
already -print-multi-directory and -print-multi-os-directory, seems like a
bad idea.)
[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141 --- Comment #1 from Paolo Carlini 2011-05-24 14:17:19 UTC --- It seems to me that the problem is isnan, not complex.h. We should check what we do for the other tests using isnan.
[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.24 14:18:36 Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini 2011-05-24 14:18:36 UTC --- Will fix it momentarily.
[Bug inline-asm/49142] New: Invalid 8bit register operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49142
Summary: Invalid 8bit register operand
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
Target: x86_64
i386.md has
(define_insn "*movqi_extzv_2_rex64"
[(set (match_operand:QI 0 "register_operand" "=Q,?R")
(subreg:QI
(zero_extract:SI (match_operand 1 "ext_register_operand" "Q,Q")
(const_int 8)
(const_int 8)) 0))]
"TARGET_64BIT"
{
switch (get_attr_type (insn))
{
case TYPE_IMOVX:
return "movz{bl|x}\t{%h1, %k0|%k0, %h1}";
default:
return "mov{b}\t{%h1, %0|%0, %h1}";
}
}
However, since %ah can only be used with legacy 8bit register,
it puts restriction on the other operand. We shouldn't generate
"movb %ah, %dil".
[Bug target/48126] arm_output_sync_loop: misplaced memory barrier, missing clrex / dummy strex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48126 --- Comment #3 from Marcus Shawcroft 2011-05-24 13:37:03 UTC --- The primitive is required to have lock semantics therefore the load of the old value must be followed by a dmb in the case that the old value comparison succeeds and the swap goes ahead. In the branch out case the final dmb serves no purpose, the swap did not occur and no lock was taken. Therefore the branch over dmb is ok.
[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141 Paolo Carlini changed: What|Removed |Added Target Milestone|--- |4.6.1
[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-05-24 14:39:57 UTC --- > --- Comment #1 from Paolo Carlini > 2011-05-24 14:17:19 UTC --- > It seems to me that the problem is isnan, not complex.h. We should check what > we do for the other tests using isnan. Strangely, config.h defines HAVE_ISNAN 1. Rainer
[Bug debug/48354] internal compiler error: in splice_child_die, at dwarf2out.c:8064
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48354
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Richard Guenther 2011-05-24
14:21:57 UTC ---
In the cc1plus case the type for s is already output and we return in
static void
gen_type_die_with_usage (tree type, dw_die_ref context_die,
enum debug_info_usage usage)
{
...
if (TREE_ASM_WRITTEN (type))
return;
that isn't the case for lto1.
Called from cc1plus via
#4 0x009e9d25 in dwarf2out_type_decl (decl=0x75b86450, local=0)
at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:21985
21985 dwarf2out_decl (decl);
(gdb)
#5 0x00cd1e8c in rest_of_type_compilation (type=0x75b7f7e0,
toplev=1) at /space/rguenther/src/svn/trunk/gcc/passes.c:230
230 debug_hooks->type_decl (TYPE_STUB_DECL (type), !toplev);
(gdb)
#6 0x0062c460 in finish_struct_1 (t=0x75b7f7e0)
at /space/rguenther/src/svn/trunk/gcc/cp/class.c:5760
5760 rest_of_type_compilation (t, ! LOCAL_CLASS_P (t));
not doing that does not make us ICE the same way from cc1plus but we
are outputting the type then via the Dummy typedef instead.
The scope blocks look the same for cc1plus and lto1:
{ Scope block 0x75b42058#2
typedef struct Dummy Dummy; (unused)
struct S s; (unused)
}
One difference is that cc1plus sees DECL_ORIGINAL_TYPE for the TYPE_DECL
while lto1 does not (it's not streamed), and thus is_typedef_decl will
always return false as well.
I have a patch.
[Bug regression/49139] always_inline attribute inconsistencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139 --- Comment #3 from chrbr at gcc dot gnu.org 2011-05-24 14:47:54 UTC --- Thanks a lot, that's clear. This makes non-sense not to use inline with this attribute. Accordingly not a bug. So I am wondering if we could be more helpful to the users by changing the "sorry, unimplemented" error message by something more explicit, something like "invalid attribute without inline", and more consistent among the cases ? Looking on a few opensources packages, I see a few usages of this attribute without the inline keyword (e.g, the gcc testsuite, some target dl-machine.h in the glibc). This is not frequent, I admit, but enough to be confusing.
[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141 --- Comment #4 from Paolo Carlini 2011-05-24 14:49:30 UTC --- But isn't imported in std::, because something else is missing. We don't do this kind of config-time work with a very small granularity. We want dg-require-c-std to be safe.
[Bug gcov-profile/48845] [4.7 regression] All g++.dg/tree-prof and gcc.dg/{matrix, tree-prof} executions tests fail on Solaris 8/9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48845 --- Comment #1 from Rainer Orth 2011-05-24 14:53:42 UTC --- Author: ro Date: Tue May 24 14:53:39 2011 New Revision: 174119 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174119 Log: PR gcov-profile/48845 * config/sol2.h (LIB_SPEC): Link TLS support for tree profiling. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sol2.h
[Bug fortran/49138] Add /usr/include/fortran/{,gcc-} to the file/module search path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138
--- Comment #2 from Tobias Burnus 2011-05-24
14:54:03 UTC ---
(In reply to comment #1)
> The Fortran directories should be searched within the sysroot when there
> is one (the same conditions under which such C directories are searched
> within the sysroot).
OK, one then has the "fortran" subdirectory of: sysroot, LOCAL_INCLUDE_DIR,
SYSTEM_INCLUDE_DIR and STANDARD_INCLUDE_DIR - in that order. Is the list
complete and correctly ordered?
> > The result of -print-mod-dir-suffix should be
> > gcc-/lib{,}
>
> By "lib{,}" do you mean lib/$(gcc -print-multi-os-directory) ?
Yes - although using -print-multi-directory instead would be probably better as
it avoid the misleading "lib". Thus, instead of, e.g., ./lib32/ and ./lib/, one
has ./ and ./32/.
Thanks for your comments!
[Bug debug/48354] internal compiler error: in splice_child_die, at dwarf2out.c:8064
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48354 --- Comment #5 from Richard Guenther 2011-05-24 14:43:00 UTC --- Created attachment 24343 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24343 patch Honza, can you try this on mozilla?
[Bug tree-optimization/49140] [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49140 --- Comment #1 from Richard Guenther 2011-05-24 14:53:29 UTC --- stack_init computes &pari_tree - &s_node which is undefined, stack_alloc then re-computes one via stack_base. That's broken as well. Not sure if this eventually causes the issue, but certainly the code is full of C implementation details that you can't capture in standard C.
[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141 --- Comment #6 from Paolo Carlini 2011-05-24 15:00:21 UTC --- Rainer, please confirm that everything is ok now, 2/3 of the patch goes to 4_6-branch too.
[Bug libstdc++/49141] 26_numerics/complex/cons/48760.cc FAILs on Tru64 UNIX V5.1B, Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49141 --- Comment #5 from paolo at gcc dot gnu.org 2011-05-24 14:59:16 UTC --- Author: paolo Date: Tue May 24 14:59:13 2011 New Revision: 174120 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174120 Log: 2011-05-24 Paolo Carlini PR libstdc++/49141 * testsuite/26_numerics/complex/cons/48760.cc: Use dg-require-c-std. * testsuite/26_numerics/complex/cons/48760_c++0x.cc: Likewise. * testsuite/26_numerics/headers/cmath/19322.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/26_numerics/complex/cons/48760.cc trunk/libstdc++-v3/testsuite/26_numerics/complex/cons/48760_c++0x.cc trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/19322.cc
[Bug debug/48354] internal compiler error: in splice_child_die, at dwarf2out.c:8064
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48354 --- Comment #6 from Richard Guenther 2011-05-24 14:58:53 UTC --- It seems that we can pull in types via that link that have function-decls in them (methods) that do not have an assembler name set. But we happily enter them into symtab merging and so we ICE. See also PR48437 for a related case. Hohumm.
[Bug middle-end/49139] always_inline attribute inconsistencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139 Manuel López-Ibáñez changed: What|Removed |Added Status|RESOLVED|REOPENED Keywords||diagnostic Last reconfirmed||2011.05.24 15:12:15 Component|regression |middle-end CC||manu at gcc dot gnu.org Resolution|INVALID | Ever Confirmed|0 |1 Severity|minor |enhancement --- Comment #4 from Manuel López-Ibáñez 2011-05-24 15:12:15 UTC --- Using "sorry" for this doesn't make any sense. I'd would like to have time to fix this, but I don't. Christian, I would suggest that you put forward a patch for comments including self-contained testcases.
[Bug target/49133] [4.6/4.7 Regression] modification of aliased __m128d miscompiles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49133 --- Comment #5 from uros at gcc dot gnu.org 2011-05-24 15:31:15 UTC --- Author: uros Date: Tue May 24 15:31:12 2011 New Revision: 174122 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174122 Log: PR target/49133 * config/i386/sse.md (sse2_loadhpd): Remove shufpd alternative. testsuite/ChangeLog: PR target/49133 * g++.dg/other/pr49133.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/pr49133.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug middle-end/49139] always_inline attribute inconsistencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139 --- Comment #5 from chrbr at gcc dot gnu.org 2011-05-24 15:39:18 UTC --- (In reply to comment #4) > Using "sorry" for this doesn't make any sense. I'd would like to have time to > fix this, but I don't. > > Christian, I would suggest that you put forward a patch for comments including > self-contained testcases. OK, I have the testcases, I will try a patch in the light of the semantic clarification from Jacub and Richard.
[Bug c/49143] New: make -Wsuggest-attribute less verbose
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49143
Summary: make -Wsuggest-attribute less verbose
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: madco...@debian.org
In many code bases, -Wsuggest-attribute={const|pure} is really verbose (unlike
missing printf/sccanf format attributes or noreturn attributes, which are
rarer).
Though it's not particularly useful to mark functions as pure/const when those
are known inside the compilation unit or are inline. It'd be great to be able
to restrict the -Wsuggest-attribute to functions whose storage isn't static
because those are the functions for those it's useful (because it's likely that
the prototype lives in some header to be used by external programs).
[Bug tree-optimization/49135] ICE in gcc.c-torture/execute/920302-1.c on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49135 --- Comment #3 from Janis Johnson 2011-05-24 16:07:25 UTC --- With sources updated yesterday the ICE is at line 11950. Configured with: /scratch/janisjo/arm-linux-fsf/src/gcc-mainline/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --enable-shared --enable-lto --enable-symvers=gnu --enable-__cxa_atexit --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --disable-libgomp --enable-poison-system-directories --with-gmp= --with-mpfr= --with-mpc= --with-ppl= --with-cloog= --with-libelf= --with-build-time-tools= --with-build-sysroot=
[Bug rtl-optimization/48971] [4.7 regression] ICE with -msoft-float -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48971 --- Comment #5 from Vladimir Makarov 2011-05-24 16:14:56 UTC --- Author: vmakarov Date: Tue May 24 16:14:51 2011 New Revision: 174123 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174123 Log: 2011-05-13 Vladimir Makarov PR rtl-optimization/48971 * ira.c (setup_pressure_classes): Don't check register move cost for classes with one registers. Don't add pressure class if there is a pressure class with the same available hard registers. Check contains_reg_of_mode. Fix a typo in collecting temp_hard_regset. Ignore hard registers not belonging to a class. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c
[Bug fortran/49138] Add /usr/include/fortran/{,gcc-} to the file/module search path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138 --- Comment #3 from joseph at codesourcery dot com 2011-05-24 16:19:25 UTC --- On Tue, 24 May 2011, burnus at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138 > > --- Comment #2 from Tobias Burnus 2011-05-24 > 14:54:03 UTC --- > (In reply to comment #1) > > The Fortran directories should be searched within the sysroot when there > > is one (the same conditions under which such C directories are searched > > within the sysroot). > > OK, one then has the "fortran" subdirectory of: sysroot, LOCAL_INCLUDE_DIR, > SYSTEM_INCLUDE_DIR and STANDARD_INCLUDE_DIR - in that order. Is the list > complete and correctly ordered? I advise following cppdefault.c (specifically, the add_sysroot flags therein) - and probably adding a "fortran" field to indicate if a Fortran subdirectory is searched, rather than duplicating the list.
[Bug target/48126] arm_output_sync_loop: misplaced memory barrier, missing clrex / dummy strex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48126 --- Comment #4 from Michael K. Edwards 2011-05-24 16:38:41 UTC --- OK, that's a clear explanation of why the DMB is necessary in the case where both the compare and the store succeed (neither branch is taken; at a higher semantic level, a lock is acquired, if that's what the atomic is being used for). For future reference, I would appreciate having those ARM ARM quotations, along with some indication of how load scheduling interacts with a branch past a memory barrier. Suppose that the next instruction after label "2" is a load. On some ARMv7 implementations, I presume that this load can get issued speculatively as early as label "1", due to the "bne 2f" branch shadow, which skips the trailing dmb. I gather that the intention is that, if this branch is not taken (and thus we execute through the trailing dmb), the fetch results from the branch shadow should be discarded, and the load re-issued (with, in a multi-core device, the appropriate ordering guarantee with respect to the strex). If this interpretation is more or less right, and the shipping silicon behaves as intended, then the branch past the dmb may be harmless -- although I might argue that it wastes memory bandwidth in what is usually the common case (compare-and-swap succeeds) in exchange for a slight reduction in latency in the other case. Yet that's still not quite the documented semantics of the GCC compare-and-swap primitive, which is supposed to be totally ordered whether or not the swap succeeds. When I write a lock-free algorithm, I may well rely on the guarantee that the value read in the next line of code was actually fetched after the value fetched by the ldrex. In fact, I have code that does rely on this guarantee; if thread A sees that thread B has altered the atomic location, then it expects to be able to see all data that thread B wrote before issuing its compare-and-swap. Here's the problem case: thread A: thread B: dmb store Y dmb ldrex X cmp bne (doesn't branch) strex X ldrex X cmp bne (branches) load Y (speculated above) Is there something I'm not seeing that prevents this?
[Bug rtl-optimization/48633] [4.7 regression] IRA causes ICE in compensate_edge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48633 --- Comment #5 from Vladimir Makarov 2011-05-24 16:28:42 UTC --- Author: vmakarov Date: Tue May 24 16:28:38 2011 New Revision: 174124 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174124 Log: 2011-05-24 Vladimir Makarov PR rtl-optimization/48633 * ira-build.c (loop_with_eh_edge_p): New function. (mark_loops_for_removal): Use it. 2011-05-24 Michael Matz PR rtl-optimization/48633 * g++.dg/pr48633.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr48633.C Modified: trunk/gcc/ChangeLog trunk/gcc/ira-build.c trunk/gcc/testsuite/ChangeLog
[Bug target/49145] New: ICE in simplify_const_unary_operation, at simplify-rtx.c:1322
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49145 Summary: ICE in simplify_const_unary_operation, at simplify-rtx.c:1322 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com Host: x86_64-linux-gnu Target: mips-unknown-linux-uclibc Build: x86_64-linux-gnu Created attachment 24344 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24344 preprocessed source $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: mips-unknown-linux-uclibc Configured with: ../configure --target=mips-unknown-linux-uclibc --prefix=/home/ryan/x-tools/mips-unknown-linux-uclibc --with-sysroot=/home/ryan/x-tools/mips-unknown-linux-uclibc/mips-unknown-linux-uclibc/sys-root --enable-languages=c++,lto --disable-multilib --with-float=soft --enable-__cxa_atexit --with-local-prefix=/home/ryan/x-tools/mips-unknown-linux-uclibc/mips-unknown-linux-uclibc/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99 --enable-long-long --enable-target-optspace Thread model: posix gcc version 4.7.0 20110524 (experimental) [trunk revision 174114] (GCC) $ ./xgcc -B. ~/ice.i -O1 /home/ryan/ice.i: In function 'func3': /home/ryan/ice.i:30:1: internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1322 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug other/49144] New: [4.6/4.7 regression] miscompiled reverse_iterator?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49144
Summary: [4.6/4.7 regression] miscompiled reverse_iterator?
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@ubuntu.com
[forwarded from http://bugs.debian.org/PR627795]
seen with 4.6 r174102 and trunk r173903
The attached test program is supposed to print -42, and does so when compiled
with g++-4.4 or g++-4.5. However, it outputs random junk when compiled with
g++-4.6:
$ g++ -Wall -O2 test.cxx
$ ./a.out
31
$ ./a.out
207
$ ./a.out
79
#include
int f()
{
unsigned char data[3] = { 42, 42, 42 };
unsigned char *begin = data;
unsigned char *end = data + 3;
std::reverse_iterator reversed(end);
for (; begin < end; begin++, reversed++)
if (*reversed != 42)
return *reversed;
return -42;
}
int main(int argc, char ** argv)
{
std::cout << f() << "\n";
}
[Bug c++/49136] [C++0x][constexpr] Incorrect constexpr c'tor evaluation with bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49136 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #4 from Jakub Jelinek 2011-05-24 17:08:22 UTC --- Created attachment 24345 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24345 gcc47-pr49136.patch Adjusted fix that passes also on powerpc on the testcases.
[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146 --- Comment #1 from Ariel Burton 2011-05-24 17:18:45 UTC --- Created attachment 24347 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24347 preprocessed file for t_repro.c
[Bug tree-optimization/49144] [4.6/4.7 regression] miscompiled reverse_iterator?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49144 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.24 17:30:16 CC||rguenth at gcc dot gnu.org Component|other |tree-optimization Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2011-05-24 17:30:16 UTC --- Seems indeed a serious issue, note happen only at -O1 and above. Let's ask Richard to have a look.
[Bug target/49146] New: segv from libgcc_s when raising an exception, or unwinding stack with backtrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146
Summary: segv from libgcc_s when raising an exception, or
unwinding stack with backtrace
Product: gcc
Version: 4.4.6
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ariel.bur...@roguewave.com
Created attachment 24346
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24346
preprocessed file for t_exception.cpp
Unwinding the stack through a frame for a function annotated
with __attribute__((ms_abi)) causes a segv from libgcc_s.
System type: linux x8664, gcc 4.4.6, 4.5.3, and 4.6.0.
This error can be reproduced in two ways.
The first is to throw an exception and there is a function
annotated with __attribute__((ms_abi)) between where it's
thrown and where it's caught.
The other is to call the (libc) function backtrace. On most
contemporary linux x8664 distributions, backtrace calls code
in libgcc_s.so. Note also that in this case the backtrace
shown for f looks wrong (it has too few frames). The segv
occurs in the unwind code in libgcc_s.so.
This is output of gcc -v:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /packages/gcc-4.4.6/src/gcc-4.4.6/configure
--prefix=/packages/gcc-4.4.6/linux-x8664/installation
--with-gmp=/packages/gcc-4.4.6/linux-x8664/installation
--with-mpfr=/packages/gcc-4.4.6/linux-x8664/installation
--with-mpc=/packages/gcc-4.4.6/linux-x8664/installation
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.4.6 (GCC)
This is how I built the sample programs:
/packages/gcc-4.4.6/linux-x8664/installation/bin/g++ -save-temps -g
../ms_abi-reproducer/t_exception.cpp -o t_exception
-Wl,-rpath,/packages/gcc-4.4.6/linux-x8664/installation/lib64
/packages/gcc-4.4.6/linux-x8664/installation/bin/gcc -save-temps -g
../ms_abi-reproducer/t_repro.c -o t_repro
-Wl,-rpath,/packages/gcc-4.4.6/linux-x8664/installation/lib64
I submit the preprocessed files as attachments. This is the source
for the two programs:
t_exception.cpp
#include
struct E {
};
void
f ( int arg )
{
if ( arg > 0 )
{
f ( arg - 1 );
}
else
{
throw E ();
}
} /* f */
int
__attribute__((ms_abi))
f_ms_abi ( int arg )
{
if ( arg > 0 )
{
f_ms_abi ( arg - 1 );
}
else
{
throw E ();
}
} /* f_ms_abi */
int
main ( int argc, char *argv [] )
{
printf ( "calling f\n" );
try
{
f ( 6 );
}
catch ( ... )
{
printf ( "caught exception thrown by f\n" );
}
printf ( "calling f_ms_abi\n" );
try
{
f_ms_abi ( 6 );
}
catch ( ... )
{
printf ( "caught exception thrown by f_ms_abi\n" );
}
return 0;
} /* main */
t_repro.c:
#include
#include
void
do_backtrace (void)
{
void *pcs [ 64 ];
intmax_pcs = sizeof ( pcs ) / sizeof ( pcs [ 0 ] );
intnum_pcs = backtrace ( pcs, max_pcs );
inti;
for ( i = 0; i < num_pcs; i ++ )
printf ( " %2d: %p\n", i, pcs [ i ] );
} /* do_backtrace */
void
f ( int arg )
{
if ( arg > 0 )
{
f ( arg - 1 );
}
else
{
do_backtrace ();
}
} /* f */
int
__attribute__((ms_abi))
f_ms_abi ( int arg )
{
if ( arg > 0 )
{
f_ms_abi ( arg - 1 );
}
else
{
do_backtrace ();
}
} /* f_ms_abi */
int
main ( int argc, char *argv [] )
{
printf ( "calling f\n" );
f ( 6 );
printf ( "calling f_ms_abi\n" );
f_ms_abi ( 6 );
return 0;
} /* main */
[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146 --- Comment #2 from Ariel Burton 2011-05-24 17:31:22 UTC --- f and f_ms_abi are identical with the exception that f_ms_abi is annoted with __attribute__((ms_abi)). This causes the compiler to emit code to save registers not otherwise saved. The DWARF thus also contains directives for these registers. I believe that the problem is that the arrays of registers in struct _Unwind_Context and _Unwind_FrameState *fs are too small to accommodate the higher-numbered registers saved in the prologues of the ms_abi annotated functions. This change made the segv go away: *** src/gcc-4.6.0/gcc/config/i386/i386.h2011-05-18 22:43:30.642575000 -0400 --- tmp/gcc-4.6.0/gcc/config/i386/i386.h2011-01-14 16:03:22.0 -0500 *** *** 889,899 #define FIRST_PSEUDO_REGISTER 53 /* Number of hardware registers that go into the DWARF-2 unwind info. If not defined, equals FIRST_PSEUDO_REGISTER. */ ! // #define DWARF_FRAME_REGISTERS 17 /* 1 for registers that have pervasive standard uses and are not available for the register allocator. On the 80386, the stack pointer is such, as is the arg pointer. --- 889,899 #define FIRST_PSEUDO_REGISTER 53 /* Number of hardware registers that go into the DWARF-2 unwind info. If not defined, equals FIRST_PSEUDO_REGISTER. */ ! #define DWARF_FRAME_REGISTERS 17 /* 1 for registers that have pervasive standard uses and are not available for the register allocator. On the 80386, the stack pointer is such, as is the arg pointer. However, the wrong backtrace remained.
[Bug c/49128] -march=native generates unsupported instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49128 --- Comment #5 from hjl at gcc dot gnu.org 2011-05-24 17:38:38 UTC --- Author: hjl Date: Tue May 24 17:38:34 2011 New Revision: 174126 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174126 Log: Always add -mno-XXX for -march=native. 2011-05-24 H.J. Lu PR target/49128 * config/i386/driver-i386.c (host_detect_local_cpu): Always add -mno-XXX. Handle FMA. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/driver-i386.c
[Bug objc/48187] infinite errors with misplaced [ in @interface definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48187 --- Comment #2 from Nicola Pero 2011-05-24 17:45:59 UTC --- I have a patch ready to fix this -- http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01735.html Thanks
[Bug c/49128] -march=native generates unsupported instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49128 --- Comment #6 from hjl at gcc dot gnu.org 2011-05-24 17:41:54 UTC --- Author: hjl Date: Tue May 24 17:41:51 2011 New Revision: 174127 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174127 Log: Always add -mno-XXX for -march=native. 2011-05-24 H.J. Lu Backport from mainline 2011-05-24 H.J. Lu PR target/49128 * config/i386/driver-i386.c (host_detect_local_cpu): Always add -mno-XXX. Handle FMA. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/i386/driver-i386.c
[Bug c/49128] -march=native generates unsupported instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49128 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hjl.tools at gmail dot com Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #7 from H.J. Lu 2011-05-24 17:55:21 UTC --- Fixed.
[Bug lto/48437] [4.6/4.7 Regression] LTO crashes with block-local function declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48437 H.J. Lu changed: What|Removed |Added Target Milestone|--- |4.6.1 Summary|LTO crashes with|[4.6/4.7 Regression] LTO |block-local function|crashes with block-local |declarations|function declarations --- Comment #2 from H.J. Lu 2011-05-24 17:58:41 UTC --- It is caused by revision 170321: http://gcc.gnu.org/ml/gcc-cvs/2011-02/msg00866.html
[Bug target/3746] compilation of mips-tfile missing mips/a.out.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3746 --- Comment #10 from Rainer Orth 2011-05-24 17:51:54 UTC --- Author: ro Date: Tue May 24 17:51:51 2011 New Revision: 174128 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174128 Log: PR target/3746 * config.gcc (alpha*-dec-osf5.1*): Only build mips-tfile, mips-tdump native. * mips-tfile.c: Remove CROSS_DIRECTORY_STRUCTURE handling. * mips-tdump.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/mips-tdump.c trunk/gcc/mips-tfile.c
[Bug tree-optimization/46728] GCC does not generate fmadd for pow (x, 0.75)+y on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46728 --- Comment #4 from William J. Schmidt 2011-05-24 18:02:27 UTC --- Author: wschmidt Date: Tue May 24 18:02:22 2011 New Revision: 174129 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174129 Log: 2011-05-24 Bill Schmidt PR tree-optimization/46728 * tree-ssa-math-opts.c (powi_table): New. (powi_lookup_cost): New. (powi_cost): New. (powi_as_mults_1): New. (powi_as_mults): New. (gimple_expand_builtin_powi): New. (execute_cse_sincos): Add switch case for BUILT_IN_POWI. (gate_cse_sincos): Remove sincos/cexp restriction. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug tree-optimization/46728] GCC does not generate fmadd for pow (x, 0.75)+y on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46728 --- Comment #5 from William J. Schmidt 2011-05-24 18:06:04 UTC --- Above is first of a series of patches. It handles converting __builtin_powi to a sequence of multiplies in the cse_sincos gimple pass. More to come.
[Bug middle-end/49147] New: graphite branch ICEs with -fgraphite-opencl-ignore-dep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49147 Summary: graphite branch ICEs with -fgraphite-opencl-ignore-dep Product: gcc Version: lno Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: s...@gcc.gnu.org Created attachment 24348 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24348 This is the same as gcc.dg/graphite/block-0.c Compiling some testcases from the graphite testsuite, I got an ICE with: cc1 -fgraphite-opencl -fgraphite-opencl-ignore-dep -g -Ofast block-0.c block-0.c: In function ‘foo’: block-0.c:10:1: internal compiler error: Segmentation fault The compiler does not ICE when removing -fgraphite-opencl-ignore-dep
[Bug target/49133] [4.6/4.7 Regression] modification of aliased __m128d miscompiles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49133 --- Comment #6 from uros at gcc dot gnu.org 2011-05-24 18:41:33 UTC --- Author: uros Date: Tue May 24 18:41:31 2011 New Revision: 174131 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174131 Log: PR target/49133 * config/i386/sse.md (sse2_loadhpd): Remove shufpd alternative. testsuite/ChangeLog: PR target/49133 * g++.dg/other/pr49133.C: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/other/pr49133.C Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/i386/sse.md branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086 --- Comment #21 from John David Anglin 2011-05-24 18:44:38 UTC --- Author: danglin Date: Tue May 24 18:44:35 2011 New Revision: 174132 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174132 Log: PR rtl-optimization/49007 Backport from mainline: 2009-11-30 Hans-Peter Nilsson PR rtl-optimization/40086 * reorg.c (relax_delay_slots): When looking for redundant insn at the branch target, use next_real_insn, not next_active_insn. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/reorg.c
[Bug fortran/47720] problems with makefile dependency generation using -M
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47720 Zaak changed: What|Removed |Added CC||zbeekman at gmail dot com --- Comment #1 from Zaak 2011-05-24 18:33:33 UTC --- The page here: http://gcc.gnu.org/wiki/GFortran#GCC4.6 seems to suggest that you need to specify -cpp. I must admit, however, the documentation for this features is a bit murky. I suspect that the module constants shows up three times because it is used in three procedures in the second module. This is by no means a deficiency. If you include this in your makefile it will not cause problems. In fact, make has ways of removing duplicates. gfortran/cpp likely parse your source code and every time they encounter a use statement ad the module(s) mentioned there to the list of dependencies. May I ask what version of gfortran this is? (Trunk build of gfortran from yesterday is a bit ambiguous) The reason I ask is that I am not getting as far as you. on gfortran 4.6.0 if have a program which uses two modules and dependency listing I get is myprog.0: myprog.f90 which is less than helpful.
[Bug rtl-optimization/49007] ICE in extract_true_false_edges_from_block at tree-cfg.c:7379
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49007 --- Comment #23 from John David Anglin 2011-05-24 18:44:38 UTC --- Author: danglin Date: Tue May 24 18:44:35 2011 New Revision: 174132 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174132 Log: PR rtl-optimization/49007 Backport from mainline: 2009-11-30 Hans-Peter Nilsson PR rtl-optimization/40086 * reorg.c (relax_delay_slots): When looking for redundant insn at the branch target, use next_real_insn, not next_active_insn. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/reorg.c
[Bug rtl-optimization/42775] [4.4 regression] GCC fails to rebuild itself with STAGE1_CFLAGS=-O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42775 --- Comment #13 from John David Anglin 2011-05-24 18:47:17 UTC --- Author: danglin Date: Tue May 24 18:47:14 2011 New Revision: 174133 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174133 Log: Backport from mainline: 2010-09-20 Eric Botcazou PR rtl-optimization/42775 * cfgrtl.c (rest_of_pass_free_cfg): Recompute notes if delay slot scheduling is enabled. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/cfgrtl.c
[Bug c/49148] New: Certain expressions take an extremely long time for no apparent reason
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49148 Summary: Certain expressions take an extremely long time for no apparent reason Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: jcht...@yahoo.com Created attachment 24349 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24349 This is a minimal test case of an expression that takes 100 times longer to evaluate than it should. See comments for explanations. I have been doing work on 1-D Jacobi stencils. Basically, this involves a lot of repeated operations. For some reason, however, I have been getting extremely long run times for certain expressions. What is weird is that if I TAKE OUT a multiply operation, the function takes about 100 times longer to run than if I left it in. The line that causes the problems is marked in the source code. It reads: new[i] = (A[i-1] + A[i] + A[i+1]) / 4.0; If I change this to the following, there is no problem: new[i] = (A[i-1] + 2*A[i] + A[i+1]) / 4.0; As another example, the following line runs slowly: new[i] = (A[i-1] + A[i] + A[i+1]) * 0.3; while this line runs quickly: new[i] = (A[i-1] + 2*A[i] + A[i+1]) * 0.333; The reason I think this is a bug is that it does not happen with older versions of GCC (for example, 4.1.2), nor with the Intel C Compiler.
[Bug c/49148] Certain expressions take an extremely long time for no apparent reason
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49148 John Peyton changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from John Peyton 2011-05-24 18:56:52 UTC --- The following command was used to compile and execute the test case: gcc gcc_bug.c -O3 -o gcc_bug && ./gcc_bug Note that -O3 was used. In addition, -lm affects performance minimally if it is used.
[Bug debug/48354] internal compiler error: in splice_child_die, at dwarf2out.c:8064
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48354 --- Comment #7 from Jan Hubicka 2011-05-24 18:53:14 UTC --- > Honza, can you try this on mozilla? Can try, but only after returning from Bertinoro. All connections I found here filters VPN. Honza
[Bug c/49148] Certain expressions take an extremely long time for no apparent reason
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49148 --- Comment #2 from John Peyton 2011-05-24 19:16:20 UTC --- Created attachment 24350 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24350 This is a minimal example of an expression that takes longer to evaluate than it should. Run the slightly longer file for an example of the speed difference.
[Bug rtl-optimization/49007] ICE in extract_true_false_edges_from_block at tree-cfg.c:7379
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49007 John David Anglin changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #24 from John David Anglin 2011-05-24 19:08:23 UTC --- Fixed.
[Bug middle-end/49143] make -Wsuggest-attribute less verbose
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49143 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org Component|c |middle-end --- Comment #1 from Manuel López-Ibáñez 2011-05-24 19:16:16 UTC --- Pierre, could you add some testcase(s) please? http://gcc.gnu.org/bugs/#need
[Bug c/49148] Certain expressions take an extremely long time for no apparent reason
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49148 --- Comment #3 from John Peyton 2011-05-24 19:16:51 UTC --- Created attachment 24351 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24351 Finally, this is a preprocessed version of the minimal case.
[Bug fortran/49149] New: Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 Summary: Dependency autogeneration with `-M` rendered useless by requiring .mod files Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zbeek...@gmail.com Here is some fortran code: MODULE utils USE types, ONLY: WP IMPLICIT NONE CONTAINS ELEMENTAL FUNCTION initPI() RESULT(PI) REAL(WP) :: PI PI = ATAN(1.0_WP)*4.0_WP END FUNCTION initpi END MODULE utils When I run the following command with gfortran 4.6 I get the following error. $ gfortran -MG -cpp modutils.f90 modutils.f90:2.21: USE types, ONLY: WP 1 Fatal Error: Can't open module file 'types.mod' for reading at (1): No such file or directory This entirely defeats the purpose of having a preprocessor spit out makefile rules. If I want my dependencies resolved automatically, I should be able to spit out .d files which are later included in my makefile *in an arbitrary order.* GENERATION OF MAKEFILE RULES FOR AUTOMATIC DEPENDENCY RESOLUTION MUST BE ABLE TO BE DONE IN ANY ORDER BY PARSING THE SOURCE. There should not be a requirement to have .mod files present. These files are part of a separate source file and contribute zero knowledge to the dependencies of the current file. The need not be present for preprocessing, or dependency resolution. (But yes, they are needed for syntax checking.) With the `-M` feature added to gfortran one should be able to follow the procedure outlined on the GNUmake website for automatic dependency generation to build codes with a small set of pattern rules. See this page for more info. http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_43.html If the procedure outlined on that page is attempted, the include statement in the makefile will cause the makefile to about because the include statement tries to build the files in arbitrary order (likely ascii collating sequence by file name). The makefile code listed bellow should work but doesn't because of the eroneously required .mod files: FC=ifort GFC = gfortran %.o: %.f90 %.d $(FC) $(FCFLAGS) $(FPPFLAGS) -c $< -o $@ %.d: %.f90 $(SHELL) -ec "$(GFC) -M -cpp $(FPPFLAGS) $< | sed '1 s/^/$@ /' > $@" sources:=$(wildcard *.f90) depends:=$(patsubst %.f90,%.d,$(wildcard *.f90)) include $(depends) Dependency resolution is the bane of Fortran developers, and a huge headache. Being able to implement Makefiles like the one listed above instead of teadiously writing line after line of dependency resolutions by hand will be a boon for the Fortran community as a whole. Please make it a priority to look into this in the near future. Many thanks, and keep up the great work.
[Bug c++/19351] operator new[] can return heap blocks which are too small
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351 --- Comment #24 from Florian Weimer 2011-05-24 19:54:47 UTC --- (In reply to comment #23) > Florian, your patch seems to have gone unreviewed, could you ping it? Jason reviewed it and Ian, too (off-list). I haven't yet gotten around to incorporating their feedback. I'm also not sure if I'm qualified to tackle the optimization requests.
[Bug preprocessor/49150] New: Preprocessing fortran code with the `-M` flag to automatically resolve dependencies and produce makefile rules rendered useless by requiring .mod files be present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49150 Summary: Preprocessing fortran code with the `-M` flag to automatically resolve dependencies and produce makefile rules rendered useless by requiring .mod files be present Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: zbeek...@gmail.com Here is some fortran code which can be put in it's own .f90 source file and compiled into an object file and module file: MODULE utils USE types, ONLY: WP IMPLICIT NONE CONTAINS ELEMENTAL FUNCTION initPI() RESULT(PI) REAL(WP) :: PI PI = ATAN(1.0_WP)*4.0_WP END FUNCTION initpi END MODULE utils When I run the following command with gfortran 4.6 I get the following error. $ gfortran -MG -cpp modutils.f90 modutils.f90:2.21: USE types, ONLY: WP 1 Fatal Error: Can't open module file 'types.mod' for reading at (1): No such file or directory This entirely defeats the purpose of having a preprocessor spit out makefile rules. If I want my dependencies resolved automatically, I should be able to spit out .d files which are later included in my makefile *in an arbitrary order.* GENERATION OF MAKEFILE RULES FOR AUTOMATIC DEPENDENCY RESOLUTION MUST BE ABLE TO BE DONE IN ANY ORDER BY PARSING THE SOURCE. There should not be a requirement to have .mod files present. These files are part of a separate source file and contribute zero knowledge to the dependencies of the current file. The need not be present for preprocessing, or dependency resolution. (But yes, they are needed for syntax checking.) With the `-M` feature added to gfortran one should be able to follow the procedure outlined on the GNUmake website for automatic dependency generation to build codes with a small set of pattern rules. See this page for more info. http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_43.html If the procedure outlined on that page is attempted, the include statement in the makefile will cause the makefile to abort because the include statement tries to build the files in arbitrary order (likely ascii collating sequence by file name) and the -M flag won't allow this because it aborts if the required .mod files are not present. The makefile code listed bellow should work but doesn't because of the eroneously required .mod files: FC=ifort GFC = gfortran %.o: %.f90 %.d $(FC) $(FCFLAGS) $(FPPFLAGS) -c $< -o $@ %.d: %.f90 $(SHELL) -ec "$(GFC) -M -cpp $(FPPFLAGS) $< | sed '1 s/^/$@ /' > $@" sources:=$(wildcard *.f90) depends:=$(patsubst %.f90,%.d,$(wildcard *.f90)) include $(depends) Dependency resolution is the bane of Fortran developers, and a huge headache. Being able to implement Makefiles like the one listed above instead of teadiously writing line after line of dependency resolutions by hand will be a boon for the Fortran community as a whole. Please make it a priority to look into this in the near future. Many thanks, and keep up the great work. I wasn't sure whether this was a fortran issue or a preprocessor issue so I have more or less duplicated the bug I submitted as a fortran issue here.
[Bug c/49148] Certain expressions take an extremely long time for no apparent reason
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49148 --- Comment #4 from Andrew Pinski 2011-05-24 20:27:39 UTC --- Maybe you are getting subnormals which causes a huge performance decrease.
[Bug c++/48884] decltype's operand doesn't consider friend declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48884 --- Comment #2 from Jason Merrill 2011-05-24 20:26:51 UTC --- Author: jason Date: Tue May 24 20:26:47 2011 New Revision: 174139 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174139 Log: PR c++/48884 * class.c (pushclass): Accept NULL argument. (popclass): Deal with popping null class. * pt.c (push_access_scope, pop_access_scope): Use them rather than push_to_top_level/pop_from_top_level. (push_deduction_access_scope, pop_defarg_context): New. (fn_type_unification): Use them. * name-lookup.c (lookup_name_real_1): Check current_class_type. Added: trunk/gcc/testsuite/g++.dg/template/access21.C trunk/gcc/testsuite/g++.dg/template/access22.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49136] [C++0x][constexpr] Incorrect constexpr c'tor evaluation with bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49136 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jason Merrill 2011-05-24 20:24:47 UTC --- (In reply to comment #4) > Created attachment 24345 [details] > gcc47-pr49136.patch > > Adjusted fix that passes also on powerpc on the testcases. OK.
[Bug c++/49042] [C++0x] wrong "protected" when using template and decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49042 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug libstdc++/49151] New: [C++0x] chrono::duration has incorrect non-member operator semantics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49151
Summary: [C++0x] chrono::duration has incorrect non-member
operator semantics
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
This entry is a reminder for the need to synchronize the library with the
accepted LWG issue 2020,
http://lwg.github.com/issues/lwg-defects.html#2020
The observable behaviour is that the following test code is rejected by gcc
4.7.0 20110521 (experimental) in C++0x mode at the line marked with #:
//
#include
constexpr std::chrono::milliseconds ms{};
constexpr auto res = ms + ms; // #
//
"error: 'typename std::common_type,
std::chrono::duration<_Rep2, _Period2> >::type std::chrono::operator+(const
std::chrono::duration<_Rep1, _Period1>&, const std::chrono::duration<_Rep2,
_Period2>&) [with _Rep1 = long long int, _Period1 = std::ratio<1ll, 1000ll>,
_Rep2 = long long int, _Period2 = std::ratio<1ll, 1000ll>, typename
std::common_type,
std::chrono::duration<_Rep2, _Period2> >::type = std::chrono::duration
[Bug c++/49152] New: Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Summary: Unhelpful diagnostic for iterator dereference
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
This code, based on what happens in std::find():
#include
struct X { };
struct Y { } val;
std::vector::iterator first;
bool b = *first == val;
produces this output:
fail.cc:8:20: error: no match for 'operator==' in
'first.__gnu_cxx::__normal_iterator<_Iterator, _Container>::operator* [with
_Iterator = X*, _Container = std::vector,
__gnu_cxx::__normal_iterator<_Iterator, _Container>::reference = X&]() == val'
or with -fno-pretty-templates
fail.cc:8:20: error: no match for 'operator==' in
'first.__gnu_cxx::__normal_iterator >
>::operator*() == val'
I have a few problems with the diagnostic, the main ones are
1) Why is the "()" after the "[with ...]" template argument list in the
-fpretty-templates version?
2) "first.__gnu_cxx::__normal_iterator<_Iterator, _Container>::operator*" is an
abomination, "*first" would be far more helpful
3) after all that verbosity about *first, there's no clue what type val is.
To be helpful it should either show something resembling the original source:
*first == val;
or it should show the types involved:
no match for operator== with operands X& and Y&
or it should show both, like clang does:
error: invalid operands to binary expression ('X' and 'struct Y')
bool b = *first == val;
~~ ^ ~~~
but what we actually have doesn't manage to resemble the original source or
show the types involved
[Bug libstdc++/49151] [C++0x][constexpr] chrono::duration has incorrect non-member operator semantics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49151 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.24 21:18:39 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2011-05-24 21:18:39 UTC --- yep, thanks for the reminder
[Bug rtl-optimization/49148] Certain expressions take an extremely long time for no apparent reason
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49148 John Peyton changed: What|Removed |Added Severity|normal |minor
