WinAvr with Atmega16:
Source Code:
//
#include
#include
#define lcm_DI_SET PORTD&=_BV(PD7)
void lcm_WriteByte(unsigned char dat)
{
lcm_DI_SET;
}
void lcm_Show(unsigned char column, prog_void *addr)
{
unsigned char i, m;
for(m
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-13 04:29 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00685.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from corsepiu at gcc dot gnu dot org 2006-01-13 03:57
---
Created an attachment (id=10636)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10636&action=view)
--save-temps generated file from the ICE
GCC ices on this code with -O2, but doesn't ice with -O1 or -O0:
#
sparc-rtems4.7-gcc -O2 smc9.i smc9.c: In function 'smc9_rxDaemon':
smc9.c:481: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
# sparc-rtems4.7-gcc --version
sp
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-13 03:34 ---
You are violating C++ aliasing rules, you have:
int new_ybar_inline
p = reinterpret_cast( free_list );
free_list = free_list->next;
..
return p;
*newchild = new_ybar_inline();
(*newchild)
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-13 03:03 ---
*** Bug 25779 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 2006-01-13 03:03 ---
Yes declarations are not statements. Labels only apply to statements and not
declarations.
See PR 7508 comment #1 for more clarification.
Closing as a dup of bug 7508.
*** This bug has been marked as a duplicate
C99 supports mixed declarations and code but the following does not compile
(with --std=c99). It will compile if you uncomment the lone semicolon, a parser
bug, or perhaps I'm missing something?
#include
main()
{
int a = 0;
switch (a) {
case 0:
//;
int b = 0;
printf("
--- Comment #12 from seidl at feld dot cvut dot cz 2006-01-13 02:11 ---
(In reply to comment #11)
Hi Nick,
the patched compiler works OK and cross-compiled program in target v850
platform seems to be functional and stable. I assume, the problem is solved,
but I plane to make a thorough p
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-13 01:38 ---
Taking for now while waiting for the results.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-13 01:36 ---
Created an attachment (id=10635)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10635&action=view)
patch which needs testing but works for simple testing
ChangeLog:
* i386.md (builtin_setjmp_receiver): Don't em
disable-multilib --with-newlib --without-headers --disable-nls
--enable-threads=no --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c --disable-shared
Thread model: single
gcc version 4.2.0 20060112 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25381
--- Comment #26 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-13
00:12 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error: verify_flow_info
failed
> --- Comment #25 from steven at gcc dot gnu dot org 2006-01-12 22:56
> ---
> I can not reproduce this ICE. We
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-12 23:53 ---
Ok, I think I will be able to fix this fully, working on it for now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-12 23:46 ---
This is not a bug. The alignment of u64 is 8bytes so the whole struct becomes
alignment of 8bytes. This is called natural alignment.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
typedef unsigned char u8;
typedef unsigned int u32;
typedef unsigned long long u64;
struct x
{
u8 x1[64];
u64 x2;
u32 x3;
};
#include
int main()
{
struct x x;
printf("sizeof(x)= %2u\n", sizeof(x));
printf("offset(M.x1) = %2u\n", (unsigned)&x.x1 - (unsigne
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-01-12 23:18 ---
Mine, testing a patch.
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
Assi
--- Comment #9 from dberlin at gcc dot gnu dot org 2006-01-12 23:13 ---
That would fix it perfectly fine, i'll bootstrap and test it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22415
--- Comment #25 from steven at gcc dot gnu dot org 2006-01-12 22:56 ---
I can not reproduce this ICE. We really need some way to reproduce the problem
that Mustafa's patch was supposed to fix.
I use a cross-compiler from AMD64 to ppc:
GNU C version 4.2.0 20060112 (experim
--- Comment #7 from kargl at gcc dot gnu dot org 2006-01-12 22:42 ---
I have a patch.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unas
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2006-01-12 22:41 ---
Subject: Re: ICE on valid code with labels
On Thu, Jan 12, 2006 at 08:18:50PM -, kargl at gcc dot gnu dot org wrote:
>
> get rids of the ICE, but I don't understand why we have an ICE in firs
--- Comment #1 from echristo at apple dot com 2006-01-12 22:25 ---
I'm testing it for Andrew.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25758
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-12 21:48 ---
Reduced testcase:
int g();
struct string {
static int _S_empty_rep_storage[];
void _M_destroy();
char* _M_rep;
~string()
{
if (_M_rep != (char*)&_S_empty_rep_storage )
if (g() <= 0)
--- Comment #22 from laurent at guerby dot net 2006-01-12 21:29 ---
On mainline as of 20060111, the three ACATS ICE are present when cross
compiling from x86-linux to sparc-rtems4.7.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18659
This causes numerous testsuite failures. See
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00437.html
versus
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00555.html.
In the latter run, I explicitly exported LD_LIBRARY_PATH in
my build script. The exported patch included the gcc build
dire
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #4 from pluto at agmk dot net 2006-01-12 21:04 ---
(In reply to comment #2)
> ../../xgcc -B../../ -c -g -O2 -gnatpg -nostdinc -gnatwZ s-fore.adb -o
> s-fore.o
> s-fore.adb: In function 'System.Fore.Fore':
> s-fore.adb:57: error: unrecognizable insn:
> (insn 18 17 19 0
C++ testcase:
namespace std {
template struct allocator {
};
}
namespace __gnu_cxx {
}
namespace std {
template class
basic_string {
};
template struct _Vector_base {
struct _Vector_impl : public _Tp_alloc_type {
};
~_Vector_base() {
--- Comment #8 from law at redhat dot com 2006-01-12 20:41 ---
Subject: Re: [4.0 Regression] ICE in
coalesce_abnormal_edges
On Thu, 2006-01-12 at 20:30 +, law at redhat dot com wrote:
> You should assign this bug to Daniel since he's the PRE expert.
I'll note that somethin
--- Comment #7 from law at redhat dot com 2006-01-12 20:30 ---
Subject: Re: [4.0 Regression] ICE in
coalesce_abnormal_edges
On Thu, 2006-01-12 at 16:30 +, pinskia at gcc dot gnu dot org wrote:
Before PRE a$a_1 is live from the beginning of BB6 through the outgoing
edge in
--- Comment #5 from kargl at gcc dot gnu dot org 2006-01-12 20:18 ---
The following simple patch
Index: parse.c
===
--- parse.c (revision 109606)
+++ parse.c (working copy)
@@ -349,8 +349,10 @@ next_free (void)
--- Comment #29 from jason at gcc dot gnu dot org 2006-01-12 20:10 ---
Subject: Bug 24660
Author: jason
Date: Thu Jan 12 20:10:47 2006
New Revision: 109647
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109647
Log:
PR libstdc++/24660
* pt.c (check_explicit_specia
--- Comment #4 from sschunck at pdf dot de 2006-01-12 19:55 ---
additional info:
if instruction
movl$1, (%edx)
would be located two lines later the generated code would be correct (AFAIK)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25768
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-12 19:29 ---
*** Bug 25775 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25772
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-12 19:29 ---
*** This bug has been marked as a duplicate of 25772 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
The preprocessor (or any subsequent component) does not remove superfluous
referencing and dereferencing. For instance take the example of accessing the
address of an element in an array.
&(data[i])
The preprocessor or at least another part should convert this to the equivalent
of
(data + i)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-12 19:00 ---
VC++ is wrong, there is no preprocessing token for "//"
GCC is right in saying:
t5.cc:5:1: error: pasting "/" and "/" does not give a valid preprocessing token
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from bonzini at gnu dot org 2006-01-12 18:58 ---
The compiler surely converts &data[i] to data+i or the other way round even at
no optimization level and so does with &*&*&*&*&*a that is equivalent to a.
You cannot expect the preprocessor to do that, and the result to sho
The code below fails to preprocess correctly. Shouldn't it handle this simple
case correctly? VC++ produces the expected results.
#define COMMENT /##/
void main( void )
{
COMMENT this line should be commented out
}
--
Summary: Preprocessor concatenation of forward-slash fail
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-12 18:54 ---
I don't understand what you want here?
The preprocessor is not allowed to do this at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
The preprocessor (or any subsequent component) does not remove superfluous
referencing and dereferencing. For instance take the example of accessing the
address of an element in an array.
&(data[i])
The preprocessor or at least another part should convert this to the equivalent
of
(data + i)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-12 18:43 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25771
--- Comment #1 from dcb314 at hotmail dot com 2006-01-12 18:22 ---
Created an attachment (id=10631)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10631&action=view)
C++ source code
You need to use flag -O2 on an x86_64 linux box
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
I just tried to compile package wesnoth-1.0.2 from Suse Linux with a recent
GNU C compiler version 4.2 snapshot 20060107.
The compiler snapshot said
widgets/menu.hpp: In destructor "virtual gui::menu::~menu()":
widgets/menu.hpp:33: internal compiler error: in coalesce_abnormal_edges, at
tree-out
--- Comment #2 from audriusa at bluewin dot ch 2006-01-12 17:49 ---
Confirmed for the GNU Classpath CVS version as of Thu Jan 12 18:47:25 CET 2006.
On each start, we print the same sequence of numbers, when Sun's jre each time
prints the different sequence of numbers.
--
audriusa at
--- Comment #1 from brett dot albertson at stratech dot com 2006-01-12
17:48 ---
Update: If I add "-mmmx" as a command line argument, this successfully
compiles for me. I got the idea from this error message:
dev-zero:{root}# /opt/gcc-4.1/bin/g++ -c 20050316-1.c
20050316-1.c: In func
--- Comment #3 from sschunck at pdf dot de 2006-01-12 17:04 ---
The miscompiled line is
(*newchild)->kind = interior; ( interior = 1 )
but when
movl$1, (%edx)
is done
edx points to
free_list;
from function MemPool::new_element()
instead of newchild
--
http://gcc.g
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-12 16:49 ---
>From looking at the source, it looks like you are violating aliasing rules but
I cannot pinpoint where you are violating them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25768
--- Comment #1 from sschunck at pdf dot de 2006-01-12 16:45 ---
Created an attachment (id=10630)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10630&action=view)
c++ code
the following assembler snipplet shows that the
movl$1, (%edx)
is scheduled too early
.globl _ZN1A3foo
the following program will return 1 when compiled with gcc 3.3.x or with gcc
3.4.x
without optimization and when compiled with gcc 3.4.4 -O2 it return 0
--
Summary: [3.4 regression] wrong code with inlining at -O2
Product: gcc
Version: 3.4.4
Status
--- Comment #13 from nathan at gcc dot gnu dot org 2006-01-12 16:20 ---
Subject: Bug 24824
Author: nathan
Date: Thu Jan 12 16:20:10 2006
New Revision: 109644
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109644
Log:
PR c++/24824
* class.c (handle_using_decl): Pa
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-12 16:14 ---
FAIL: gcc.c-torture/execute/built-in-setjmp.c compilation, -O0
UNRESOLVED: gcc.c-torture/execute/built-in-setjmp.c execution, -O0
Executing on host: /Volumes/HD/ltmp/ssen/gcc-build/gcc/xgcc
-B/Volumes/HD/ltmp/ssen/
--- Comment #12 from nathan at gcc dot gnu dot org 2006-01-12 16:13 ---
2006-01-12 Nathan Sidwell <[EMAIL PROTECTED]>
PR c++/24824
* class.c (handle_using_decl): Pass correct scope to
cp_emit_debug_info_for_using.
PR c++/24824
* g++.dg/debug/dw
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-12 16:13 ---
FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O0
UNRESOLVED: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -O0
Executing on host: /Volumes/HD/ltmp/ssen/gcc-build/gcc/xgcc
-B/Volumes/HD/lt
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-12 16:12 ---
It is not fully fixed:
FAIL: gcc.c-torture/compile/20011029-1.c -O0 (test for excess errors)
Excess errors:
/var/tmp//cc4yx2Rb.s:23:non-relocatable subtraction expression, "L4" minus
"L001$pb"
/var/tmp//cc4
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-12 16:09 ---
PASS: g++.old-deja/g++.other/store-expr1.C PIC unsupported (test for bogus
messages, line )
FAIL: g++.old-deja/g++.other/store-expr1.C (test for excess errors)
Excess errors:
/ltmp/ssen/gcc/gcc/testsuite/g++.old-deja
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-12 16:08 ---
A couple related failures:
FAIL: g++.dg/opt/temp1.C (test for excess errors)
Excess errors:
/usr/bin/ld: warning multiple definitions of symbol _memcpy
/var/tmp//cc1J5gf8.o definition of _memcpy in section (__TEXT,__
g++.dg/lookup/builtin1.C fails because "-multiply_defined suppress" is not
passed so we get warnings:
/usr/bin/ld: warning multiple definitions of symbol _abort
/var/tmp//ccGf0er9.o definition of _abort in section (__TEXT,__text)
/usr/lib/libm.dylib(abort.So) definition of _abort
-
g++.exp s
--- Comment #11 from nathan at gcc dot gnu dot org 2006-01-12 16:01 ---
Subject: Bug 24824
Author: nathan
Date: Thu Jan 12 16:01:15 2006
New Revision: 109643
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109643
Log:
PR c++/24824
* class.c (handle_using_decl): Pa
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-01-12 15:47
---
> The magic required was:
>
> 1. Ensure bintools was in path before /usr/ccs/bin
What is bintools?
> 2. Remove gnu ld from system
> 3. CFLAGS='-m64' configure --disable-multilib --enable-languages=c,c++
> spar
--- Comment #10 from darren at mambo dot net 2006-01-12 15:30 ---
Well, after about ten tries, I got it to all compile.
The magic required was:
1. Ensure bintools was in path before /usr/ccs/bin
2. Remove gnu ld from system
3. CFLAGS='-m64' configure --disable-multilib --enable-languag
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-12 14:57 ---
This fails on i686-darwin also (which has -fPIC by default):
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00583.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed
objc.dg/stret-2.m fails on i686-darwin because some struct is return not via
the stack but by registers. Though I don't know for sure if this is correct so
I am filing this bug.
--
Summary: objc.dg/stret-2.m fails on i686-darwin
Product: gcc
Version: 4.2.0
gfortran.dg/assign_2.f90 at -O0 fails because the subtraction between labels in
different sections cannot be done, well it is really the last label is not in
the same section when it should be as there is no nop after the last label.
we get something like:
"L001$pb":
L6:
popl%e
FAIL: gcc.dg/const-compare.c (test for excess errors)
This test should only be run on powerpc-darwin and not i686-darwin
--
Summary: gcc.dg/const-compare.c fails on i686-darwin
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: norma
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-12 14:16 ---
objc.dg/encode-8.m fails the same way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25762
FAIL: objc.dg/stubify-1.m (test for excess errors)
ERROR: objc.dg/stubify-1.m: error executing dg-final: couldn't open
"stubify-1.s": no such file or directory
UNRESOLVED: objc.dg/stubify-1.m: error executing dg-final: couldn't open
"stubify-1.s": no such file or directory
FAIL: objc.dg/stubify-2.m
All the objc.dg-struct-layout-encoding-1 tests fail because ALIGN_DOUBLES (or
what ever the option is) is set to be the opposite of the default on Linux and
such.
--
Summary: All objc.dg-struct-layout-encoding-1 fails
Product: gcc
Version: 4.2.0
Statu
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-12 13:31 ---
Oh, -fpic on i686-darwin should be made equivlant to -fPIC without any warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25761
The following test fail because of this:
FAIL: gcc.dg/20021116-1.c (test for excess errors)
FAIL: gcc.dg/20030702-1.c (test for excess errors)
FAIL: gcc.dg/20030708-1.c (test for excess errors)
FAIL: gcc.dg/20040311-2.c (test for excess errors)
FAIL: gcc.dg/20050321-2.c (test for excess errors)
-
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2006-01-12 13:08
---
This could be fixed by something similar to
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01578.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22097
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-12 12:53 ---
Class and structs are the same by definition of the C++ standard. The only
different is the default accessibility, private for class and public for
struct.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #15 from aldot at gcc dot gnu dot org 2006-01-12 12:28 ---
Subject: Bug 25486
Author: aldot
Date: Thu Jan 12 12:28:00 2006
New Revision: 109640
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109640
Log:
2006-01-12 Bernhard Fischer <[EMAIL PROTECTED]>
* gcc/
--- Comment #8 from r dot emrich at de dot tecosim dot com 2006-01-12
10:22 ---
Subject: Re: link failure for several acats tests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
for gcc-4.2 20060109:
termination of testsuite run at c52103x with the following error:
gmake: *** [check-
--- Comment #8 from tobi at gcc dot gnu dot org 2006-01-12 10:13 ---
Thanks, Steve.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
The gcc manual does not describe the behaviour of __attribute__((packed))
attached to a class definition, e.g.
class foo
{
unsigned char;
unsigned long;
} __attribute__((packed));
As far as I have observed, the behaviour is the same if foo would be declared
as struct. The gcc manual
77 matches
Mail list logo
