Ian For a middle-end error like
Ian assuming signed overflow does not occur when simplifying
Ian multiplication a caret pointer might be more misleading than
Ian otherwise, as one thing we know for sure is that it would not point at
Ian a multiplication operator.
Chris An important class of
Andi == Andi Kleen [EMAIL PROTECTED] writes:
Andi [also sometimes I would love to have an option in gcc to just
Andi display the preprocessed input when something bad happens inside
Andi a macro. I usually do that from hand using gcc -E, but it would be cool
Andi if the compiler could do it
On Mar 6, 2008, Olivier Galibert [EMAIL PROTECTED] wrote:
It's extremely rare, no doubt about it. It's just that it *yells*
security issue in the making. It's not a source bug, i.e. not easily
reviewable. It's related to signal handlers which are the mark of a
server and/or more
On Mar 4, 2008, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Richard Sandiford wrote:
If we went for an explicit move, I assume we would either have to
(a) discount hard regs that can't be moved, (b) force backends to
allow all no-op moves or (c) circumvent the backend somehow.
From my point of
On Mar 4, 2008, Richard Guenther [EMAIL PROTECTED] wrote:
the type of the result is unspecified.
??? You mean, other than by TREE_TYPE of the BIT_FIELD_REF? I'm
pretty sure that's what specifies the type of the result.
I suggest to make sure that bit position and size are constants,
+1
On Sat, 8 Mar 2008, Alexandre Oliva wrote:
On Mar 4, 2008, Richard Guenther [EMAIL PROTECTED] wrote:
the type of the result is unspecified.
??? You mean, other than by TREE_TYPE of the BIT_FIELD_REF? I'm
pretty sure that's what specifies the type of the result.
You are late, the
Hi,
I have problem with data flow and combine that is causing ICE with
experimental build. Despite all efforts to blame my own target changes,
I have reached the conclusion that this is a gcc COMBINE bug, but seek
your advice before filing a bug report.
The problem seems to be that the
Desineni, Harikishan wrote:
I just compiled an app with GCC. It is segmentation faulting in call_gmon_start
(even before reaching main() of my program
Gcc usage questions should not be sent to the gcc list. This list is
for being doing development work on gcc. This is an appropriate
On Mon, 3 Mar 2008, Gabriel Dos Reis wrote:
Do we still want to keep this branch alive?
Looking at the changes that were made in the last three months still,
it seems the branch is still surprisingly alive, so it may not yet be
the time to close it. Personally I don't have a preference either
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
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:
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
#8216;mmaxloc1_4_r16#8217;:
../../../libgfortran/generated/maxloc1_4_r16.c:220: internal compiler error: in
--- 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=15281action=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
--- 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
--- 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
--- 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=gccview=revrev=133034
Log:
PR target/22152
* gcc.target/i386/pr22152.c: New
--- 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]
--- 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 release
--- 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(): Unresolved
--- Comment #2 from jwakely dot gcc at gmail dot com 2008-03-08 15:25
---
(In reply to comment #0)
// 1
#include functional
typedef int value_type;
// void argument type
template class std::unary_functionvoid, value_type;
eurgh, even more of an abomination than int
--- 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 way
--- 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 is
--- 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
--- 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.
--
--- 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
--- 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=15282action=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=15283action=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=15283action=view) [edit]
A real patch
Correct patch.
-ADJUST_ALIGNMENT (DI, (TARGET_64BIT ||
--- 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=gccview=revrev=133037
Log:
PR fortran/34956
* trans-array.c
--- 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
--- 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 JArrayjboolean
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
--- 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
--
--- 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=gccview=revrev=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=gccview=revrev=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
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:
--- 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
55 matches
Mail list logo
