) but no
responses there. Could anybody take a look at this? This problem appears
in 4.8.0 version and still observed in latest gcc sources (4.9.0
20130610 (experimental))
--
Aleksandr Platonov
I have a set of the required libraries built and installed into
separate directories, so when gcc is configured with:
../configure --prefix=/opt/tools/gcc-4.8.1
--with-gmp=/opt/tools/gmp-5.1.2 --with-mpfr=/opt/tools/mpfr-3.2.1
--with-mpc=/opt/tools/mfr=/opt/tools/mpfr-3.2.1
On 10 June 2013 16:59, Piotr Wyderski wrote:
I have a set of the required libraries built and installed into
separate directories, so when gcc is configured with:
../configure --prefix=/opt/tools/gcc-4.8.1
--with-gmp=/opt/tools/gmp-5.1.2 --with-mpfr=/opt/tools/mpfr-3.2.1
I've just noticed this mail was sent to the gcc@ list, which is for
development of GCC itself. For help using and installing GCC please
use the gcc-help@ list instead, see http://gcc.gnu.org/lists.html
Should lower-subreg be disabled for IBM long double TFmode?
On powerpc64-linux, this testcase
long double ld_abs (long double x)
{
return __builtin_fabsl (x);
}
compiled with -m64 -O2 -S generates the horrible code shown on the
left. The code on the right is ideal, as generated by gcc-4.2.
si te gusta la fortuna de san carlos.
dale me gusta a nuestro sitio en fb
https://www.facebook.com/fortunacostarica?ref=tn_tnmn
https://www.facebook.com/fortunacostarica?ref=nf
La Fortuna Costa Rica https://www.facebook.com/fortunacostarica
aqui estaremos publicando las mejores ofertas, tal
si te gusta la fortuna de san carlos.
dale me gusta a nuestro sitio en fb
https://www.facebook.com/fortunacostarica?ref=tn_tnmn
https://www.facebook.com/fortunacostarica?ref=nf
La Fortuna Costa Rica https://www.facebook.com/fortunacostarica
aqui estaremos publicando las mejores ofertas, tal
On Mon, Jun 10, 2013 at 8:26 PM, Alan Modra amo...@gmail.com wrote:
The following patch disables lower-subreg for double double TFmode,
bootstrap and regression tests are OK, but I'm a little unsure whether
this is the right thing to do.
* rs6000.c (TARGET_INIT_LOWER_SUBREG): Define.
On Mon, Jun 10, 2013 at 6:00 PM, David Edelsohn dje@gmail.com wrote:
On Mon, Jun 10, 2013 at 8:26 PM, Alan Modra amo...@gmail.com wrote:
The following patch disables lower-subreg for double double TFmode,
bootstrap and regression tests are OK, but I'm a little unsure whether
this is the
On Mon, Jun 10, 2013 at 06:31:55PM -0700, Andrew Pinski wrote:
On Mon, Jun 10, 2013 at 6:00 PM, David Edelsohn dje@gmail.com wrote:
On Mon, Jun 10, 2013 at 8:26 PM, Alan Modra amo...@gmail.com wrote:
The following patch disables lower-subreg for double double TFmode,
bootstrap and
In the architecture that I am using, there is a big pipeline penalty for
read after write to the same memory location. Is it possible to tell the
difference between a possible memory conflict and a definite memory
conflict?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53964
Anton Shterenlikht mexas at bristol dot ac.uk changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308
Anton Shterenlikht mexas at bristol dot ac.uk changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57482
--- Comment #3 from Christophe christophe.beausoleil at sogeti dot com ---
2) -f[no-]short-enums is not an optimization option;
Hum, I do not really agree although it is strongly related to ABI, no doubt.
Anyway, it is a very special option as I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038
--- Comment #6 from Kai Koehne kai.koehne at digia dot com ---
The issue is still there with 4.8.1 . It understand that the discussion on Kai
Tietz' original patch has stalled ... Any suggestion on how we can move this
forward?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57571
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57567
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57559
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57558
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Blocks||53947
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41725
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
Do we have DR # for this issue?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57390
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Target||avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57501
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Target|attiny24a |avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56987
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Target||avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57576
Bug ID: 57576
Summary: Using declaration hides template for purposes of
explicit instantiation
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Keywords:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57576
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57575
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57482
--- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Christophe from comment #3)
Reading target.def is really instructive, but I still do not understand
(yet) how the optimizations list is built, and how options are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524
--- Comment #10 from James Michael DuPont JamesMikeDuPont at googlemail dot
com ---
I have reported the problem in the code to boost, they have fixed it.
https://svn.boost.org/trac/boost/ticket/8651#comment:1
The problem is having to do with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57577
Bug ID: 57577
Summary: internal compiler error: tree check: expected class
'expression', have 'constant' (integer_cst) in
tree_operand_check, at tree.h:4123
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57577
--- Comment #1 from Anna anna.m.tikhonova at gmail dot com ---
Also, when I change A[:] = foo (B[:][:]); to A[0] = foo (B[:][:]);
compilation hangs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541
--- Comment #5 from Anna anna.m.tikhonova at gmail dot com ---
(In reply to Balaji V. Iyer from comment #4)
Hello,
This issue should be fixed in trunk revision 199837. Please let me know
otherwise.
Thanks,
Balaji V. Iyer.
Hi Balaji,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541
--- Comment #6 from Anna anna.m.tikhonova at gmail dot com ---
Created attachment 30285
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30285action=edit
Another test case reproducing the original thing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541
--- Comment #7 from Anna anna.m.tikhonova at gmail dot com ---
(In reply to Anna from comment #6)
Created attachment 30285 [details]
Another test case reproducing the original thing
And another issue in slightly changed test case from this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541
--- Comment #8 from Anna anna.m.tikhonova at gmail dot com ---
Thing from Comment 1 is still reproducible with this case:
int A[10];
int main () {
int a;
a = __sec_reduce_add (1);
}
$ gcc -fcilkplus 1.c
1.c: In function 'main':
1.c:5:5:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541
--- Comment #9 from Anna anna.m.tikhonova at gmail dot com ---
Issue that is very alike to issue mentioned in Comment 7:
int A[10];
int main () {
int a;
a = __sec_reduce (1);
}
$ gcc -fcilkplus 1.c
1.c: In function 'main':
1.c:6:1: internal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57569
--- Comment #2 from Michael Matz matz at gcc dot gnu.org ---
My guess is that it's again somewhere using the wrong predicate
to test directed rw/wr/ww dependencies.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54207
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||ai.azuma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52371
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52440
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
Fixed in 4.7.3. I'm adding the testcase and closing the bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Assignee|hubicka at gcc dot gnu.org |jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41725
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41725
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52440
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57578
Bug ID: 57578
Summary: SPE detection broken on Linux (bits/predefs.h: No such
file or directory)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47680
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Per comment #3, this PR should probably be closed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48939
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49397
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50539
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47680
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957
--- Comment #13 from Anthony Falzone prop_design at yahoo dot com ---
My previous post needs a correction. Comparing gfortran O3 to Intel Fortran O3
I see a 60% speed improvement in favor of the Intel Fortran compiler. There is
a 40% improvement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57539
--- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org ---
Created attachment 30286
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30286action=edit
Proposed fix
I'm currently bootstrapping and testing this patch to fix the issue. I'll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48163
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57579
Bug ID: 57579
Summary: Problem with vectorization
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57379
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57575
Anass Lasram anass.lasram at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57580
Bug ID: 57580
Summary: Repeated _Pragma message directives in macro causes
problems
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Assignee|jason at gcc dot gnu.org |unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57579
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|federico.carminati at cern dot ch |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37132
--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org ---
New draft patch: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00534.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57581
Bug ID: 57581
Summary: abi_tag vs. demangler
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57581
--- Comment #1 from Andreas Schwab sch...@linux-m68k.org ---
Try using a newer demangler.
$ ./cxxfilt
_ZNSt3setIiSt4lessIiESaIiEE5eraseB5cxx11ESt23_Rb_tree_const_iteratorIiES5_
std::setint, std::lessint, std::allocatorint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52332
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Hi DJ,
Uses a U constraint. What should that constraint do? Could you post a
patch to add it?
The U constraint was part of a source tree we worked on previously. I have
provided the patch for it below.
I have also set the valloc attribute for the multiplication insns to 'umul'.
Would that be
On 08/06/13 20:41, Vladimir Makarov wrote:
On 13-06-07 11:12 AM, Vladimir Makarov wrote:
On 13-06-07 10:57 AM, Andreas Krebbel wrote:
I've applied the attached patch. This helps me getting a little
further when bootstrapping with lra and --with-arch=zEC12.
2013-06-07 Andreas Krebbel
Hi,
On Thu, Jun 06, 2013 at 08:10:13AM -0700, Dehao Chen wrote:
Hi, Martin,
Yes, your patch can fix my case. Thanks a lot for the fix.
good. However, as usual when I'm trying to do things too quickly, I
made a stupid mistaker and testing has revealed I picked exactly the
wrong branch in the
On Sat, Jun 08, 2013 at 07:48:27PM +0200, Marc Glisse wrote:
+ tt = fold_build2 (EQ_EXPR, boolean_type_node, op1,
+integer_minus_one_node);
Don't we usually try to have both operands of a comparison of the
same type?
Will fix.
+ t = fold_build2 (EQ_EXPR,
On Mon, Jun 10, 2013 at 11:24:16AM +0200, Marek Polacek wrote:
@@ -4070,8 +4077,15 @@ cp_build_binary_op (location_t location,
{
enum tree_code tcode0 = code0, tcode1 = code1;
tree cop1 = fold_non_dependent_expr_sfinae (op1, tf_none);
+cop1 = maybe_constant_value (cop1);
On Mon, Jun 10, 2013 at 11:32:22AM +0200, Jakub Jelinek wrote:
On Mon, Jun 10, 2013 at 11:24:16AM +0200, Marek Polacek wrote:
@@ -4070,8 +4077,15 @@ cp_build_binary_op (location_t location,
{
enum tree_code tcode0 = code0, tcode1 = code1;
tree cop1 =
Hi!
This patch mentions support of Silvermont architecture in the
gcc-4.9/changes.html page.
OK to install?
Thanks,
Igor
Index: htdocs/gcc-4.9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving
On 06/07/2013 10:43 PM, Richard Henderson wrote:
But these I think require a good hard look to see if they really intended an
ABI alignment:
c6x comment explicitly mentions abi
The ABI specifies a minimum alignment for arrays.
Bernd
Hi all,
This patch makes the changes to the various floating point patterns in
vfp.md. Since pretty much all floating point instruction are always
encoded in 32 bits, they cannot be used inside an IT block by the
-mrestrict-it rules. Therefore this patch just goes and disables the
predicable
On Mon, Jun 10, 2013 at 12:51:05PM +0200, Bernd Schmidt wrote:
On 06/07/2013 10:43 PM, Richard Henderson wrote:
But these I think require a good hard look to see if they really intended an
ABI alignment:
c6x comment explicitly mentions abi
The ABI specifies a minimum alignment for
On 06/10/2013 12:55 PM, Jakub Jelinek wrote:
On Mon, Jun 10, 2013 at 12:51:05PM +0200, Bernd Schmidt wrote:
On 06/07/2013 10:43 PM, Richard Henderson wrote:
But these I think require a good hard look to see if they really intended an
ABI alignment:
c6x comment explicitly mentions abi
The
Igor Zamyatin wrote:
+ li GCC now supports new Intel microarchitecture named Silvermont
+ through code-march=slm/code.
Not related to the release notes, but I think it should also be added to
gcc/doc/invoke.texi's @item -march=@var{cpu-type} - presumably after
the item:
@item
Richard Henderson wrote:
s390 comment mentions LARL instruction
On s390(x) it is indeed an ABI requirement that all global symbols
are at least 2-aligned. (Note that we skip that alignment requirement
if a symbol is marked as attribute((aligned(1)), but that attribute
must then be present for
This fixes one very annoying thing collect2 does when trying to
debug LTO WPA issues. Even with -v you need to wait until all
LTRANS stages completed to see the lto1 -fwpa invocation which
is because collect2 buffers and replays stdout/stderr of ld
(to avoid duplicating that in some cases). But
Hi!
Following patch documents Intel Silvermont support.
OK to install?
Thanks,
Igor
Changelog:
2013-06-10 Igor Zamyatin igor.zamya...@intel.com
* doc/invoke.texi: Document slm.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b7b32f7..e4f1d45 100644
---
On Mon, Jun 10, 2013 at 3:25 PM, Igor Zamyatin izamya...@gmail.com wrote:
Following patch documents Intel Silvermont support.
OK to install?
Thanks,
Igor
Changelog:
2013-06-10 Igor Zamyatin igor.zamya...@intel.com
* doc/invoke.texi: Document slm.
diff --git
On Mon, Jun 10, 2013 at 05:25:36PM +0400, Igor Zamyatin wrote:
Following patch documents Intel Silvermont support.
OK to install?
2013-06-10 Igor Zamyatin igor.zamya...@intel.com
* doc/invoke.texi: Document slm.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index
On Thu, May 23, 2013 at 7:20 PM, Richard Henderson r...@redhat.com wrote:
On 05/23/2013 12:38 AM, Uros Bizjak wrote:
2013-05-23 Uros Bizjak ubiz...@gmail.com
* config/alpha/alpha.md (unspec): Add UNSPEC_XFLT_COMPARE.
* config/alpha/alpha.c (alpha_emit_xfloating_compare): Construct
On Sat, 8 Jun 2013, Marek Polacek wrote:
+ if (code == LSHIFT_EXPR
+ !TYPE_UNSIGNED (TREE_TYPE (op0))
+ (flag_isoc99 || flag_isoc11))
flag_isoc11 implies flag_isoc99, you only need to check flag_isoc99 here.
--
Joseph S. Myers
jos...@codesourcery.com
On Sun, 9 Jun 2013, Iyer, Balaji V wrote:
Attached, please find a patch that will fix the bug reported in PR
57563. There are a couple issues that went wrong. First, in the test
case, we have a double multiplied to a double. When -std=c99 flag is
used, they get converted to long
On Mon, 10 Jun 2013, Richard Biener wrote:
This fixes one very annoying thing collect2 does when trying to
debug LTO WPA issues. Even with -v you need to wait until all
LTRANS stages completed to see the lto1 -fwpa invocation which
is because collect2 buffers and replays stdout/stderr of ld
On 2013-06-09 20:34 , Gabriel Dos Reis wrote:
So, my advice is for GCC source code to forget about the cxxx
headers for the most part. I can see an instance where cmath or cstring
would make a difference but given point (1) above, no it doesn't.
Just use the traditional xxx.h headers and be
On 06/07/2013 02:14 PM, Jakub Jelinek wrote:
When the linker merges common blocks, it chooses both maximum size and
maximum
alignment. Thus for any common block for which we can prove the block must
reside in the module (any executable, or hidden common in shared object),
we
can go
-Original Message-
From: Joseph Myers [mailto:jos...@codesourcery.com]
Sent: Monday, June 10, 2013 10:40 AM
To: Iyer, Balaji V
Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek; mpola...@gcc.gnu.org
Subject: Re: [PATCH] Fix for PR c/57563
On Sun, 9 Jun 2013, Iyer, Balaji V wrote:
On Mon, 10 Jun 2013, Iyer, Balaji V wrote:
You don't say what the actual error was, and neither does the original PR.
But if it was an ICE from an EXCESS_PRECISION_EXPR getting to the
gimplifier,
that suggests that c_fully_fold isn't getting called somewhere it should be
- and
On 07/06/13 17:50, Cesar Philippidis wrote:
On 6/6/13 9:00 AM, Richard Earnshaw wrote:
The pipeline offset is 4 for Thumb2 as well. So at the very least you
need to explain why your change doesn't apply then as well.
Yes some context is lost in that comment. Thunks are usually emitted in
Mike,
This patch is okay, but something seems really broken with respect to
TImode. I don't know if we have to separate TImode from V1TImode or
some distinction for atomics from other uses of TImode. This isn't
like float modes where they mostly live in FPRs and only occassionally
need to live
On Mon, Jun 10, 2013 at 07:51:54AM -0700, Richard Henderson wrote:
On 06/07/2013 02:14 PM, Jakub Jelinek wrote:
When the linker merges common blocks, it chooses both maximum size and
maximum
alignment. Thus for any common block for which we can prove the block
must
reside in the
On 6/10/13 8:32 AM, Richard Earnshaw wrote:
On 07/06/13 17:50, Cesar Philippidis wrote:
On 6/6/13 9:00 AM, Richard Earnshaw wrote:
The pipeline offset is 4 for Thumb2 as well. So at the very least you
need to explain why your change doesn't apply then as well.
Yes some context is lost in
Steven,
The assert has been in ToT for over a week now and I haven't seen any problems
reported.
Is it time to move on to the next step?
Steve Ellcey
sell...@mips.com
From: Steven Bosscher [stevenb@gmail.com]
Sent: Wednesday, May 29, 2013 3:15 PM
Hi,
committed to mainline.
Thanks,
Paolo.
2013-06-10 Paolo Carlini paolo.carl...@oracle.com
PR c++/52440
* g++.dg/cpp0x/pr52440.C: New.
Index: g++.dg/cpp0x/pr52440.C
===
---
On 06/09/2013 08:34 PM, Gabriel Dos Reis wrote:
I strongly suggest prefering stdlib.h over cstdlib for GCC source code
base.
The problem is that including stdlib.h does not define
_GLIBCXX_CSTDLIB, so if one of the C++ library headers includes
cstdlib the contents are added then, but by that
On 06/09/2013 08:49 PM, Gabriel Dos Reis wrote:
If you put the function in an unnamed namespace
you would expect GCC to treat is as if it was of internal
linkage for many purposes including automatic inlining, but
it doesn't:-( For example, you lose the defined but not used
warning, and the
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Joseph S. Myers
Sent: Monday, June 10, 2013 11:16 AM
To: Iyer, Balaji V
Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek; mpola...@gcc.gnu.org
Subject: RE: [PATCH] Fix for PR
On 05/27/2013 01:13 PM, Eric Botcazou wrote:
I have just created a new branch off the trunk named scalar-storage-order to
host the (experimental) support to specify a reverse storage order (byte/word
order, aka endianness) for scalar components of aggregate types.
I will be maintaining the
On Sat, Jun 8, 2013 at 4:03 PM, David Edelsohn dje@gmail.com wrote:
FYI, gcc/cp has it's own ChangeLog file. Yes, it is confusing that
some directories have their own and others do not.
Fixed now.
Sri.
- David
Am 22.05.2013 11:18, schrieb Paolo Carlini:
On 05/21/2013 10:25 AM, Matthias Klose wrote:
Am 19.05.2013 11:40, schrieb Paolo Carlini:
On 05/19/2013 11:35 AM, Andreas Schwab wrote:
Tests that now fail, but worked before:
Thanks Andreas. Matthias, please revert ASAP, thanks.
you already did
The following patch fixes the remaining problems in the C++ front-end to
bring the pragma simd implementation on equal footing with the C FE.
Herein lie some small changes to the code parsing the initialization
statement in the for loop, as well as the condition. I also separated
out the
1 - 100 of 136 matches
Mail list logo
