--- Comment #15 from dodji at gcc dot gnu dot org 2009-12-14 08:24 ---
(In reply to comment #13)
> The .ii file I have attached? Yes, I was expecting it to be correct, it
> compiles without error or warnings with GCC 4.4, even with all warnings
> enabled, AFAIK.
Fair enough. It was me d
--- Comment #13 from paolo dot carlini at oracle dot com 2009-12-14 08:39
---
Yes, you understood correctly, that is our policy and nothing changes if you
overstate the issue by using the "broken" catch-all. To repeat, our general
policy is that any issue corresponding to an ISO DR is n
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-14 08:44
---
I do not have the time to get into the language details, but I think you should
investigate the conformance of the code a bit more: recent SunStudio and Comeau
also agree with ICC and GCC on this.
--
http:
--- Comment #5 from reichelt at gcc dot gnu dot org 2009-12-14 08:46
---
Fixed.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-14 09:27
---
Likewise VC++ v8
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41455
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-14 10:34 ---
See also PR 41600
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41599
--- Comment #28 from dominiq at lps dot ens dot fr 2009-12-14 10:51 ---
(In reply to comment #27)
> My current collection of patches and hacks for this problem. Obviously the
> "if (0)" in tree-ssa-pre.c will break pr38819 again; apart from that untested,
> hence probably miscompiles ev
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-14 11:03 ---
Add -msse2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCO
--- Comment #29 from dominiq at lps dot ens dot fr 2009-12-14 11:21 ---
On x86_64-apple-darwin10, I don't see any speedup with the patch in comment #27
(not a clean bootstrap, but just an incremental build).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #30 from rguenth at gcc dot gnu dot org 2009-12-14 11:23
---
I fail to see why FRE does not remove the redundant load of *n_9(D). Oh, it
is because we first value-number D.1537_58 = *n_9(D); and only after it
we value-number D.1529_45 = *n_9(D);
This is because while we vi
--- Comment #31 from rguenth at gcc dot gnu dot org 2009-12-14 11:49
---
Created an attachment (id=19288)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19288&action=view)
another hack
Sorts the SCCs after collecting them all. Breaks most of the PRE/FRE testcases
because it sorts
--- Comment #32 from rguenther at suse dot de 2009-12-14 12:27 ---
Subject: Re: [4.4/4.5 Regression] 50% performance
regression
On Mon, 14 Dec 2009, matz at gcc dot gnu dot org wrote:
> --- Comment #26 from matz at gcc dot gnu dot org 2009-12-14 04:55 ---
> And if I fix this
--- Comment #33 from rguenth at gcc dot gnu dot org 2009-12-14 12:30
---
Created an attachment (id=19289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19289&action=view)
VRP hack
Hack marking divisions non-trapping during VRP (re-using some stmt bit, not
updating relevant places
--- Comment #16 from jacob dot benoit dot 1 at gmail dot com 2009-12-14
12:43 ---
(In reply to comment #15)
> Fair enough. It was me doing weird things.
>
> I submitted a patch to http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00669.html
> Let's see how it turns out.
>
> Thanks for your
--- Comment #4 from mikpe at it dot uu dot se 2009-12-14 12:57 ---
This bug is also present in gcc-4.4-20091208 but not in gcc-4.3-20091206. The
two fixes listed here apply Ok to 4.4 and solve the problem there w/o
regressions (tested on i686, powerpc64, and arm).
--
mikpe at it dot
--- Comment #34 from rguenth at gcc dot gnu dot org 2009-12-14 12:57
---
"Another possibility is to artificially grow SCCs and
their dependencies by honoring dominating virtual operand uses, not only
defs (ugh)."
what I mean with this is that when finding SCCs we process all uses of a
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-14 12:59 ---
Re-open to mark as regression for 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-14 12:59 ---
I'll take care of a backport after some more testing on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-12-14 13:03
---
(In reply to comment #16)
> I mention this because I heared that GCC has a list of project it builds
> before
> releasing a version, as real-world test cases. Maybe Eigen's test suite can be
> added to that list?
static int
f0 (char *s0, char *s1)
{
return __builtin_strlen (s0) > __builtin_strlen (s1);
}
int
f1 (char *s, int j)
{
if (f0 (s, ""))
return 1;
return j;
}
void
f2 (char *s)
{
f1 (s, 0);
}
fails with -O1 -fipa-cp -flto:
> ./cc1 -quiet -O1 -fipa-cp -flto t.i
t.i:23:1: internal compi
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-14 13:15 ---
This is btw the topmost ICE that appears when you run all of the testsuite
with -flto.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42366
Why GCC copies vectorized buffers to and from stack ?
Am I doing something wrong ?
===
Compiler:
===
gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enabl
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-12-14 13:50
---
We don't fold anything here (because of the volatileness of z4). Thus this
can't be a mpc issue but is probably libm issue.
I don't know how PPC implements _Complex float and if the HW has excess
precision and th
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-12-14 14:01
---
If no calls remain in the assembly as dominiq suggests then the
*call_value_nonlocal_darwin64 pattern must be bogus.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |
--- Comment #5 from igodard at pacbell dot net 2009-12-14 14:58 ---
There's no question that there was an error here. The report is on the
diagnostic. I'm sorry if I hadn't made that clear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
The cio.c file provides some low level routines used by the Ada run-time. The
names of these routines end up in the global namespace. Unfortunately, the
names are very generic and can conflict with the application or other
libraries. I would like to request that the names of the following routine
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-14 16:25 ---
Well, nobody tried to optimize non-HW sized vectors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42367
--- Comment #3 from tromey at gcc dot gnu dot org 2009-12-14 16:26 ---
This seems to work better with svn trunk:
Breakpoint 2, func2 () at pr.c:5
5 return 0;
(gdb) fini
Run till exit from #0 func2 () at pr.c:5
0x080483c3 in main () at pr.c:13
13|| func2 ()
Value ret
--- Comment #2 from aldyh at gcc dot gnu dot org 2009-12-14 16:38 ---
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00716.html
Patch fixes both testcases, but the second testcase has another unrelated SSA
bug.
--
aldyh at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2009-12-14
16:47 ---
there are several problems:
1/ the target-supports tests fail if called with ObjC/ObjC++ specific flags
(e.g. -fgnu-runtime).
2/ there is no specific target-supports test for OBJC2 (which is needed fo
--- Comment #3 from spop at gcc dot gnu dot org 2009-12-14 16:50 ---
Subject: Bug 42284
Author: spop
Date: Mon Dec 14 16:49:47 2009
New Revision: 155218
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155218
Log:
Fix PR42284.
2009-12-12 Sebastian Pop
PR middle-end/42
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2009-12-14
16:50 ---
Created an attachment (id=19290)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19290&action=view)
add support for ObjC/ObjC++ and an effective target OBJ2 test
when -fnext-runtime, -fgnu-runtime,
--- Comment #4 from spop at gcc dot gnu dot org 2009-12-14 16:51 ---
Subject: Bug 42284
Author: spop
Date: Mon Dec 14 16:51:43 2009
New Revision: 155219
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155219
Log:
PR middle-end/42284
* testsuite/gcc.dg/graphite/pr4
--- Comment #6 from developer at sandoe-acoustics dot co dot uk 2009-12-14
16:54 ---
Created an attachment (id=19291)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19291&action=view)
changes to recognize correctly which ObjC runtime is in use
this (a) tracks the -fgnu-runtime/-fn
--- Comment #2 from Shvaiger_Felix at emc dot com 2009-12-14 16:55 ---
vector_size designed as general solution.
Section 5.42 (Using vector instructions through built-in functions)
of gcc info says:
"Specifying a combination that is not valid for the current architecture
will cause GCC
--- Comment #96 from jakub at gcc dot gnu dot org 2009-12-14 16:55 ---
Subject: Bug 41473
Author: jakub
Date: Mon Dec 14 16:55:12 2009
New Revision: 155221
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155221
Log:
PR debug/41473
* dwarf2out.c (add_var_loc_to_dec
--- Comment #97 from jakub at gcc dot gnu dot org 2009-12-14 16:56 ---
Subject: Bug 41473
Author: jakub
Date: Mon Dec 14 16:55:52 2009
New Revision: 155222
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155222
Log:
PR debug/41473
* dwarf2out.c (AT_loc_list_ptr):
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2009-12-14
16:56 ---
Created an attachment (id=19292)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19292&action=view)
changes to recognize correctly which ObjC runtime is in use
this (a) tracks the -fgnu-runtime/-fn
--- Comment #35 from matz at gcc dot gnu dot org 2009-12-14 16:58 ---
Exactly my thinking (growing SCCs -> slow, sorting SCCs -> difficult).
What I thought about the trapping problem is that in this situation we could
ignore the trap test. We start with this situation:
bb1:
goto bb2
--- Comment #8 from developer at sandoe-acoustics dot co dot uk 2009-12-14
16:59 ---
with the patches above;
testsuite/obj-c++.dg/const-str-9.mm should have:
/* { dg-do compile { target *-*-darwin* } } */
/* { dg-skip-if "" { *-*-darwin* } { "-fgnu-runtime" } { "" } } */
/* { dg-skip-i
--- Comment #5 from spop at gcc dot gnu dot org 2009-12-14 17:11 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #98 from developer at sandoe-acoustics dot co dot uk
2009-12-14 18:31 ---
i686-apple-darwin9 bootstraps without dsymutil fails at 155225, thanks Jakub.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
On Linux/ia32, revision 155225 gave:
../../src-trunk/gcc/config/i386/i386.c:23844: error: duplicate case value
../../src-trunk/gcc/config/i386/i386.c:23842: error: previously used here
--
Summary: [4.5 Regression] Failed to bootstrap
Product: gcc
Version: 4.5.0
--- Comment #1 from hjl dot tools at gmail dot com 2009-12-14 19:01 ---
It is caused by revision 155217:
http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00361.html
The problem is
;; Single word integer modes without QImode and HImode.
(define_mode_iterator SWI48 [SI (DI "TARGET_64BIT")])
wi
--- Comment #4 from spop at gcc dot gnu dot org 2009-12-14 19:02 ---
Subject: Bug 42181
Author: spop
Date: Mon Dec 14 19:02:37 2009
New Revision: 155233
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155233
Log:
Fix PR42181.
2009-12-14 Sebastian Pop
PR middle-end/42
--- Comment #5 from spop at gcc dot gnu dot org 2009-12-14 19:03 ---
Fixed in the Graphite branch. I will commit it to trunk after test.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-14 19:11 ---
Subject: Bug 42354
Author: dfranke
Date: Mon Dec 14 19:10:56 2009
New Revision: 155234
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155234
Log:
gcc/fortran/:
2009-12-14 Daniel Franke
PR fortran
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-14 19:13 ---
Created an attachment (id=19293)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19293&action=view)
A patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42369
--- Comment #1 from spop at gcc dot gnu dot org 2009-12-14 19:17 ---
Mine.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gc
--- Comment #2 from spop at gcc dot gnu dot org 2009-12-14 19:20 ---
Mine.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gc
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-12-14 19:22 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|spop at gcc dot gnu dot org |unassigned at gcc dot gnu
|
--- Comment #2 from spop at gcc dot gnu dot org 2009-12-14 19:24 ---
Mine.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gc
--- Comment #3 from spop at gcc dot gnu dot org 2009-12-14 19:41 ---
I cannot reproduce this bug (both testcases) on amd64-linux on trunk revision
155219.
Could you please try again to see if this has been resolved?
Thanks,
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-14 19:59 ---
Subject: Bug 42369
Author: jakub
Date: Mon Dec 14 19:59:00 2009
New Revision: 155237
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155237
Log:
PR bootstrap/42369
* config/i386/i386.c (ix86_exp
Test with a SVN build:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/rodrigo/local/gcc/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/rodrigo/local/gcc
--with-gmp=/home/rodrigo/local/gcc --with-mpfr=/
--- Comment #1 from rodrigorivascosta at gmail dot com 2009-12-14 20:19
---
Created an attachment (id=19294)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19294&action=view)
Simplest test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42370
--- Comment #2 from rodrigorivascosta at gmail dot com 2009-12-14 20:21
---
Created an attachment (id=19295)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19295&action=view)
Simplest test case
Sorry, wrong MIME in the atch 19294
--
rodrigorivascosta at gmail dot com changed:
The follwing program:
#include
typedef unsigned char(*Calculable)(void);
unsigned char one() { return 1; }
unsigned char two() { return 2; }
static void print(Calculable calculate)
{
printf("%d\n", calculate());
printf("+1: %d\n", calculate() + 1);
}
int main()
{
print
--- Comment #14 from dominiq at lps dot ens dot fr 2009-12-14 20:42 ---
When compiled with '-m64 -O1 -frename-registers' the code in comment #6 fails,
but passes with ''-m64 -O1'.
> If no calls remain in the assembly as dominiq suggests then the
> *call_value_nonlocal_darwin64 pattern m
--- Comment #33 from dominiq at lps dot ens dot fr 2009-12-14 20:43 ---
Created an attachment (id=19296)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19296&action=view)
assembly generated with -frename-registers
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
--- Comment #34 from dominiq at lps dot ens dot fr 2009-12-14 20:45 ---
Created an attachment (id=19297)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19297&action=view)
assembly generated without -frename-registers
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
--- Comment #15 from dominiq at lps dot ens dot fr 2009-12-14 20:48 ---
Created an attachment (id=19298)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19298&action=view)
assembly generated with -frename-registers
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #35 from dominiq at lps dot ens dot fr 2009-12-14 20:51 ---
Wrong pr. Sorry for the noise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
--- Comment #16 from dominiq at lps dot ens dot fr 2009-12-14 20:54 ---
Created an attachment (id=19299)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19299&action=view)
assembly generated without -frename-registers
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #6 from dominiq at lps dot ens dot fr 2009-12-14 21:10 ---
The test passes with '-O3 -fno-tree-vectorize' or '-O2 -ftree-vectorize', so
its seems that it is a vectorizer problem.
--
dominiq at lps dot ens dot fr changed:
What|Removed |A
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-14 21:28
---
Is c++/42336 related?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42364
--- Comment #18 from sacolcor at provide dot net 2009-12-14 21:36 ---
Should the library support for this be split into a separate bug? Or two bugs,
if libstdc++ and glibc both need to handle the new types?
--
sacolcor at provide dot net changed:
What|Removed
--- Comment #4 from dominiq at lps dot ens dot fr 2009-12-14 21:38 ---
I see it for both reduced tests on powerpc-apple-darwin9, revision 155196, in
32 bit mode, but not in the 64 bit one. The compilation goes fine on
x86_64-apple-darwin10, revision 155224.
--
http://gcc.gnu.org/bug
attached testcase fails on trunk for arm target with the following optset
-c -fgnu89-inline -Os -frename-registers
it works ok with -O2 or -O3
/tmp/cc9PcQw8.s: Assembler messages:
/tmp/cc9PcQw8.s:438: Error: undefined symbol `.LPIC7' in operation
--
Summary: Error: undefined symbol
--- Comment #1 from raj dot khem at gmail dot com 2009-12-14 22:51 ---
Created an attachment (id=19300)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19300&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42372
--- Comment #10 from rearnsha at gcc dot gnu dot org 2009-12-14 23:14
---
While getting the size right is useful, it's not something that can be relied
on by users, so this is really an enhancement.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-14 23:25 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #20 from paolo dot carlini at oracle dot com 2009-12-14 23:26
---
This is in fact DR 865 and now that the status is [Ready] we can simply re-open
it, say in the docs that we implement it already and then close it again.
--
paolo dot carlini at oracle dot com changed:
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-12-14 23:35
---
There's a lot of debate about whether the ARM behaviour is a good thing or not.
Not pushing the return address means that the debugger cannot generate a
back-trace in the event that the no-return function is somet
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-14 23:37 ---
Confirmed - the work around appears to also be to remove -frename-registers.
Reducing testcase.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from ramana at gcc dot gnu dot org 2009-12-14 23:43 ---
I now see a bootstrap failure with build/genmddeps going into an infinite loop
for stage2. This has to be a problem with the the system compiler.
This utility jumps into never never land from read_rtx in read-rtl.c -
--- Comment #21 from paolo at gcc dot gnu dot org 2009-12-15 00:08 ---
Subject: Bug 25304
Author: paolo
Date: Tue Dec 15 00:07:52 2009
New Revision: 155241
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155241
Log:
2009-12-14 Paolo Carlini
PR libstdc++/25304, DR 865
--- Comment #22 from paolo dot carlini at oracle dot com 2009-12-15 00:10
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #3 from jason at gcc dot gnu dot org 2009-12-15 01:47 ---
I suspect this is the same bug as 42225.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-15
01:56 ---
Any ideas on why we are failing this on x86_64-apple-darwin10? There we are
seeing...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.b
On both x86_64-apple-darwin9 and x86_64-apple-darwin10, we are failing the
testcase g++.dg/cpp0x/lambda/lambda-mangle.C in the section...
FAIL: g++.dg/cpp0x/lambda/lambda-mangle.C scan-assembler weak[
\t]*_?_ZN1RIiE1xMUlvE_clEv
Using built-in specs.
COLLECT_GCC=/sw/src/fink.build/gcc45-4.4.999-20
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-12-15
02:06 ---
Created an attachment (id=19301)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19301&action=view)
assembly from g++.dg/cpp0x/lambda/lambda-mangle.C
Created with...
/sw/src/fink.build/gcc45-4.4.999-2
--- Comment #2 from jason at gcc dot gnu dot org 2009-12-15 02:12 ---
Subject: Bug 42364
Author: jason
Date: Tue Dec 15 02:11:54 2009
New Revision: 155246
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155246
Log:
PR c++/42364
* pt.c (function_parameter_expanded_
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-12-15 03:02
---
I have started looking at this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41872
--- Comment #3 from jason at gcc dot gnu dot org 2009-12-15 03:25 ---
How do you make the whole testsuite run with certain flags, anyway? Nothing
I'm trying works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42364
--- Comment #2 from jason at gcc dot gnu dot org 2009-12-15 03:59 ---
Created an attachment (id=19302)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19302&action=view)
patch
Does this fix it?
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from jason at gcc dot gnu dot org 2009-12-15 04:02 ---
Perhaps this is related to bug 11633.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41449
/set/operators/1_neg.cc (test for errors, line 287)
FAIL: 23_containers/set/operators/1_neg.cc (test for errors, line 291)
FAIL: 23_containers/set/operators/1_neg.cc (test for excess errors)
on x86_64-apple-darwin10. These appear as...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091214
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #4 from jason at gcc dot gnu dot org 2009-12-15 04:54 ---
Mysterious hash table lookup failure after htab_expand.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42358
the attached code from the diffutils configure script is supposed to check for
"working C stack overflow detection" but instead hangs when built with trunk at
-O2 or higher. 4.4.2 works.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-unknown-linux-gnu/gcc-bin/4.5.0-pre/gcc
COLLECT_LTO
--- Comment #1 from dirtyepic at gentoo dot org 2009-12-15 05:24 ---
Created an attachment (id=19303)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19303&action=view)
conftest.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42375
--- Comment #2 from dirtyepic at gentoo dot org 2009-12-15 05:24 ---
Created an attachment (id=19304)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19304&action=view)
conftest.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42375
--- Comment #36 from tkoenig at gcc dot gnu dot org 2009-12-15 07:09
---
If it is any help, code which traps for a do loop is illegal Fortran,
so the compiler may do anything in this case anyway.
Is there a function like
__builtin_i_dont_care_if_this_traps_or_not_if_it_traps_its_the_us
99 matches
Mail list logo
