--- Comment #1 from Denis dot Excoffier at airbus dot com 2010-06-11 08:05
---
The same applies to mpfr-3.0.0 (now official). The MPFR people have however
added the following note in ./INSTALL:
> As gmp-impl.h and longlong.h are only in the GMP source directory,
> you first need to cop
--- Comment #5 from iains at gcc dot gnu dot org 2010-06-11 08:32 ---
closing as fixed after back-porting to the 4.5 release branch at r160482
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from iains at gcc dot gnu dot org 2010-06-11 08:36 ---
is this now fixed?
in 4.5 after r160526,
and trunk after r160457
which should have made the detection of emulated TLS more reliable.
--
iains at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from iains at gcc dot gnu dot org 2010-06-11 08:37 ---
closing as fixed by r160457 (trunk) and r160526 (4.5 release branch)
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #77 from iains at gcc dot gnu dot org 2010-06-11 08:38 ---
no new issues having been reported by the regression testers, closing this as
fixed.
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-06-11 08:43
---
I remember discussing that a long while back, and I don't think people had
strong opinions. WONTFIX seems good.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #17 from iains at gcc dot gnu dot org 2010-06-11 08:57 ---
closing as fixed after back-ports to the current release branch (4.5) for
various ObjC fixes including the ones listed here:
r160482, r160541, r160546
--
iains at gcc dot gnu dot org changed:
What|
The following code:
class C {
};
class D : public C {
};
const D g_d;
fails to compile on trunk (rev. 160489) with the following message:
$ g++ test.cpp
test.cpp:11:9: error: uninitialized const 'g_d' [-fpermissive]
test.cpp:6:11: note: 'const class D' has no user-provid
--- Comment #6 from iains at gcc dot gnu dot org 2010-06-11 09:10 ---
@r160568 (or earlier) this is no longer showing.
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-11 09:26 ---
gcc is correct, accepting the code previously was a bug that was fixed recently
You need to provide an initializer for g_d
--
redi at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-11 10:27 ---
A question: apart from quoting chapter and verse from the standard (8.5
[dcl.init], para 9 in C++03, para 6 in C++0x,) how could the diagnostic have
been any clearer?
It indicates you can use -fpermissive to relax the
Compiling with g++ -std=c++0x, using gcc-4.5.0 :
struct A {
char x;
};
template void f() {
char y = 42;
A a = { y+C };
}
int main() {
f<1>();
}
yields an "error: narrowing conversion of â(((int)y) + 8)â from âintâ
to âcharâ inside { }".
If I change th
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-06-11 10:47
---
Reduced testcase at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00131.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-06-11 10:48
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #9 from aoliva at gcc dot gnu dot org 2010-06-11 10:49 ---
Steve, lto and whopr seem to have been introduced in a way that broke VTA.
This is not ia64-specific, and it's not what this bug is about. I guess what
you're seeing are other cases of lossage, that we might have to
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-11 10:53 ---
(In reply to comment #1)
> gcc is correct, accepting the code previously was a bug that was fixed
> recently
>
> You need to provide an initializer for g_d
This sort of changes should be documented in the changes.htm
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-11 10:57 ---
I wonder what the C++ standard said because we have the same issue in
Wconversion and Joseph rejected my patch arguing that the operation was done in
the larger type, so there was a narrowing conversion. I still believe
--- Comment #4 from piotr dot wyderski at gmail dot com 2010-06-11 11:01
---
(In reply to comment #2)
> A question: apart from quoting chapter and verse from the standard (8.5
> [dcl.init], para 9 in C++03, para 6 in C++0x,) how could the diagnostic have
> been any clearer?
>
> It indi
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-11 11:11 ---
Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
Copyright 1988-2008 Comeau Computing. All rights reserved.
MODE:strict errors C++ C++0x_extensions
"ComeauTest.c", line 9: error: const variable
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org
|dot org
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-11 11:13 ---
LLVM is still using GCC in their demo, not Clang. So I cannot test their
output.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
--- Comment #2 from gpiez at web dot de 2010-06-11 11:34 ---
Sorry for the unicode mess. The error message is 'error: narrowing conversion
of "(((int)y) + 1)" from "int" to "char" inside { }'.
The same error happens with a non templated function, but if I use two template
parameters, th
--- Comment #3 from redi at gcc dot gnu dot org 2010-06-11 11:37 ---
'y' and 'C' are both promoted to int and 'y' is not a constant, so the
resulting value cannot be proven to fit in a char, so it's a narrowing
conversion.
If you make 'y' a const int then the value y+C is a constant and
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-11 11:42 ---
(In reply to comment #2)
> Sorry for the unicode mess. The error> I believe I should not get an error,
> even if the template parameter type is
> larger than a char, as long as the template parameter value fits in in c
--- Comment #7 from aoliva at gcc dot gnu dot org 2010-06-11 11:45 ---
Not a bug
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIR
--- Comment #10 from ro at gcc dot gnu dot org 2010-06-11 11:46 ---
Subject: Bug 44216
Author: ro
Date: Fri Jun 11 11:45:59 2010
New Revision: 160602
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160602
Log:
Backport from mainline:
2010-05-25 Rainer Orth
--- Comment #11 from ro at gcc dot gnu dot org 2010-06-11 11:49 ---
Subject: Bug 44216
Author: ro
Date: Fri Jun 11 11:49:16 2010
New Revision: 160603
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160603
Log:
config:
* override.m4 (AC_LANG_WERROR): Redefine to au
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44497
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44498
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44495
--- Comment #5 from gpiez at web dot de 2010-06-11 12:09 ---
So is it provable that for a "T op T" to be stored in T no narrowing takes
place?
If the answer for T == char is no and for T == int it is yes this is rather
fishy ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-06-11 12:23 ---
Mine
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #3 from aoliva at gcc dot gnu dot org 2010-06-11 12:23 ---
Created an attachment (id=20887)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20887&action=view)
Patch that fixes the problem
Here's the patch I'm testing now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #4 from aoliva at gcc dot gnu dot org 2010-06-11 12:28 ---
*** Bug 44247 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44181
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-06-11 12:28 ---
The patch for bug 44181 fixes this one as well.
*** This bug has been marked as a duplicate of 44181 ***
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-11 12:43 ---
(In reply to comment #2)
> It could be a dup of PR 44498.
It if does not turn out to be a dup of the bitmap work / PR 44498, we need a
backtrace or valgrind trace (with minimal options, e.g. -O0 if possible).
--
--- Comment #6 from redi at gcc dot gnu dot org 2010-06-11 12:51 ---
(In reply to comment #5)
> So is it provable that for a "T op T" to be stored in T no narrowing takes
> place?
Yes, if the values are constants.
> If the answer for T == char is no and for T == int it is yes this is r
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-06-11 12:56 ---
*** Bug 43650 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44181
--- Comment #3 from aoliva at gcc dot gnu dot org 2010-06-11 12:56 ---
Unlike PR43656, this one is also fixed by the patch proposed for PR44181.
*** This bug has been marked as a duplicate of 44181 ***
--
aoliva at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from manu at gcc dot gnu dot org 2010-06-11 13:07 ---
He is referring to a testcase like:
template void f() {
struct A {
T x;
};
T y = 42;
A a = { y + C };
}
int main() {
f();
f();
}
So, we warn for T == char but not for T == int. I know that the standa
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #8 from redi at gcc dot gnu dot org 2010-06-11 13:20 ---
(In reply to comment #7)
> He is referring to a testcase like:
>
> template void f() {
> struct A {
> T x;
> };
>
> T y = 42;
> A a = { y + C };
> }
>
> int main() {
> f();
> f();
> }
>
> So, we warn
--- Comment #22 from jakub at gcc dot gnu dot org 2010-06-11 13:22 ---
Created an attachment (id=20888)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20888&action=view)
gcc46-pr44492.patch
Updated patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed
Hello,
it seems if there is a bug in the avr 32 gcc compiler.
avr32-gcc: version 4.3.2
toolchain: avr32-gnu-toolchain-2.4.2-setup.exe
avr32studio: avr32studio-ide-installer-2.5.0.35-win32.win32.x86.exe
Both got from www.atmel.com
Device: UC3B0256
Compilerflags: -O2 -g2 -mpart=uc3b0256
When compi
--- Comment #9 from gpiez at web dot de 2010-06-11 13:27 ---
I understand now after the implicit promotion to int of a non constant value
the result of the narrowing operation can't be guaranteed to fit in the
original type. But I still think it shouldn't give an error, and if the
standa
--- Comment #1 from roland dot cassebohm at dh-partner dot com 2010-06-11
13:27 ---
Created an attachment (id=20889)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20889&action=view)
Test program
This file could be compiled alone with
avr32-gcc -v -save-temps -O2 -g3 -mpart=uc3b0
--- Comment #2 from roland dot cassebohm at dh-partner dot com 2010-06-11
13:29 ---
Created an attachment (id=20890)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20890&action=view)
Listfile with resulted assembler
Generated with:
avr32-objdump.exe -S main.o > main.lst
--
ht
--- Comment #3 from roland dot cassebohm at dh-partner dot com 2010-06-11
13:31 ---
Created an attachment (id=20891)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20891&action=view)
gcc output
Output of avr32-gcc by using:
avr32-gcc -v -save-temps -O2 -g3 -mpart=uc3b0256 -c main.
--- Comment #10 from manu at gcc dot gnu dot org 2010-06-11 13:33 ---
(In reply to comment #8)
>
> In both cases, T+T has type int,
We know that, but I don't think most C/C++ programmers know about integer
promotion rules. We just disagree here. But since this is mandated by the
stand
--
roland dot cassebohm at dh-partner dot com changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=445
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-06-11 13:38
---
(In reply to comment #2)
> Still true for gcc version 4.6.0 20100509 (experimental) (GCC)
I don't know if it's worth the extra work, but this can be tackled in
gfc_conv_substring() by checking whether start.expr
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2010-06-11 13:51
---
> if(atan(1.0, i/10.0) -atan2(1.0, i/10.)/= 0.0) call abort()
Try to change that into a "print *, atan(1.0, i/10.0) -atan2(1.0, i/10.)"
and see what it outputs.
--
fxcoudert at gcc dot gnu dot o
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2010-06-11 13:52
---
OK, so I suppose the test is a bit extreme, but other than that, I vote for
WONTFIX (or INVALID).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33584
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-06-11 13:57 ---
Mine
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-11 13:58 ---
Latest draft: ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1808.pdf
Time line: ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1812.txt (-> 2nd draft:
2010-10)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41897
--- Comment #6 from aoliva at gcc dot gnu dot org 2010-06-11 14:00 ---
Created an attachment (id=20892)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20892&action=view)
Patch that fixes the problem
This patch (perhaps in addition to the patch for PR 44181, I haven't tried the
old
--- Comment #6 from gael dot guennebaud at gmail dot com 2010-06-11 14:05
---
Created an attachment (id=20893)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20893&action=view)
A new test case preprocessed with gcc 4.3.4 for -fno-guess-branch-probability
Hi,
here is a new test ca
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501
When passing the result of __builtin_bswap32() to printf() and -Wformat is
enabled, the following code:
#include
int foo(unsigned int arg) {
return printf("%u", __builtin_bswap32(arg));
}
generates this odd diagnostic:
foo.c:3: warning: format '%u' expects type 'unsigned int', but argument
--- Comment #4 from tromey at gcc dot gnu dot org 2010-06-11 14:53 ---
I think the problem with this patch is that it leaves gdb no way
to determine which approach it should use. This is important because
there is a lot of existing code compiled with the incorrect approach.
Currently g
--- Comment #11 from redi at gcc dot gnu dot org 2010-06-11 14:56 ---
(In reply to comment #9)
> I understand now after the implicit promotion to int of a non constant value
> the result of the narrowing operation can't be guaranteed to fit in the
> original type. But I still think it sh
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-06-11 14:56 ---
*** Bug 44502 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-11 14:56 ---
*** This bug has been marked as a duplicate of 37743 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from tromey at gcc dot gnu dot org 2010-06-11 15:07 ---
Jakub pointed out that gdb can just look for an isolated
DW_OP_constu to fall back to the old code.
I will write a gdb patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126
--- Comment #9 from redi at gcc dot gnu dot org 2010-06-11 15:32 ---
Subject: Bug 44268
Author: redi
Date: Fri Jun 11 15:31:53 2010
New Revision: 160617
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160617
Log:
2010-06-11 Jonathan Wakely
PR libstdc++/44268
*
--- Comment #10 from redi at gcc dot gnu dot org 2010-06-11 15:35 ---
fixed (but website not updated with the changes yet)
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from zsojka at seznam dot cz 2010-06-11 16:10 ---
I can confirm the testcase from comment #3 doesn't fail in r158095 when only
patch from comment #6 is applied (and gcc_checking_assert() is replaced by
gcc_assert())
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43656
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-11 16:27 ---
For completeness, also Cray Fortran 7.2.3 prints:
A WRITE operation is invalid if the file is positioned after the end-of-file.
Updated summary:
- Error with: NAG f95 v5.1, Pathscale pathf95 3.2.99, Cray ftn 8.2.3,
Attached is a test case from gcc regression test. verify_flow_info failed
when I turned on prefetching.
gcc -O3 -fprefetch-loop-arrays setjmp-1.c
setjmp-1.c: In function main:
setjmp-1.c:17:1: error: control flow in the middle of basic block 20
setjmp-1.c:17:1: error: control flow in the middle
--- Comment #1 from changpeng dot fang at amd dot com 2010-06-11 16:32
---
Created an attachment (id=20894)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20894&action=view)
prefetching for the while loop?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44503
--- Comment #19 from janus at gcc dot gnu dot org 2010-06-11 16:46 ---
Subject: Bug 43896
Author: janus
Date: Fri Jun 11 16:45:48 2010
New Revision: 160622
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160622
Log:
2010-06-11 Paul Thomas
PR fortran/42051
PR f
Using built-in specs.
Target: x86_64-apple-darwin10.3.0
Configured with: ../gcc-4.4.4/configure --prefix=/sw --prefix=/sw/lib/gcc4.4
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.4/info
--enable-languages=c,c++,fortran,objc,obj-c++ --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-clo
--- Comment #9 from janus at gcc dot gnu dot org 2010-06-11 16:46 ---
Subject: Bug 42051
Author: janus
Date: Fri Jun 11 16:45:48 2010
New Revision: 160622
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160622
Log:
2010-06-11 Paul Thomas
PR fortran/42051
PR fo
--- Comment #18 from jamborm at gcc dot gnu dot org 2010-06-11 16:49
---
When I tried the LTO step in any of the two testcases I got:
jamb...@tuc:~/gcc/mine/test/pr44464$ ~/gcc/inst/mine/bin/gcc -r -fwhopr
igmp.mini.o
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
--- Comment #20 from janus at gcc dot gnu dot org 2010-06-11 16:50 ---
Fixed with r160622. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from andi-gcc at firstfloor dot org 2010-06-11 17:09
---
Sorry you need -nostdlib too (forgot that)
-r is immediate linking
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #5 from dominiq at lps dot ens dot fr 2010-06-11 17:48 ---
For the record revision 160549 also broke boostrap on x86_64-apple-darwin10.3.0
near the end of stage 2:
echo CRTSTUFF_T_CFLAGS = '' >> tmp-libgcc.mvars
echo CRTSTUFF_T_CFLAGS_S = '' >> tmp-libgcc.mvars
echo TARGET_
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-11 18:04 ---
I think this is a bug in your program:
allocate (a) ! Allocate memory
p1 => a
p2 => a
! All of {a, p1, p2} point to the same memory.
deallocate (p1, stat=ios)
! Free memory pointed to by {a, p1, p2}
! and mark "p1
--- Comment #2 from kargl at gcc dot gnu dot org 2010-06-11 18:12 ---
Reset several to 'normal'. Fortran bugs are never 'major'.
I believe your code is invalid, and so gfortran can do
anything it wants. F2003 has
19 6.3.3.2 Deallocation of pointer targets
If a pointer appear
--- Comment #3 from remko dot scharroo at me dot com 2010-06-11 18:22
---
I fully agree that the second "deallocate (p2, stat=ios)" is a violation.
That is the actual intend of this program.
You know, this is not arbitrary code. You can often have multiple pointers
pointing to allocated
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-11 18:24 ---
It is caused by revision 121863:
http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00421.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #6 from spop at gcc dot gnu dot org 2010-06-11 18:28 ---
Subject: Bug 44483
Author: spop
Date: Fri Jun 11 18:28:17 2010
New Revision: 160625
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160625
Log:
Fix PR44483: incrementally gimplify BB predicates to avoid redundan
--- Comment #7 from spop at gcc dot gnu dot org 2010-06-11 18:30 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from changpeng dot fang at amd dot com 2010-06-11 18:45
---
Bug 39398 looks similar but that one seems with except handling instead of
setjmp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44503
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-11 19:54 ---
(In reply to comment #3)
> I fully agree that the second "deallocate (p2, stat=ios)" is a violation.
> That is the actual intend of this program.
Well, I can also complain that
fhjdshlkgjflsg
end
does not calculate
--- Comment #2 from ubizjak at gmail dot com 2010-06-11 19:54 ---
Generic parts do not like parity in CCmode.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2010-06-11 19:55 ---
Created an attachment (id=20895)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20895&action=view)
Patch to fix the failure.
Patch in testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44481
--- Comment #6 from tromey at gcc dot gnu dot org 2010-06-11 20:02 ---
Ok, I committed the gdb change:
http://sourceware.org/ml/gdb-patches/2010-06/msg00287.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126
--- Comment #12 from hp at gcc dot gnu dot org 2010-06-11 20:07 ---
(In reply to comment #11)
> (In reply to comment #10)
> > Now (with r160560) appearing for cris-elf too!
>
> Forgot to mention that it last worked for cris-elf with r160547.
Last known appearance r160602, gone again at
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2010-06-11 20:16 ---
Subject: Re: DEALLOCATE aborts program even with STAT=
On Fri, Jun 11, 2010 at 06:22:57PM -, remko dot scharroo at me dot com
wrote:
>
>
> --- Comment #3 from remko dot scharroo at me do
--- Comment #13 from sje at cup dot hp dot com 2010-06-11 20:19 ---
On hppa2.0w-hp-hpux11.11, I don't see the testsuite failure after 158397.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
--- Comment #17 from manu at gcc dot gnu dot org 2010-06-11 20:22 ---
The patch was rejected but it may be accepted by using a new -Wno-* option to
disable these warnings. Perhaps -Wno-conversion-after-promotion?
Suggestions are welcome.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #4 from tkoenig at gcc dot gnu dot org 2010-06-11 20:27 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Still true for gcc version 4.6.0 20100509 (experimental) (GCC)
>
> I don't know if it's worth the extra work, but this can be tackled in
> gfc_conv_substring()
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-06-11 20:34
---
> [...@gnu-12 gcc]$ ./xgcc -B./ -O
> /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/pr42461.c
> /tmp/ccmdb99H.o: In function `main':
> pr42461.c:(.text+0x22): undefined reference to `link_failure
On Linux/ia32, revision 160623 gave:
FAIL: gcc.c-torture/execute/frame-address.c execution, -O2
FAIL: gcc.c-torture/execute/frame-address.c execution, -O3 -g
FAIL: gcc.c-torture/execute/frame-address.c execution, -Os
FAIL: gcc.c-torture/execute/frame-address.c execution, -O2 -flto
FAIL: gc
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-06-11 20:51
---
Subject: Bug 42461
Author: ebotcazou
Date: Fri Jun 11 20:50:46 2010
New Revision: 160632
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160632
Log:
PR rtl-optimization/42461
* gcc.dg/pr424
--- Comment #4 from zsojka at seznam dot cz 2010-06-11 21:02 ---
When rp() is declared with __attribute__((pure)), it fails even with
-fno-ipa-pure-const. (still fails in r160527)
I don't know if this is a bug or if this behaviour is fine according to
standard.
--
http://gcc.gnu.org
1 - 100 of 129 matches
Mail list logo
