--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-19 09:33
---
Subject: Bug 36765
Author: rguenth
Date: Mon Jan 19 09:33:06 2009
New Revision: 143494
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143494
Log:
2009-01-19 Richard Guenther
Backport from mainl
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-01-19 09:35
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENE
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-19 09:49 ---
P1 as this happens on a secondary target with -O3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #36 from bonzini at gnu dot org 2009-01-19 10:33 ---
Would you please attach the assembler diff:
1) between -m32 -O1 and -m32 -O1 -fforward-propagate
2) between the latter and -m32 -O1 -fforward-propagate -fschedule-insns2?
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #37 from bonzini at gnu dot org 2009-01-19 10:36 ---
This is the fishy part: notice that the %esi in the failing test case is
completely bogus.
- leal-680(%ebp), %esi
- movb$32, (%esi)
- movb$32, -679(%ebp)
- movw$8224, -678(%ebp)
+
--- Comment #38 from rguenth at gcc dot gnu dot org 2009-01-19 10:50
---
Created an attachment (id=17139)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17139&action=view)
assembler diff between -O -m32 -fforward-propagate and -O -m32
-fforward-propagate -fschedule-insns2
--
h
--- Comment #33 from r dot emrich at de dot tecosim dot com 2009-01-19
10:51 ---
(In reply to comment #32)
>
> Dave, thank you for the explanation.
> Next week I will try to build some functional C++ application.
> Then we will see if there are remaining issues.
>
> Rainer
>
There a
--- Comment #34 from r dot emrich at de dot tecosim dot com 2009-01-19
10:52 ---
Created an attachment (id=17140)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17140&action=view)
C compile log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
--- Comment #35 from r dot emrich at de dot tecosim dot com 2009-01-19
10:53 ---
Created an attachment (id=17141)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17141&action=view)
C compile static log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
--- Comment #37 from r dot emrich at de dot tecosim dot com 2009-01-19
10:54 ---
Created an attachment (id=17143)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17143&action=view)
C++ compile static log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
--- Comment #39 from bonzini at gnu dot org 2009-01-19 11:04 ---
Looks like a scheduling bug:
-O1 -fforward-propagate has
leal-676(%ebp), %edi
movl$19, %ecx
movl$538976288, %eax
rep stosl
movw$31096, -603(%ebp)
movb$122
--- Comment #35 from rguenth at gcc dot gnu dot org 2009-01-19 10:29
---
I can reproduce the issue with the testcase in comment #27 on x86_64-linux
with -m32 -O2 vs. -m32 -O.
It can be reduced to the effect of -fschedule-insns2 and -fforward-propagate
(disabling either on -O2 -fno-stri
--- Comment #36 from r dot emrich at de dot tecosim dot com 2009-01-19
10:53 ---
Created an attachment (id=17142)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17142&action=view)
C++ compile log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
--- Comment #40 from rguenth at gcc dot gnu dot org 2009-01-19 12:20
---
Which means this might be a target bug as well, more specifically a bug in the
*rep_stossi pattern.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #41 from rguenth at gcc dot gnu dot org 2009-01-19 12:37
---
In
(insn 37 86 40 4 t.f:9 (parallel [
(set (reg:SI 2 cx [74])
(const_int 0 [0x0]))
(set (reg/f:SI 5 di [72])
(plus:SI (ashift:SI (reg:SI 2 cx [74])
--- Comment #42 from rguenth at gcc dot gnu dot org 2009-01-19 12:40
---
Rather it is broken from expansion:
;; __builtin_memset (&line[2]{lb: 1 sz: 1}, 32, 79);
(insn 28 27 29 t.f:9 (parallel [
(set (reg:SI 70)
(plus:SI (reg/f:SI 54 virtual-stack-vars)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
--- Comment #38 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-19
13:38 ---
Subject: Re: fails to build cross gcc for target hppa64-hp-hpux11.00 in
libstdc++/libmath
> There are some strange symptoms.
>
> I tried to build a simple "Hello, World!" application in 4 variants.
> 1.
--- Comment #1 from j dot s dot sebastian at gmail dot com 2009-01-19
13:50 ---
After some trial and error, I found it does compile (on same system) if I
modify the code as follows, to use the 3-argument version of sort:
#include
#include
int main()
{
std::vector v(100);
// Exp
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-19 14:05
---
Thanks for the additional info. Let's add Johannes in CC, I'm confident we can
fix this pretty soon.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #43 from bonzini at gnu dot org 2009-01-19 14:06 ---
The bug is actually in target independent code. The code to change_address_1
in adjust_address_1 does nothing if the addr is simple, and this causes the
creation of shared or wrong RTL.
--
http://gcc.gnu.org/bugzilla/
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-19 14:07 ---
Can you attach preprocessed source of idecode.c at least? Can you track down
where in idecode.c the bug is and wrap a main () around that piece, making it
an executable testcase?
Does 4.3.[23] work? Pleas adjust t
This RFE is for two related issues. I'll call it an RFE rather
than attempt to argue it is a Bug (by omission or inconsistent
behavior).
1: Typing "gcc -v" will print the 'specs info', 'HBT', 'how gcc was
"./configured"', 'the thread model' and 'version / revision'. When
you actually compile a p
--- Comment #7 from joel at gcc dot gnu dot org 2009-01-19 14:38 ---
Works with 4.3.2 as shipped with Fedora 10 (RPM gcc-4.3.2-7.x86_64)
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from joel at gcc dot gnu dot org 2009-01-19 14:45 ---
$ gcc --version
gcc (GCC) 4.4.0 20090116 (experimental) [trunk revision 143442]
broken still. Test script
=
rm -rf b-gdb && mkdir b-gdb && cd b-gdb && \
/home/joel/gcc-
--- Comment #9 from joel at gcc dot gnu dot org 2009-01-19 14:51 ---
Created an attachment (id=17144)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17144&action=view)
PSIM test executable that produces assertion
PowerPC PSIM executable used by previous test script.
--
http://
--- Comment #10 from joel at gcc dot gnu dot org 2009-01-19 14:54 ---
Created an attachment (id=17145)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17145&action=view)
preprocessed idecode.c
Preprocessed version of idecode.i using this gcc version on Fedora 10:
4.4.0 20090116 (ex
--- Comment #11 from joel at gcc dot gnu dot org 2009-01-19 15:00 ---
(In reply to comment #6)
> Can you attach preprocessed source of idecode.c at least? Can you track down
> where in idecode.c the bug is and wrap a main () around that piece, making it
> an executable testcase?
psim i
--- Comment #44 from bonzini at gnu dot org 2009-01-19 15:03 ---
Created an attachment (id=17146)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17146&action=view)
patch under test
testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
TYPE_CANONICAL should specify a canonical type node (equivalent for type
comparison for example during TBAA) for each type declaration. Failing to do
so causes TBAA pessimizations.
The frontend also does not properly identify equivalent types, which is
a correctness issue. Consider (reduced from
--- Comment #14 from danglin at gcc dot gnu dot org 2009-01-19 16:14
---
New test fails on hpux:
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr36227.c -w -O0 -lm
-o
/test/gnu/gcc/objdir/gcc/t
--- Comment #15 from rguenther at suse dot de 2009-01-19 16:22 ---
Subject: Re: [4.3 Regression] POINTER_PLUS folding
introduces undefined overflow
On Mon, 19 Jan 2009, danglin at gcc dot gnu dot org wrote:
> --- Comment #14 from danglin at gcc dot gnu dot org 2009-01-19 16:14
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-19 16:23 ---
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00937.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38913
--- Comment #3 from rob1weld at aol dot com 2009-01-19 16:26 ---
(In reply to comment #1)
> Probably the Solaris /bin/sh misparses ${BOOT_CFLAGS+'print
> "BOOT_CFLAGS='"${BOOT_CFLAGS}"'";'}. The autoconf manual describes a similar
> bug in connection with ${foo='}'}.
There may well be
--- Comment #4 from rob1weld at aol dot com 2009-01-19 16:39 ---
Ada has it's errors fixed but now it presents output that is not "captured
and warned" in the Testsuite reports. The extra messages are not reported.
Here is part of: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01790
The following program causes an ICE. If the contains and subroutine statements
are uncommented, then the program compiles.
Dick Hendrickson
MODULE U_above_TESTS
! fails on Windows XP
! gcc version 4.4.0 20081219 (experimental) [trunk revision 142842] (GCC)
! contains
! subrouti
--- Comment #6 from rob1weld at aol dot com 2009-01-19 17:09 ---
The Trunk (143454) is now:
# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --e
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-19 17:17
---
Hummm, actually, I can't reproduce with current mainline... Can you also try a
snapshot / SVN checkout of current mainline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38897
--- Comment #9 from vmakarov at gcc dot gnu dot org 2009-01-19 17:17
---
Subject: Bug 38869
Author: vmakarov
Date: Mon Jan 19 17:17:14 2009
New Revision: 143498
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143498
Log:
2009-01-19 Vladimir Makarov
PR c/38869
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38897
--- Comment #4 from paolo dot carlini at oracle dot com 2009-01-19 17:36
---
By the way, I don't see any serious divergence between the 4_3 and the mainline
libraries in this area, therefore likely the issue is ultimately due to a C++
front-end issue... Since 4.3.3 is being released rig
--- Comment #18 from rob1weld at aol dot com 2009-01-19 17:43 ---
With my fix I can configure with "--enable-java-awt=gtk,xlib,qt,x", see:
Results for 4.4.0 20090117 (experimental) [trunk revision 143454] (GCC)
testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-
--- Comment #8 from rob1weld at aol dot com 2009-01-19 17:46 ---
(In reply to comment #7)
> After my "moc-qt4" fix to the Makefile I have test results to prove it built:
>
> Results for 4.3.0 20070716 (experimental) testsuite on i686-pc-linux-gnu
> http://gcc.gnu.org/ml/gcc-testresults/
The following program gives the wrong results for the character assignments to
a structure component. The problem appears to occur when there is an overlap
between the left and right hand sides of the assignment. It is "as if" the
character length of the right hand side is treated as 1, rather th
--- Comment #1 from kargl at gcc dot gnu dot org 2009-01-19 17:56 ---
Reduced testcase. This appears to be an array section problem
with lbound().
MODULE U_above_TESTS
INTEGER, PARAMETER, DIMENSION(0:20,4) :: IP_ARRAY2_4_S = 0
INTEGER, PARAMETER, DIMENSION(2) :: IP_A
--- Comment #4 from rob1weld at aol dot com 2009-01-19 18:01 ---
(In reply to comment #3)
> Fixed in GCC 4.2.4 and GCC 4.3. I don't think it is worth to fix this in
> earlier versions.
Thank you for fixing this.
BTW: Between 4.2.1 and 4.2.2 the gcc compiler changed from "supporting old
--- Comment #2 from rob1weld at aol dot com 2009-01-19 18:06 ---
(In reply to comment #1)
> A few hours later and it failed for want of ltcf-c.sh and ltcf-cxx.sh. I ran
> gcc_update again and that fixed the configure / makefile problem of not
> copying
> those files over.
I no longer g
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-19 18:48 ---
DLA => DDA(2:3, 1:3:2, 5:4:-1, NF2, NF5:NF2:MF2)
The descriptor built for DLA has negative strides for dimension >= 3.
This makes ubound fail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38852
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-19 18:49 ---
Confirm. ICE with 4.1.x and 4.2.x and wrong code with 4.3.x and 4.4.
Thanks for the report.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from ubizjak at gmail dot com 2009-01-19 18:53 ---
(In reply to comment #10)
> Fails on s390 and s390x as well.
And alpha.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35729
--- Comment #12 from hjl dot tools at gmail dot com 2009-01-19 19:01
---
How can I reproduce it on Linux/x86-64, assuming I know nothing
about rtems and sim?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #13 from joel at gcc dot gnu dot org 2009-01-19 19:09 ---
Created an attachment (id=17147)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17147&action=view)
script to run psim
script to run psim to reproduce bug. Specifying the device tree is painful.
--
http://gc
--- Comment #14 from joel at gcc dot gnu dot org 2009-01-19 19:15 ---
(In reply to comment #12)
> How can I reproduce it on Linux/x86-64, assuming I know nothing
> about rtems and sim?
>
You don't have to know much of anything. It should be reproducible with
powerpc-elf but this is t
--- Comment #10 from hjl dot tools at gmail dot com 2009-01-19 19:30
---
The problem is x86 doesn't set the memory size correct for rep_stos.
Gcc 4.3.3 gave:
(gdb) call debug_rtx (destmem)
(mem/s/c:BLK (reg:DI 59) [3 buffer+8 S1 A64])
(gdb)
Jakub's patch corrected it to
(gdb) call d
--- Comment #45 from dominiq at lps dot ens dot fr 2009-01-19 19:31 ---
The patch in comment #44 fixes the problem (as far as I can test it) on
i686-apple-darwin9 without regression for gcc, g++, gfortran, objc, and
obj-c++, full test this night.
Thanks for the patch.
--
http://gcc
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|nathan at gcc dot gnu dot |jason at gcc dot gnu dot org
|org
--- Comment #2 from mikael at gcc dot gnu dot org 2009-01-19 19:47 ---
the lbound should be simplified in simplify_bound even if the ARRAY argument is
not a full array.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38914
--- Comment #11 from hjl dot tools at gmail dot com 2009-01-19 20:30
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00948.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
The ISO C++ standard in section 20.4.5.3 defines the effects and postconditions
of auto_ptr conversions. It says that
template operator auto_ptr_ref() throw();
returns "an auto_ptr_ref that holds *this". Unlike the other conversions in
the same section, there is no call to release(), so after
--- Comment #15 from hjl dot tools at gmail dot com 2009-01-19 21:38
---
Revision 142516 gave:
[...@gnu-28 pr38587]$ ./psim-4.10 ./powerpc-psim-ticker.ralf
events.c:329: assertion failed - !events->processing
[...@gnu-28 pr38587]$
Revision 142517 gave:
[...@gnu-34 pr38587]$ ./psim-
The following program gives error messages for using DATA to iniialize pointers
to arrays to NULL()
Dick Hendrickson
SUBROUTINE PF0005
! fails on Windows XP
! gcc version 4.4.0 20081219 (experimental) [trunk revision 142842] (GCC)
REAL, SAVE, POINTER :: PTR1
INTEGER, POINTER
The following program gives a compile time error for a DATA assignment of
NULL() to a structure component. Probably related to 38917
Dick Hendrickson
SUBROUTINE PF0009
! fails on Windows XP
! gcc version 4.4.0 20081219 (experimental) [trunk revision 142842] (GCC)
TYPE :: HAS_POINT
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-19 22:18 ---
> > I suspect the following is invalid as the arguments to the defined
> > assignment
> > alias.
> >
>
> Why do you think it is invalid?
Because the arguments to the i_to_t (or l_to_t) alias. They point to the sa
--- Comment #6 from mikael at gcc dot gnu dot org 2009-01-19 22:19 ---
Subject: Bug 38859
Author: mikael
Date: Mon Jan 19 22:19:34 2009
New Revision: 143501
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143501
Log:
2009-01-19 Mikael Morin
PR fortran/38859
*
--- Comment #16 from joel at gcc dot gnu dot org 2009-01-19 22:20 ---
(In reply to comment #15)
> Revision 142516 gave:
>
> [...@gnu-28 pr38587]$ ./psim-4.10 ./powerpc-psim-ticker.ralf
> events.c:329: assertion failed - !events->processing
That sounds like the previous psim miscompiled
--- Comment #10 from mckelvey at maskull dot com 2009-01-19 22:29 ---
(In reply to comment #7)
> Created an attachment (id=17132)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132&action=view) [edit]
> Move _ctors* and _chkstk* to import lib
>
> Danny, this is the approach that
--- Comment #4 from dick dot hendrickson at gmail dot com 2009-01-19 22:31
---
Subject: Re: WHERE with multiple elemental defined assignments gives wrong
answer
On Mon, Jan 19, 2009 at 4:18 PM, mikael at gcc dot gnu dot org
wrote:
>
>
> --- Comment #3 from mikael at gcc dot gnu d
--- Comment #4 from mikael at gcc dot gnu dot org 2009-01-19 22:33 ---
This removes the ICE:
Index: primary.c
===
--- primary.c (révision 143501)
+++ primary.c (copie de travail)
@@ -2370,6 +2370,8 @@
bool implicit_c
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-19 22:35
---
Note that auto_ptr is deprecated for the next Standard, replaced by unique_ptr
(which we deliver in C++0x mode). In fact the specifications of auto_ptr are
known to be irreparably broken. That means we must be
--- Comment #5 from dominiq at lps dot ens dot fr 2009-01-19 22:39 ---
> This removes the ICE: ...
Do you understand why?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38907
--- Comment #2 from janis at gcc dot gnu dot org 2009-01-19 22:45 ---
I assume that the person who sent me the test did so because it passes with
some other implementation, but that doesn't mean it's widespread. It's fine
with me if you say it won't be fixed.
--
http://gcc.gnu.org/
--- Comment #2 from steven at gcc dot gnu dot org 2009-01-19 22:49 ---
Yah, seen -> CONFIRMED
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #22 from jason at gcc dot gnu dot org 2009-01-19 22:50 ---
Subject: Bug 23287
Author: jason
Date: Mon Jan 19 22:50:43 2009
New Revision: 143502
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143502
Log:
PR c++/23287
* parser.c (cp_parser_unqualified_i
--- Comment #11 from steven at gcc dot gnu dot org 2009-01-19 22:53 ---
I vote WONTFIX. No user is ever going to notice this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38871
--- Comment #23 from jason at gcc dot gnu dot org 2009-01-19 23:05 ---
Fixed for 4.4.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|3.3.
--- Comment #6 from pault at gcc dot gnu dot org 2009-01-19 23:08 ---
Created an attachment (id=17148)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17148&action=view)
A patch for the PR
This regtests and bootstraps on FC9/x86_i64. I'll do ChangeLogs and so on
tomorrow.
Thanks f
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-19 23:12
---
Please, double check that, if possible. Then we'll see...
By the way, we are essentially following Josuttis' implementation, in his book.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38916
--- Comment #15 from hjl dot tools at gmail dot com 2009-01-19 23:28
---
This isn't really fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #17 from hjl dot tools at gmail dot com 2009-01-19 23:29
---
*** Bug 38387 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587
--- Comment #16 from hjl dot tools at gmail dot com 2009-01-19 23:29
---
*** This bug has been marked as a duplicate of 38587 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #18 from hjl dot tools at gmail dot com 2009-01-19 23:35
---
(In reply to comment #11)
> (In reply to comment #6)
> > Can you attach preprocessed source of idecode.c at least? Can you track
> > down
> > where in idecode.c the bug is and wrap a main () around that piece, ma
--- Comment #19 from hjl dot tools at gmail dot com 2009-01-19 23:41
---
Revert revision revision 139996 doesn't solve the problem.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #46 from howarth at nitro dot med dot uc dot edu 2009-01-19
23:44 ---
I can confirm that gcc trunk with the proposed patch can now build xplor-nih at
-O3 (with to resorting to -funroll-loops) and the output code works correctly
now on i686-apple-darwin9. Thanks for fixing th
--- Comment #4 from janis at gcc dot gnu dot org 2009-01-20 00:22 ---
See the analysis in http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00801.html
which skips the test for MIPS targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219
building 4.4 snap with mingw-w64-snapshot-20081115.tar.bz2 ends with:
(...)
libtool: compile:
/home/users/pluto/rpm/BUILD/gcc-4.4-20090116/BUILDDIR/./gcc/xgcc -shared-libgcc
-B/home/users/pluto/rpm/BUILD/gcc-4.4-20090116/BUILDDIR/./gcc -nostdinc++
-L/home/users/pluto/rpm/BUILD/gcc-4.4-20090116/BU
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-20 01:09
---
Benjamin, can you have a look?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #20 from hjl dot tools at gmail dot com 2009-01-20 02:00
---
The problem may something to do with
setjmp
...
while (1)
{
foo (); // foo calls longjmp and foo is inlined.
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587
$ x86_64-mingw32-g++ -v
Reading specs from /usr/lib64/gcc/x86_64-mingw32/4.4.0/specs
Target: x86_64-mingw32
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--includedir=/usr/x86_64-mingw32/include --with-gnu-a
--- Comment #1 from pluto at agmk dot net 2009-01-20 02:51 ---
Created an attachment (id=17149)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17149&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
With 4.3 branch at revision 143494 (probably also at least 135713, but that has
local patches I don't care to revert to verify) the attached code puts the
p->next load in the delay-slot of the NULL-check branch, yielding a NULL
access.
I'm guessing a reorg.c bug...
(It doesn't seem to happen at HE
--- Comment #1 from hp at gcc dot gnu dot org 2009-01-20 03:57 ---
Created an attachment (id=17150)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17150&action=view)
testcase
Compile at -O2. Run in simulator (note the linker option) or compile with -O2
-S and observe:
mov
--- Comment #4 from rob1weld at aol dot com 2009-01-20 04:05 ---
(In reply to comment #1)
> I really don't think using solaris threads is that well supported anymore. Is
> there a reason why you are not using just --enable-threads=pthreads?
I have another reason for the compiler to sup
--- Comment #2 from bkoz at redhat dot com 2009-01-20 04:21 ---
If this is a native build, then GLIBCXX_CHECK_MATH_SUPPORT should have defined
_GLIBCXX_HAVE_FABSL
_GLIBCXX_HAVE_MODFL
in c++config.h. One would have seen something like:
checking for fabsl declaration... yes
checking fo
--- Comment #11 from dave dot korn dot cygwin at gmail dot com 2009-01-20
04:32 ---
Created an attachment (id=17151)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17151&action=view)
Fill out missing syms from shared libgcc using static libgcc archive.
(In reply to comment #10)
>
--- Comment #21 from hjl dot tools at gmail dot com 2009-01-20 05:00
---
(In reply to comment #20)
> The problem may something to do with
>
> setjmp
> ...
> while (1)
> {
> foo (); // foo calls longjmp and foo is inlined.
> }
>
The problem is
if (setjmp (buf))
{
/* Res
--- Comment #17 from bkoz at redhat dot com 2009-01-20 05:51 ---
The float versions were added in r143457
http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00470.html
hpux 11 looks fine, but I don't see 10.x results.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32666
--- Comment #7 from pault at gcc dot gnu dot org 2009-01-20 05:54 ---
Ticked off 4.4...:-)
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-01-20
06:07 ---
libstdc++ also needs to be built and linked in as dll.
Search mingw archive lists for other examples and approaches.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-20 07:25 ---
Confirm. Thanks for the report.
R532 data-stmt-constant is ...
or null-init
R507 null-init is function-reference
C506 (R507) The function-reference shall be a reference to the NULL intr
1 - 100 of 102 matches
Mail list logo
