[Bug c/30936] const attribute in nanf prototype causes gcc not producing correct code.
--- Comment #3 from filippo dot arcidiacono at gmail dot com 2007-02-26 08:08 --- Created an attachment (id=13111) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13111action=view) prerprocessed file of nanf-test.c In attach you can find the preprocessed file nanf-test.i of nanf-test.c. It contains the nanf prototype, declared by bits/mathcalls.h included by math.h header file. Using -Wall option I doesn't obtain any warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936
[Bug target/30936] const attribute in nanf prototype causes gcc not producing correct code.
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-26 08:21 --- No, the const attribute does not cause to produce wrong code. On powerpc-darwin with your testcase, I get: mflr r0 lis r3,ha16(LC0) la r3,lo16(LC0)(r3) stw r0,8(r1) stwu r1,-64(r1) bl _nanf li r3,0 fcmpu cr7,f1,f1 bne- cr7,L5 You can see the floating point compare happens but only one call to nanf. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936
[Bug target/30936] const attribute in nanf prototype causes gcc not producing correct code.
--- Comment #5 from filippo dot arcidiacono at gmail dot com 2007-02-26
09:29 ---
Created an attachment (id=13112)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13112action=view)
assembler code of nanf-test.c
Following a piece of the objdump of the nanf-test:
:
:
int
main (void)
{
0: e6 2f mov.l r14,@-r15
2: 22 4f sts.l pr,@-r15
4: f8 7f add #-8,r15
6: f3 6e mov r15,r14
int op;
op = (nanf () != nanf () );
8: e3 62 mov r14,r2
a: c8 72 add #-56,r2
c: 00 e1 mov #0,r1
e: 1f 12 mov.l r1,@(60,r2)
if (!op) {
10: e3 61 mov r14,r1
12: c8 71 add #-56,r1
14: 1f 51 mov.l @(60,r1),r1
16: 18 21 tst r1,r1
18: 08 8b bf 2c main+0x2c
printf (Test NAN Failed!\n);
1a: 09 d1 mov.l 40 main+0x40,r1 ! 0x0 main
1c: 13 64 mov r1,r4
1e: 09 d1 mov.l 44 main+0x44,r1 ! 0x0 main
20: 0b 41 jsr @r1
22: 09 00 nop
return (1);
24: 01 e1 mov #1,r1
26: 12 2e mov.l r1,@r14
28: 02 a0 bra 30 main+0x30
2a: 09 00 nop
}
:
:
Note that I using sh4 architecture.
In attach you can find the nanf-test.s that doesn't contains any reference
to nanf symbol.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936
[Bug libstdc++/28080] header dependencies
--- Comment #16 from paolo at gcc dot gnu dot org 2007-02-26 09:36 --- Subject: Bug 28080 Author: paolo Date: Mon Feb 26 09:36:39 2007 New Revision: 122329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122329 Log: 2007-02-26 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/28080 (partial) * include/std/bitset: Do not include istream and ostream, ios is enough. * include/std/iomanip: Do not include the whole istream, ios is enough; do not include functional; reformat. * include/std/functional: Do not include cstddef. * include/std/list: Do not include bits/stl_uninitialized.h. * include/std/numeric: Do not include the whole iterator and bits/stl_function.h. * include/std/valarray: Do not include numeric. * include/bits/stl_numeric.h: Include bits/concept_check.h. * src/iostream-inst.cc: Include istream. * include/ext/functional: Include cstddef. * testsuite/util/testsuite_hooks.h: Do not include locale, ctime is enough; qualify tm. * testsuite/util/testsuite_hooks.cc: Qualify tm. 2007-02-26 Paolo Carlini [EMAIL PROTECTED] * include/bits/locale_facets.h (class ctype_bynamechar, class ctype_bynamewchar_t): Declare. * src/ctype.cc (ctype_bynamewchar_t::ctype_byname(const char*, size_t), ctype_bynamewchar_t::~ctype_byname): Define. * config/locale/generic/ctype_members.cc (ctype_bynamechar:: ctype_byname(const char*, size_t), ctype_bynamechar::~ctype_byname): Likewise. * config/locale/gnu/ctype_members.cc (ctype_bynamechar:: ctype_byname(const char*, size_t), ctype_bynamechar::~ctype_byname): Likewise. * config/locale/darwin/ctype_members.cc (ctype_bynamechar:: ctype_byname(const char*, size_t), ctype_bynamechar::~ctype_byname): Likewise. * testsuite/22_locale/headers/locale/synopsis.cc: Remove xfail. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/locale/darwin/ctype_members.cc trunk/libstdc++-v3/config/locale/generic/ctype_members.cc trunk/libstdc++-v3/config/locale/gnu/ctype_members.cc trunk/libstdc++-v3/include/bits/locale_facets.h trunk/libstdc++-v3/include/bits/stl_numeric.h trunk/libstdc++-v3/include/ext/functional trunk/libstdc++-v3/include/std/bitset trunk/libstdc++-v3/include/std/functional trunk/libstdc++-v3/include/std/iomanip trunk/libstdc++-v3/include/std/list trunk/libstdc++-v3/include/std/numeric trunk/libstdc++-v3/include/std/valarray trunk/libstdc++-v3/src/ctype.cc trunk/libstdc++-v3/src/iostream-inst.cc trunk/libstdc++-v3/testsuite/22_locale/headers/locale/synopsis.cc trunk/libstdc++-v3/testsuite/util/testsuite_hooks.cc trunk/libstdc++-v3/testsuite/util/testsuite_hooks.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug target/30936] __builtin_nanf() != __builtin_nanf() is false for sh4-linux-gnu
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-26 09:52 --- In attach you can find the nanf-test.s that doesn't contains any reference to nanf symbol. That is ok, because nanf() is foldded into a constant and the function is not called. I don't read sh asm that well but it looks like: mov #0,r1 is wrong, it should be instead: mov #1, r1 If I changed nanf() to __builtin_nanf() on powerpc-darwin, I get: li r0,1 stw r0,56(r30) lwz r0,56(r30) cmpwi cr7,r0,0 So it is doing the correct thing there. So this still has nothing to do with the nanf prototype really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|const attribute in nanf |__builtin_nanf() != |prototype causes gcc not|__builtin_nanf() is false |producing correct code. |for sh4-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936
[Bug tree-optimization/30965] New: Fails to tree-combine conditions in COND_EXPRs
(split from PR19431)
#include tr1/functional
#include algorithm
extern void assign( long* variable, long v )
{
std::transform( variable, variable + 1, variable,
std::tr1::bind( std::plus long (), 0L, v ) );
}
extern void assign( long variable, long v )
{
std::transform( variable, variable + 1, variable,
std::tr1::bind( std::plus long (), 0L, v ) );
}
at -O3 gcc 4.2 produces:
assign(long, long):
movq-40(%rsp), %rax
movq%rsi, -24(%rsp)
movq$0, -32(%rsp)
movq$0, -64(%rsp)
movq%rsi, -56(%rsp)
movq%rsi, (%rdi)
movq%rax, -72(%rsp)
ret
assign(long*, long):
movq%rsi, (%rdi)
ret
The problem is:
We start with
D.59982_3 = variable_2(D) + 4B;
__unary_op = __unary_op.65;
goto bb 4 (L1);
L0:;
D.61146_10 = __unary_op._M_arg1;
D.61147_11 = __unary_op._M_arg2;
D.61093_12 = D.61146_10 + D.61147_11;
*variable_13 = D.61093_12;
variable_14 = variable_7 + 4B;
variable_15 = variable_13 + 4B;
# variable_7 = PHI variable_2(D)(2), variable_14(3)
# variable_13 = PHI variable_2(D)(2), variable_15(3)
L1:;
if (D.59982_3 != variable_7) goto L0; else goto L2;
and loop header copying and DOM make it optimizable:
D.59982_3 = variable_2(D) + 4B;
__unary_op.65._M_arg2 = v_1(D);
__unary_op.65._M_arg1 = 0;
__unary_op = __unary_op.65;
__unary_op$_M_arg2_54 = __unary_op._M_arg2;
__unary_op$_M_arg1_53 = __unary_op._M_arg1;
if (variable_2(D) != D.59982_3) goto L7; else goto L2;
L2:;
return;
# variable_49 = PHI variable_2(D)(2)
# variable_27 = PHI variable_2(D)(2)
L7:;
__unary_op$_M_arg1_25 = __unary_op$_M_arg1_53;
__unary_op$_M_arg2_17 = __unary_op$_M_arg2_54;
D.61093_18 = __unary_op$_M_arg1_53 + __unary_op$_M_arg2_54;
*variable_49 = D.61093_18;
variable_20 = variable_27 + 4B;
variable_21 = variable_49 + 4B;
goto bb 3 (L2);
so a tweaked forwprop fixes it at least before PRE. But dunno if we want
to do tree combining on conditions here. The code is optimized at
RTL expansion time.
--
Summary: Fails to tree-combine conditions in COND_EXPRs
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30965
[Bug tree-optimization/19431] missed optimization with ifs and deferencing
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-02-26 10:33 --- I split the issue in comment #10 to PR30965 as it is a slightly different issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
[Bug tree-optimization/30966] New: (long long)(int_var) == (long long)(int_var1) is not simplified down to int_var == int_var1 when expanded
Both of these functions should produce the same asm:
int f(int a, int b)
{
long long c = a;
long long d = b;
return c == d;
}
int f1(int a, int b)
{
return ((long long) a) == ((long long)b);
}
But don't at least on powerpc-darwin:
_f:
srawi r0,r3,31
srawi r2,r4,31
cmpw cr7,r0,r2
mr r9,r3
li r3,0
bnelr+ cr7
cmpw cr7,r9,r4
bnelr+ cr7
li r3,1
blr
_f1:
xor r3,r3,r4
cntlzw r3,r3
srwi r3,r3,5
blr
Even powerpc64-darwin does not produce the same asm, in this case f1 is worse
than f:
_f:
xor r3,r3,r4
cntlzd r3,r3
srdi r3,r3,6
blr
_f1:
xor r4,r3,r4
cntlzw r4,r4
srwi r4,r4,5
extsw r3,r4
blr
But only because there is an extra sign extends (I will file this in a
different bug).
--
Summary: (long long)(int_var) == (long long)(int_var1) is not
simplified down to int_var == int_var1 when expanded
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30966
[Bug rtl-optimization/30967] New: Extra sign/zero extend with word comparison result
Testcase:
int f1(int a, int b)
{
return a == b;
}
--
We produce right now:
_f1:
xor r4,r3,r4
cntlzw r4,r4 --- sign never 1
srwi r4,r4,5 --- upper bits defined as 0
extsw r3,r4
blr
The sign extend is incorrect as r4's sign will never be 1 and all the upper
bits will always be zero because of srwi.
we have the same issue if the return value is unsigned int also in that there
is an extra zero extend.
This is even with -fsee.
--
Summary: Extra sign/zero extend with word comparison result
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc64-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30967
[Bug rtl-optimization/30967] Extra sign/zero extend with word comparison result
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30967
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #4 from eres at il dot ibm dot com 2007-02-26 11:46 --- Created an attachment (id=13113) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13113action=view) assembly file (PPC) It seems that problem is in the initialization of the expansion (which related to the sign of the init value). The original accumulator is been initialized as follows: fmr 0,1 rlwinm 0,3,0,29,31 while the expansion is been initialized as follows: lis 11,[EMAIL PROTECTED] lfs 13,[EMAIL PROTECTED](11) when the expansion is been initialized with the value of the original accumulator the program executed as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug target/30936] __builtin_nanf() != __builtin_nanf() is false for sh4-linux-gnu
--- Comment #7 from filippo dot arcidiacono at gmail dot com 2007-02-26 13:01 --- is wrong, it should be instead: mov #1, r1 OK! This is what I get if I use __builtin_nanf() instead of nanf. But using nanf there isn't any undefined nanf symbol in the obiect generated, as expected, as well as happens also with gcc (3.4.3). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936
[Bug fortran/30285] gfortran excessive memory usage with large modules
--- Comment #9 from anlauf at gmx dot de 2007-02-26 13:05 --- (In reply to comment #8) the below patch looks like it fixes the problem. any chance this could be tryed on the reported problem ? If somebody with sufficient resources can provide a binary (like FX's snapshots), I will try to recompile the project. -ha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug fortran/30968] New: Bogus warning with continued lines of concatenated strings
The following program gives a bogus warning when compiled with -Wall or -std=f95 or -std=f2003: program gfcbug59 print *, Hello // World ! Bogus warning with -Wall or -std=f95 or -std=f2003 end program gfcbug59 % gfc -Wall gfcbug59.f90 gfcbug59.f90:3.8: // World ! Bogus warning with -Wall or -std=f95 or -std=f2003 1 Warning: Missing '' in continued character constant at (1) gfcbug59.f90:3.8: // World ! Bogus warning with -Wall or -std=f95 or -std=f2003 1 Warning: Missing '' in continued character constant at (1) -- Summary: Bogus warning with continued lines of concatenated strings Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30968
[Bug regression/30969] New: The polyhedron test 'fatigue.f90' is no longer working.
With powerpc-apple-darwin7.9.0, version 4.3.0 20070223, the polyhedron test 'fatigue.f90' (see http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html) gives ... Simulation terminated. This sample will never fracture. The imposed stress is below the fatigue limit. See the output file for more information. with optimisation -O1 and above. It worked with 4.3.0 20070217. If I add the line if(coefficient == 1000.0) print *, n, coefficient after line 1428, the code works again. I am attaching two reduced tests. The first one works without optimization, gives Simulation terminated. Spin cycle = 10 Time (sec) = 2.8E+01 The maximum number of simulation spin cycles was exceeded. with -O1, and This sample will never fracture. The imposed stress is below the fatigue limit. with -O2. The second test is similar to the previous one but works with -O3 -ffast-math -funroll-loops I have commented several variants which break the code. Of special interest is !4 where if (accumulated_plastic_strain plastic_strain_threshold) then else is working, but not if (accumulated_plastic_strain = plastic_strain_threshold) then Note that there is also some problems with the test 'induct.f90' see http://gcc.gnu.org/ml/fortran/2007-02/msg00554.html -- Summary: The polyhedron test 'fatigue.f90' is no longer working. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969
[Bug regression/30969] The polyhedron test 'fatigue.f90' is no longer working.
--- Comment #1 from dominiq at lps dot ens dot fr 2007-02-26 13:30 --- Created an attachment (id=13114) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13114action=view) this test works only without optimization -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969
[Bug regression/30969] The polyhedron test 'fatigue.f90' is no longer working.
--- Comment #2 from dominiq at lps dot ens dot fr 2007-02-26 13:31 --- Created an attachment (id=13115) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13115action=view) test working with -O3 -ffast-math -funroll-loops -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969
[Bug rtl-optimization/30970] New: Register zeroing by xor N,N should be moved out of loop
The testcase:
--cut here--
#define N 256
int b[N];
void test()
{
int i;
for (i = 0; i N; i++)
b[i] = 0;
}
--cut here--
compiles with '-O2 -msse2 -ftree-vectorize' into:
test:
movl$16, %eax
pxor%xmm0, %xmm0
movdqa %xmm0, b
.p2align 4,,7
.L2:
pxor%xmm0, %xmm0
movdqa %xmm0, b(%eax)
addl$16, %eax
cmpl$1024, %eax
jne .L2
rep ; ret
Please note second pxor that is _not_ needed. Also, it should be moved out of
loop as it is loop invariant.
For slightly different testcase, where 'b[i] = 1' (or anything != 0) we get
optimized code:
test:
movl$16, %eax
movdqa .LC0, %xmm0
movdqa %xmm0, b
.p2align 4,,7
.L2:
movdqa %xmm0, b(%eax)
addl$16, %eax
cmpl$1024, %eax
jne .L2
rep ; ret
It looks like (g)cse doesn't know what 'xor N,N' means.
--
Summary: Register zeroing by xor N,N should be moved out of loop
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30970
[Bug rtl-optimization/30971] New: Wrong return value in loop (Tail call)
When changing n to be 0 (instead of 10) in testsuite/gcc.c-torture/execute/ieee/mzero6.c the return value is 0 but it should be -0, which causes the program to abort the execution. gcc mzero6.c -w -O2 -fno-show-column -lm -funroll-loops --fast-math -O2 -o out -da if (__builtin_copysign (1.0, func (0.0 / -5.0, 0)) != -1.0) If we look at the assembly we see that the return value in 0 when n = 0 (instead of d): .L43: lis 5,[EMAIL PROTECTED] lfd 0,[EMAIL PROTECTED](5) fcmpu 0,13,0 bne 0,.L47 li 3,0 bl exit -- Summary: Wrong return value in loop (Tail call) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eres at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30971
[Bug rtl-optimization/30971] Wrong return value in loop (Tail call)
--- Comment #1 from eres at il dot ibm dot com 2007-02-26 13:38 --- Created an attachment (id=13116) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13116action=view) assembly file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30971
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #5 from eres at il dot ibm dot com 2007-02-26 13:51 --- The reason that this tescase fails is because the expansion is been initialized with +0, which means that it's final result will be +0 and not -0 as expected. expansion += d -- expansion += -0 -- +0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug c/30972] New: Call to _access has invalid parameter when linked with msvcrt
WinAVR, the AVR compiler package for Windows has some problems with Vista. I looked into it and think I have found the problem, which is in the GCC compiler and possibly in other parts of the GCC toolchain. The error shows up in any compilation with avr-gcc.exe: avr-gcc: _spawnvp: No such file or directory spawnvp is trying to spawn cc1.exe, but fails because it does not know where to find it. The argument to spawnvp is 'cc1', without any path. spawnv is tried first as well. The call comes from pex_win32_exec_child (libiberty/pex-win32.c). The problem is not spawnvp but the part that creates the correct path for cc1. I'm not sure where this code is (I only debugged the binary without source code), but I suspect it is the function find_a_file (gcc.c). The problem is project wide though. What I do know is that when the possible cc1 paths are tested for existance, a call to the standard _access C function is used to test the paths. The problem is that the mode parameter is sometimes set to X_OK (system.h, equals 1). In unix like environments this tests for execute rights. However, when mingW is used to build GCC, the _access function from Microsoft's msvcrt.dll is used. This function does not allow the mode parameter to be 1. Only 0 (existance), 1 (write-only), 4 (read-only) or 6 (read-write). See: http://msdn2.microsoft.com/en-us/library/1w06ktdy(VS.80).aspx. Earlier versions of msvcrt somehow ignored the invalid parameter and succeeded anyway. Newer versions, as found in Windows Vista do check for the invalid mode parameter and the function fails. GCC does not check for errors but falsely assumes that the file passed to _access does not exist. Therefore it does not find the correct cc1 path and subsequently the spawn fails. The solution I think is to define X_OK as 0 on the MingW Windows platform. When the mode is 0 msvcrt's _access tests for existence. Which is pretty close to the execute right check. -- Summary: Call to _access has invalid parameter when linked with msvcrt Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ska-pig at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972
Re: GCC has problems with 64-bit multiplication
On Thursday 08 February 2007 16:02, Graham Stott wrote:
All,
Not a bug in GCC the result is correct as you've only asked for a 32-bit
multiply.
Hi again,
The problem was not that mull is used, but that gcc 3.4.6 generates highly
un-optimized code when I for example multiply a 16-bit integer by a 64-bit
integer.
It actually generates code where three multiplications are used instead of
two. That has a speed impact.
Code:
#include stdio.h
#include sys/types.h
int main() {
int64_t temp;
int16_t x;
temp *= x;
printf(%lld\n, temp);
return 0;
}
objdump -D ./a.out
8048507: 89 4d e8mov%ecx,0xffe8(%ebp)
804850a: 31 c0 xor%eax,%eax
804850c: 89 55 ecmov%edx,0xffec(%ebp)
804850f: f7 65 e8mull 0xffe8(%ebp)
8048512: 6b 7d ec 00 imul $0x0,0xffec(%ebp),%edi
8048516: 89 d6 mov%edx,%esi
8048518: 89 c1 mov%eax,%ecx
804851a: 01 fe add%edi,%esi
804851c: 6b 45 e8 00 imul $0x0,0xffe8(%ebp),%eax
8048520: 83 e4 f0and$0xfff0,%esp
8048523: 83 ec 14sub$0x14,%esp
8048526: 8d 1c 06lea(%esi,%eax,1),%ebx
--HPS
[Bug fortran/30973] New: undetected name conflict: variables may be named like modules
$ cat foo.f90 MODULE foo END MODULE PROGRAM test_foo USE foo, ONLY: INTEGER :: foo foo = 1 END PROGRAM $ gfortran-svn -g -Wall foo.f90 echo ok ok $ gfortran-svn -v gcc version 4.3.0 20070220 (experimental) If , ONLY: is removed in the USE, gfortran gives: foo.f90:6.16: INTEGER :: foo 1 Error: Symbol 'foo' at (1) cannot have a type -- Summary: undetected name conflict: variables may be named like modules Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30973
[Bug c++/30925] c++ frontend error: ?-operator parameter binding
--- Comment #2 from istvan at benedek-home dot de 2007-02-26 14:52 --- ?: is a lvalue in C++ Why? I'm missing the quotation from the Holy Standard! IMHO: we deal with two nonmodifiable lvalues here. from HS 5.12 3: Because E1 can't be converted to type 'reference to T2', the Section 'Otherwise hits us: '... E1 can be converted to match E2 if E1 can be implicitly converted to the type that E2 would have if E2 were converted to an rvalue ...' Please reconsider your opinion. -- istvan at benedek-home dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30925
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #6 from eres at il dot ibm dot com 2007-02-26 15:01 --- It seems that initializing the expansion with -zero (instead of +zero) will solve this problem. According IEEE standard if we have - x += something; initializing x with -0 will cause x to get the sign of something. -0 + (-0) = -0 -0 + (+0) = +0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug middle-end/30666] [4.3 Regression] warning: canonical types differ for identical types double __complex__ and double __complex__
--- Comment #6 from doug dot gregor at gmail dot com 2007-02-26 15:26 --- This looks like a straightforward fix to build_common_tree_nodes2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30666
[Bug target/30970] Register zeroing by xor N,N should be moved out of loop
--- Comment #1 from ubizjak at gmail dot com 2007-02-26 15:48 --- It is a target issue. Working on a fix. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Severity|normal |minor Status|UNCONFIRMED |ASSIGNED Component|rtl-optimization|target Ever Confirmed|0 |1 GCC target triplet||i686-pc-linux-gnu Keywords||ssemmx Last reconfirmed|-00-00 00:00:00 |2007-02-26 15:48:01 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30970
[Bug bootstrap/30598] Misdetection of COMDAT group support
--- Comment #2 from uwe at netbsd dot org 2007-02-26 16:35 --- (In reply to comment #1) On the second thought, I might be confused here. Please, leave UNCONFIRMED. I'll do more testing and get back with an update later today. Sorry. That was a pilot error. Please close. Sorry for the fuss. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30598
[Bug fortran/30973] undetected name conflict: variables may be named like modules
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-26 16:47 --- I checked: USE foo, ONLY: is syntactically correct. The problem is that only_flag = 1; and no symbol is in the only-list. I think one needs to modify module.c's read_module, but I fail quickly to see were the symbol foo is not added/deleted from the symbol tree. All other compilers I tried (g95,ifort,nagf95,sunf95) gave an error. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2007-02-26 16:47:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30973
[Bug fortran/30973] undetected name conflict: variables may be named like modules
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-02-26 16:54 --- Tobias, the same happens if the MODULE foo contains anything and the ONLY part actually lists something. I omitted this to keep the testcase short. Same problem here: $ cat foo2.f90 MODULE foo INTEGER :: x END MODULE PROGRAM test_foo USE foo, ONLY: x INTEGER :: foo foo = 1 END PROGRAM -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30973
[Bug fortran/30968] Bogus warning with continued lines of concatenated strings
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-26 17:11 --- Confirmed. One needs the second for: Hello World But one does not need it for: Hello , World The following seems to be a gfortran/ifort extension: Hello World For this case, the warning / std error is correct. The bug in gfortran is that Hellois correctly seen as non-character context whereas Hello is wrongly regarded as character context. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic, rejects-valid Last reconfirmed|-00-00 00:00:00 |2007-02-26 17:11:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30968
[Bug tree-optimization/30966] (long long)(int_var) == (long long)(int_var1) is not simplified down to int_var == int_var1 when expanded
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-26 17:33 --- They also don't on x86_64: f: .LFB2: movslq %edi,%rdi movslq %esi,%rsi cmpq%rsi, %rdi sete%al movzbl %al, %eax ret .LFE2: .size f, .-f .globl f1 .type f1, @function f1: .LFB3: cmpl%esi, %edi sete%al movzbl %al, %eax ret on the tree level this is a missing tree-combiner bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-26 17:33:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30966
[Bug target/30969] The polyhedron test 'fatigue.f90' is no longer working.
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-02-26 17:34 --- Still works on x86_64, so it's a target issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|regression |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969
[Bug target/30970] Register zeroing by xor N,N should be moved out of loop
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-26 17:35 --- Shouldn't rtl invariant motion catch this? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30970
[Bug rtl-optimization/30971] Wrong return value (Tail call optimization)
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-26 17:37 --- With -ffast-math -0 is treated the same as 0. Which would make this report invalid...? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30971
[Bug fortran/30968] Bogus warning with continued lines of concatenated strings
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-26 17:39 --- The bug in gfortran is that Hellois correctly seen as non-character context whereas Hello is wrongly regarded as character context. The last line should be: Hello without space between and . Note: Printing an error twice is also a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30968
[Bug target/30969] The polyhedron test 'fatigue.f90' is no longer working.
--- Comment #4 from dominiq at lps dot ens dot fr 2007-02-26 17:50 --- Subject: Re: The polyhedron test 'fatigue.f90' is no longer working. Still works on x86_64, so it's a target issue. Nevertheless a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969
[Bug target/30970] Register zeroing by xor N,N should be moved out of loop
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30970
[Bug middle-end/30969] [4.3 Regression] The polyhedron test 'fatigue.f90' is no longer working.
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-26 17:54 --- Still works on x86_64, so it's a target issue. There really has not been any rs6000 changes lately so I am going to say middle-end until I get to look into it on powerpc-linux-gnu. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|The polyhedron test |[4.3 Regression] The |'fatigue.f90' is no longer |polyhedron test |working.|'fatigue.f90' is no longer ||working. Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969
[Bug bootstrap/30598] Misdetection of COMDAT group support
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-26 17:54 --- Closing as works for me as requested by the reporter. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30598
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-26 17:57 --- -ffast-math violates the IEEE standard in some cases so why is this option being used to test an ieee math testcase? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug target/30936] __builtin_nanf() != __builtin_nanf() is false for sh4-linux-gnu
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-02-26 18:02 --- Actually it turns out this is not a bug but rather you did not read the full documentation: http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/SH-Options.html -mieee Increase IEEE-compliance of floating-point code. At the moment, this is equivalent to -fno-finite-math-only. When generating 16 bit SH opcodes, getting IEEE-conforming results for comparisons of NANs / infinities incurs extra overhead in every floating point comparison, therefore the default is set to -ffinite-math-only. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #8 from eres at il dot ibm dot com 2007-02-26 18:11 --- MVE is enabled with -funsafe-math-optimizations as it changes the order of summation. I think it should honor signed zero, which it does not in the current implantation. I agree that -funsafe-math-optimizations is more suitable than -fast-math as in the later signed zero is not been honored. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-02-26 18:24 --- Both -ffast-math and -funsafe-math-optimizations violate IEEE math specs so this is an invalid bug. At one point -funsafe-math-optimizations used to not honor signed zero but recently you have: -flag_signed_zeros with 2007-01-19 Roger Sayle [EMAIL PROTECTED] * common.opt (fsigned-zeros): New command line option. * flags.h (HONOR_SIGNED_ZEROS): Control via flag_signed_zeros instead of flag_unsafe_math_optimizations. * opts.c (set_fast_math_flags): The -ffast-math command line option implies -fno-signed-zeros. (fast_math_flags_set_p): Likewise. But -funsafe-math-optimizations still says you can reassiocate so maybe this is just the case where we want a flag for reassiocating. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug rtl-optimization/30971] Wrong return value (Tail call optimization)
--- Comment #3 from eres at il dot ibm dot com 2007-02-26 18:26 --- Sure, sorry about that,-funsafe-math-optimizations is more suitable here. The testcase also fails when -funsafe-math-optimizations is used (fsigned-zeros is set in that case which means the testcase should not have been failed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30971
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #10 from eres at il dot ibm dot com 2007-02-26 18:34 --- I think that the way -fnsafe-math-optimization violates ieee is important. Introducing flag_signed_zeros, as you mensioned before, enforce -fnsafe-math-optimization to honor signed zero. So I think MVE should honor that too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
-- bangerth at dealii dot org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #8 from bangerth at dealii dot org 2007-02-26 19:10 --- Mark, I think you misunderstood: the value *should* be set to 'true' (==1), but is set to '2'. Or do you mean that '2' is another valid representation of 'true' and that therefore this is ok? W. -- bangerth at dealii dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug rtl-optimization/30931] [4.1 Regression] Simple test case loops infinitely with -O1 -fstrength-reduce.
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2007-02-26 19:18 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-23 14:13:03 |2007-02-26 19:18:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug target/30970] Register zeroing by xor N,N should be moved out of loop
--- Comment #3 from ubizjak at gmail dot com 2007-02-26 19:51 ---
(In reply to comment #2)
Shouldn't rtl invariant motion catch this?
It would be nice, but the problem is again in the fact that we lie to the
compiler about supported instructions. This one is not a valid x86 insn:
(insn 12 8 13 2 (set (mem:V4SI (symbol_ref:DI (b) var_decl 0x2e15b000
b) [3 S16 A128])
(const_vector:V4SI [
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
])) 919 {*movv4si_internal} (nil)
(nil))
This sequence is later split into pxor+store, unfortunatelly a bit late in the
game, after RTL optimizers have already done their job.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30970
[Bug fortran/30964] optional arguments to random_seed
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-02-26 19:53 --- (In reply to comment #1) I have a patch to permit gfc_check_random_seed to deal with arguments with the optional attribute set. I was waiting on pault's size0/size1 patch to hit the tree to see if it does the right thing. In case you missed it, I submitted pault's patch (without changes), to http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01956.html . You could also attach your patch to this PR, I'll have a look at it then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30964
[Bug fortran/30968] Bogus warning with continued lines of concatenated strings
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-26 20:17 ---
Patch.
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (Revision 122328)
+++ gcc/fortran/primary.c (Arbeitskopie)
@@ -773,7 +773,7 @@
return c;
old_locus = gfc_current_locus;
- c = gfc_next_char_literal (1);
+ c = gfc_next_char_literal (0);
if (c == delimiter)
return c;
@@ -852,7 +852,7 @@
match_string_constant (gfc_expr **result)
{
char *p, name[GFC_MAX_SYMBOL_LEN + 1];
- int i, c, kind, length, delimiter;
+ int i, c, kind, length, delimiter, warn_ampersand;
locus old_locus, start_locus;
gfc_symbol *sym;
gfc_expr *e;
@@ -979,10 +979,16 @@
gfc_current_locus = start_locus;
gfc_next_char ();/* Skip delimiter */
+ /* We disable the warning for the following loop as the warning has already
+ been printed in the loop above. */
+ warn_ampersand = gfc_option.warn_ampersand;
+ gfc_option.warn_ampersand = 0;
+
for (i = 0; i length; i++)
*p++ = next_string_char (delimiter);
*p = '\0'; /* TODO: C-style string is for development/debug purposes. */
+ gfc_option.warn_ampersand = warn_ampersand;
if (next_string_char (delimiter) != -1)
gfc_internal_error (match_string_constant(): Delimiter not found);
+
if (next_string_char (delimiter) != -1)
gfc_internal_error (match_string_constant(): Delimiter not found);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30968
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-02-26 20:19 --- I'm sorry; I did apparently misunderstand. My reading of the report was that x did not become 2, and that this made the submitter unhappy. I agree that x should not become 2. Although 2 is a valid *representation* of true, converting x to int must yield 1, not 2. So, either we need conversion code, or we need to avoid x being 2 in the first place. The latter is clearly more efficient. Either the C++ front end or the middle end should transform any ++ operation on bool to = true. I'm not sure if there are languages where the equivalent of b = true; ++b should yield false. In any case, I suspect this is most easily done in the front end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug fortran/30865] optional argument passed on to size(...,dim=)
--- Comment #10 from tkoenig at gcc dot gnu dot org 2007-02-26 21:16 --- Subject: Bug 30865 Author: tkoenig Date: Mon Feb 26 21:16:00 2007 New Revision: 122342 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122342 Log: 2007-02-26 Thomas Koenig [EMAIL PROTECTED] Paul Thomas [EMAIL PROTECTED] PR fortran/30865 * trans-intrinsic.c (gfc_conv_intrinsic_size): If dim is an optional argument, check for its presence and call size0 or size1, respectively. 2007-02-26 Thomas Koenig [EMAIL PROTECTED] PR fortran/30865 * size_optional_dim_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/size_optional_dim_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30865
[Bug bootstrap/30974] New: pdp11-dec-bsd will not successfully build
I have an x86 NetBSD box and am attempting to build gcc for pdp11-dec-bsd. I have binutils 2.17 installed and configured for that target, and I have includes and libraries from the latest revision of 2.11BSD. configure is run as ../configure --target=pdp11-dec-bsd --enable-languages=c --with-gmp=/usr/pkg Building gets to this point: /usr/src/gcc/vax/./gcc/xgcc -B/usr/src/gcc/vax/./gcc/ -B/usr/local/pdp11-dec-bsd/bin/ -B/usr/local/pdp11-dec-bsd/lib/ -isystem /usr/local/pdp11-dec-bsd/include -isystem /usr/local/pdp11-dec-bsd/sys-include -O2 -g -O2 -msoft-float -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -O2 -mfloat32 -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../libgcc -I../../../../libgcc/. -I../../../../libgcc/../gcc -I../../../../libgcc/../include -I../../../../libgcc/../libdecnumber -I../../../libdecnumber -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../../libgcc/../gcc/libgcc2.c \ cc1: warning: target system does not support debug output cc1: warning: target system does not support debug output cc1: warning: target system does not support debug output /var/tmp//ccSoMtqq.s: Assembler messages: /var/tmp//ccSoMtqq.s:323: Error: junk at end of line, first unrecognized character is `0' /var/tmp//ccSoMtqq.s:324: Error: junk at end of line, first unrecognized character is `0' /var/tmp//ccSoMtqq.s:325: Error: junk at end of line, first unrecognized character is `0' /var/tmp//ccSoMtqq.s:326: Error: junk at end of line, first unrecognized character is `0' /var/tmp//ccSoMtqq.s:329: Error: junk at end of line, first unrecognized character is `0' /var/tmp//ccSoMtqq.s:330: Error: junk at end of line, first unrecognized character is `0' gmake[4]: *** [_muldi3.o] Error 1 The mis-generated assembly is at the very end of the file, and looks like this: LC_0: 0 /* short */ 0 /* short */ 0 /* short */ 0 /* short */ .even LC_1: 0 /* short */ 0 /* short */ Unfortunately I have not the faintest clue as to what is happening here, or why. I would be happy to provide more details if someone can tell me what they need. -- Summary: pdp11-dec-bsd will not successfully build Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hbent at cs dot oberlin dot edu GCC build triplet: i386-unknown-netbsdelf4.99.9 GCC host triplet: i386-unknown-netbsdelf4.99.9 GCC target triplet: pdp11-dec-bsd http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30974
[Bug target/30974] pdp11-dec-bsd will not successfully build
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-26 21:30 ---
static bool
pdp11_assemble_integer (rtx x, unsigned int size, int aligned_p)
{
if (aligned_p)
switch (size)
{
case 1:
fprintf (asm_out_file, \t.byte\t);
output_addr_const_pdp11 (asm_out_file, x);
fprintf (asm_out_file, /* char */\n);
return true;
case 2:
fprintf (asm_out_file, TARGET_UNIX_ASM ? \t : \t.word\t);
output_addr_const_pdp11 (asm_out_file, x);
fprintf (asm_out_file, /* short */\n);
return true;
}
return default_assemble_integer (x, size, aligned_p);
}
TARGET_UNIX_ASM is true for pdp11-dec-bsd
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30974
[Bug target/30974] pdp11-dec-bsd will not successfully build
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-26 21:32 --- Actually wait, you are using binutils but this target really defaults to the old as and not binutils at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30974
[Bug fortran/30973] undetected name conflict: variables may be named like modules
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-26 21:36 ---
Tobias, the same happens if the MODULE foo contains anything and the ONLY part
actually lists something. I omitted this to keep the testcase short.
Good news. That means that indicates that my patch does the right thing and is
not too kludgy.
In read_module, p = find_use_name_n (name, j); is used to find renamed
symbols. If a symbol is not in in the only list, p == NULL. Since the module
name is never in the only list, we have p = NULL.
Index: module.c
===
--- module.c(Revision 122328)
+++ module.c
@@ -3438,6 +3438,9 @@
/* Get the jth local name for this symbol. */
p = find_use_name_n (name, j);
+ if (p == NULL strcmp (name, module_name) == 0)
+ p = name;
+
/* Skip symtree nodes not in an ONLY clause, unless there
is an existing symtree loaded from another USE
statement. */
Another related bug: use foo, only: foo gives no error.
- test case ---
MODULE foo
integer :: i
END MODULE
PROGRAM test_foo
use foo, only: foo ! { dg-error been used as an external module name }
USE foo, ONLY: i = foo! { dg-error been used as an external module name }
USE foo, ONLY: foo = i! { dg-error been used as an external module name }
END PROGRAM
--
Possible patch below; note: Even with the patch
use bar, only foo = j
use foo
is possible. But as soon as one accesses foo, e.g. foo = 5, an error is
given.
This is in the line with other compilers.
Index: module.c
===
*** module.c(revision 122328)
--- module.c(working copy)
*** gfc_match_use (void)
*** 619,624
--- 619,632
goto cleanup;
}
+ if (strcmp (new-use_name, module_name) == 0
+ || strcmp (new-local_name, module_name) == 0)
+ {
+ gfc_error (The name '%s' at %C has already been used as
+an external module name., module_name);
+ goto cleanup;
+ }
+
break;
case INTERFACE_USER_OP:
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30973
[Bug target/30974] pdp11-dec-bsd will not successfully build
--- Comment #3 from hbent at cs dot oberlin dot edu 2007-02-26 21:38 --- I'm not clear on what you're saying. Is binutils not going to work at all for this target? It can't be built natively AFAIK, so I'm not sure what toolchain I should be using if binutils isn't going to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30974
[Bug fortran/30865] [4.1, 4.2 only] optional argument passed on to size(...,dim=)
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Summary|optional argument passed on |[4.1, 4.2 only] optional |to size(...,dim=) |argument passed on to ||size(...,dim=) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30865
[Bug c++/30975] New: ptr to member func __delta is 0 if ptr declaration does not match function porototype
if a ptr to member function declaration differs from the prototype of the actual function being used, and the function is implemented in a subclass, and inherits from multiple base classes, the 4.x compiler generates a 0 for the __delta which cause the appl to crash when the function is called through the pointer with a wrong this ptr (pointing to the baseclass offset instead of the objects). problem was introduced with g++4.x, tested ok with g++3.4. -- Summary: ptr to member func __delta is 0 if ptr declaration does not match function porototype Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ingo dot donasch at L-3com dot com GCC build triplet: Red Hat 4.1.1-51 GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975
[Bug c++/30975] ptr to member func __delta is 0 if ptr declaration does not match function porototype
--- Comment #1 from ingo dot donasch at L-3com dot com 2007-02-26 22:49 --- Created an attachment (id=13117) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13117action=view) ref to C_good is ok, ref to C_bad crashes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975
[Bug c++/30975] ptr to member func __delta is 0 if ptr declaration does not match function porototype
--- Comment #2 from ingo dot donasch at L-3com dot com 2007-02-26 22:51 --- Created an attachment (id=13118) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13118action=view) output from: g++ -v -save-temps -g -Wall a.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975
[Bug c++/30962] cause compile error for const anonymous class object
--- Comment #2 from gzljg at hotmail dot com 2007-02-26 22:55 ---
Not sure what you mean by MyAnonymous = {}; to initialize it... if change to:
const class { /* */ } MyAnonymous = {};
will cause another error:
MyAnonymous' must be initialized by constructor, not by '{...}'
--
gzljg at hotmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
[Bug c++/30975] ptr to member func __delta is 0 if ptr declaration does not match function porototype
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-26 22:56 --- Well this is undefined code really. You are calling the function via the wrong type. If you do: c.t((FPTR)(FPTR1)C::C_bad); And use it as a FPTR1, it works. FPTR1 is defined as: typedef void (B::*FPTR1)(); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975
[Bug c++/30962] cause compile error for const anonymous class object
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-26 23:00 ---
(In reply to comment #2)
Not sure what you mean by MyAnonymous = {}; to initialize it... if change
to:
You example which you gave works for me with that:
const class
{
public:
int foo() const
{
return 1;
}
} MyAnonymous = {};
int
main()
{
return MyAnonymous.foo();
}
[EMAIL PROTECTED]:~$ ~/x86-linux-4.0.2/bin/gcc t.cc
[EMAIL PROTECTED]:~$ gcc t.cc
Anyways this is not a GCC bug but rather you not knowing C++.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
[Bug c++/30962] cause compile error for const anonymous class object
--- Comment #4 from gzljg at hotmail dot com 2007-02-26 23:14 ---
I would rather to blame on Suse 10(I happend to verify on that machine). It
doesn't work for a gcc 3.3.5(prerelease) version ===
myweb: g++ -v
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.5/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada
--disable-checking --libdir=/usr/lib --enable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)
myweb: make
g++ -g -DDEBUG -Wall -c test.C -o test.o
test.C:17: error: `Anonymous' must be initialized by constructor, not by
`{...}'
make: *** [test.o] Error 1
Anyways, I rerun the test case with other compiler, such as gcc 3.3.3, 4.1.2,
both works fine now.
PS. I don't have a gcc 3.3.5 official release version to verify.
--
gzljg at hotmail dot com changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
[Bug rtl-optimization/30967] Extra sign/zero extend with word comparison result
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-26 23:20 ---
I think this is a case where combine (and other passes) don't know that eq is
always signed extended (when the true is not -1):
(insn 9 8 10 2 (set (reg:SI 123)
(eq:SI (reg:SI 3 3 [ a ])
(reg:SI 4 4 [ b ]))) 471 {*eqsi} (nil)
(expr_list:REG_DEAD (reg:DI 3 3 [ a ])
(expr_list:REG_DEAD (reg:DI 4 4 [ b ])
(nil
(note 10 9 16 2 NOTE_INSN_DELETED)
(insn 16 10 22 2 (set (reg/i:DI 3 3 [ result ])
(sign_extend:DI (reg:SI 123))) 27 {*rs6000.md:393}
(insn_list:REG_DEP_TRUE 9 (nil))
(expr_list:REG_DEAD (reg:SI 123)
(nil)))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30967
[Bug c++/30962] cause compile error for const anonymous class object
--- Comment #5 from gzljg at hotmail dot com 2007-02-26 23:35 ---
Subject: RE: cause compile error for const anonymous class object
CORRECTION: Suse 10 should be read as Suse 9.
Can some one verify the official release of gcc 3.3.5?
From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bug c++/30962] cause compile error for const anonymous class
object
Date: 26 Feb 2007 23:00:22 -
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-26 23:00
---
(In reply to comment #2)
Not sure what you mean by MyAnonymous = {}; to initialize it... if
change to:
You example which you gave works for me with that:
const class
{
public:
int foo() const
{
return 1;
}
} MyAnonymous = {};
int
main()
{
return MyAnonymous.foo();
}
[EMAIL PROTECTED]:~$ ~/x86-linux-4.0.2/bin/gcc t.cc
[EMAIL PROTECTED]:~$ gcc t.cc
Anyways this is not a GCC bug but rather you not knowing C++.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
[Bug c++/30976] New: generating non-conforming rep retn with -match=athlon, k8 ; with -masm=intel fails
gcc versions tested (all have this problem on both architectures):
x86_64
3.4.6 4.1.1 4.1.2
i686
3.4.6 4.1.1
Reduced testcase: main.cpp
---
struct o {
virtual void a() { }
};
int main(int,char**) {
new o();
return 0;
}
When a() is removed or set as non-virtual, problem disappears
Commandline to fail compilation:
i686:
g++ main.cpp -o main -O -fomit-frame-pointer -march=athlon -masm=intel
x86_64:
g++ main.cpp -o main -O -masm=intel
-march of athlon, athlon-4, k8 fails
without -masm the code is compiled, but its behavior is undefined (although
working)
---
In assembler output, the following line appears with ATT syntax:
rep ; ret
and is accepted. (two independendend instructions, although meaningless)
With Intel syntax, generated code:
rep ret
is not accepted. (meaningless prefix)
---
According to Intel IA-32 documentation:
The behavior of the REP prefix is undefined when used with non-string
instructions.
AMD AMD64 documentation:
The (rep/repe) prefixes should only be used with such (lods,stos,movs,...)
string instructions.
---
I could post exact error messages and outputs of gcc -v on all tested systems
if needed (I have already done so, but the output is very long to past here)
Conlusion:
Generates code non-conforming to Intel and AMD documentation. Unlikely, code
would not work on future processors. With ATT syntax, asm code is accepted.
With Intel syntax, it is rejected.
The pair 'rep ; retn' should never appear as it is undefined when executed by
CPU. (and it most likely gets generated nonintentionally)
--
Summary: generating non-conforming rep retn with -match=athlon,
k8 ; with -masm=intel fails
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC build triplet: x86_64-pc-linux-gnu i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30976
[Bug c++/30976] generating non-conforming rep retn with -match=athlon, k8 ; with -masm=intel fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-27 00:22 --- *** This bug has been marked as a duplicate of 29473 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30976
[Bug target/29473] -masm=intel combined with -march=athlon64 has some issues.
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-27 00:22 --- *** Bug 30976 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||zsojka at seznam dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
[Bug target/29473] -masm=intel combined with -march=athlon64 has some issues.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
[Bug c++/30976] generating non-conforming rep retn with -match=athlon, k8 ; with -masm=intel fails
--- Comment #2 from zsojka at seznam dot cz 2007-02-27 00:36 --- (In reply to comment #1) *** This bug has been marked as a duplicate of 29473 *** Sorry, I was searching at http://gcc.gnu.org/bugzilla/query.cgi in 'Open' bugs only. (anyway, this is another case this bug appears) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30976
[Bug c++/30962] cause compile error for const anonymous class object
--- Comment #6 from gzljg at hotmail dot com 2007-02-27 01:57 ---
Subject: RE: cause compile error for const anonymous class object
Hi Pinskia,
I update the notes there, can you take a look?
Thanks.
Gavin
From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bug c++/30962] cause compile error for const anonymous class
object
Date: 26 Feb 2007 23:00:22 -
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-26 23:00
---
(In reply to comment #2)
Not sure what you mean by MyAnonymous = {}; to initialize it... if
change to:
You example which you gave works for me with that:
const class
{
public:
int foo() const
{
return 1;
}
} MyAnonymous = {};
int
main()
{
return MyAnonymous.foo();
}
[EMAIL PROTECTED]:~$ ~/x86-linux-4.0.2/bin/gcc t.cc
[EMAIL PROTECTED]:~$ gcc t.cc
Anyways this is not a GCC bug but rather you not knowing C++.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
[Bug c++/30962] cause compile error for const anonymous class object
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-27 01:59 --- It works in the official 3.3.3 and 3.4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
[Bug middle-end/29715] fold produces a - 4
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-27 06:55 --- The comment from the code: For pointer types we assume overflow doesn't happen. That is true but you can cause an overflow to happen when you transform the code this way. Mine, I have a fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-27 06:55:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29715
[Bug middle-end/29715] fold produces a - 4
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-27 07:01 --- Before we would produce: i = a + 12B; i = i - 4B; D.1616 = a - 4B; if (i D.1616) Now we produce: i = a + 12B; D.1620 = i a; i = i - 4B; if (D.1620) Which is better because we can actually fold it down to return 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29715
