The building for AVR target is aborted at compilation libgcc stage with
error: Illegal opcode movw for mcu avr3. The lastest official release
of binutils is used: 2.18. The reason of error is an attempt to assemble
MOVW command for avr3 architecture which permits only classic instruction
set hist
For funcion:
long mult (long x, long y)
{
return x * y;
}
the avr-gcc 4.3.0 produces 29 words of code (-Os option):
mult:
push r14
push r15
push r16
push r17
/* prologue: function */
/* frame size = 0 */
mov r14,r18
mov r15,r19
The next program is not linked (-Os option):
int ffs (int);
int main (int argc, char *argv[])
{
(void)argv;
return ffs (argc);
}
with undefined link to '__ffshi2'.
The used libc library (Avr-libc project) contains the ffs() funcion.
--
Summary: [avr] 4.3.0: undefine
The compiler ICEs while compiling libgfortran for powerpc:
$ ../../gcc/xgcc -B ../../gcc/ -c -std=gnu99 -O maxloc1_4_r16.i
../../../libgfortran/generated/maxloc1_4_r16.c: In function
‘mmaxloc1_4_r16’:
../../../libgfortran/generated/maxloc1_4_r16.c:220: internal compiler error: in
memory_address,
--- Comment #1 from schwab at suse dot de 2008-03-08 10:05 ---
Created an attachment (id=15281)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15281&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35510
The next program is aborted in execution (avr-gcc 4.3.0, -Os):
int isinf (double);
void abort (void);
volatile double x = -1.0/0.0;
int main ()
{
if (isinf (x) != isinf (-__builtin_inf ()))
abort ();
return 0;
}
The second comparison argument is evaluated at compile ti
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-08 10:40 ---
We run into the machine-independent inline expansion that replaces
isinf(x) with isgreater(fabs(x),DBL_MAX). This is indeed inconsistend with
the constant folding we do.
--
rguenth at gcc dot gnu dot org changed
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-08 10:52 ---
Note that one might argue that the testcase is invalid as as you say, C99 only
says isinf returns non-zero. So strictly speaking comparing the return value
of two invocations is not a way to check if both values are
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-08 10:58 ---
Interesting ;)
Please send patches to [EMAIL PROTECTED] indicating how you tested it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
the release scripts added the release note for 4.3.0 to zlib/ChangeLog
(upstream), not zlib/ChangeLog.gcj
--
Summary: release scripts added release note to zlib/ChangeLog,
not zlib/ChangeLog.gcj
Product: gcc
Version: 4.3.1
Status:
--- Comment #9 from uros at gcc dot gnu dot org 2008-03-08 12:44 ---
Subject: Bug 22152
Author: uros
Date: Sat Mar 8 12:43:13 2008
New Revision: 133034
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133034
Log:
PR target/22152
* gcc.target/i386/pr22152.c: New te
--- Comment #1 from simartin at gcc dot gnu dot org 2008-03-08 12:45
---
Patch submitted here:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00527.html
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from ubizjak at gmail dot com 2008-03-08 12:51 ---
BTW: The larger testcase from the Comment 0 should add two numbers together,
but the carry propagation logic in the loop is fatally flawed. The testcase
that was added to the testsuite [1] fixes this problem.
[1]
http://
--- Comment #4 from jwakely dot gcc at gmail dot com 2008-03-08 13:41
---
(In reply to comment #2)
> Finding this spot,
> however, is the sole purpose of offering the debug mode libstdc++.
I agree with every word of Wolfgang's, but this is the key point.
User code would never want to
--- Comment #1 from brian at dessent dot net 2008-03-08 14:27 ---
Subject: New: [avr] 4.3.0 buid error: illegal opcode movw for
mcu avr3
> The building for AVR target is aborted at compilation libgcc stage with
> error: Illegal opcode movw for mcu avr3. The lastest official releas
--- Comment #3 from pault at gcc dot gnu dot org 2008-03-08 15:11 ---
(In reply to comment #2)
> Paul, do you have an idea?
>
> The ICE happens when reading the .mod for p->u.wsym.sym->name == "i" in
> free_pi_tree:
> if (p->fixup != NULL)
> gfc_internal_error ("free_pi_tree(): Un
--- Comment #2 from jwakely dot gcc at gmail dot com 2008-03-08 15:25
---
(In reply to comment #0)
> // 1
> #include
>
> typedef int value_type;
>
> // void argument type
> template class std::unary_function;
eurgh, even more of an abomination than int f(void) :-)
> template c
--- Comment #3 from ghazi at gcc dot gnu dot org 2008-03-08 15:45 ---
(In reply to comment #2)
> Note that one might argue that the testcase is invalid as as you say, C99 only
> says isinf returns non-zero. So strictly speaking comparing the return value
> of two invocations is not a wa
--- Comment #4 from ubizjak at gmail dot com 2008-03-08 15:51 ---
(In reply to comment #2)
> (Only i386 and s390 have target dependent expansions for isinf - what is
> their behavior here?)
>
> Kaveh, you introduced the generic fallback, Andreas, what does s390 return
> here, Uros, how
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-08 15:51 ---
*** This bug has been marked as a duplicate of 35373 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-03-08 15:51
---
*** Bug 35510 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-03-08 15:55 ---
I don't think this is even a QOI bug. The values are defined by the C99
standard. If the person used -std=c89, then he would get what the target's
libc defines them. The inconstaint value is ok at different optimi
--- Comment #1 from dominiq at lps dot ens dot fr 2008-03-08 17:10 ---
The failures disappear if I revert revision 132966:
2008-03-05 H.J. Lu <[EMAIL PROTECTED]>
* config/i386/i386-modes.def: Use 4 byte alignment on DI for
32bit host.
--
http://gcc.gnu.org/bugzil
--- Comment #7 from dje at gcc dot gnu dot org 2008-03-08 17:14 ---
The failure was introduced between r132949 and r132965. The two mainline
patches during that time were Richi's alias change and Kenny's dataflow change.
Given the RTL failure, it more likely is caused by the dataflow p
--- Comment #2 from hjl dot tools at gmail dot com 2008-03-08 17:39 ---
Created an attachment (id=15282)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15282&action=view)
A patch
Can you try this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
--- Comment #3 from hjl dot tools at gmail dot com 2008-03-08 17:41 ---
Created an attachment (id=15283)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15283&action=view)
A real patch
Correct patch.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #4 from ubizjak at gmail dot com 2008-03-08 18:16 ---
(In reply to comment #0)
> FAIL: gfortran.dg/array_constructor_12.f90 -O3 -fomit-frame-pointer
> execution
> test
> FAIL: gfortran.dg/array_constructor_12.f90 -O3 -fomit-frame-pointer
> -funroll-loops execution test
--- Comment #5 from ubizjak at gmail dot com 2008-03-08 18:18 ---
(In reply to comment #3)
> Created an attachment (id=15283)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15283&action=view) [edit]
> A real patch
>
> Correct patch.
> -ADJUST_ALIGNMENT (DI, (TARGET_64BIT || TARGET
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-03-08 18:23
---
Subject: Bug 34956
Author: fxcoudert
Date: Sat Mar 8 18:22:31 2008
New Revision: 133037
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133037
Log:
PR fortran/34956
* trans-array.c (gfc_co
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-03-08 18:24
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ubizjak at gmail dot com 2008-03-08 18:31 ---
Segfault is here due to unaligned access:
...
movdqa .LC1, %xmm0
movdqa .LC2, %xmm2
...
.align 8
.LC1:
.long 2147483647
.long 0
.long -2147483647
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #4 from pault at gcc dot gnu dot org 2008-03-08 20:34 ---
(In reply to comment #3)
> (In reply to comment #2)
> Oddly, reverting my patch for 32103 by hand does not get rid of the fault:) I
> am beginning to think that we need fixups for the common block references to
> the
--- Comment #7 from laurent at guerby dot net 2008-03-08 20:45 ---
For reference H. J. Lu proposed patch (for C++):
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00466.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35493
--- Comment #3 from jakub at gcc dot gnu dot org 2008-03-08 20:55 ---
jboolean is lost in convert_template_argument:
/* We only form one instance of each template specialization.
Therefore, if we use a non-canonical variant (i.e., a
typedef), any future messages r
--- Comment #8 from dje at gcc dot gnu dot org 2008-03-08 21:03 ---
Sorry, the range is r132891 to r132965. So this is likely due to Loko's patch.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from rguenther at suse dot de 2008-03-08 21:17 ---
Subject: Re: [4.3/4.4 Regression] Rejects JArray
On Sat, 8 Mar 2008, jakub at gcc dot gnu dot org wrote:
> --- Comment #3 from jakub at gcc dot gnu dot org 2008-03-08 20:55 ---
> jboolean is lost in convert_tem
--- Comment #7 from dominiq at lps dot ens dot fr 2008-03-08 22:31 ---
Subject: Re: [4.4 Regression] test failures between revs.
132950 and 132974
> Can you try this patch?
For the record, the right patch works on intel-apple-darwin9
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #7 from hjl at gcc dot gnu dot org 2008-03-08 22:34 ---
Subject: Bug 35350
Author: hjl
Date: Sat Mar 8 22:33:54 2008
New Revision: 133044
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133044
Log:
2008-03-08 H.J. Lu <[EMAIL PROTECTED]>
PR target/35350
--- Comment #8 from hjl at gcc dot gnu dot org 2008-03-08 22:37 ---
Subject: Bug 35350
Author: hjl
Date: Sat Mar 8 22:37:07 2008
New Revision: 133045
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133045
Log:
2008-03-08 H.J. Lu <[EMAIL PROTECTED]>
PR target/35350
--- Comment #1 from hutchinsonandy at aim dot com 2008-03-09 04:35 ---
I can confirms this regression.
There appears to be something strange in commutation of operands before RTL is
created which may well explain why it used to work.
BThe default expander are creating calls to commuta
Revision 133014 gives
FAIL: gcc.target/ia64/visibility-1.c scan-assembler gprel.*variable_i
Revision 132852 is OK.
--
Summary: [4.4 Regression]: gcc.target/ia64/visibility-1.c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: norma
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-09 04:58 ---
>FAIL: gcc.target/ia64/visibility-1.c scan-assembler gprel.*variable_i
If you look at the testcase, you will notice that variable_i is only read from
and never written to so the variable becomes a readonly variable
--- Comment #9 from hjl dot tools at gmail dot com 2008-03-09 04:59 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #2 from eric dot weddington at atmel dot com 2008-03-09 05:43
---
*** This bug has been marked as a duplicate of 35073 ***
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
-
--- Comment #8 from eric dot weddington at atmel dot com 2008-03-09 05:43
---
*** Bug 35506 has been marked as a duplicate of this bug. ***
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--
46 matches
Mail list logo
