--- Comment #5 from uros at gcc dot gnu dot org 2010-06-12 06:29 ---
Subject: Bug 44481
Author: uros
Date: Sat Jun 12 06:29:44 2010
New Revision: 160647
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160647
Log:
PR target/44481
* config/i386/i386.md (UNSPEC_PARIT
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-12 04:12 ---
Fixed with r160646. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-12 04:10 ---
Subject: Bug 40117
Author: janus
Date: Sat Jun 12 04:10:25 2010
New Revision: 160646
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160646
Log:
2010-06-12 Janus Weil
PR fortran/40117
* decl
--- Comment #10 from janus at gcc dot gnu dot org 2010-06-12 04:03 ---
Fixed on trunk and 4.5. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from janus at gcc dot gnu dot org 2010-06-12 04:02 ---
Subject: Bug 44430
Author: janus
Date: Sat Jun 12 04:02:27 2010
New Revision: 160645
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160645
Log:
2010-06-12 Janus Weil
PR fortran/44430
* dump
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #2 from Daniel dot Davies at xerox dot com 2010-06-12 01:04
---
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/tool/gcc/4.5.0/i386-pc-solaris2.10/libexec/gcc/i386-pc-solaris2.10/4.5.0/lto-wrapper
Target: i386-pc-solaris2.10
Configured with: /tool/gcc/4.5.0/gcc-4.
--- Comment #1 from Daniel dot Davies at xerox dot com 2010-06-12 01:02
---
Created an attachment (id=20900)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20900&action=view)
The preprocessed test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44507
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44507
When the enclosed test case is compiled with -O3, the vectorization code loads
and SSE register with 0x0001000100010001 instead of
0x, then ANDs this with elements of the array.
This causes the code to fail.
--
Summary: vectorization AN
===command line and terminal output=
avr-gcc -v -save-temps -Os -mmcu=atmega328p -mtiny-stack -c bug.c
Using built-in specs.
Target: avr
Configured with: ../configure --prefix=/usr/local/avr --target=avr
--disable-nls --enable-languages=c --disable-libssp --with
--- Comment #8 from bernds at gcc dot gnu dot org 2010-06-11 22:36 ---
Fixed.
--
bernds at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-06-11 22:17
---
Created an attachment (id=20899)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20899&action=view)
Possible patch
OK, maybe I came out too strong in my last comment.
It is possible to get the front-end to c
--- Comment #25 from janus at gcc dot gnu dot org 2010-06-11 22:16 ---
This seems to be a module-loading bug. When reading the specific binding of the
TBP 'get' from 'mod1' (which happens in module.c, mio_typebound_proc), we
expect to get the symbol 'my_get' from 'mod1', but instead we g
--- Comment #13 from danglin at gcc dot gnu dot org 2010-06-11 21:59
---
268 MB for one number is a bit much! However, I think this is a gmp issue.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from uros at gcc dot gnu dot org 2010-06-11 21:58 ---
Subject: Bug 44481
Author: uros
Date: Fri Jun 11 21:58:31 2010
New Revision: 160638
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160638
Log:
PR target/44481
* config/i386/i386.md (UNSPEC_PARIT
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2010-06-11 21:55
---
We generate a variadic prototype for the decl when calling bar because we try
to generate it anew, instead of finding the toplevel decl already existing.
This is (again) the multiple decls issue.
(Well, we could
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44505
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-11 21:36 ---
It is caused by revision 160615:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00530.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #24 from janus at gcc dot gnu dot org 2010-06-11 21:33 ---
Here is a somewhat modified version of comment #14, which compiles but produces
wrong code:
module mod1
type :: t1
contains
procedure, nopass :: get => my_get
end type
contains
subroutine my_get()
pr
--- Comment #7 from bernds at gcc dot gnu dot org 2010-06-11 21:32 ---
This would appear to be a bug in the sparc backend then; my patch is only
exposing it. I'll not investigate further and leave this for a Sparc
maintainer since I have no clue about the machine.
--
http://gcc.gnu
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-06-11 21:30
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-06-11 21:29
---
*** Bug 44494 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-06-11 21:29
---
*** This bug has been marked as a duplicate of 44484 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from mikpe at it dot uu dot se 2010-06-11 21:27 ---
The bug is easily observed with a cross to sparc64-linux, using e.g. the
task-2.c test case in libgomp's libgomp.c test suite.
Diffing the -S output of 4.6-20100605 vanilla (bad) with the same where r160260
has been reve
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|burnus at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #3 from mikpe at it dot uu dot se 2010-06-11 21:10 ---
Created an attachment (id=20898)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20898&action=view)
working -S output from gcc-4.6-20100605 with r160260 reverted
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=444
--- Comment #2 from mikpe at it dot uu dot se 2010-06-11 21:09 ---
Created an attachment (id=20897)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20897&action=view)
broken -S output from gcc-4.6-20100605
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44484
--- Comment #1 from mikpe at it dot uu dot se 2010-06-11 21:07 ---
Created an attachment (id=20896)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20896&action=view)
task-2.c test case from libgomp's test suite
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44484
--- 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
--- 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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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
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 #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,
--- 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 #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 #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 #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 #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 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 #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 #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
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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501
--- 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
--- 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 #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 #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 #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 #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
--
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 #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
--
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 #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
--- 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 #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 #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 #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
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 #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
--- 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
--
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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
--
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
1 - 100 of 129 matches
Mail list logo
