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
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
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: UNCONFIRME
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
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
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50065
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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 com
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 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50071
Mikael Morin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25062
Dominique d'Humieres changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Commen
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
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50072
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
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
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 b
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 : -
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: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50073
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||accepts-invalid
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
S
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50058
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
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
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 tre
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|
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
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:
>
> v
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.)
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
Statu
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
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?
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_convers
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
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)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063
Georg-Johann Lay changed:
What|Removed |Added
Component|target |rtl-optimization
Summary|[a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43748
Andrew Paprocki changed:
What|Removed |Added
CC||andrew at ishiboo dot com
--- Comment #
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?
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
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
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.
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?
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.
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50059
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 trun
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
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.
trict-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 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50075
Jason Merrill changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UN
: 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
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 yo
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.
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_binding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50075
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
54 matches
Mail list logo
