--- Comment #1 from nickols_k at mail dot ru 2007-11-25 07:58 ---
Created an attachment (id=14632)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14632&action=view)
preroccesed compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34220
I've tried to compile megapov-1.2.1 (at megapov.inetart.net) with using of this
command line:
g++4 -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../source
-I../../source/patches -I../../unix -I/usr/X11R6/include -pipe
-Wno-multichar -s -O3 -ffast-math -malign-double -minline-all-stringops
-marc
--- Comment #11 from fang at csl dot cornell dot edu 2007-11-25 04:10
---
*nudge* (got patch?)
Also, is there a "make installcheck" mechanism in place to automatically test
installed builds?
It wouldn't have to be very extensive, just enough to make sure each supported
language at le
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-11-25 03:28
---
I have a patch on its way.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-25 03:15 ---
value = MAX_EXPR <(int) value, 1>
Which means we did not "inline" the value of the other value.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-25 03:11 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-11-25 03:11 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-25 03:10 ---
Confirmed, and here is a patch which really fixes the issue:
Index: ../../gcc/cp/cvt.c
===
--- ../../gcc/cp/cvt.c (revision 130402)
+++ ../../gcc/cp/cv
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-25 03:07 ---
init2.c:37: assertion failed: ((64 - 0)+0) == (((64 - 0)+0)/8) * 8 &&
sizeof(mp_limb_t) == (((64 - 0)+0)/8)
:0: internal compiler error: Abort
Can you build a newer GMP/MPFR and try again? It looks like a bug in
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-25 03:05 ---
Confirmed, another regression due to anonymous namespace changes.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-25 03:04 ---
Confirmed, an error recovery issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-11-25 03:03 ---
This is too hard to fix really, you need all the Translation units inside the
compiler itself to dect it and then compare the functions to make sure they are
the same (which is slow).
Closing as fixed.
--
pinski
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-25 03:02 ---
Confirmed, most likely what is happening is that we are not going back and
instatitating A::x during the link (which is the correct way of doing it).
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-11-25 02:59 ---
With types checking on the trunk, I actually get an ICE:
t.cc:8: error: type mismatch in address expression
struct G *
const struct G *
D.2051 = &D.2032->g
t.cc:8: internal compiler error: verify_gimple failed
Plea
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-25 02:49 ---
Can you show the full build log?
Also can you try a newer revision?
This builds for many folks on i686-linux-gnu.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Add
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-25 02:45 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-25 02:44 ---
3.4.x is no longer maintained, can you try using 4.1.3 or 4.2.2?
Also I don't think eabi was really supported in 3.4.3 anyways.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pcarlini at suse dot de 2007-11-25 01:01 ---
Doug, can you have a look? Adding the missing definitions moves the error to
link-time but it persists: something seems indeed fishy in the front-end code
for static constant members vs variadic templates...
--
pcarlini
template
struct max
{
static const T value = a > max::value ? a : max::value;
};
template
struct max
{
static const T value = a > b ? a : b;
};
static const int value1 = max< int, 1, 2>::value;
static const int value2 = max< int, 1, 3, 5>::value;
As the initialization for value
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2007-11-24 23:36
---
> What I saw when mode changes were allowed was something like
> the following:
>
> set (subreg:SI (mem:HI)) (fix:SI (fix:SF))
>
> where the mem was a spilled HImode pseudo. At the time,
> I thought I had stop
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-24 23:02 ---
Some debugging notes. While the following crashes
C_NULL_PTR1 = transfer(0_C_INTPTR_T, C_NULL_PTR1)
it works after replacing the constant by a variable.
In gfc_simplify_transfer (for the constant expression),
/*
--- Comment #24 from rakdver at gcc dot gnu dot org 2007-11-24 22:28
---
(In reply to comment #20)
> > Couldn't ivopts be taught to recognize "dec and branch on zero" patterns
> >
> > k_114 = k_15 + -1;
> > if (k_114 != 0)
> > goto ;
> > else
> > goto ;
> >
> > and take
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-24
22:14 ---
Subject: Re: [4.2/4.3 Regression] ICE in reload_cse_simplify_operands, at
postreload.c:392
> > I haven't seen the paradoxical subreg in a float/fix conversion
> > insns with the current patch. I did see
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-24
21:58 ---
Subject: Re: [4.2 Regression] ICE in delete_output_reload, at reload1.c:7926
This seems to help:
Index: reload1.c
===
--- reload1.c (revi
--- Comment #23 from rakdver at gcc dot gnu dot org 2007-11-24 21:56
---
Let me have a look what's going on here.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #22 from rakdver at kam dot mff dot cuni dot cz 2007-11-24
21:52 ---
Subject: Re: [4.3 Regression] Code size regression caused by fix to PR 31360
> > Why? If using dec and branch is profitable, doloop pass should do it; the
> > transformation that ivopts do does not preve
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-11-24 21:47
---
> Is there a reason why you want to load/store HImode/QImode values in
> the FPU registers on sparc? On the pa, there aren't any insns that
> operate on them. So, the only reason we supported this was because
>
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-24
21:31 ---
Subject: Re: [4.2/4.3 Regression] ICE in reload_cse_simplify_operands, at
postreload.c:392
>We need a temporary when loading/storing a HImode/QImode value
>between memory and the FPU registers. T
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-11-24 20:31
---
> This probably means I don't have the change quite right. I also have a
> problem with paradoxical SUBREGS when the inner register is spilled. I'm
> not clear on how this is to be handled on a big endian target
--- Comment #3 from manu at gcc dot gnu dot org 2007-11-24 20:23 ---
Invalid then.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #2 from p dot vanhoof at oma dot be 2007-11-24 19:57 ---
Actually it was LDFLAGS, inherited that from an old build and had completely
forgotten about it. The build seems to be going fine now. My mistake, my
apologies...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3421
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-24 19:50 ---
Are you sure you don't have CFLAGS set?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
building the trunk fails on x86_64-unknown-linux-gnu as of r130396. The failure
occurs while building fixincl. The compilation is done in 64 bit, but the link
stage in 32 bit, which of course fails:
gcc -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definit
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-11-24 19:45 ---
(In reply to comment #4)
> I think that future standard compliance is important so I move that we make
> -fno-backslash the default behavior.
Agreed.
Is this still in time for 4.3? If we make that change, it's pro
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-24 19:44 ---
With trunk the same code is generated for both cases.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
Consider the following code:
struct bar
{ virtual int get_val() { return 1; } };
int inline get_value(bar* b) { return b->get_val(); }
int main(void)
{
bar b;
//return (&b)->get_val();#1
return get_value(&b); #2
}
Using #1, the compiler optimises away all the code with -O.
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-24
19:27 ---
Subject: Re: [4.2/4.3 Regression] ICE in
reload_cse_simplify_operands, at postreload.c:392
The attached patch seems to fix the problem on the trunk. However,
it doesn't work on 4.2. It makes the
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2007-11-24 19:19
---
> Why? If using dec and branch is profitable, doloop pass should do it; the
> transformation that ivopts do does not prevent that or make it any more
> difficult.
I'm not sure that blindly doing transformations
--- Comment #6 from bob at digilink dot net 2007-11-24 19:14 ---
I forgot to add that the above failure occurs when building with the following
options:
+ ../gcc-4.2.2/configure --prefix=/opt --with-local-prefix=/opt/include
--with-gnu-as --with-gnu-ld --with-build-time-tools=/opt/bin -
--- Comment #20 from rakdver at gcc dot gnu dot org 2007-11-24 19:08
---
> Couldn't ivopts be taught to recognize "dec and branch on zero" patterns
>
> k_114 = k_15 + -1;
> if (k_114 != 0)
> goto ;
> else
> goto ;
>
> and take into account their breakage for its cost es
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-11-24 18:59
---
With a cross-compiler.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pluto at agmk dot net 2007-11-24 18:50 ---
(In reply to comment #2)
> A quick untested patch which I have not even tested on this testcase:
doesn't work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34212
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2007-11-24 18:43
---
The pessizimation actually happens at the tree level, -fivopts turns
:
s1 = (long unsigned int) *buf + s1;
buf = buf + 1;
s2 = s1 + s2;
k = k + -1;
if (k != 0)
goto ;
else
goto ;
into
:
s
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-24 17:58 ---
This is obviously not very useful information. You have to track this down
further. The usual process is
1) Build individual source files without optimization until you figure out
which file triggers the fail
We've found a serious audio distortion with the standard GSM 6.10 library, when
optimizations are turned on in gcc 4.2. No such problem exists in gcc 4.1.
Sorry I can't be more specific as to where the problem lies.
Asterisk bugtracker: http://bugs.digium.com/view.php?id=11243
--
S
--- Comment #2 from tbm at cyrius dot com 2007-11-24 15:26 ---
The reduced testcase only shows the problem with 4.2:
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
void calc_score_dist (int mxdlen, long double d, long double **dist)
{
unsigned long i, scr2;
for (i = 1; i <
--- Comment #1 from tbm at cyrius dot com 2007-11-24 15:25 ---
Created an attachment (id=14630)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14630&action=view)
preprocessed source
Shows the problem with gcc 4.2 and with trunk from 20070916 and earlier.
--
http://gcc.gnu.org/
[ Forwarded from http://bugs.debian.org/446714 ]
We're seeing the following ICE with 4.2:
(sid)1851:[EMAIL PROTECTED]: ~] gcc-4.2 -m32 -c -O dialign-t-prob.c
dialign-t-prob.c: In function âcalc_score_distâ:
dialign-t-prob.c:11: warning: incompatible implicit declaration of built-in
function â
--- Comment #11 from burnus at gcc dot gnu dot org 2007-11-24 13:18 ---
Subject: Bug 34192
Author: burnus
Date: Sat Nov 24 13:18:27 2007
New Revision: 130396
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130396
Log:
2007-11-24 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-24 13:12 ---
Well, C is not Fortran and this program is INVALID. The invalidity is very hard
to detect at compile time and gfortran currently does not have an option to do
so at run time.
If you need to change the variable in the
--- Comment #11 from patchapp at dberlin dot org 2007-11-24 13:05 ---
Subject: Bug number PR34079
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-11/msg01275.html
--
http://gcc.gnu.org/bugzilla/s
A Fortran DO loop does not terminate if the loop variable is changed
inside of the loop to a value higher than the implied limit.
Please find below a small example which shows this behavior.
program main
integer LOOP
do LOOP=1,3
print *,' LOOP = ',LOOP,' < 3'
Hi,
In simple cases like linear sequences, will the GCC compiler make a jump
table?
switch (x) {
case 0:
case 1:
case 2:
case 3:
}
In all other cases where a jump table is not applicable, will the GCC compiler
sort the values and do a binary search?
switch (x) {
case 1:
case 256:
case 65536:
--- Comment #11 from burnus at gcc dot gnu dot org 2007-11-24 12:20 ---
I think the failures in test3 are ok. Example program:
module m
integer :: a = 10
end module m
program p
integer :: a
a = 5
call s()
contains
subroutine s()
use m, local1 => a
use m
print *, local
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-24 12:15 ---
A quick untested patch which I have not even tested on this testcase:
Index: stmt.c
===
--- stmt.c (revision 130381)
+++ stmt.c (working copy)
--- Comment #10 from burnus at gcc dot gnu dot org 2007-11-24 12:09 ---
(In reply to comment #9)
> The following test now fails:
That test passes (0 0 0) with gfortran (w/o patch) and g95.
With ifort, NAG f95, openf95 and sunf95 it fails with "0 0 2".
And with the patched gfortran it fa
--- Comment #1 from tim at klingt dot org 2007-11-24 11:42 ---
Created an attachment (id=14629)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14629&action=view)
program to illustrate the issue
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34213
trying to use member functions of classes in the anonymous namespace as
template argument doesn't work.
the following code illustrates this issue:
template
void call(void)
{
fn();
}
namespace
{
struct bar
{
static void fn(void) {}
};
}
int main()
{
call<&bar::fn>();
}
it complains
--- Comment #5 from bob at digilink dot net 2007-11-24 11:15 ---
On Solaris 2.10 x86 (AMD64)
After the patches referenced in
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00563.html are applied to gcc
4.2.2 the build fails with:
/home/bob/src/gnu/gcc/gcc-4.2.2_SunOS-5.10.amd64/./gcc/xgc
--- Comment #9 from patchapp at dberlin dot org 2007-11-24 11:10 ---
Subject: Bug number PR33499
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-11/msg01273.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #9 from dominiq at lps dot ens dot fr 2007-11-24 11:04 ---
The following test now fails:
! { dg-do run }
! A test to prove that, a sub-routine, variables from the module takes
! precedence in case of name conflict with local entities.
! Reference Fortran 95 standard documen
--- Comment #8 from pault at gcc dot gnu dot org 2007-11-24 10:17 ---
Subject: Bug 33541
Author: pault
Date: Sat Nov 24 10:17:26 2007
New Revision: 130395
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130395
Log:
2007-11-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
68 matches
Mail list logo
