--- 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=gccview=revrev=130395
Log:
2007-11-24 Paul Thomas [EMAIL PROTECTED]
PR
--- 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
--- 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
--
--- 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:
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 (*fn)(void)
void call(void)
{
fn();
}
namespace
{
struct bar
{
static void fn(void) {}
};
}
int main()
{
callbar::fn();
}
--- 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=14629action=view)
program to illustrate the issue
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34213
--- 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
--- 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
--- 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 *,
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:
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'
--- 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
--
--- 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
--- 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=gccview=revrev=130396
Log:
2007-11-24 Tobias Burnus [EMAIL PROTECTED]
PR
--- 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=14630action=view)
preprocessed source
Shows the problem with gcc 4.2 and with trunk from 20070916 and earlier.
--
--- 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 =
[ 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
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
--
--- 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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
bb 9:
s1 = (long unsigned int) *buf + s1;
buf = buf + 1;
s2 = s1 + s2;
k = k + -1;
if (k != 0)
goto bb 9;
else
goto bb
--- 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 #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 #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 bb 10;
else
goto bb 11;
and take into account their breakage for its cost
--- 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 #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
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 #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 #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
--- 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
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
--- 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
--- 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...
--
--- 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 #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 #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.
--- 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 #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 prevent
--- 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 #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
--- 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 #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 bb 10;
else
goto bb 11;
and take into
--- 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 #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 stopped
templatetypename T, T a, T... Params
struct max
{
static const T value = a maxT, Params::value ? a : maxT,
Params::value;
};
templatetypename T, T a, T b
struct maxT, a, b
{
static const T value = a b ? a : b;
};
static const int value1 = max int, 1, 2::value;
static const int
--- 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...
--
--- 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
--
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
--
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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
--- 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 AT::x during the link (which is the correct way of doing it).
--
pinskia at gcc dot gnu dot org changed:
What
--
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 #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.
--
--- 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 #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:07 ---
init2.c:37: assertion failed: ((64 - 0)+0) == (((64 - 0)+0)/8) * 8
sizeof(mp_limb_t) == (((64 - 0)+0)/8)
built-in:0: internal compiler error: Abort
Can you build a newer GMP/MPFR and try again? It looks like a
--- 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)
+++
--- 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
--- 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
--- 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 #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 #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
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
--- 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=14632action=view)
preroccesed compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34220
68 matches
Mail list logo
