--- Comment #15 from ubizjak at gmail dot com 2007-05-17 08:28 ---
Just for the record, the only remaining x86 conversion (sse < 4) is vectorized
BUILT_IN_LRINT that uses cvtpd2dq. The problem here is that n_in < n_out, so we
probably need to apply narrowing modifier to
TARGET_VECTORIZE_
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-17 09:39 ---
Subject: Bug 31917
Author: burnus
Date: Thu May 17 08:39:32 2007
New Revision: 124787
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124787
Log:
2007-05-14 Tobias Burnus <[EMAIL PROTECTED]>
PR fortr
Build fails because as is incorrect (??), after deleting it from build tree,
compilation continues.
ERROR:
[EMAIL PROTECTED]' \
SHLIB_EXT='.so' \
SHLIB_MULTILIB='' \
SHLIB_MKMAP='../../gcc/mkmap-symver.awk' \
SHLIB_MKMAP_OPTS='' \
SHLIB_MAPFILES='../../gcc/libgcc-std.ver' \
SHLIB_NM_FLAGS='-pg' \
GCC compilation fails on bad collect-ld, after removing it from build tree
compilation continued.
/data/sam/tao-test/gcc-4.2.0/build/./gcc/xgcc
-B/data/sam/tao-test/gcc-4.2.0/build/./gcc/
-B/opt/devtools/sparc-sun-solaris2.10/bin/
-B/opt/devtools/sparc-sun-solaris2.10/lib/ -isystem
/opt/devtools/s
This might be possibly related to bug 31967.
ERROR OUTPUT:
...
make GCC_FOR_TARGET="/data/sam/tao-test/gcc-4.2.0/build/./gcc/xgcc
-B/data/sam/tao-test/gcc-4.2.0/build/./gcc/
-B/opt/devtools/sparc-sun-solaris2.10/bin/
-B/opt/devtools/sparc-sun-solaris2.10/lib/ -isystem
/opt/devtools/sparc-sun-solar
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-05-17 11:16
---
Please do not open duplicate entries.
*** This bug has been marked as a duplicate of 31967 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-05-17 11:16
---
*** Bug 31969 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31967
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-05-17 11:17
---
*** Bug 31968 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31967
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-05-17 11:17
---
Please do not open duplicate entries.
*** This bug has been marked as a duplicate of 31967 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-05-17 11:21
---
> /bin/sh ../../gcc/mkconfig.sh tconfig.h
This is incorrect. Please read the build instructions before opening bugs:
http://gcc.gnu.org/install/specific.html#x-x-solaris2
> CONFIGURE:
> ../configure --prefi
--- Comment #10 from tbm at gcc dot gnu dot org 2007-05-17 11:37 ---
I just saw this again with 20070515 r124745.
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from tbm at cyrius dot com 2007-05-17 11:37 ---
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c -O2 ddd-exit.ii
/home/tbm/src/ddd-3.3.11/./ddd/exit.C: In function 'void
gdb_exceptionHP(Agent*, void*, void*)':
/home/tbm/src/ddd-3.3.11/./ddd/exit.C:975: error: return
--- Comment #12 from tbm at cyrius dot com 2007-05-17 11:38 ---
Created an attachment (id=13568)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13568&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31733
--- Comment #13 from tbm at cyrius dot com 2007-05-17 11:38 ---
Steve, do you think you could investigate again because this issue is still
there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31733
problem with tamplates, an example of incorrect c++ code is here:
http://mx1.ru/super_example.cpp
std::set b;
std::set::iterator i = b.begin();
the second line should is incorrect, but compiles well.
--
Summary: g++ compiles incorrect c++ code
Product: gcc
Ver
gfortran-43 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gcc-43
--program-suffix=-43 --enable-threads=posix --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.3.0 20070517 (experimental)
gfortran-43 -save-temps -c
--- Comment #7 from Zarathustra at gentlemansclub dot de 2007-05-17 13:27
---
According to my current understanding, the compiler is right not to accept the
given example code:
Name resolution at the point of instantiation does only work for dependent
names.
Given a expression which lo
When I compile the program listed below I get the following message:
lsstr.f90:3.18:
i = (/ TRANSFER(4HSOLR, 0) /)
1
Warning: Extension: Hollerith constant at (1)
lsstr.f90:4.17:
END PROGRAM lsstr
1
Internal Error at (1):
Invalid expression in gfc_target_expr_size.
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-05-17 13:37 ---
Subject: Bug 31919
Author: dfranke
Date: Thu May 17 12:37:24 2007
New Revision: 124794
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124794
Log:
gcc/fortran:
2007-05-15 Daniel Franke <[EMAIL PROTECTED]>
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-05-17 13:37 ---
Subject: Bug 31929
Author: dfranke
Date: Thu May 17 12:37:24 2007
New Revision: 124794
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124794
Log:
gcc/fortran:
2007-05-15 Daniel Franke <[EMAIL PROTECTED]>
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-05-17 13:37 ---
Subject: Bug 31930
Author: dfranke
Date: Thu May 17 12:37:24 2007
New Revision: 124794
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124794
Log:
gcc/fortran:
2007-05-15 Daniel Franke <[EMAIL PROTECTED]>
--- Comment #1 from michael dot a dot richmond at nasa dot gov 2007-05-17
13:41 ---
The constructor is not necessary to produce the error. It is due entirely to
the TRANSFER function.
--
michael dot a dot richmond at nasa dot gov changed:
What|Removed
ombine.c (simplify_set): Build a new src pattern instead of
substituting its operands in the COMPARE case.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20070517-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/
ombine.c (simplify_set): Build a new src pattern instead of
substituting its operands in the COMPARE case.
Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/20070517-1.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/combine.c
ombine.c (simplify_set): Build a new src pattern instead of
substituting its operands in the COMPARE case.
Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/20070517-1.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/combine.c
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-05-17 14:34
---
Fixed on all branches.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from tkoenig at gcc dot gnu dot org 2007-05-17 14:40
---
Created an attachment (id=13569)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13569&action=view)
partial implementation
Here's a partial implementation that seems to get
things right for the (min)|(max)loc0
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-05-17 14:43
---
Confirmed by Richard.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-05-17 14:44
---
Won't be fixed on the 4.0 and 4.1 branches.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2007-05-17 14:52
---
Definitively closed on the 4.0 and 4.1 branches, it's too late for caring about
ICE-on-invalid there at this point.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
In
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00804.html
there are
FAIL: libgomp.fortran/vla1.f90 -O2 execution test
FAIL: libgomp.fortran/vla1.f90 -O3 -fomit-frame-pointer execution test
FAIL: libgomp.fortran/vla1.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: libg
--- Comment #1 from hjl at lucon dot org 2007-05-17 15:06 ---
Failures look like
Fortran runtime error: Attempt to allocate a negative amount of memory.
FAIL: libgomp.fortran/vla1.f90 -O2 execution test
Is this related to
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00148.html
--
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:11
---
Is this still a problem? I don't see it in the logs.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
I'm getting a bootstrap error on mips with 4.3 SVN 20070515 revision 124745.
The compiler segfaults when compiling libstdc++-v3/src/strstream.cc with:
Program received signal SIGSEGV, Segmentation fault.
0x0074701c in try_split (pat=, trial=0x2bfb31e0, last=1)
at ../../src/gcc/emit-rtl.c:3286
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:17
---
3.4.x is not maintained anymore.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from tbm at cyrius dot com 2007-05-17 15:20 ---
Created an attachment (id=13570)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13570&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31975
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:28
---
3.3.x is not maintained anymore.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:29
---
3.4.x is not maintained anymore.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:30
---
Not a GCC bug.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:34
---
Do you still have the testcase?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from andrew dot stubbs at st dot com 2007-05-17 15:34
---
Another example perhaps?
void
foo()
{
try
{
}
catch (void *e)
{
void *e; // invalid
}
}
The C++ standard, clause 3.3.2 paragraph 3, states that catch
exception-declarations may not be re
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:36
---
3.4.x is not maintained anymore.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from bangerth at dealii dot org 2007-05-17 15:46 ---
The link you give doesn't work. Can you attach your testcase?
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2007-05-17 15:48 ---
Indeed, like Andrew says.
--
bangerth at dealii dot org changed:
What|Removed |Added
Statu
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:50
---
*** This bug has been marked as a duplicate of 31523 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:50
---
*** Bug 27901 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from bangerth at dealii dot org 2007-05-17 15:51 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #3 from bangerth at dealii dot org 2007-05-17 15:53 ---
I agree as well.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:53
---
2006-10-03 Eric Botcazou <[EMAIL PROTECTED]>
* builtins.c (expand_builtin_return_addr): Deal with FRAME_ADDR_RTX.
* doc/tm.texi (Basic Stack Layout): Document FRAME_ADDR_RTX.
* config/sp
--- Comment #2 from bangerth at dealii dot org 2007-05-17 15:55 ---
Initializer syntax
int i = i;
is a gcc extension. You may want to read the documentation of -Winit-self.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
-
--- Comment #4 from tbm at cyrius dot com 2007-05-17 15:58 ---
(In reply to comment #3)
> Is this still a problem? I don't see it in the logs.
Seems to work fine here now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30815
--- Comment #1 from kargl at gcc dot gnu dot org 2007-05-17 16:05 ---
Works for me. What OS are you using and where did you get
the version of gfortran? An illegal instruction error
normally means you are using a version of gfortran on the
wrong architecture (ie., i686 on amd64).
--
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-05-17 16:10
---
Fixed in 4.1.x and later.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-05-17 16:13
---
*** Bug 29045 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27935
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-05-17 16:13
---
*** This bug has been marked as a duplicate of 27935 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-05-17 16:15
---
Configure using an absolute path as recommended in the build instructions.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-05-17 16:17
---
Nothing platform-specific.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
GC
I'm getting the following ICE with gcc 4.3 20060515 and -O3:
(sid)24074:[EMAIL PROTECTED]: ~/delta/bin] /usr/lib/gcc-snapshot/bin/gcc -c -O3
838.c
838.c: In function 'rPIc_entry':
838.c:3181: internal compiler error: in ssa_operand_alloc, at
tree-ssa-operands.c:487
Please submit a full bug report
--- Comment #7 from andrew dot stubbs at st dot com 2007-05-17 16:37
---
Another example that might be of interest if anybody eventually tries to fix
this:
void
foo ()
{
for (int i = 0; int i = 0; i++) ;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2288
I'm using gcc 3.4.5, and I was looking into a weird condition. The following
program compiles OK:
#include
int alloc()
{
return 0;
}
int main(int argc, char* argv[])
{
printf("Testing!\n");
if(alloc() == 0)goto Radhe;
return 0;
Radhe:
printf("Hello\n");
}
The resul
--- Comment #1 from bmcfadden at cdp dot com 2007-05-17 16:48 ---
Created an attachment (id=13571)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13571&action=view)
The file from -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31977
Dear all
It looks like specifying the option -x f77-cpp-input forces the preprocessor to
be run even though the input files are object or static libraries.
As an toy exmple try with a simple prog.f
% gfortran -x f77-cpp-input -c prog.f
% gfortran -x f77-cpp-input prog.o -o prog
It looks like the
--- Comment #2 from bmcfadden at cdp dot com 2007-05-17 16:52 ---
Created an attachment (id=13572)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13572&action=view)
the assembly (.s) file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31977
--- Comment #3 from bmcfadden at cdp dot com 2007-05-17 16:54 ---
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-s
--- Comment #5 from bkoz at gcc dot gnu dot org 2007-05-17 17:22 ---
Also an issue with class templates.
See this thread:
http://gcc.gnu.org/ml/libstdc++/2007-05/msg00113.html
I'm changing this to normal severity, since we absolutely need a solution
pronto on this, as it is essential
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-05-17 17:33 ---
Confirmed. Adding Brooks Moses to CC as he recently worked on this.
(gdb) bt
#0 gfc_internal_error (
format=0x86ca3bc "Invalid expression in gfc_target_expr_size.")
at ../../../gcc/gcc/fortran/error.c:820
#
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-17 17:46 ---
and this is exactly the way -x should behave. the documention is clear at
that.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from amylaar at gcc dot gnu dot org 2007-05-17 17:50 ---
(In reply to comment #2)
> Do you still have the testcase?
>
Not as such. However, AFAICR it was triggered by a regression test
(i.e. building library or testcase).
But the issue should be clear enough without a
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-05-17 17:59 ---
Add Brooks to CC, again.
Brooks, could you have a look at this one?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #21 from pinskia at gcc dot gnu dot org 2007-05-17 18:15
---
*** Bug 30815 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29841
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from dominiq at lps dot ens dot fr 2007-05-17 18:18 ---
Works for me on OSX 10.3.9 gfortran 4.3.0 20070511:
PROGRAM lsstr
INTEGER, DIMENSION(1) :: i
i = (/ TRANSFER(4HSOLR, 0) /)
print *, i
END PROGRAM lsstr
outputs 1397705810 (83797682 hexa) with gfortran, xlf, and g95,
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-17 18:15 ---
This was fixed with the same patch that fixed PR 29841.
*** This bug has been marked as a duplicate of 29841 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The host machine is a mpc8540 embedded PowerPC (e500 core)
$ uname -a
Linux ecam.anagramm.de 2.6.21-rc5-g9a5ee4cc #4 Mon Apr 2 21:31:53 CEST 2007 ppc
e500 GNU/Linux
Sources (just in case):
http://www.openssl.org/source/openssl-0.9.8e.tar.gz
It fails when compiling the file: openssl-0.9.8e/apps/oc
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-17 18:39 ---
This code is undefined as the warning points out.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from clemens dot koller at anagramm dot de 2007-05-17 18:41
---
Created an attachment (id=13573)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13573&action=view)
preprocessed file
It's just big. :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31979
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-17 18:53 ---
[pinskia-laptop:~/src] pinskia% gcc -Wreturn-type t.c
t.c: In function 'main':
t.c:15: warning: control reaches end of non-void function
This code is only undefined at runtime which means you cannot error out.
--
--- Comment #14 from sje at cup dot hp dot com 2007-05-17 18:54 ---
Created an attachment (id=13574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13574&action=view)
reduced test case
Here is a reduced test case. I think the problem is related to having the
optimizer remove the g
C:\mingw\bugs>type bug.f90
subroutine dummy
contains
function quadric(a,b) result(c)
intent(in) a,b; dimension a(0:3),b(0:3),c(0:9)
c(0)=a(0)*b(0); c(1:3)=a(1:)*b(0)+a(0)*b(1:); c(4:6)=a(1:)*b(1:)
c(7:9)=(/a(1)*b(2)+b(1)*a(2),a(1)*b(3)+b(1)*a(3),a(2)*b(3)+b(2)*a(3)/)
end function
end
C:\m
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-05-17 20:15 ---
Dominique, target-memory.c (frame #1 in the backtrace) was newly introduced at
20070516.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31972
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-05-17 20:27 ---
> I can not reproduce the segfault, so if I can get a backtrace it would help.
Jerry, I hope this helps. Let me know if you need something else :)
$> gfortran-svn -v
gcc version 4.3.0 20070517 (experimental)
In an arm target which is not in gcc svn (see http://gccsdk.riscos.info/) we
have the following options defined in its .opt file:
--8<--
mlibscl
Target Report RejectNegative InverseMask(UNIXLIB,LIBSCL)
Compile with the SharedCLibrary headers
munixlib
Target Report RejectNegative Mask(UNIXLIB)
Com
--- Comment #5 from bangerth at dealii dot org 2007-05-17 20:38 ---
Both the C99 standard (section 5.1.2.2.3) and the C++ standard (3.6.1/5)
say that if you hit the end of the main() function, then this is equivalent
to a "return 0;" statement.
W.
--
bangerth at dealii dot org chang
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-17 20:45 ---
(In reply to comment #5)
> Both the C99 standard (section 5.1.2.2.3) and the C++ standard (3.6.1/5)
> say that if you hit the end of the main() function, then this is equivalent
> to a "return 0;" statement.
C90 is
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-17 20:48 ---
I don't think you want the options to be in the MASK anyways.
Use Var(a, 0) Var(a, 1) Var(a, 2) etc. instead and that should fix your ICE.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from andreast at gcc dot gnu dot org 2007-05-17 21:16
---
I'll take it over and apply it to gcc-head and classpath. Tom did approve it.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from sje at gcc dot gnu dot org 2007-05-17 21:29 ---
Subject: Bug 31850
Author: sje
Date: Thu May 17 20:29:34 2007
New Revision: 124810
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124810
Log:
PR target/31850
* reload.c (subst_reloads): Remove ch
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from brooks at gcc dot gnu dot org 2007-05-17 22:45 ---
Yeah, this is to be expected, I think. Holleriths store the memory
representation but not the "semantic" representation of their value, and
transfer tries to fold things and gets confused.
There's probably an easy f
This testcase should pass:
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-forwprop" } */
/* We should be able to optimize this to b.t[i] = 1 during
early optimizations. */
struct a
{
int t[10];
};
struct a b;
void f(__SIZE_TYPE__ i)
{
int *c = b.t;
c[i] = 1;
}
/* { dg-fina
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31981
--- Comment #2 from dannysmith at gcc dot gnu dot org 2007-05-17 23:51
---
Subject: Bug 31965
Author: dannysmith
Date: Thu May 17 22:51:05 2007
New Revision: 124813
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124813
Log:
PR target/31965
* config/i386/mingw32.
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-05-17
23:59 ---
Fixed by:
2007-05-17 Danny Smith <[EMAIL PROTECTED]>
PR target/31965
* config/i386/mingw32.h (_INTEGRAL_MAX_BITS): Define builtin as
TYPE_PRECISION (intmax_type_node).
--
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-05-17
23:59 ---
Closing.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #15 from tim at klingt dot org 2007-05-18 00:06 ---
4.2.0 still has this bug ... maybe someone with enough power can add this to
the "known to fail" section?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13675
This testcase should pass:
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-forwprop" } */
/* We should be able to optimize this to b->t[i] = 1 during
early optimizations. */
struct a
{
char t[10];
};
struct a *b;
void f(__SIZE_TYPE__ i)
{
int *c = b->t;
c[i] = 1;
}
/* { dg-
As a supplement to the -- by necessity -- terse error messages generated by
gcc, it would be fantastic (IMHO) if a new option could be added to gcc to
display the current language standard along with the _section_ in that standard
that the error applies to.
IE, rather than...
hello.c:1:10: error:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-18 01:13 ---
> Alternatively, or in combination, gcc could provide references to more
> widely-available sources (such as K&R and H&S for C, and Stroustrup or the ARM
> for C++ for example).
Except those are very unofficial when
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-05-18 02:04 ---
Subject: Bug 30251
Author: ghazi
Date: Fri May 18 01:04:12 2007
New Revision: 124818
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124818
Log:
PR middle-end/30251
* builtins.c (do_mpfr_bessel_
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-05-18 02:15 ---
Subject: Bug 30251
Author: ghazi
Date: Fri May 18 01:15:28 2007
New Revision: 124819
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124819
Log:
PR middle-end/30251
* builtins.c (fold_builtin_1)
1 - 100 of 122 matches
Mail list logo
