--- Comment #28 from bonzini at gnu dot org 2009-02-06 07:33 ---
Subject: Bug 35659
Author: bonzini
Date: Fri Feb 6 07:33:05 2009
New Revision: 143980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143980
Log:
2009-02-06 Paolo Bonzini
PR tree-optimization/35659
--- Comment #2 from valery_reznic at yahoo dot com 2009-02-06 07:12 ---
(In reply to comment #1)
> r11 is saved by the caller so this is the generated code is valid.
> Since nothing else uses r11 in the inline-asm, the code is correct.
The problem is not that r11 not saved at stack, but
--- Comment #1 from ian at airs dot com 2009-02-06 05:53 ---
Created an attachment (id=17260)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17260&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
This is a bug report for gcc 4_3 branch. I will attach a test case, slightly
reduced from zlib code. When compiling this test case for the x86_64-linux
target with -O2 -fomit-frame-pointer, I see this at the start of the function:
adler32:
pushq %rbp
movq%rdi, %rax
--- Comment #5 from fabrice at mocana dot com 2009-02-06 04:24 ---
(In reply to comment #4)
> Yes, initializing b[1] makes the problem go away in the snippet. I see this
> problem in a much larger program but I can't reproduce it in a simple context.
> Feel free to close the bug as inval
--- Comment #11 from nightstrike at gmail dot com 2009-02-06 04:21 ---
Created an attachment (id=17259)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17259&action=view)
Kai's attempt
This patch has a few caveats:
You can't use the winsup link hack to work around the issue that Co
--- Comment #4 from fabrice at mocana dot com 2009-02-06 03:48 ---
(In reply to comment #3)
> b[1] is uninitialized.
Yes, initializing b[1] makes the problem go away in the snippet. I see this
problem in a much larger program but I can't reproduce it in a simple context.
Feel free to cl
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-06 03:36 ---
LTO creates huge temporary assembly files, some of which > 2GB.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39042
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39041
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-06 02:46 ---
Do you know what temporary files are being used here? Is it an issue with the
driver or with the reader?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39042
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-06 02:41 ---
This is looks like PR 29039.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
>From this thread:
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00271.html
Compiling with -c -g -O2 -Wall from r143978, I only get one warning, but should
get two.
struct A
{
int j;
int i;
};
void foo()
{
char buf[sizeof(struct A)];
// warns
((struct A*)buf)->i = 1;
// does not
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-06 02:25 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-06 02:22 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from rob1weld at aol dot com 2009-02-06 02:15 ---
There really is some trouble with the scripts in this area.
As you might expect simply restarting the make simply repeats the
trouble, shows the same errors and ends the build.
If you restart the build with "gmake -i -k"
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-06 02:11 ---
Works on the trunk:
bl _Z11my_tv_makerf
nop
mr 3,31
bl _ZN2TV4getTEv
nop
tv = my_tv_maker (4.34230010986328125e+2); [return slot optimization]
D.1758 = getT (&tv);
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-06 01:58 ---
b[1] is uninitialized.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-02-06 01:51 ---
(In reply to comment #4)
> Yes because char = char + char is really char = (char)((int)char + (int)char);
Let me expand on that. ((char)CHAR_MAX) + 1 is well defined and there is no
overflow that occurs. Since GCC
--- Comment #2 from fabrice at mocana dot com 2009-02-06 01:51 ---
Created an attachment (id=17258)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17258&action=view)
generated assembly
note the mulq %rax instruction towards the end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #1 from fabrice at mocana dot com 2009-02-06 01:50 ---
Created an attachment (id=17257)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17257&action=view)
preprocessed file
Note that all multiplicands are distinct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3911
The inline assembly can end up generating instructions of the form
mulq %rax when the two operands should be distinct (i.e. one should not compute
%rax * %rax, a square but a product of two different numbers).(The x86 mulq
instruction will compute the product of the operand with the %rax register)
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-06 01:45 ---
*** Bug 39068 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-06 01:45 ---
(In reply to comment #3)
> Are the casts actually needed in this case? It seems the get introduced very
> early on, the .original dump already has:
Yes because char = char + char is really char = (char)((int)char +
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-06 01:42 ---
r11 is saved by the caller so this is the generated code is valid.
Since nothing else uses r11 in the inline-asm, the code is correct.
>From the i386.h header:
The value is zero if the register is not call used o
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-06 01:37 ---
I don't get a segfault on the trunk but I do get an error message:
t.cc: In instantiation of 'const int junk::value':
t.cc:6: instantiated from here
t.cc:4: error: no matching function for call to 'junk::test(int)'
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-06 01:35 ---
> tv = my_tv_maker(434.23); // over-write previous tv.
This needs to have a space for the return value as tv can be accessed via
my_tv_maker as the address of it was passed to an extern function.
Think of:
exte
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-02-06 01:23
---
Not a gcc bug so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Target Milestone|--- |4.3.4
http:/
--- Comment #3 from kkojima at gcc dot gnu dot org 2009-02-06 00:29 ---
Subject: Bug 38991
Author: kkojima
Date: Fri Feb 6 00:29:03 2009
New Revision: 143978
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143978
Log:
PR target/38991
* config/sh/predicates.md (ge
--- Comment #10 from jakub at gcc dot gnu dot org 2009-02-05 23:39 ---
Just s/class ios_base/struct ios_base/ if you don't want 4.3 to reject it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
--- Comment #3 from gnu_andrew at member dot fsf dot org 2009-02-05 23:09
---
Committed to GNU Classpath for 0.98.
CVSROOT:/sources/classpath
Module name:classpath
Changes by: Andrew John Hughes 09/02/05 22:54:11
Modified files:
. : ChangeLog
--- Comment #3 from mt at debian dot org 2009-02-05 23:04 ---
I should have added that this worked fine on 4.2 and was broken as of 4.3.1 at
least, earlier versions (> 4.2) untested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39115
--- Comment #2 from mt at debian dot org 2009-02-05 23:02 ---
Created an attachment (id=17256)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17256&action=view)
Fully preprocessed source, compile with -O2 to see wrong behaviour
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=391
--- Comment #1 from mt at debian dot org 2009-02-05 23:01 ---
Created an attachment (id=17255)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17255&action=view)
Not fully preprocessed source (includes ), compile with -DVOLATILE to
see the correct behaviour
--
http://gcc.gnu.org
[The bug has been reported to the Debian BTS before:
http://bugs.debian.org/491137]
On s390, when using -O2, the attached code fails to throw an exception,
apparently because it does not re-evaluate the value of a variable. If the
variable is marked volatile, the code works as expected.
Best,
Mic
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-02-05 22:48 ---
4.3 rejects the reduced testcase, the original works though.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-05 22:44 ---
Created an attachment (id=17254)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17254&action=view)
reduced testcase
ICEs with -O2 -fno-tree-sra -g [-m32]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3908
--- Comment #23 from dhill at clusterresources dot com 2009-02-05 22:44
---
note that gcc version 3.2.3 correctly reports this warning
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-05 22:17 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-02-05 22:13
---
I have a patch that works.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-05 22:11 ---
Indeed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIR
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||rejects-valid
Priority|P3 |P1
ht
--- Comment #3 from alexey dot pushkin at mererand dot com 2009-02-05
22:08 ---
I believe you are right that it works on x86-linux,
the problem is it doesn't work on x86_64-windows :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39112
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-05 22:06 ---
"eax"(a[0])
That is not how you use constraints.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-02-05 22:06 ---
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3
--- Comment #1 from fabrice at mocana dot com 2009-02-05 22:05 ---
Created an attachment (id=17253)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17253&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39114
gcc-4.1 -v -save-temps -msse2 gnu_bug_test.c
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-05 21:57 ---
*** This bug has been marked as a duplicate of 18501 ***
*** This bug has been marked as a duplicate of 18501 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-05 22:03 ---
5% is way below our release criteria threshold. P4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-05 21:59 ---
Works for me on i686-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39112
--- Comment #22 from pinskia at gcc dot gnu dot org 2009-02-05 21:57
---
*** Bug 39113 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-05 21:54 ---
Subject: Bug 39106
Author: jakub
Date: Thu Feb 5 21:54:06 2009
New Revision: 143973
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143973
Log:
PR c++/39106
* cgraphunit.c (cgraph_function_vers
--- Comment #3 from dhill at clusterresources dot com 2009-02-05 21:48
---
Note that the warning is correctly reported in older versions of the compiler.
The following example is from gcc 3.2.3
$ gcc -O -W um3.c
um3.c: In function `main':
um3.c:5: warning: `J' might be used uninitial
I am using gcc 4.3.2 on a Linux x86_64 system, compiling *.f and *.f90
source code files with gfortran and using the -Wall option. I am getting
several warnings about unused dummy arguments in my code. The warnings are
valid, but I would like to suppress them because they are non-trivial to
corre
--- Comment #4 from spop at gcc dot gnu dot org 2009-02-05 21:45 ---
Subject: Bug 38953
Author: spop
Date: Thu Feb 5 21:44:57 2009
New Revision: 143972
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143972
Log:
2009-02-05 Sebastian Pop
PR middle-end/38953
*
--- Comment #2 from dhill at clusterresources dot com 2009-02-05 21:04
---
Here is the gcc -v output if that is helpful
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu12'
--with-bugurl=file:///usr/shar
--- Comment #1 from dhill at clusterresources dot com 2009-02-05 20:51
---
Created an attachment (id=17252)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17252&action=view)
.i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39113
--- Comment #10 from hjl dot tools at gmail dot com 2009-02-05 20:50
---
Linux/ia64 is OK now:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00543.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
$gcc -O -Wextra -save-temps um3.c
$
um3.c
#include
main()
{
char *J;
if (rand())
J = NULL;
printf("\ntest %s\n",J);
}
In this example, J could be used uninitialized but the compiler is not giving
that warning.
--
Summary: no warning that a variable may be used uninitialized
--- Comment #9 from sje at cup dot hp dot com 2009-02-05 20:45 ---
Ack, my HP-UX and Linux builds were from two different source trees. The HP-UX
build that worked had the patch, the Linux build that failed did not have the
patch applied.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #8 from sje at cup dot hp dot com 2009-02-05 20:41 ---
My IA64 HP-UX bootstrap worked but my IA64 Linux bootstrap failed. When
building libgfortran the configure script tried to compile:
| program foo
| real, parameter :: bar = sin (12.34 / 2.5)
| end prog
--- Comment #1 from alexey dot pushkin at mererand dot com 2009-02-05
20:27 ---
Created an attachment (id=17251)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17251&action=view)
example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39112
there is a class with a static const double member:
struct Foobar{
static const double var;
};
In one translation unit variable 'var' is defined and initialized as 1.0:
const double Foobar::var = 1.0;
When I access Foobar::var from another translation unit, it's value is 0
instead of 1.0 !
Int
--- Comment #8 from bero at arklinux dot org 2009-02-05 20:14 ---
mkdir build
cd build
../configure --prefix=/usr --enable-static --enable-shared
--enable-fast-install --enable-c99 --enable-wchar_t --disable-gconf-peer
--target=i686-pc-mingw32 --enable-threads --enable-tls --with-tls
--e
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|4.3.0 |4.3.0 4.2.2
Target Milestone|--- |4.2.2
h
--- Comment #7 from paolo dot carlini at oracle dot com 2009-02-05 19:36
---
Yes. Please add details about the way you are setting up your build, give
people a chance to analyse it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Add
--- Comment #5 from rsa at us dot ibm dot com 2009-02-05 19:32 ---
>From the libdfp math.h:
#if __STDC_WANT_DEC_FP__
# define DEC_INFINITY>---__builtin_infd32()
# define DEC_NAN>>---(0.0DF * DEC_INFINITY)
# define HUGE_VAL_D64>--__builtin_infd64()
# define HUGE_VAL_D64 (9.
--- Comment #4 from rsa at us dot ibm dot com 2009-02-05 19:28 ---
This situation is a little bit muddy.
The position of the GLIBC maintainer is that requirements of the DFP Technical
Report will NEVER be added to GLIBC proper.
There is indeed currently a EGLIBC branch that is hosting
--- Comment #1 from laurent at guerby dot net 2009-02-05 19:25 ---
At rev 143942 on trunk the test now PASS
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00541.html
Executing on host: /mnt/LG500/home/guerby/build-143942/gcc/xgcc
-B/mnt/LG500/home/guerby/build-143942/gcc/ ./common-1.
--- Comment #1 from rob1weld at aol dot com 2009-02-05 18:36 ---
Correction (not careful enough with the cut-and-pasting):
The "BUG" is this:
If you compile gcc (using a gcc that uses Sun's Linker) to make a gcc
Toolchain that uses GNU's Linker the resulting gcc Toolchain will WORK
rea
On Solaris (and HPUX, other ...) Operating Systems the OS's Manufacturer
has their own Linker and recommends it be used for all linking.
The OpenSolaris "default gcc" supplied by Sun is:
# /usr/sfw/bin/gcc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
Configured with: /b
--- Comment #7 from bonzini at gnu dot org 2009-02-05 18:30 ---
patch committed, please close it as soon as you can confirm it is fixed.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #6 from bonzini at gnu dot org 2009-02-05 18:29 ---
Subject: Bug 39110
Author: bonzini
Date: Thu Feb 5 18:29:11 2009
New Revision: 143971
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143971
Log:
2009-02-05 Paolo Bonzini
PR rtl-optimization/39110
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-05 18:25 ---
Every strict alignment platform is broken.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #2 from aph at gcc dot gnu dot org 2009-02-05 18:18 ---
Created an attachment (id=17250)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17250&action=view)
This should do it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38861
--- Comment #4 from bonzini at gnu dot org 2009-02-05 18:14 ---
*** Bug 39101 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from bonzini at gnu dot org 2009-02-05 18:14 ---
every strict alignment platform is broken.
*** This bug has been marked as a duplicate of 39110 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-05 17:54 ---
Created an attachment (id=17249)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17249&action=view)
Processed gcc/fortran/interface.c
This file is miscompiled with
-DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-05 17:49 ---
Program received signal SIGSEGV, Segmentation fault.
0x4006ac11 in gfc_check_interfaces (ns=0x602b05c0)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/fortran/interface.c:1301
1301 switch
--- Comment #18 from dberlin at gcc dot gnu dot org 2009-02-05 17:43
---
Subject: Re: [4.3/4.4 Regression]
-fprofile-generate = huge SCCs for PRE
My hacking will seriously improve this, since it doesn't iterate over
pieces of the SCC that aren't changing (which often is most
--- Comment #6 from bonzini at gnu dot org 2009-02-05 17:05 ---
That would indeed make it a dup. (I meant 143938 would be the last good
build).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39101
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-05
16:53 ---
Subject: Re: [4.4 Regression] Null pointer dereference in delay slot
> Maybe a dup of 39110 -- try revision 143938.
I'm reconfirming, but I believe 143938 is ok. The problem
is present with 143939.
Dave
--- Comment #17 from dberlin at gcc dot gnu dot org 2009-02-05 16:41
---
Subject: Re: [4.3/4.4 Regression]
-fprofile-generate = huge SCCs for PRE
Ugh.
It might make sense to just replace the hash table implementation we
use with something better (simple power of 2, key-value
--- Comment #4 from bonzini at gnu dot org 2009-02-05 16:37 ---
Maybe a dup of 39110 -- try revision 143938.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39101
--- Comment #6 from r dot emrich at de dot tecosim dot com 2009-02-05
16:34 ---
(In reply to comment #5)
> It does get called when building that i686-pc-linux-gnu -> i686-pc-mingw32
> crosscompiler -- but maybe the fact that it does indicates a bug elsewhere in
> the build system
>
Th
--- Comment #16 from bonzini at gnu dot org 2009-02-05 16:30 ---
Not much. The remaining compile-time hogs (~25%) are the pre_expr and
expr_pred_trans hash tables.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
--- Comment #1 from bonzini at gnu dot org 2009-02-05 16:28 ---
Can you please attach .i files for the fortran compiler? thanks
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.4.0
http://gcc
Revision 143939:
http://gcc.gnu.org/ml/gcc-cvs/2009-02/msg00105.html
caused miscompilation of the fortran compiler on ia64.
--
Summary: [4.4 Regression] Revision 143939 breaks bootstrap on
Linux/ia64
Product: gcc
Version: 4.4.0
--- Comment #5 from bero at arklinux dot org 2009-02-05 15:56 ---
It does get called when building that i686-pc-linux-gnu -> i686-pc-mingw32
crosscompiler -- but maybe the fact that it does indicates a bug elsewhere in
the build system
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-05 15:55 ---
Created an attachment (id=17248)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17248&action=view)
gcc44-pr39106.patch
Patch I'm going to bootstrap/regtest. The problem is that
cgraph_function_versioning copies
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-02-05 15:36
---
Relevant source snippet:
if (default_buffered_input != -1 &&
(!async_p || default_buffered_input > 0))
sync_buffered_stream (default_buffered_input);
if ((pid = fork ()) < 0)
{
sys_error (
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-05 15:36
---
Note the first snippet only triggers a warning with ICC / Comeau in strict
mode, the second one, compiles just fine...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36406
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-02-05 15:31
---
Some more details:
jobs.c: In function 'make_child':
jobs.c:4121: error: corrupted profile info: profile data is not flow-consistent
jobs.c:4121: error: corrupted profile info: number of executions for edge 10-11
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39109
struct N
{
private:
virtual ~N ();
};
N *
foo ()
{
return new N ();
}
used to compile until http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138355
Does it really need to have an accessible destructor if it is never deleted?
Dodji cited [basic.life]/4 which could mean this is valid.
Disti
when configuring libgcc:
configure:2611: /home/falk/lto/build/./gcc/xgcc -B/home/falk/lto/build/./gcc/
-B/usr/local/alphaev68-unknown-linux-gnu/bin/
-B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem
/usr/local/alphaev68-unknown-linux-gnu/include -isystem
/usr/local/alphaev68-unknown-linux-gnu
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-05 14:23 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-05 14:09
---
But, isn't GLIBCXX_CHECK_LINKER_FEATURES called *only* when $GLIBCXX_IS_NATIVE?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107
1 - 100 of 132 matches
Mail list logo
