I think the main reason is that DMD front end sources are dual licensed
with GPL and Artistic License. The DMD backend is not under an open
source license (personal use only), so the Artistic License is how the
two are integrated. The fork is required to allow DMD to continue under
its
On 01/23/2010 04:29 PM, Richard Guenther wrote:
We could warn about this when building with C++ but with C we do not
see bools but ints here.
With such a warning there would be no reason not to build stage2 and
stage3 with bool == _Bool.
Paolo
On Sun, Jan 24, 2010 at 07:00:44AM -0800, Paolo Bonzini wrote:
I think the main reason is that DMD front end sources are dual licensed
with GPL and Artistic License. The DMD backend is not under an open
source license (personal use only), so the Artistic License is how the
two are
Strictly speaking, that's not true. Even if the submitter would still
be required to have copyright assignment for the FSF, they could be
copyable to the DMD front-end _as long as the submitter himself sends
them for inclusion there too_. This is the practical significance of
the license
Richard,
Could you provide us with a good reference for the latencies and other
speed issues of SSE operations? What I've found is scattered and hard
to compare.
Frankly, I was under the misconception that each of these SSE operatons
was meant to be accomplished in a single clock cycle
On Sun, Jan 24, 2010 at 10:32 PM, Steve White swh...@aip.de wrote:
Richard,
Could you provide us with a good reference for the latencies and other
speed issues of SSE operations? What I've found is scattered and hard
to compare.
Frankly, I was under the misconception that each of these SSE
Steve White wrote:
I was under the misconception that each of these SSE operatons
was meant to be accomplished in a single clock cycle (although I knew there
are various other issues.)
Current CPU architectures permit an SSE scalar or parallel multiply and
add instruction to be issued on
Snapshot gcc-4.3-20100124 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100124/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
This is to report a successful build of GCC 4.4.3 and GCC 4.5.0
(156177) on my Macbook6,1.
./config.guess:
i386-apple-darwin10.2.0
gcc -v:
For GCC 4.4.3:
Using built-in specs.
Target: x86_64-apple-darwin10.2.0
Configured with: ../gcc-4.4.3/configure
--- Comment #5 from jon_y at users dot sourceforge dot net 2010-01-24
07:59 ---
Ping,
We need to get this fixed ASAP. Probably involving the libtool devs as well. I
propose the following naming scheme.
libw64stdc++-6.dll (64bit mingw-w64)
libw32stdc++-6.dll (32bit mingw-w64)
--- Comment #11 from burnus at gcc dot gnu dot org 2010-01-24 08:13 ---
Subject: Bug 39304
Author: burnus
Date: Sun Jan 24 08:10:47 2010
New Revision: 156195
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156195
Log:
2010-01-24 Tobias Burnus bur...@net-b.de
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-24 11:52 ---
*** This bug has been marked as a duplicate of 41464 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-24 11:52 ---
*** Bug 42846 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-24 12:08 ---
In the testcase from PR42846 one issue is that
base_address: p__3(D)
offset from base address: 0
constant offset from base address: 0
step: 4
aligned to: 128
--- Comment #5 from aanisimov at inbox dot ru 2010-01-24 12:11 ---
(In reply to comment #4)
This looks like a bug in gold rather then in GCC.
Try the latest development version of gold http://sourceware.org/binutils/.
If it still fails, please file a bug report with more details at
--- Comment #3 from aanisimov at inbox dot ru 2010-01-24 12:12 ---
No longer fails.
--
aanisimov at inbox dot ru changed:
What|Removed |Added
Status|WAITING
--- Comment #12 from burnus at gcc dot gnu dot org 2010-01-24 12:54 ---
(In reply to comment #10)
I think there are actually two issues - one is the SPAN/array descriptor
issue, which causes an ICE if one calls the specific function directly, cf.
PR 42851 for the ICE I get there.
I
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-24 13:16 ---
Works for me with GCC 4.3.4 and 4.4.2. GCC 4.2 is no longer maintained.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bjg at gnu dot org 2010-01-24 13:47 ---
same error occurs with gcc-4.4.3
--
bjg at gnu dot org changed:
What|Removed |Added
CC|
--- Comment #7 from hubicka at ucw dot cz 2010-01-24 13:55 ---
Subject: Re: [4.5 Regression] another GCC 4.5 ICE on C++ templated code
I think it was an accident as this is a P1 bug anyways.
That was accident (i meant to update different PR). I tought I fixed that
already.
Honza
Since revision 155920 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01286.html or
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02004.html ) there are the
following failures on *-apple-darwin*:
FAIL: gcc.dg/darwin-weakimport-1.c scan-assembler-not weak_[a-z \\t]*_b
FAIL:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
--- Comment #2 from danglin at gcc dot gnu dot org 2010-01-24 14:59 ---
The failure also occurs on hppa2.0w-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2010-01-24
15:00 ---
Subject: Re: [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test
Probably related to PR42837.
The failure started before the failure of g++.dg/abi/packed1.C.
Dave
--
--- Comment #1 from mikpe at it dot uu dot se 2010-01-24 16:04 ---
I'm now seeing failures in StackTrace2 and Throw_3 on arm-linux-gnueabi with
gcc-4.3 branch which I didn't use to see. gcc-4.4 branch doesn't fail for me on
these two, but both 4.4 and 4.3 fail (as always) on Throw_2.
On powerpc*-*-* gcc.dg/tree-ssa/pr42585.c fails with:
FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized struct _fat_ptr
_ans 0
FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized struct _fat_ptr
_T2 0
(see http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02116.html or
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-24 16:58 ---
It's a new test. Probably MOVE_RATIO is not defined for your target and thus
the default of 2 applies.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42855
--- Comment #5 from pault at gcc dot gnu dot org 2010-01-24 17:00 ---
Subject: Bug 41167
Author: pault
Date: Sun Jan 24 16:59:51 2010
New Revision: 156197
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156197
Log:
2010-01-24 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #11 from pault at gcc dot gnu dot org 2010-01-24 17:00 ---
Subject: Bug 41044
Author: pault
Date: Sun Jan 24 16:59:51 2010
New Revision: 156197
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156197
Log:
2010-01-24 Paul Thomas pa...@gcc.gnu.org
PR
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/
/mnt/
gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr41555.c -O0 -std=c99 -lm -o
./p
r41555.exe(timeout = 300)
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr41555.c:4:20: error: stdint.h:
N
o such file or directory
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-24 18:42
---
Richard, I'm sorry, I realize now that I'm confused about an important point:
does your analysis of function::swap mean that we are *already* miscompiling
it? Or, are we going to commit patches which will lead
When ignoring the number of bytes available in a streambuf using
std::istream::ignore, ignore calls underflow. This should not happen. I feel
the easiest way to reproduce it is to look at strace output when ignoring bytes
from ifstream:
#include iostream
#include fstream
int main(int argc, char*
--- Comment #3 from rguenther at suse dot de 2010-01-24 20:50 ---
Subject: Re: Revisit std::function for aliasing
issues
On Sun, 24 Jan 2010, paolo dot carlini at oracle dot com wrote:
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-24 18:42
---
Richard,
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-24 21:20 ---
Needs /* { dg-require-effective-target stdint_types } */
HJ, you backported this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-24 21:22 ---
Blocks improvement/regression fix for PR42617 (has patches attached to
reproduce
this bug).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
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
Between svn rev. 156083 and 156198 the following ICE started to
occur with the attached testcase:
f951: internal compiler error: Segmentation fault
Running gdb on the testcase:
(gdb) run gfcbug102.f90
Starting program: /opt/gfortran/4.5/libexec/gcc/i686-pc-linux-gnu/4.5.0/f951
gfcbug102.f90
--- Comment #1 from anlauf at gmx dot de 2010-01-24 22:36 ---
Created an attachment (id=19697)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19697action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42858
--- Comment #2 from dominiq at lps dot ens dot fr 2010-01-24 23:15 ---
Confirmed. I think this is due to revision 156195. I also see the same ICE for
the test in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42418#c1 (with the
comments removed). For both cases the backtrace is:
(gdb) run
--- Comment #13 from dominiq at lps dot ens dot fr 2010-01-24 23:31 ---
I think the patch in comment #11 caused pr42858. Also the tests in comment #1
and #4 give a segmentation fault:
(gdb) run pr39304_1.f90
The program being debugged has been started already.
Start it from the
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: ./configure --prefix=/usr --disable-win32-registry
--enable-threads=posix --enable-languages=c,c++,java
--with-win32-nlsapi=unicode --enable-tls
--- Comment #1 from jojelino at gmail dot com 2010-01-25 00:11 ---
Created an attachment (id=19698)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19698action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
--- Comment #2 from jojelino at gmail dot com 2010-01-25 00:23 ---
Created an attachment (id=19699)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19699action=view)
testcase
other testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-01-25 01:18
---
This appears to fix this: regression tested on x86-64
Index: array.c
===
--- array.c (revision 156201)
+++ array.c (working copy)
@@
--- Comment #2 from hjl dot tools at gmail dot com 2010-01-25 03:11 ---
Created an attachment (id=19700)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19700action=view)
A patch
Please test this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42856
I've just upgraded to 4.4.3 and tried a fresh build of mesa's git/master. I
get an ICE as:
/usr/bin/gcc -I../../include -march=native -msse2 -mfpmath=sse -O3 -ffast-math
-funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine
-floop-block -Wall -Wmissing-prototypes -std=c99
--- Comment #5 from mmitchel at gcc dot gnu dot org 2010-01-25 03:14
---
Subject: Bug 42748
Author: mmitchel
Date: Mon Jan 25 03:14:25 2010
New Revision: 156202
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156202
Log:
PR c++/42748
* config/arm/arm.c
--- Comment #1 from ronis at ronispc dot chem dot mcgill dot ca 2010-01-25
03:15 ---
Created an attachment (id=19701)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19701action=view)
Preprocessed source file causing the ICE
This is the first source file that triggers the ICE;
--- Comment #6 from mmitchel at gcc dot gnu dot org 2010-01-25 03:16
---
Fixed.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |middle-end
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2010-01-25 06:58
---
Jakub, what to do with this PR? It is still marked blocker although it seems
to have blocked nothing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-01-25 07:35
---
3.x isn't supported anymore.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Priority|P1 |P3
--- Comment #12 from pault at gcc dot gnu dot org 2010-01-25 07:53 ---
I just posted the patch for this, so could take it with some advantage. Will
correct 4.4 in a few days.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from frank dot braun at rz dot uni-regensburg dot de
2010-01-25 07:57 ---
Today I am not able to reproduce the error. The compiler is working. Where
exactly does the file m.mod reside? In the user directory or in a compiler
directory?
Frank Braun
(In reply to comment
55 matches
Mail list logo
