--- Comment #2 from patchapp at dberlin dot org 2007-02-28 06:55 ---
Subject: Bug number PR c++/30895
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg02193.html
--
http://gcc.gnu.org/bugzil
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-28 04:42 ---
And I think the pattern is incorrect anyways, lets look at it:
(define_insn "bitset_c"
[(set (match_operand:SI 0 "register_operand" "=e,d")
(ior:SI (match_operand:SI 1 "register_operand" "0,d")
--- Comment #2 from ian at airs dot com 2007-02-28 02:24 ---
The problem is that the bitset_c insn comes before the iorsi3 insn in the MD
files. It matches the ior:SI insn with one added clobber. Unfortunately, the
added clobber is of a hard reg, and so this is rejected by insn_invalid
--- Comment #21 from manu at gcc dot gnu dot org 2007-02-28 00:31 ---
(In reply to comment #20)
> Created an attachment (id=13003)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13003&action=view) [edit]
> preliminary patch
>
This patch only works for fortran and C front-ends. Obj
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-28 00:26 ---
*** Bug 30993 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30988
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-28 00:26 ---
*** This bug has been marked as a duplicate of 30988 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
The following code incorrectly warns that the function g is missing a return
statement. The warning goes away if __FUNCTION__ is replaced by
(const char*)__FUNCTION__.
BEGIN CODE ==
void f(const char*) __attribute__ ((noreturn));
template
class A
{
int g()
The function DFP_TO_INT() in gcc/config/dfp-bit.c has the job of converting
decimal floating point values to integers. It does this by calling the
decNumberFromString() function from the IBM decnumber library, but with an
incorrect argument. Fortunately, the patch is just one character:
% diff -
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-27 23:33 ---
> The same is true for -Werror.
I have to correct myself:
-Werror gives a non-zero exit status, but still writes "Warning:". I think
gfortran should follow gcc by changing also the label from "Warning:" to
"Error:" f
--- Comment #39 from michaelni at gmx dot at 2007-02-27 22:50 ---
(In reply to comment #38)
> (In reply to comment #37)
> > now if there is a unwritten rule that "m" operands and variations of them
> > cannot be copied anywhere, then it would be very desireable to have a asm
> > constrai
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-27 22:24 ---
Can you do two things for me, first supply what is the date on 4.3.0 you are
trying to compile? Second, can you attach the preprocessed source found by
recompiling the source which is failing with -save-temps?
--
The following code incorrectly warns that the function g is missing a return
statement. The warning goes away if __FUNCTION__ is replaced by
(const char*)__FUNCTION__.
BEGIN CODE ==
void f(const char*) __attribute__ ((noreturn));
template
class A
{
int g()
Hello,
there seems to be a gcc problem with the target 'score':
/home/mstein/sim/score-elf/build/./gcc/xgcc
-B/home/mstein/sim/score-elf/build/./gcc/ -nostdinc
-B/home/mstein/sim/score-elf/build/score-elf/newlib/ -isystem
/home/mstein/sim/score-elf/build/score-elf/newlib/targ-include -isystem
/n/
--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-27 22:04 ---
> > Also isn't -huge()-1 undefined code for Fortran?
> -huge()-1 can be defined in Fortran. [...]
> I'll also note that -pedantic will reject -huge()-1
Just for completeness: In the original example (the very long,
--- Comment #24 from schwab at suse dot de 2007-02-27 21:54 ---
ICE's with every optimization level.
--
schwab at suse dot de changed:
What|Removed |Added
Summ
On 2/27/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 2/27/07, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> $ avr-gcc -mmcu=atmega64 -g -O2 -Wall -Wextra -Werror -Os -I.. -I.
I submitted http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984 for this
bug. It is a generic issue.
Thanks, Andrew! I'd
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-27 21:50 ---
*** Bug 30985 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-27 21:50 ---
*** This bug has been marked as a duplicate of 29580 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #23 from pinskia at gcc dot gnu dot org 2007-02-27 21:48
---
*** Bug 30986 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 2007-02-27 21:48 ---
I don't know how many times I have to mark this as a dup.
*** This bug has been marked as a duplicate of 28834 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Add
The test gcc.c-torture/execute/mayalias-2.c is causing an ICE when compiled
with -g. The failure can be reproduced as far back as gcc 4.0, but gcc-3.3
works.
$ ./xgcc -B./ -g -c ../../gcc/testsuite/gcc.c-torture/execute/mayalias-2.c
../../gcc/testsuite/gcc.c-torture/execute/mayalias-2.c:2: inter
--- Comment #4 from uros at gcc dot gnu dot org 2007-02-27 21:27 ---
Subject: Bug 30970
Author: uros
Date: Tue Feb 27 21:27:27 2007
New Revision: 122387
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122387
Log:
PR target/30970
* config/i386/sse.md (*mov_internal
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-27 20:49 ---
This is a bogus PR. The are no negative numbers.
This is a unary minus operation and 2147483648
is too big for INTEGER(4). The only method to
get the most negative value is -HUGE() - 1.
--
kargl at gcc dot gnu do
--- Comment #7 from kargl at gcc dot gnu dot org 2007-02-27 20:46 ---
(In reply to comment #5)
> Also isn't -huge()-1 undefined code for Fortran?
-huge()-1 can be defined in Fortran. The problem
comes when one tries to use that value in, e.g.,
IABS() because the standard prohibits call
If one inputs a variable which is (-huge(i)-1), gfortran outputs:
i = -2147483648
1
Error: Integer too big for its kind at (1)
This can be very irritating as the number is representable hardware wise, even
if it is not a Fortran number (symmetrically around the zero).
I had a
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2007-02-27 20:23
---
Fixed on 4.1 branch.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
* loop.c (combine_givs_p): Return false if either GIV is not
always executed.
Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/20070227-1.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/loop.c
branches/gcc-4_1-branch/gcc/t
--- Comment #6 from ray at ultramarine dot com 2007-02-27 19:57 ---
Subject: Re: a ** exp fails for integer exponents if exp
is "-huge()-1" (endless loop)
On Tue, 27 Feb 2007, pinskia at gcc dot gnu dot org wrote:
>
>
> --- Comment #5 from pinskia at gcc dot gnu dot org 2007-0
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-27 19:54 ---
Also isn't -huge()-1 undefined code for Fortran?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
--- Comment #4 from ray at ultramarine dot com 2007-02-27 19:52 ---
Subject: Re: a ** exp fails for integer exponents if exp
is "-huge()-1" (endless loop)
On Tue, 27 Feb 2007, burnus at gcc dot gnu dot org wrote:
>
>
> --- Comment #3 from burnus at gcc dot gnu dot org 2007-02-
--- Comment #38 from xyzzy at speakeasy dot org 2007-02-27 19:36 ---
(In reply to comment #37)
> now if there is a unwritten rule that "m" operands and variations of them
> cannot be copied anywhere, then it would be very desireable to have a asm
> constraint like "m" without this restri
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-27 19:35 ---
Hi,
> > Could you post an example?
With example I mean something which actually compiles and runs. Here, I have
two problems:
include '$(where)/amos/include/essential.ecm'
is missing as well as the main progr
--- Comment #16 from tobi at gcc dot gnu dot org 2007-02-27 19:21 ---
The patch has moved into its new home on the 4.1 branch.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from tobi at gcc dot gnu dot org 2007-02-27 19:20 ---
Subject: Bug 25392
Author: tobi
Date: Tue Feb 27 19:20:21 2007
New Revision: 122382
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122382
Log:
2006-12-29 Tobias Schlueter <[EMAIL PROTECTED]>
PR fortran/2539
On 2/27/07, Shaun Jackman <[EMAIL PROTECTED]> wrote:
$ avr-gcc -mmcu=atmega64 -g -O2 -Wall -Wextra -Werror -Os -I.. -I.
I submitted http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984 for this
bug. It is a generic issue.
Thanks,
Andrew Pinski
int fs_exec(int ino)
{
void *src = 0;
if (ino)
src = (void*)0xe000;
goto *src;
}
Reduced from http://gcc.gnu.org/ml/gcc-bugs/2007-02/msg02973.html.
--
Summary: ICE with computed goto and constants
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
$ avr-gcc -mmcu=atmega64 -g -O2 -Wall -Wextra -Werror -Os -I.. -I.
-MMD -DBOOTLOADER -DF_CPU=1600 -c -o fs.o ../fs.c
../fs.c: In function 'fs_exec':
../fs.c:35: internal compiler error: tree check: expected class
'expression', have 'constant' (integer_cst) in find_taken_edge, at
tree-cfg.c:20
elseif( n_normal.lt. 1.) then
exponent = exponent - 1
temp = temp * 10.
pow = max(sigfig,(exponent+1))
n_normal = temp + 5./10.**pow
endif
c
c* all done
c
return
c
end
> And the follo
--- Comment #17 from paolo at gcc dot gnu dot org 2007-02-27 17:48 ---
Subject: Bug 28080
Author: paolo
Date: Tue Feb 27 17:48:09 2007
New Revision: 122380
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122380
Log:
2007-02-27 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #11 from burnus at gcc dot gnu dot org 2007-02-27 17:46 ---
The following additional patch needs to be applied when backporting:
http://gcc.gnu.org/ml/fortran/2007-02/msg00620.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30865
--- Comment #5 from patchapp at dberlin dot org 2007-02-27 17:46 ---
Subject: Bug number PR30973
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg02134.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #4 from burnus at gcc dot gnu dot org 2007-02-27 17:44 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg02134.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from geoffk at gcc dot gnu dot org 2007-02-27 17:25 ---
I'm confident that my patch could not possibly have affected targets other than
Darwin, and should not have significantly affected code generation even there.
Complex arithmetic testcases will fail for other reasons
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-27 17:07 ---
Could you post an example?
pow_r4_i4 means that you have x**a = **
I don't see how the exponent "a" can be infinity if it is an integer(4).
And the following program executes in <4 ms with gfort
--- Comment #8 from jakub at gcc dot gnu dot org 2007-02-27 16:27 ---
Fixed on 4.1 branch as well.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2007-02-27 16:26 ---
Fixed on 4.1 branch as well.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from jakub at gcc dot gnu dot org 2007-02-27 16:21 ---
Created an attachment (id=13120)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13120&action=view)
gcc41-pr25392.patch
Yes, I think so. Attached is what we have in Red Hat gcc 4.1.x tree for a few
days already
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-27 16:15 ---
Patch posted.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #13 from tobi at gcc dot gnu dot org 2007-02-27 16:10 ---
Should I backport this to 4.1? I guess it makes sense since this can be
considered a regressions WRT g77.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-27 15:47 ---
> I'm adding Eric too, maybe he wants to investigate the sparc version of the
> issue.
The patch which I was worried about causing a regression with respect of
calling complex functions is:
2007-02-18 Sandra Loose
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-27 15:42 ---
PR 30969 is related. The reduced fortran looks like the reduced C++.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-27 15:41 ---
Related to PR30980.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDepend
--- Comment #6 from dominiq at lps dot ens dot fr 2007-02-27 15:36 ---
I don't know if this reduced test account for all the problem, but it exhibits
at least one bug:
module perdida_m
implicit none
contains
subroutine perdida (dt, strain_tensor)
real (kind = 8), intent(in)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-27 15:33 ---
The same is true for -Werror.
Warnings still give an exit status code of zero.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-02-27 15:28
---
*** Bug 30979 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 2007-02-27 15:28 ---
*** This bug has been marked as a duplicate of 25392 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from gdr at cs dot tamu dot edu 2007-02-27 15:17 ---
Subject: Re: New: Junk in diagnostic message
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| Maybe this is a known issue, but I just noticed that many meaningless words
are
| output for this wrong snippet:
t
Maybe this is a known issue, but I just noticed that many meaningless words are
output for this wrong snippet:
class base
{
public:
typedef int vvv;
};
template
class derived : public base
{ };
template
void
f(const derived&)
{
typedef typename derived::base base;
/* typename
--- Comment #4 from tim dot bevan at 1spatial dot com 2007-02-27 15:03
---
Having got gcc 4.1.3 (which supplied 4.1.2 prerelease) and some newer version
of the GMP library installed.
gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux)
The problem still occurs
gcc orient
--- Comment #4 from patchapp at dberlin dot org 2007-02-27 14:20 ---
Subject: Bug number PR c++/29993
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01828.html
--
http://gcc.gnu.org/bugzil
--- Comment #3 from tim dot bevan at 1spatial dot com 2007-02-27 13:51
---
Unfortunately it is not possible to test that here at the moment. This is not
critical as I can avoid needing this code. Not sure if we do actually need to
specify the -ff2c flag anyway, I have a report that we n
--- Comment #5 from pcarlini at suse dot de 2007-02-27 13:41 ---
I'm adding Eric too, maybe he wants to investigate the sparc version of the
issue.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2007-02-27 13:39 ---
Note, however, that per Kaveh' reports, around the same dates (between
2007-02-14 and 2007-02-19) it started failing also on sparc-sun-solaris2.10...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
--- Comment #3 from pcarlini at suse dot de 2007-02-27 13:30 ---
Yes, I can confirm it cannot be reproduced on linux targets. Anyway, we can
easily nail down between 122051 and 122067 (from testresults).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-27 13:27 ---
As I cannot reproduce this on any linux target I guess the following change did
it:
+2007-02-16 Geoffrey Keating <[EMAIL PROTECTED]>
+
+ * config/darwin.h (LINK_SPEC): Always pass -macosx_version_min
+
If a has a value of +Infinity, then a program will "hang" (run forever) when
b = x**a
is executed.
The traceback shows that this occurs in the library routine pow_r4_i4
uname -a
Linux devlop 2.6.16.13-4-smp #1 SMP Wed May 3 04:53:23 UTC 2006 x86_64 x86_64
x86_64 GNU/Linux
--- Comment #1 from pcarlini at suse dot de 2007-02-27 13:20 ---
Looking at testresults, it seems 26_numerics/complex/13450.cc started failing
on powerpc-apple-darwin8.5.0 between 122031 and 122067.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-02-27 13:11 ---
Works, in terms of compiles, with gfortran-4.3 (svn version, 20070220).
Did you try the latest 4.1.2 release?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
Recently (~10 days ago), 26_numerics/complex/13450.cc started failing for
*many* targets, among which powerpc-darwin. On the latter I'm seeing a
miscompilation at -O1 and above of this reduced C++ snippet:
#include
#include
int main()
{
__complex__ double x;
__real__ x = -1.0;
__imag__ x
--- Comment #1 from tim dot bevan at 1spatial dot com 2007-02-27 12:21
---
Created an attachment (id=13119)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13119&action=view)
trimmed down source file
Just the ont function that provokes the problem.
--
http://gcc.gnu.org/bugzil
gcc version 4.1.0 (SUSE Linux)
Trivial file fails to compile with -ff2c:
gcc orient.f -ff2c -c -O -Wall -o orient.o
orient.f: In function 'angnrm':
orient.f:1: internal compiler error: in emit_move_insn, at expr.c:3158
Please submit a full bug report,
with preprocessed source if appropriate.
Omi
int foo(int a)
{
unsigned int b = a > 0;
char c = b;
return c;
}
is not optimized to
int foo(int a)
{
return a > 0;
}
at the tree level. Forwprop has code to do this if the final propagation
result is in a COND_EXPR.
I have a patch.
--
Summary: Does not propagate comparis
--- Comment #6 from aph at gcc dot gnu dot org 2007-02-27 09:34 ---
I think we're going to have to change this to a WONTFIX for the 4.1 branch.
If we can get a 4.3 backtrace that will be interesting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20495
74 matches
Mail list logo
