--- Comment #4 from raj dot khem at gmail dot com 2010-06-21 17:45 ---
(In reply to comment #3)
Dupe of PR43961?
yes seems so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44603
There appears to be some sort of regression with avr-gcc 4.5.0. When compiling
a sketch for the atmega1280 everything works except for serial output. The fix
is to revert to 4.3.x
The issue is documented here:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1276727004/15
and
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-21 17:47
---
Reopening
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-21 17:48
---
I'm working on these, maybe will be ready in time for 4.6.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-21 17:57
---
Did you read this, before opening the PR?
http://gcc.gnu.org/bugs/
Please provide all the required information, otherwise nobody will be able to
look at the issue.
--
paolo dot carlini at oracle dot
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-21 18:00 ---
Confirmed. Changing the CLASS statement into TYPE gives the correct error:
type(Connection) :: self
1
Error: the type of 'self' at (1) has not been declared within the
--- Comment #2 from scott at perturb dot org 2010-06-21 18:07 ---
* the exact version of GCC;
avr-gcc-c++-4.5.0-1.fc13.x86_64
avr-gcc-4.5.0-1.fc13.x86_64
* the system type;
Compiled on 2.6.33.5-112.fc13.x86_64 but the target was an atmega1280
* the options given when
--- Comment #8 from uros at gcc dot gnu dot org 2010-06-21 18:08 ---
Subject: Bug 44505
Author: uros
Date: Mon Jun 21 18:07:59 2010
New Revision: 161105
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161105
Log:
PR testsuite/44505
*
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-21 18:10 ---
Can you also try on a FSF released GCC rather than one that has been modified
by the Fedora project?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from scott at perturb dot org 2010-06-21 18:13 ---
(In reply to comment #3)
Can you also try on a FSF released GCC rather than one that has been modified
by the Fedora project?
That might be harder... I do see from the two forum posts that the bug persists
in GCC from
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-21 18:30 ---
Here is a fix:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 161045)
+++ gcc/fortran/resolve.c (working copy)
@@
--- Comment #2 from ubizjak at gmail dot com 2010-06-21 18:30 ---
Dupe of PR44505?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24344
--- Comment #5 from scott at perturb dot org 2010-06-21 18:38 ---
* the complete command line that triggers the bug;
avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections
-mmcu=atmega1280 -DF_CPU=1600L -DARDUINO=18
--- Comment #6 from scott at perturb dot org 2010-06-21 18:39 ---
For the record, the code I'm attempting to compile is extremely simple. Might
explain why it compiles so cleanly:
---
void setup() {
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-06-21 18:40 ---
*.i*
It should have produced a file that ended in .ii .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617
--- Comment #8 from scott at perturb dot org 2010-06-21 19:03 ---
Here is the full command the arduino ide generates when it compiles code. I
just took the last command for sketch_jun21a.cpp.o (my code) and added the -v
and -save-temps.
avr-gcc -c -g -Os -w -ffunction-sections
On 32 bit powerpc targets, the family of out-of-line restore functions
(_restgpr_xx_x), expects r11 (or something else, depending on the
ABI used) to have the new value of the stack pointer.
Gcc emits rtl that sets r11, and a jump_insn that flags the use of r11.
When compiling the test case with
--- Comment #1 from edmar at freescale dot com 2010-06-21 20:14 ---
Created an attachment (id=20967)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20967action=view)
patch for 4.5 and 4.6
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
--- Comment #3 from edmar at freescale dot com 2010-06-21 20:17 ---
Created an attachment (id=20969)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20969action=view)
ChangeLog for propsed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
--- Comment #4 from edmar at freescale dot com 2010-06-21 20:17 ---
Created an attachment (id=20970)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20970action=view)
ChangeLog for proposed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
--- Comment #2 from edmar at freescale dot com 2010-06-21 20:15 ---
Created an attachment (id=20968)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20968action=view)
patch for 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
--- Comment #5 from edmar at freescale dot com 2010-06-21 20:24 ---
(In reply to comment #0)
Sorry for the spelling, please read unknown through out the report.
Thanks
Edmar
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
--- Comment #4 from hjl at gcc dot gnu dot org 2010-06-21 20:26 ---
Subject: Bug 44615
Author: hjl
Date: Mon Jun 21 20:26:11 2010
New Revision: 161112
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161112
Log:
Add -mtune=k8 to gcc.target/i386/amd64-abi-3.c.
2010-06-21 H.J. Lu
--- Comment #5 from hjl at gcc dot gnu dot org 2010-06-21 20:28 ---
Subject: Bug 44615
Author: hjl
Date: Mon Jun 21 20:28:03 2010
New Revision: 161113
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161113
Log:
Add -mtune=k8 to gcc.target/i386/amd64-abi-3.c.
2010-06-21 H.J. Lu
--- Comment #6 from hjl at gcc dot gnu dot org 2010-06-21 20:28 ---
Subject: Bug 44615
Author: hjl
Date: Mon Jun 21 20:28:24 2010
New Revision: 161114
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161114
Log:
Add -mtune=k8 to gcc.target/i386/amd64-abi-3.c.
2010-06-21 H.J. Lu
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-06-21 20:34 ---
I think this is the wrong fix I think the problem is in the patterns not
using a hard register or a constraint that says only those registers can be
used.
Confirmed.
--
pinskia at gcc dot gnu dot org
host:~$ cat bogus.cpp
struct S { int x, y; };
int main(int argc, char *argv[])
{
struct S foo;
int S::*bar = S::x;
foo.*bar = 5;
return foo.*bar;
}
host:~$ g++ -o bogus bogus.cpp -Wunused
bogus.cpp: In function 'int main(int, char**)':
bogus.cpp:5:12: warning: variable 'foo' set but not
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-21 20:54 ---
Confirmed on the trunk:
GNU C++ (GCC) version 4.6.0 20100621 (experimental) [trunk revision 161061]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20100621 (experimental) [trunk revision
161061
--- Comment #10 from hjl dot tools at gmail dot com 2010-06-21 20:57
---
Revision 161041 deosn't fix it on Linux/x86-64. I got
valgrind --tool=memcheck ./f951
/export/gnu/import/rrs/161041/src/gcc/testsuite/gfortran.dg/typebound_proc_15.f03
-quiet -dumpbase typebound_proc_15.f03
--- Comment #11 from hjl dot tools at gmail dot com 2010-06-21 21:00
---
Revision 161061 has the same bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
This simple source file causes gcc to crash when compiled with
-fvisibility-ms-compat:
void foo()
{
throw Help!;
}
% gcc -v -save-temps -c -fvisibility-ms-compat crash.cxx
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../src/lnx32/configure
--- Comment #1 from soren dot soe at gonsoe dot com 2010-06-21 21:13
---
Created an attachment (id=20971)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20971action=view)
crash.ii
Attached crash.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44620
--- Comment #7 from edmar at freescale dot com 2010-06-21 21:18 ---
(In reply to comment #6)
I think this is the wrong fix I think the problem is in the patterns not
using a hard register or a constraint that says only those registers can be
used.
Confirmed.
I mostly
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-06-21 21:29 ---
(In reply to comment #7)
I mostly agree with you. But in this case, it is already a hard register (rtl
generated in epilogue).
No the pattern accepts any registers which means register rename can rename the
--- Comment #7 from hjl at gcc dot gnu dot org 2010-06-21 21:57 ---
Subject: Bug 44615
Author: hjl
Date: Mon Jun 21 21:56:47 2010
New Revision: 161118
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161118
Log:
Properly handle psrldq when optimizing for Atom.
gcc/
2010-06-21
--- Comment #8 from hjl at gcc dot gnu dot org 2010-06-21 21:59 ---
Subject: Bug 44615
Author: hjl
Date: Mon Jun 21 21:58:38 2010
New Revision: 161119
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161119
Log:
Properly handle psrldq when optimizing for Atom.
gcc/
2010-06-21
--- Comment #1 from danglin at gcc dot gnu dot org 2010-06-21 23:03 ---
This was introduced by the following change:
Author: bernds
Date: Thu Jun 17 21:51:55 2010
New Revision: 160947
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160947
Log:
PR rtl-optimization/39871
--- Comment #5 from jsm28 at gcc dot gnu dot org 2010-06-21 23:17 ---
This appears to be fixed on trunk, probably by:
2010-04-07 Simon Baldwin sim...@google.com
* directives.c (do_diagnostic): Add warning reason argument,
call appropriate error reporting function for
--- Comment #2 from danglin at gcc dot gnu dot org 2010-06-21 23:20 ---
This change also probably introduced the following fails on
hppa-unknown-linux-gnu:
FAIL: gcc.c-torture/execute/frame-address.c execution, -O2
FAIL: gcc.c-torture/execute/frame-address.c execution, -O3
http://gcc.gnu.org/install/specific.html#ix86-x-solaris210 says to use
/usr/bin/ksh as CONFIG_SHELL on solaris2.
When you do so, gcc-4.5.0/configure emits the following text:
$TOOL/gcc/4.5.0/gcc-4.5.0/configure
--prefix=$TOOL/gcc/4.5.0/i386-pc-solaris2.10 --with-gnu-as --with-gnu-ld
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-21 23:30 ---
and LTO silently does nothing.
Huh? gold is not required for lto to work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44621
--- Comment #9 from edmar at freescale dot com 2010-06-21 23:36 ---
Hummm, I will work on your input, But now I have more questions:
1) Why do you call this case as explicit, and function call arguments implicit
? The way I see it, this is a special function call (implemented with a
--- Comment #2 from Daniel dot Davies at xerox dot com 2010-06-21 23:42
---
Excellent! Here's where I must have gotten confused.
http://gcc.gnu.org/install/configure.html says
--enable-gold
Enable support for using gold as the linker. If gold support is enabled
together with
--- Comment #2 from danglin at gcc dot gnu dot org 2010-06-21 23:43 ---
Subject: Bug 39690
Author: danglin
Date: Mon Jun 21 23:43:42 2010
New Revision: 161121
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161121
Log:
PR target/39690
config/pa/pa.c
--- Comment #3 from Daniel dot Davies at xerox dot com 2010-06-21 23:47
---
Yup, another mistake. The gold build fails. The version of g++ I'm using to
compile gold is too old (3.4.3 from the solaris distribution). I'll go try to
make a newer one.
g++ -DHAVE_CONFIG_H -I.
--- Comment #3 from danglin at gcc dot gnu dot org 2010-06-21 23:47 ---
Subject: Bug 39690
Author: danglin
Date: Mon Jun 21 23:47:46 2010
New Revision: 161122
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161122
Log:
PR target/39690
config/pa/pa.c
--- Comment #4 from danglin at gcc dot gnu dot org 2010-06-21 23:51 ---
Subject: Bug 39690
Author: danglin
Date: Mon Jun 21 23:51:10 2010
New Revision: 161123
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161123
Log:
PR target/39690
config/pa/pa.c
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-06-21 23:54
---
(In reply to comment #9)
Hummm, I will work on your input, But now I have more questions:
1) Why do you call this case as explicit, and function call arguments implicit
? The way I see it, this is a special
--- Comment #5 from danglin at gcc dot gnu dot org 2010-06-21 23:54 ---
Subject: Bug 39690
Author: danglin
Date: Mon Jun 21 23:54:25 2010
New Revision: 161124
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161124
Log:
PR target/39690
config/pa/pa.c
--- Comment #3 from bernds at gcc dot gnu dot org 2010-06-21 23:59 ---
At first glance, it looks like the tricks in the prefetch_cc simply aren't
valid. It seems to be trying to prevent certain types of addressing modes, but
reload is allowed to change them as it sees fit.
If I read
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #5 from ramana at gcc dot gnu dot org 2010-06-22 00:51 ---
Khem,
Can you check if this fixes your problem ? Feel free to submit this to
gcc-patches@ if you get around to testing this before me.
Ramana
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-06-22 01:24
---
atan2_1.f90 has failed on other platforms before too. I think we just need:
! { dg-options -ffloat-store }
or maybe this
! { dg-options -O0 -ffloat-store }
in the test file. Can you try that and see if it
--- Comment #3 from hp at gcc dot gnu dot org 2010-06-22 01:24 ---
(In reply to comment #2)
Dupe of PR44505?
Unknown, please hold.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from sandra at codesourcery dot com 2010-06-22 01:55 ---
Julian's patch overlapped some other NEON changes I was already preparing for
submission, so I did some refactoring before posting it for review. Here's the
main part of the fix:
--- Comment #13 from paul dot richard dot thomas at gmail dot com
2010-06-22 04:36 ---
Subject: Re: gfortran generates wrong results due to wrong
ABI in function with array return
Dear Tobias,
Thanks for looking through the patch.
Does use_assoc also include
--- Comment #4 from hp at gcc dot gnu dot org 2010-06-22 04:58 ---
FWIW, I didn't see this with r158717 (late April), so I think I'll just close
this PR. No, I don't think it's the same issue as PR44505; after all, these are
two wildly different architectures for which the test failed
101 - 157 of 157 matches
Mail list logo
