But that's the problem with trying to do the optimisation in this way.
We first simplify a truncation of an SImode addition X. Then we simplify
a zero extension of that truncation. Then we have the opportunity to
realise that the zero extension wasn't necessary after all, so we actually
Eric Botcazou ebotca...@adacore.com writes:
But that's the problem with trying to do the optimisation in this way.
We first simplify a truncation of an SImode addition X. Then we simplify
a zero extension of that truncation. Then we have the opportunity to
realise that the zero extension
Hi,
I have been seeing 3 libstdc++ tests:
FAIL: 17_intro/headers/c++200x/stdc+
+.cc (test for excess errors)
FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for
excess errors)
FAIL: 30_threads/async/async.cc execution test
fail/pass at random on a fast machine. Is this
On 12/07/2013 04:48 PM, H.J. Lu wrote:
Hi,
I have been seeing 3 libstdc++ tests:
FAIL: 17_intro/headers/c++200x/stdc+
+.cc (test for excess errors)
FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for
excess errors)
FAIL: 30_threads/async/async.cc execution test
fail/pass at
On Sat, Dec 07, 2013 at 05:43:12PM +0100, Paolo Carlini wrote:
On 12/07/2013 04:48 PM, H.J. Lu wrote:
I have been seeing 3 libstdc++ tests:
FAIL: 17_intro/headers/c++200x/stdc+
+.cc (test for excess errors)
FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for
excess
On Sat, Dec 7, 2013 at 9:09 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Dec 07, 2013 at 05:43:12PM +0100, Paolo Carlini wrote:
On 12/07/2013 04:48 PM, H.J. Lu wrote:
I have been seeing 3 libstdc++ tests:
FAIL: 17_intro/headers/c++200x/stdc+
+.cc (test for excess errors)
FAIL:
On Sat, Dec 7, 2013 at 9:26 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, Dec 7, 2013 at 9:09 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Dec 07, 2013 at 05:43:12PM +0100, Paolo Carlini wrote:
On 12/07/2013 04:48 PM, H.J. Lu wrote:
I have been seeing 3 libstdc++ tests:
FAIL:
Googling:
gcc undefined reference to `lexer_line'
yields:
http://stackoverflow.com/questions/4262531/trouble-building-gcc-4-6
Please check for it in configure and mention it in the dependency message. :)
Thank you!
On 12/07/13 12:59, Bruce Korb wrote:
Googling:
gcc undefined reference to `lexer_line'
yields:
http://stackoverflow.com/questions/4262531/trouble-building-gcc-4-6
Please check for it in configure and mention it in the dependency message. :)
Thank you!
Oops -- I was too optimistic:
Snapshot gcc-4.7-20131207 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20131207/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
The Got It button has been removed on Warning: Enabling the Script
panel causes a Firefox slow-down due to a platform bug. This will be
fixed with the next major Firefox and Firebug versions. It appears
when Firebug has a warning.
The Launchpad account seotaewong40 has been suspended with request
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #25 from Kostya Serebryany kcc at gcc dot gnu.org ---
https://bugzilla.kernel.org/show_bug.cgi?id=66721
Good! Looking forward for a fix and hoping to have it in the next Ubuntu LTS.
Any chance?
Is there anything else we could do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52898
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
Kaz, I'd like to deprecate the mcbranchdi and mcmpeqdi options in 4.9 and make
the current default values fixed as follows:
mcbranchdi is usually enabled (it gets disabled in some SH5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #7 from rguenther at suse dot de rguenther at suse dot de ---
hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52898
--- Comment #8 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
I'm OK with it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18649
--- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org ---
For mingw-code this bug is fixed. It was caused by a bug in SjLj catch-reason.
Issue is fixed for 32-bit and 64-bit mingw targets for all open branches.
As report was for different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to rguent...@suse.de from comment #7)
hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #3 from H.J.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19970
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #26 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #25)
https://bugzilla.kernel.org/show_bug.cgi?id=66721
Good! Looking forward for a fix and hoping to have it in the next Ubuntu LTS.
Any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56686
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #2 from janus at gcc dot gnu.org ---
This draft patch fixes the error (but has not been regtested yet):
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59416
Bug ID: 59416
Summary: A nested template reusing the template arguments of
the enclosing type in a template template argument not
working
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
With the patch the reduced test case in comment 1 compiles cleanly, but the
full code in comment 0 then gives an ICE on a different location:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #4 from janus at gcc dot gnu.org ---
Btw, when using the second (commented-out) version of 'AddArray' (which
apparently crashes with ifort), the full code in comment 0 compiles cleanly
with gfortran trunk plus the patch in comment 2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #5 from Antony Lewis antony at cosmologist dot info ---
Thanks for the quick fix!
The sourced allocate errors crop up in various places in the full code, and
already seem to be known in several bug reports, e.g.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to Antony Lewis from comment #5)
The sourced allocate errors crop up in various places in the full code, and
already seem to be known in several bug reports, e.g.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Hi !
I'm using GCC 4.9 20131207.
$ cat deter.c
int a, b, d;
short c;
void f(void)
{
if(b)
{
int *e;
if(d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417
Markus Trippelsdorf octoploid at yandex dot com changed:
What|Removed |Added
CC||jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The issue of comment 3 appeared between revisions 187190 (2012-05-05) and
187198 (actually 187193 and I'ld bet for 187192).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #8 from janus at gcc dot gnu.org ---
The patch in comment 2 regtests cleanly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59011
--- Comment #7 from Mikael Pettersson mikpelinux at gmail dot com ---
It appears the test case wasn't added to 4.8 branch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59011
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Sat Dec 7 15:43:05 2013
New Revision: 205783
URL: http://gcc.gnu.org/viewcvs?rev=205783root=gccview=rev
Log:
PR middle-end/59011
* gimplify.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58864
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Sat Dec 7 15:43:48 2013
New Revision: 205784
URL: http://gcc.gnu.org/viewcvs?rev=205784root=gccview=rev
Log:
PR target/58864
* optabs.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #9 from rguenther at suse dot de rguenther at suse dot de ---
hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com ---
(In
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to rguent...@suse.de from comment #9)
Is that ever possible to have latch execution count 0
and FIRST_NITERS == 0? It happens in x32 253.perlbmk.
That should be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com ---
latch execution count can be an expression like if (b) in
gcc.dg/torture/pr59058.c. Will such an expression be possible
negative at run-time?
-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-shared
--disable-libmudflap --disable-libssp --enable-checking
Thread model: posix
gcc version 4.9.0 20131207 (experimental) [trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #12 from H.J. Lu hjl.tools at gmail dot com ---
This function:
SV *
sv_mortalcopy(SV *oldstr)
{
dTHR;
register SV *sv;
new_SV(sv);
SvANY(sv) = 0;
SvREFCNT(sv) = 1;
SvFLAGS(sv) = 0;
sv_setsv(sv,oldstr);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411
--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
One should check the
Fortran standard for restrictions in the case of C_PTRs (which, strictly
speaking, are no actual pointers in the Fortran sense).
Since
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Severity|blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411
--- Comment #3 from janus at gcc dot gnu.org ---
In F03, I think the relevant quotes are:
R506 initialization is = initialization-expr
or = null-init
7.1.7 Initialization expression
An initialization expression is an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #13 from H.J. Lu hjl.tools at gmail dot com ---
loop in Perl_pp_aassign is miscompiled:
44098a: e8 91 38 05 00 callq 494220 Perl_sv_mortalcopy
44098f: 67 89 03mov%eax,(%ebx)
440992:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #14 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to H.J. Lu from comment #13)
loop in Perl_pp_aassign is miscompiled:
44098a: e8 91 38 05 00 callq 494220 Perl_sv_mortalcopy
44098f: 67 89 03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #10 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Dec 7 19:27:19 2013
New Revision: 205785
URL: http://gcc.gnu.org/viewcvs?rev=205785root=gccview=rev
Log:
2013-12-07 Janus Weil ja...@gcc.gnu.org
PR fortran/59414
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #11 from janus at gcc dot gnu.org ---
r205785 fixes the original error (i.e. comment 1). ToDo: The ICE regression of
comment 3.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419
Bug ID: 59419
Summary: [4.9 Regression] Failing OPEN with FILE='xxx' and
IOSTAT creates the file 'xxx' after revision 196783
Product: gcc
Version: 4.9.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
Bug ID: 59420
Summary: arm: broken code generated (memset from newlib 2.0)
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
--- Comment #1 from Alexander Holler holler at ahsoftware dot de ---
Created attachment 31397
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31397action=edit
memset.s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421
Bug ID: 59421
Summary: stof(), stod() wrong result
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
You'll get more attention paid to this if you can describe why you think the
code generated is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
Do you have a full testcase that is able to compile and work?
s/work/run/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59300
--- Comment #1 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
clang had an even stranger behavior
(http://llvm.org/bugs/show_bug.cgi?id=18174). I fixed that in a way that it now
agrees with gcc on the testcase in this bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419
--- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
I will take this one if you like.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
--- Comment #4 from Alexander Holler holler at ahsoftware dot de ---
Thanks a lot for the very fast solution.
I wasn't aware that gcc does such optimizations and maybe posted the bug too
fast without really having examined the assembler.
Using
Hi!
libssp apparently doesn't build with -Werror=format-security
which is planned to be default for Fedora. While this is a false
positive, msg3 is always one of two string literals, I think it
doesn't hurt to use %s there.
Committed to trunk as obvious.
--- libssp/ChangeLog(revision
On 6/11/2013, at 1:44 pm, Maxim Kuvyrkov ma...@kugelworks.com wrote:
On 19/09/2013, at 8:26 am, Maxim Kuvyrkov ma...@kugelworks.com wrote:
Following recent breakage caused by adding nominal Android support to all
*linux* targets [*] this patch series cleans up libc selection for Linux
Kenneth Zadeck zad...@naturalbridge.com writes:
+/* One could argue that GET_MODE_PRECISION (TYPE_MODE (type))
+ should always be the same as TYPE_PRECISION (type).
+ However, it is not. Since we are converting from tree to
+ rtl, we have to expose this ugly truth here.
On Fri, 6 Dec 2013, H.J. Lu wrote:
http://en.wikipedia.org/wiki/IA
IA-32, Intel Architecture, 32-bit
IA-64, Intel Architecture, 64-bit
And Intel 64 is an implementation of and extension to the 64-bit
extension of IA-32 created by AMD, totally unrelated to IA-64.
Marketing. :-)
Gerald
It's not fully fixing the issue as _all_ aggregates that may be
accessed beyond their declarations size are broken.
Sure, but we don't need to support such nonsense in the general case. And not
every language allows it, for example in Ada you cannot do that of course.
I'd say we should
Kenneth Zadeck zad...@naturalbridge.com writes:
#define WIDE_INT_MAX_ELTS \
- ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \
- / HOST_BITS_PER_WIDE_INT)
+ (((MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \
+/ HOST_BITS_PER_WIDE_INT) + 1)
I think this
I'd certainly be concerned. Ports have (for better or worse) keyed on
BLKmode rather than looking at the underlying types. So if something
which was previously SImode or DImode is now BLKmode, there's a nonzero
chance we're going to change how it gets passed.
Well, we have been saying that
That being said, the concern is certainly valid so we may want to go for a
kludge instead of the fix. The point is that the kludge should do exactly
what the fix would have done in the RTL expander and nothing more; it's out
of question to pessimize all the other languages and all the other
On 12/06/13 19:13, Ralf Corsepius wrote:
Hi,
I intend to the patch below to gcc-trunk and 4.8-branch:
It's a partial sync of the microblaze-rtems* section in gcc/config.gcc with
microblaze*-*-elf's:
Add TARGET_BIG_ENDIAN_DEFAULT-switch for microblaze*-*-rtems*.
Ralf
OK.
--
Michael Eager
Richard,
This patch implements the target hook TARGET_FN_OTHER_HARD_REG_USAGE (posted
here: http://gcc.gnu.org/ml/gcc-patches/2013-03/msg01318.html) for MIPS, to
address the issue that $6 is sometimes used in split calls.
Build and reg-tested on MIPS.
OK for stage1?
Thanks,
- Tom
Hi all,
here is a small patch to fix a problem with class-array-valued
functions, where the rank was not determined properly. Regtestes on
x86_64-unknown-linux-gnu. Ok for trunk?
[Note: This patch only fixes the rejects-valid problem of comment 0/1,
but not the ICE of comment 2/3, which is a
Janus Weil wrote:
here is a small patch to fix a problem with class-array-valued
functions, where the rank was not determined properly. Regtestes on
x86_64-unknown-linux-gnu. Ok for trunk?
[Note: This patch only fixes the rejects-valid problem of comment 0/1,
but not the ICE of comment 2/3,
2013/12/7 Tobias Burnus bur...@net-b.de:
Janus Weil wrote:
here is a small patch to fix a problem with class-array-valued
functions, where the rank was not determined properly. Regtestes on
x86_64-unknown-linux-gnu. Ok for trunk?
[Note: This patch only fixes the rejects-valid problem of
Hi,
noticed this while preparing some testcases for the library (but
probably Daniel pointed it out together with related issues some time
ago): if we don't handle separately identical types modulo
cv-qualifiers, we incorrectly return false for incomplete types.
Tested x86_64-linux.
This patch fixes Ian's issue, and several similar patterns:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00681.html
$ make check
autogen -T ../.././fixincludes/check.tpl ../.././fixincludes/inclhack.def
/bin/sh ./check.sh ../.././fixincludes/tests/base
Fixed: testing.h
[[...]]
Fixed: unistd.h
77 matches
Mail list logo
