[Bug fortran/50069] New: FORALL fails on a character array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50069 Bug #: 50069 Summary: FORALL fails on a character array Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 24997 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24997 compile it and run Must be compiled and run. g95 and Intel ifort deliver the correct result.
[Bug fortran/50070] New: Segmentation fault at size_binop_loc in fold-const.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50070 Bug #: 50070 Summary: Segmentation fault at size_binop_loc in fold-const.c Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 24998 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24998 just compile it gfortran compiler Segmentation fault at size_binop_loc in fold-const.c
[Bug fortran/50071] New: gfortran does not distinguish labels in different type scoping units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50071 Bug #: 50071 Summary: gfortran does not distinguish labels in different type scoping units Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 24999 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24999 just compile it gfortran does not distinguish labels in different type scoping units g95 and Intel ifort compile correctly
[Bug fortran/50072] New: gfortran must not accept same name for external and common
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50072 Bug #: 50072 Summary: gfortran must not accept same name for external and common Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25000 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25000 just compile it, gfortran must reject it gfortran must not accept same name for external and common
[Bug fortran/50073] New: gfortran must not accept function name when result name is present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50073 Bug #: 50073 Summary: gfortran must not accept function name when result name is present Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25001 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25001 just compile it, gfortran must reject it gfortran must not accept function name when result name is present
[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066 --- Comment #3 from Paolo Carlini 2011-08-13 08:53:47 UTC --- Indeed. Seems invalid to me.
[Bug rtl-optimization/50065] -Os, -O2, -O3 optimization breaks LD/ST ordering on 32-bit SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50065
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||ebotcazou at gcc dot
||gnu.org
Resolution||INVALID
--- Comment #2 from Eric Botcazou 2011-08-13
10:10:47 UTC ---
> instruction 2C, clrb [%g1] corresponds to inline function 'spinlock_unlock'
> *(volatile unsigned char*)lock = 0;
>
> This happens before the lock protected content 'remap_barrier++', i.e.
>
> 30: c6 00 a0 00 ld [ %g2 ], %g3
> 34: 86 00 e0 01 inc %g3
> 38: 81 c3 e0 08 retl
> 3c: c6 20 a0 00 st %g3, [ %g2 ] ---> use the branch delay slot
>
> This is wrong and will cause serious lock issues under a multithreading
> environment.
On what grounds is this wrong exactly? The end of the code is equivalent to:
volatile unsigned char lock;
int remap_barrier;
remap_barrier++;
lock = 0;
It is perfectly valid for an optimizing C compiler to swap the two lines.
You want something like:
static inline void spin_unlock(char *lock)
{
__asm__ __volatile__("stb %%g0, [%0]" : : "r" (lock) : "memory");
}
[Bug fortran/50046] Hexadecimal Constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50046 --- Comment #4 from Mikael Morin 2011-08-13 10:11:47 UTC --- This is accepted by gfortran trunk (4.7): integer(8) :: i = ''X end Please provide a small self-contained test case demonstrating the problem. Also precise the compiler version and the command line used. Otherwise, we will close this bug. PS: see http://gcc.gnu.org/bugs/ for bug reporting tips.
[Bug fortran/50071] gfortran does not distinguish labels in different type scoping units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50071 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin 2011-08-13 11:05:19 UTC --- OK, it's valid. But is there any real need for this? The labels in the derived types aren't usable, are they? One could just throw them away.
[Bug fortran/50071] gfortran does not distinguish labels in different type scoping units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50071 Mikael Morin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-08-13 AssignedTo|unassigned at gcc dot |mikael at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Mikael Morin 2011-08-13 11:14:28 UTC --- Created attachment 25002 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25002 Patch to accept comment #0
[Bug fortran/25062] same name for parameter and common block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25062 Dominique d'Humieres changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #12 from Dominique d'Humieres 2011-08-13 11:21:34 UTC --- *** Bug 50072 has been marked as a duplicate of this bug. ***
[Bug fortran/50070] Segmentation fault at size_binop_loc in fold-const.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50070 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2011-08-13 11:22:45 UTC --- I can confirm the segfault with 4.5, 4.6 and 4.7 (trunk) on the test case in comment #0: subroutine sub common n,z character(n) z end However, when removing the subroutine line, I get: common n,z 1 Error: 'z' at (1) must have constant character length in this context And on the following variant subroutine sub common z character(n) z end one get's a different error: character(n) z 1 Error: Variable 'n' cannot appear in the expression at (1)
[Bug fortran/50072] gfortran must not accept same name for external and common
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50072 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Dominique d'Humieres 2011-08-13 11:21:34 UTC --- Gfortran gives the following error with -std=f95 (gfortran 4.4.6 to trunk): [macbook] f90/bug% gfc -std=f95 pr50072.f90 pr50072.f90:2.17: common/sub/ a 1 Error: Fortran 2003: COMMON block 'sub' at (1) that is also a global procedure but not with -std=f2003 nor with -std=f2008 as expected from the above error. This behavior has been introduced by revision 126279 (pr25062). For discussion and some pending corner cases see pr32515. *** This bug has been marked as a duplicate of bug 25062 ***
[Bug fortran/50070] Segmentation fault at size_binop_loc in fold-const.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50070 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Known to fail||4.1.2, 4.4.4, 4.5.4, 4.6.2, ||4.7.0 --- Comment #2 from janus at gcc dot gnu.org 2011-08-13 11:53:58 UTC --- (In reply to comment #1) > I can confirm the segfault with 4.5, 4.6 and 4.7 (trunk) on the test case in > comment #0: Same with 4.4 and 4.1. Apparently this bug has been existing forever. ifort rejects the original test case with: error #6756: A COMMON block data object must not be an automatic object. [Z] common n,z ---^ g95 says: common n,z 1 Error: Character variable 'z' at (1) must have a constant length I assume this is an ice-on-invalid-code.
[Bug fortran/50070] Segmentation fault at size_binop_loc in fold-const.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50070
--- Comment #3 from janus at gcc dot gnu.org 2011-08-13 12:05:31 UTC ---
(In reply to comment #2)
> I assume this is an ice-on-invalid-code.
The relevant quote from the F08 std is probably:
"C417 (R422) A type-param-value in a char-length shall be a colon, asterisk, or
speciļ¬cation-expr."
together with chapter 7.1.11 ("Speciļ¬cation expression").
[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066
--- Comment #4 from H.J. Lu 2011-08-13 12:09:16
UTC ---
This code comes from mpz/set_si.c in gmp:
void
mpz_set_si (mpz_ptr dest, signed long int val)
{
mp_size_t size;
mp_limb_t vl;
vl = (mp_limb_t) (unsigned long int) (val >= 0 ? val : -val);
mp_limb_t is unsigned 64bit and long is 32bit. It works
with all released GCC versions.
[Bug tree-optimization/50074] New: [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50074 Bug #: 50074 Summary: [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64-apple-darwin10 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr Between revisions 176012 and 176060 running gcc.dg/sibcall-6.c compiled with -O2 -foptimize-sibling-calls -fno-ipa-cp on x86_64-apple-darwin10 aborts.
[Bug fortran/50073] gfortran must not accept function name when result name is present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50073 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2011-08-13 12:44:18 UTC --- Confirmed. However, the following variant is rejected correctly: function fun() result(f) integer :: fun f = 0 end integer :: fun 1 Error: Function name 'fun' not allowed at (1)
[Bug c++/50075] New: ICE related to parameter deduction and initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50075
Bug #: 50075
Summary: ICE related to parameter deduction and
initializer_list
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: z...@sogetthis.com
Host: x86
Target: x86
[Please rephrase the title with something more appropriate, I don't know how to
pin this down.]
I was trying to deduce the size parameter of an std::array from the size
of an initializer list. The following code is probably not correct, but in any
event, it causes GCC 4.6.1 with -std=c++0x to crash:
#include
#include
template
std::array make_array_helper(const std::initializer_list & il)
{
return std::array(il);
}
template
auto make_array(const std::initializer_list & il) ->
decltype(make_array(il))
{
return make_array_helper(il);
}
int main()
{
auto z = make_array({{1,2}});
}
[Bug c++/50058] [4.7 Regression] FAIL: g++.dg/tree-ssa/pr41186.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50058 --- Comment #1 from Dominique d'Humieres 2011-08-13 13:45:50 UTC --- Created attachment 25003 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25003 pr41186.C.027t.fre1 file
[Bug c++/50058] [4.7 Regression] FAIL: g++.dg/tree-ssa/pr41186.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50058 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-13 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres 2011-08-13 13:47:05 UTC --- On x86_64-apple-darwin10 I get [macbook] f90/bug% grep Replaced pr41186.C.027t.fre1 Replaced b1.b with 1 in D.2166_2 = b1.b; I have attached the pr41186.C.027t.fre1 file.
[Bug c++/50075] ICE related to parameter deduction and initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50075 --- Comment #1 from Jonathan Wakely 2011-08-13 14:00:45 UTC --- obviously it shouldn't crash, but what you're trying won't work, because initializer_list::size is not constexpr, so il.size() is not a constant expression
[Bug c++/50075] ICE related to parameter deduction and initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50075 --- Comment #2 from Kerrek SB 2011-08-13 14:09:20 UTC --- Indeed, according to the FDIS size() is *not* constexpr, but I had initially just checked the GCC implementation, in which it *is* declared as constexpr! (This is in "c++/4.6.1/initializer_list".)
[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066 --- Comment #5 from H.J. Lu 2011-08-13 14:27:58 UTC --- Does this patch --- diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index df7a9a2..f5e0a30 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -2065,6 +2065,12 @@ vrp_int_const_binop (enum tree_code code, tree val1, tree val2) && is_overflow_infinity (val2)) return NULL_TREE; + /* Punt integer subtraction with overflow on -MIN. */ + if (code == MINUS_EXPR + && INTEGRAL_TYPE_P (TREE_TYPE (res)) + && (sgn1 < 0 || sgn2 < 0)) +return NULL_TREE; + /* Don't try to handle division or shifting of infinities. */ if ((code == TRUNC_DIV_EXPR || code == FLOOR_DIV_EXPR --- make any senses?
[Bug fortran/50073] gfortran must not accept function name when result name is present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50073 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-08-13 AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org 2011-08-13 14:54:28 UTC --- Mine (have a patch).
[Bug testsuite/50076] New: FAIL: c-c++-common/cxxbitfields-3.c scan-assembler movl.*, var on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50076 Bug #: 50076 Summary: FAIL: c-c++-common/cxxbitfields-3.c scan-assembler movl.*, var on x86_64-apple-darwin10 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: al...@gcc.gnu.org Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 scan-assembler for c-c++-common/cxxbitfields-3.c fails on x86_64-apple-darwin10. The assembly is .text .align 4,0x90 .globl _setit _setit: LFB0: movq_var@GOTPCREL(%rip), %rdx movl(%rdx), %eax andb$15, %al orl$80, %eax movl%eax, (%rdx) ret LFE0: .comm_var,4,2 .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support EH_frame1: .set L$set$0,LECIE1-LSCIE1 .long L$set$0 LSCIE1: .long0 .byte0x1 .ascii "zR\0" .byte0x1 .byte0x78 .byte0x10 .byte0x1 .byte0x10 .byte0xc .byte0x7 .byte0x8 .byte0x90 .byte0x1 .align 3 LECIE1: LSFDE1: .set L$set$1,LEFDE1-LASFDE1 .long L$set$1 LASFDE1: .longLASFDE1-EH_frame1 .quadLFB0-. .set L$set$2,LFE0-LFB0 .quad L$set$2 .byte0 .align 3 LEFDE1: .subsections_via_symbols The test has been introduced in revision 176824 and probably never succeeded. I cannot tell if the test should be updated for darwin or if it is a bug in the compiler.
[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066
--- Comment #6 from joseph at codesourcery dot com 2011-08-13 15:28:22 UTC ---
On Sat, 13 Aug 2011, hjl.tools at gmail dot com wrote:
> --- Comment #4 from H.J. Lu 2011-08-13 12:09:16
> UTC ---
> This code comes from mpz/set_si.c in gmp:
>
> void
> mpz_set_si (mpz_ptr dest, signed long int val)
> {
> mp_size_t size;
> mp_limb_t vl;
>
> vl = (mp_limb_t) (unsigned long int) (val >= 0 ? val : -val);
So that GMP code is buggy. Change it to
vl = (mp_limb_t) (val >= 0 ? (unsigned long int) val : -(unsigned long int)
val);
and it will be valid.
[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066 --- Comment #7 from joseph at codesourcery dot com 2011-08-13 15:31:05 UTC --- (The original code is of course valid if you use -fwrapv, so hopefully the problem optimization does not occur in that case.)
[Bug target/50077] New: FAIL: gcc.target/i386/pr49866.c (test for excess errors) on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50077 Bug #: 50077 Summary: FAIL: gcc.target/i386/pr49866.c (test for excess errors) on x86_64-apple-darwin10 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ia...@gcc.gnu.org, ja...@gcc.gnu.org, ubiz...@gmail.com Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 On x86_64-apple-darwin10 gcc.target/i386/pr49866.c fails with [macbook] f90/bug% gcc47 -O2 -mcmodel=large /opt/gcc/work/gcc/testsuite/gcc.target/i386/pr49866.c /var/folders/LW/LW1oufkMGIqlLpjYn45fBU+++TI/-Tmp-//ccCXYFLc.s:10:junk `@PLTOFF' after expression /var/folders/LW/LW1oufkMGIqlLpjYn45fBU+++TI/-Tmp-//ccCXYFLc.s:32:junk `@PLTOFF' after expression /var/folders/LW/LW1oufkMGIqlLpjYn45fBU+++TI/-Tmp-//ccCXYFLc.s:34:junk `@PLTOFF' after expression /var/folders/LW/LW1oufkMGIqlLpjYn45fBU+++TI/-Tmp-//ccCXYFLc.s:48:junk `@PLTOFF' after expression The test has been introduced at revision 176842, but fails for all the gcc versions I have tried from 4.4.6 to trunk.
[Bug c++/50075] ICE related to parameter deduction and initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50075 --- Comment #3 from Jonathan Wakely 2011-08-13 15:42:06 UTC --- ah, sorry, I didn't check our impl - so then it should work, just isn't portable
[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066 --- Comment #8 from H.J. Lu 2011-08-13 15:56:22 UTC --- make_overflow_infinity sets to TYPE_MAX_VALUE/TYPE_MIN_VALUE. Shouldn't it set to TYPE_MAX_VALUE + 1/TYPE_MIN_VALUE - 1?
[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066 --- Comment #9 from H.J. Lu 2011-08-13 16:33:19 UTC --- Shouldn't we check TREE_OVERFLOW: diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index df7a9a2..4ec7e5b 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -7263,6 +7263,8 @@ simplify_conversion_using_ranges (gimple stmt) /* Get the value-range of the inner operand. */ innervr = get_value_range (innerop); if (innervr->type != VR_RANGE + || TREE_OVERFLOW (innervr->min) + || TREE_OVERFLOW (innervr->max) || TREE_CODE (innervr->min) != INTEGER_CST || TREE_CODE (innervr->max) != INTEGER_CST) return false;
[Bug target/50063] [avr]: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #2 from Georg-Johann Lay 2011-08-13 17:04:10 UTC --- Created attachment 25004 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25004 asm-no-dse.s Compiler output with -Os -mmcu=atmega8 -fno-dse
[Bug target/50063] [avr]: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #3 from Georg-Johann Lay 2011-08-13 17:05:39 UTC --- Created attachment 25005 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25005 asm-dse.s Compiler output with -Os -mmcu=atmega8 (-fdse by default)
[Bug rtl-optimization/50063] [avr]: DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 Georg-Johann Lay changed: What|Removed |Added Component|target |rtl-optimization Summary|[avr]: wrong code for |[avr]: DSE: wrong code for |gcc.dg/torture/pta-ptrarith |gcc.dg/torture/pta-ptrarith |-3.c|-3.c --- Comment #4 from Georg-Johann Lay 2011-08-13 17:09:49 UTC --- This is not a target issue. RTL Dead Store Elimination (DSE), activated by -fdse, deletes insns that are not dead.
[Bug other/43748] build machinery insufficient for installing target specific .def files as plugin headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43748 Andrew Paprocki changed: What|Removed |Added CC||andrew at ishiboo dot com --- Comment #1 from Andrew Paprocki 2011-08-13 17:32:37 UTC --- This breaks the installation of gcc-4.5 via macports. When trying to build anything which uses the plugin API, it can't find darwin-sections.def so you have to manually extract it from the tarball and sudo cp it to the installed macports directory to get the build working.
[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066 --- Comment #10 from Andrew Pinski 2011-08-13 17:51:33 UTC --- HJL, the code as written in comment #0 is undefined. Does the rewrite in comment #6 work? Also does adding -fwrapv work too?
[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066 --- Comment #11 from H.J. Lu 2011-08-13 18:11:56 UTC --- Created attachment 25006 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25006 A patch GMP code may be buggy. But it works with all other compilers, including GCC 4.6.0 and older. Is there any particular good reason to ignore range overflow? This patch checks range overflow and caused no regressions on Linux/x86.
[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066 --- Comment #12 from Andrew Pinski 2011-08-13 18:17:24 UTC --- (In reply to comment #11) > Created attachment 25006 [details] > A patch > > GMP code may be buggy. But it works with all other compilers, > including GCC 4.6.0 and older. Is there any particular good > reason to ignore range overflow? This patch checks range > overflow and caused no regressions on Linux/x86. No Again we decided long ago to have overflow declared as being undefined and ignoring range overflow is not what we decided. It might work with other compilers does not mean it is valid and well defined code.
[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066 --- Comment #13 from H.J. Lu 2011-08-13 18:23:14 UTC --- We should consider our users. GMP has been working with GCC for a long time. Now it fails with GCC 4.7. It is a very bad GCC 4.7 experience for user.
[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066 --- Comment #14 from H.J. Lu 2011-08-13 18:32:53 UTC --- What possible optimization do we gain by not checking range overflow? Does anyone have a testcase to show it?
[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066 --- Comment #15 from Andrew Pinski 2011-08-13 19:00:48 UTC --- (In reply to comment #13) > We should consider our users. GMP has been working with > GCC for a long time. Now it fails with GCC 4.7. It is > a very bad GCC 4.7 experience for user. Yes and other packages failed when the original VPR and overflow was introduced. Why should this case be any different than all the others?
[Bug c++/50059] [C++0x] Broken error message with __builtin_remquo & constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50059 --- Comment #5 from Jason Merrill 2011-08-13 20:03:26 UTC --- Author: jason Date: Sat Aug 13 20:03:23 2011 New Revision: 177735 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177735 Log: PR c++/50059 * error.c (dump_expr): Handle MODIFY_EXPR properly. Added: trunk/gcc/testsuite/g++.dg/diagnostic/expr1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50059] [C++0x] Broken error message with __builtin_remquo & constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50059 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at redhat dot com |gnu.org | Target Milestone|--- |4.7.0 --- Comment #6 from Jason Merrill 2011-08-13 20:13:40 UTC --- Fixed to print (r = 0) instead. Anything further would need to change the front end to delay folding like the C front end does.
[Bug bootstrap/50047] [4.7 Regression] Revision 177670 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50047 --- Comment #2 from gfunck at gcc dot gnu.org 2011-08-13 20:49:13 UTC --- Author: gfunck Date: Sat Aug 13 20:49:08 2011 New Revision: 177736 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177736 Log: 2011-08-13 Gary Funck Merge trunk version 177706 into gupc branch. Incorporate fix to PR bootstrap/50047 to fix broken IA64 libunwind Makefile logic. Added: branches/gupc/fixincludes/tests/base/iso/math_iso.h - copied unchanged from r177706, trunk/fixincludes/tests/base/iso/math_iso.h branches/gupc/fixincludes/tests/base/iso/setjmp_iso.h - copied unchanged from r177706, trunk/fixincludes/tests/base/iso/setjmp_iso.h branches/gupc/fixincludes/tests/base/iso/stdio_iso.h - copied unchanged from r177706, trunk/fixincludes/tests/base/iso/stdio_iso.h branches/gupc/fixincludes/tests/base/iso/stdlib_iso.h - copied unchanged from r177706, trunk/fixincludes/tests/base/iso/stdlib_iso.h branches/gupc/gcc/config/sparc/driver-sparc.c - copied unchanged from r177706, trunk/gcc/config/sparc/driver-sparc.c branches/gupc/gcc/config/sparc/x-sparc - copied unchanged from r177706, trunk/gcc/config/sparc/x-sparc branches/gupc/gcc/data-streamer-in.c - copied unchanged from r177706, trunk/gcc/data-streamer-in.c branches/gupc/gcc/data-streamer-out.c - copied unchanged from r177706, trunk/gcc/data-streamer-out.c branches/gupc/gcc/data-streamer.c - copied unchanged from r177706, trunk/gcc/data-streamer.c branches/gupc/gcc/data-streamer.h - copied unchanged from r177706, trunk/gcc/data-streamer.h branches/gupc/gcc/gimple-streamer-in.c - copied unchanged from r177706, trunk/gcc/gimple-streamer-in.c branches/gupc/gcc/gimple-streamer-out.c - copied unchanged from r177706, trunk/gcc/gimple-streamer-out.c branches/gupc/gcc/gimple-streamer.h - copied unchanged from r177706, trunk/gcc/gimple-streamer.h branches/gupc/gcc/streamer-hooks.c - copied unchanged from r177706, trunk/gcc/streamer-hooks.c branches/gupc/gcc/streamer-hooks.h - copied unchanged from r177706, trunk/gcc/streamer-hooks.h branches/gupc/gcc/testsuite/g++.dg/plugin/decl-plugin-test.C - copied unchanged from r177706, trunk/gcc/testsuite/g++.dg/plugin/decl-plugin-test.C branches/gupc/gcc/testsuite/g++.dg/plugin/decl_plugin.c - copied unchanged from r177706, trunk/gcc/testsuite/g++.dg/plugin/decl_plugin.c branches/gupc/gcc/testsuite/gcc.c-torture/execute/scal-to-vec1.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.c-torture/execute/scal-to-vec1.c branches/gupc/gcc/testsuite/gcc.c-torture/execute/scal-to-vec2.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.c-torture/execute/scal-to-vec2.c branches/gupc/gcc/testsuite/gcc.c-torture/execute/scal-to-vec3.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.c-torture/execute/scal-to-vec3.c branches/gupc/gcc/testsuite/gcc.dg/builtins-67.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.dg/builtins-67.c branches/gupc/gcc/testsuite/gcc.dg/scal-to-vec1.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.dg/scal-to-vec1.c branches/gupc/gcc/testsuite/gcc.dg/scal-to-vec2.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.dg/scal-to-vec2.c branches/gupc/gcc/testsuite/gcc.dg/tree-ssa/pr49923.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.dg/tree-ssa/pr49923.c branches/gupc/gcc/testsuite/gcc.dg/tree-ssa/vrp60.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp60.c branches/gupc/gcc/testsuite/gcc.dg/tree-ssa/vrp61.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp61.c branches/gupc/gcc/testsuite/gcc.dg/tree-ssa/vrp62.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp62.c branches/gupc/gcc/testsuite/gcc.dg/vect/no-tree-fre-pr50039.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.dg/vect/no-tree-fre-pr50039.c branches/gupc/gcc/testsuite/gcc.dg/vect/pr50014.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.dg/vect/pr50014.c branches/gupc/gcc/testsuite/gcc.target/i386/conversion.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.target/i386/conversion.c branches/gupc/gcc/testsuite/gcc.target/i386/pr49781-1.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.target/i386/pr49781-1.c branches/gupc/gcc/testsuite/gcc.target/i386/sse-22a.c - copied unchanged from r177706, trunk/gcc/testsuite/gcc.target/i386/sse-22a.c branches/gupc/gcc/testsuite/gfortran.dg/typebound_override_1.f90 - copied unchanged from r177706, trunk/gcc/testsuite/gfortran.dg/typebound_override_1.f90 branches/gupc/gcc/tree-streamer-in.c - copied unchanged from r177706, trunk/gcc/tree-streamer-in.c branches/gupc/gc
[Bug debug/50006] [4.7 Regression] ICE in in connect_traces, at dwarf2cfi.c:2677
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50006 --- Comment #9 from John David Anglin 2011-08-13 21:33:41 UTC --- Created attachment 25007 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25007 Source files
[Bug c++/50059] [C++0x] Broken error message with __builtin_remquo & constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50059 --- Comment #7 from Paolo Carlini 2011-08-13 21:33:52 UTC --- Ah, thanks also for the clarification. Anyway, at least now the error message makes clear why *exactly* the functions isn't viable as constexpr.
[Bug debug/50006] [4.7 Regression] ICE in in connect_traces, at dwarf2cfi.c:2677
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50006 --- Comment #10 from John David Anglin 2011-08-13 21:35:34 UTC --- Unfortunately, the proposed patch isn't sufficient. We hit another similar ICE a little later in the build: ../../xgcc -B../../ -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmis sing-prototypes -mdisable-indexing -gnatpg -gnata -I- -I../rts -I. -I/test/gnu/g cc/gcc/gcc/ada /test/gnu/gcc/gcc/gcc/ada/prj-proc.adb -o prj-proc.o +===GNAT BUG DETECTED==+ | 4.7.0 20110813 (experimental) [trunk revision 177733] (hppa2.0w-hp-hpux11.11) GCC error:| | in connect_traces, at dwarf2cfi.c:2677 | | Error detected around /test/gnu/gcc/gcc/gcc/ada/prj-proc.adb:1252:8 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). ../rts/system.ads /test/gnu/gcc/gcc/gcc/ada/prj-proc.adb /test/gnu/gcc/gcc/gcc/ada/prj-proc.ads /test/gnu/gcc/gcc/gcc/ada/prj.ads /test/gnu/gcc/gcc/gcc/ada/casing.ads /test/gnu/gcc/gcc/gcc/ada/types.ads ../rts/unchconv.ads ../rts/unchdeal.ads /test/gnu/gcc/gcc/gcc/ada/namet.ads /test/gnu/gcc/gcc/gcc/ada/alloc.ads /test/gnu/gcc/gcc/gcc/ada/table.ads /test/gnu/gcc/gcc/gcc/ada/hostparm.ads /test/gnu/gcc/gcc/gcc/ada/osint.ads ../rts/s-os_lib.ads ../rts/s-string.ads ../rts/ada.ads ../rts/a-uncdea.ads ../rts/s-stoele.ads /test/gnu/gcc/gcc/gcc/ada/scans.ads /test/gnu/gcc/gcc/gcc/ada/uintp.ads /test/gnu/gcc/gcc/gcc/ada/urealp.ads ../rts/gnat.ads ../rts/g-dynhta.ads ../rts/g-dyntab.ads ../rts/g-os_lib.ads /test/gnu/gcc/gcc/gcc/ada/prj-tree.ads /test/gnu/gcc/gcc/gcc/ada/prj-attr.ads ../rts/g-string.ads /test/gnu/gcc/gcc/gcc/ada/prj-env.ads /test/gnu/gcc/gcc/gcc/ada/prj-ext.ads /test/gnu/gcc/gcc/gcc/ada/err_vars.ads /test/gnu/gcc/gcc/gcc/ada/opt.ads ../rts/s-wchcon.ads /test/gnu/gcc/gcc/gcc/ada/output.ads /test/gnu/gcc/gcc/gcc/ada/prj-err.ads /test/gnu/gcc/gcc/gcc/ada/scng.ads /test/gnu/gcc/gcc/gcc/ada/styleg.ads /test/gnu/gcc/gcc/gcc/ada/errutil.ads /test/gnu/gcc/gcc/gcc/ada/prj-nmsc.ads /test/gnu/gcc/gcc/gcc/ada/prj-part.ads ./snames.ads ../rts/a-string.ads ../rts/a-strfix.ads ../rts/a-strmap.ads ../rts/a-charac.ads ../rts/a-chlat1.ads ../rts/g-casuti.ads ../rts/s-casuti.ads ../rts/g-htable.ads ../rts/s-htable.ads ../rts/s-exctab.ads ../rts/s-stalib.ads ../rts/a-unccon.ads ../rts/s-unstyp.ads ../rts/s-stoele.adb ../rts/a-fihema.ads ../rts/a-finali.ads ../rts/s-finroo.ads ../rts/a-stream.ads ../rts/s-stopoo.ads ../rts/a-tags.ads ../rts/s-soflin.ads ../rts/a-except.ads ../rts/s-parame.ads ../rts/s-traent.ads ../rts/s-stache.ads ../rts/s-secsta.ads ../rts/s-pooglo.ads ../rts/s-assert.ads ../rts/s-imenne.ads ../rts/s-imgboo.ads ../rts/s-htable.adb ../rts/s-strhas.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423 make[3]: *** [prj-proc.o] Error 1 make[3]: Leaving directory `/test/gnu/gcc/objdir/gcc/ada/tools' make[2]: *** [gnattools-native] Error 2 make[2]: Leaving directory `/test/gnu/gcc/objdir/gnattools' make[1]: *** [all-gnattools] Error 2 make[1]: *** Waiting for unfinished jobs
[Bug c++/50075] [C++0x] ICE related to parameter deduction and initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50075 Jason Merrill changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-08-13 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #4 from Jason Merrill 2011-08-13 22:00:34 UTC --- The problem is the recursion: template auto make_array(const std::initializer_list & il) -> decltype(make_array(il)) You're declaring make_array to have the same return type as itself. 4.6 happily goes down the rabbit hole until it runs out of stack. 4.7 complains and then crashes for another reason, which I will fix.
[Bug c/50078] New: [4.6.1+ SVN 2011-08-13] ARM wrong code: volatile accesses optimized out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50078
Bug #: 50078
Summary: [4.6.1+ SVN 2011-08-13] ARM wrong code: volatile
accesses optimized out
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: k...@pm.waw.pl
I think armeb-pc-linux-gnueabi-gcc 4.6.2pre 20110813 (cross-compiled on x86-64)
is a bit too optimistic with -O2:
unsigned var[2];
void test(int arg)
{
unsigned v = *(volatile unsigned *)(&var[arg]);
*(volatile unsigned *)(&var[arg]) = v;
}
produces:
:
0: e12fff1ebx lr
[Bug rtl-optimization/50065] -Os, -O2, -O3 optimization breaks LD/ST ordering on 32-bit SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50065
--- Comment #3 from Zhangxi Tan 2011-08-14
00:57:07 UTC ---
The code is equivalent to
volatile unsigned char lock;
int remap_barrier;
while (atomic_test_and_set(lock)) {
while (lock) {
;
}
}
remap_barrier++;
lock = 0;
Eric: could you let me know you you think the code inside function
spinlock_lock(&remap_lock) is a NOP? This is a suggested lock implementation by
the SPARC spec. Also, the arch_write_lock/unlock in the SPARC port of Linux
uses a very similar implementation.
Andrew: could you let me know in which version I can find this ipa-sra fix? At
least, the stable 4.6.1 doesn't work.
[Bug rtl-optimization/50065] -Os, -O2, -O3 optimization breaks LD/ST ordering on 32-bit SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50065
--- Comment #4 from Zhangxi Tan 2011-08-14
01:30:33 UTC ---
I don't think this is an valid optimization.
There are only two memory models in SPARC32, TSO and PSO (not RMO in the 64-bit
v9). Both don't allow relaxing the read->write order, i.e. 'LD remap_barrier'
should always be executed before 'ST lock'.
This optimization violates the memory model, therefore should be prohibited.
In addition, I still(In reply to comment #2)
> > instruction 2C, clrb [%g1] corresponds to inline function 'spinlock_unlock'
> > *(volatile unsigned char*)lock = 0;
> >
> > This happens before the lock protected content 'remap_barrier++', i.e.
> >
> > 30: c6 00 a0 00 ld [ %g2 ], %g3
> > 34: 86 00 e0 01 inc %g3
> > 38: 81 c3 e0 08 retl
> > 3c: c6 20 a0 00 st %g3, [ %g2 ] ---> use the branch delay slot
> >
> > This is wrong and will cause serious lock issues under a multithreading
> > environment.
>
> On what grounds is this wrong exactly? The end of the code is equivalent to:
>
> volatile unsigned char lock;
> int remap_barrier;
>
> remap_barrier++;
> lock = 0;
>
> It is perfectly valid for an optimizing C compiler to swap the two lines.
>
> You want something like:
>
> static inline void spin_unlock(char *lock)
> {
> __asm__ __volatile__("stb %%g0, [%0]" : : "r" (lock) : "memory");
> }
[Bug c++/50075] [C++0x] ICE related to parameter deduction and initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50075 --- Comment #5 from Jason Merrill 2011-08-14 04:41:49 UTC --- Author: jason Date: Sun Aug 14 04:41:43 2011 New Revision: 177743 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177743 Log: PR c++/50075 * name-lookup.c (local_bindings_p): New. * name-lookup.h: Declare it. * lex.c (unqualified_name_lookup_error): Use it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype32.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/lex.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/name-lookup.h trunk/gcc/testsuite/ChangeLog
[Bug c++/50075] [C++0x] ICE related to parameter deduction and initializer_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50075 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jason Merrill 2011-08-14 04:43:39 UTC --- Fixed for 4.7.
