--- Comment #2 from firda at seznam dot cz 2008-06-04 06:31 ---
Can you help me, what is wrong? I'd like to verify it as resolved ;)
g++ -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--- Comment #3 from firda at seznam dot cz 2008-06-04 07:50 ---
To make things even worse... (allright, I will try ARMGNU 4.1.1 or give up, and
use copy-paste)
typedef unsigned uint;
//##
--- Comment #4 from firda at seznam dot cz 2008-06-04 07:56 ---
c:\Program Files\GNUARM\binarm-elf-g++ -v
Using built-in specs.
Target: arm-elf
Configured with: ../gcc-4.1.1/configure --target=arm-elf
--prefix=/g/gnuarm-4.1.
1 --enable-interwork --enable-multilib --with-float=soft
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-06-04 07:58
---
Interesting things start to happen once you inline allocator functions as well.
See PR29286 and PR33407 which we still don't handle 100% correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #11 from dannysmith at users dot sourceforge dot net
2008-06-04 08:22 ---
This fixes for me on Vista host. Can someone confirm?
config/ChangeLog
PR35916
* mh-mingw (CFLAGS): Add -D__USE_MINGW_ACCESS.
Index: config/mh-mingw
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-06-04 08:59 ---
The only code-generation changing part of the patch is
(insert_fake_stores): Handle all component-ref style stores
in addition to INDIRECT_REF. Also handle complex types.
but that only fixes a
--- Comment #4 from gunnar at greyhound-data dot com 2008-06-04 09:29
---
I want to add that this wrong behavior is partly related to the compile option
-Os.
There are two causes where GCC generates unneeded TST instructions.
A) General arithmetic
lsr.l #1,D0
tst.l d0
jbne ...
--
Summary: mregeparm
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gunnar at greyhound-data dot com
--- Comment #1 from gunnar at greyhound-data dot com 2008-06-04 09:54
---
The parameter -mregparm is not supported on M68k / Coldfire.
As it its known from the X86 platform compiling with mregparm does improve the
size and performance of the generated code. On X86 an overall
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-06-04 10:46 ---
GCC is wrongly treating any [] in a field declarator as meaning a flexible
array member, instead of only those declaring the field itself as an array.
--
jsm28 at gcc dot gnu dot org changed:
What
--- Comment #7 from eric dot weddington at atmel dot com 2008-06-04 13:06
---
Bug closed based on comment #5.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36433
This example results in an ambiguity on the line marked !!!:
ex.c:8: error: ambiguous template specialization to_ychar for Ychar,
void*, int X::to_y()
This is currently rejected by g++, MSVC, and EDG, but we (EDG) believe it
should be accepted.
14.8.2.4 says that in contexts other than a
--- Comment #13 from davidxl at gcc dot gnu dot org 2008-06-04 16:48
---
(In reply to comment #12)
Interesting things start to happen once you inline allocator functions as
well.
See PR29286 and PR33407 which we still don't handle 100% correct.
I browsed through the two bugs --
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-06-04 17:03
---
We do the exact opposite - type-based rules override points-to must-alias
information (or really may-alias information). Also for the proposed scheme
to work you need to guarantee that you always can compute
--- Comment #15 from davidxl at gcc dot gnu dot org 2008-06-04 17:34
---
(In reply to comment #14)
We do the exact opposite - type-based rules override points-to must-alias
information (or really may-alias information). Also for the proposed scheme
to work you need to guarantee
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-06-04 19:06 ---
No time for now (Real Time is catching up with me big time).
Unassigning (for now).
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-06-04 19:06 ---
No time for now (Real Time is catching up with me big time).
Unassigning (for now).
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
If I compile the attached preprocessed file with -O1 -msse5 -ftree-vectorize
-ftree-vrp (or -O3), the compiler does a segmentation fault while garbage
collecting. If I use the -fno-tree-vrp switch, the program compiles fine, even
with -O3.
(gdb) r -O1 -msse5 -ftree-vectorize -ftree-vrp sse5.i
--- Comment #1 from gnu at the-meissners dot org 2008-06-04 19:36 ---
Created an attachment (id=15719)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15719action=view)
Preprocessed source code that shows the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36436
--
Summary: F2008: Support c_sizeof // Simplify argument to
[c_]sizeof
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component:
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-04 20:19 ---
Created an attachment (id=15720)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15720action=view)
Incomplete patch
Fortran 2008 supports c_sizeof which is identical to gfortran's sizeof.
This patch does the
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-04 20:21 ---
Created an attachment (id=15721)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15721action=view)
The real incomplete patch
Previous patch was an older version of this patch.
--
burnus at gcc dot gnu dot org
--- Comment #4 from janus at gcc dot gnu dot org 2008-06-04 21:05 ---
Subject: Bug 36275
Author: janus
Date: Wed Jun 4 21:04:32 2008
New Revision: 136372
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136372
Log:
2008-06-04 Janus Weil [EMAIL PROTECTED]
PR
--- Comment #4 from janus at gcc dot gnu dot org 2008-06-04 21:05 ---
Subject: Bug 36322
Author: janus
Date: Wed Jun 4 21:04:32 2008
New Revision: 136372
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136372
Log:
2008-06-04 Janus Weil [EMAIL PROTECTED]
PR
--- Comment #5 from janus at gcc dot gnu dot org 2008-06-04 21:10 ---
Rev. 136372 fixes the issue from comment #2 (but not the original test case in
comment #0).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36275
--- Comment #1 from pault at gcc dot gnu dot org 2008-06-04 21:15 ---
(In reply to comment #0)
This PR is totally vexacious!
A number of things get rid of the ICE:
(i) Interchange test2 and test3;
(ii) Interchange the USE statements in test2; or
(iii) Make the component of outer a
--- Comment #5 from janus at gcc dot gnu dot org 2008-06-04 21:17 ---
The test case in comment #0 is fixed by rev. 136372, but when compiling the
full program at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ff7ae6c7a7860bca/60213205751117d4
one now gets the
--- Comment #10 from hutchinsonandy at gcc dot gnu dot org 2008-06-04
22:00 ---
Subject: Bug 30243
Author: hutchinsonandy
Date: Wed Jun 4 21:59:54 2008
New Revision: 136376
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136376
Log:
PR target/30243
* builtins.c
--- Comment #15 from hutchinsonandy at gcc dot gnu dot org 2008-06-04
22:03 ---
Subject: Bug 27386
Author: hutchinsonandy
Date: Wed Jun 4 22:02:57 2008
New Revision: 136377
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136377
Log:
PR target/27386
* config/avr/avr.h:
--- Comment #11 from hutchinsonandy at gcc dot gnu dot org 2008-06-04
22:05 ---
Fixed 4.4
Back port to 4.3.2 when its open.
--
hutchinsonandy at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from hutchinsonandy at gcc dot gnu dot org 2008-06-04
22:06 ---
Fixed 4.4
--
hutchinsonandy at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kemal dot ebcioglu at acm dot org 2008-06-04 22:40
---
(In reply to comment #3)
Fixed in 4.0.0
Thanks! I also verified that the template test case works in g++ version 4.3.0
on VMWare/Linux/Fedora 9, with the -O option.
--
--- Comment #6 from burnus at gcc dot gnu dot org 2008-06-04 22:45 ---
(In reply to comment #5)
The test case in comment #0 is fixed by rev. 136372, but when compiling the
full program [...]
I don't see whether the full program is valid or not. (Well, except of the
interface in the
--- Comment #7 from burnus at gcc dot gnu dot org 2008-06-04 22:46 ---
The dump contains:
test ()
{
get_funloc (foo, .x);
What I find strange is:
a) That foo gets never defined
b) That .x is passed (string length?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36322
--- Comment #1 from eric dot weddington at atmel dot com 2008-06-04 22:55
---
*** This bug has been marked as a duplicate of 36424 ***
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #2 from eric dot weddington at atmel dot com 2008-06-04 22:55
---
*** Bug 36423 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36424
--- Comment #8 from janus at gcc dot gnu dot org 2008-06-04 23:37 ---
This further reduced test case gives a different ICE:
abstract interface
function abs_fun(x)
implicit none
integer :: x(:)
character(size(x)) abs_fun
end function
end interface
procedure(abs_fun) :: p
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-06-05 01:19
---
The patch in comment#1 fails, printing nothing for a value of zero. This patch
works OK:
Index: write.c
===
--- write.c (revision 136387)
+++
--- Comment #12 from dannysmith at gcc dot gnu dot org 2008-06-05 03:46
---
Subject: Bug 35916
Author: dannysmith
Date: Thu Jun 5 03:45:41 2008
New Revision: 136389
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136389
Log:
PR driver/35916
* mh-mingw (CFLAGS):
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-06-05 05:42
---
Patch in comment #5 is not right either. There is a dependency on pr36420 which
requires m to be set to -1, not zero. Stay tuned.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
41 matches
Mail list logo
