When I was looking at some LTO-related test failures last week (see mail
on gcc@), I found that the many punctuation and grammatical errors in
the -flto documentation made this section of the GCC manual hard to
read. I made a pass over it to clean up the worst problems -- since the
changes
These are long long on all supported platforms instead of the
default long on 64-bit, long long on 32-bit that defaults.h
assumes.
2012-01-03 Mark Kettenis kette...@openbsd.org
* config/openbsd-stdint.h (INTMAX_TYPE, UINTMAX_TYPE): New defines.
Index: gcc/config/openbsd-stdint.h
AFAICT, we previously wanted to handle restart safety by adding
abnormal edges to all calls to the TM runtime library (which could in
turn call the libitm longjmp that actually restarts a transaction).
Richard mentioned that we could drop this code (I think he meant this,
and others pieces
On Mon, 2 Jan 2012, Jakub Jelinek wrote:
Hi!
When gimple_ic is changing an indirect call into
if (cond)
direct_call ();
else
(*indirect_call) ()
and the indirect_call is not noreturn, but direct_call is
noreturn, we ICE during checking after profile, because the noreturn
call still
On Mon, 2 Jan 2012, Richard Guenther wrote:
I am testing the following patch to fix PR51730.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
Richard.
2012-01-02 Richard Guenther rguent...@suse.de
PR middle-end/51730
* fold-const.c
Applied to mainline.
2011-10-11 Andreas Krebbel andreas.kreb...@de.ibm.com
* config/s390/s390.md (*cmpmode_ccs): Fix comment mentioning
the instructions emitted by the pattern.
(*TDC_insn_mode): Add comment.
---
gcc/config/s390/s390.md |3 +!!
1 file changed, 1
Hello,
On Mon, Jan 2, 2012 at 3:30 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Ayal Zaks ayal.z...@gmail.com writes:
+ for (i = 0; i ira_pressure_classes_num; i++)
+ {
+ enum reg_class pressure_class;
+
+ pressure_class = ira_pressure_classes[i];
+
+
On Mon, Jan 2, 2012 at 8:00 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Eric Botcazou ebotca...@adacore.com writes:
You are basically (but non-optimally) locally re-implementing
what expr.c:get_object_or_type_alignment does, for the
bare MEM_REF case (you don't consider offsets
On Tue, Jan 3, 2012 at 5:53 AM, Hans-Peter Nilsson
hans-peter.nils...@axis.com wrote:
All cross-builds are still done as C. In C++ you don't need
the missing struct qualifier or the typedef in typedef struct
gfc_expr ... gfc_expr; (the struct declaration suffices) as
there's no separate
On Tue, Jan 3, 2012 at 9:36 AM, Eric Botcazou ebotca...@adacore.com wrote:
AFAICT, we previously wanted to handle restart safety by adding
abnormal edges to all calls to the TM runtime library (which could in
turn call the libitm longjmp that actually restarts a transaction).
Richard mentioned
If you have nested structure types that are TYPE_STRUCTURAL_EQUALITY
then they have TYPE_CANONICAL == NULL_TREE and types_compatible_p
will return false (it ICEd in previous releases I believe) and thus you
won't stop attaching COMPONENT_REFs.
So the fix isn't complete.
OK, I see. Then the
On Tue, Jan 3, 2012 at 11:16 AM, Eric Botcazou ebotca...@adacore.com wrote:
If you have nested structure types that are TYPE_STRUCTURAL_EQUALITY
then they have TYPE_CANONICAL == NULL_TREE and types_compatible_p
will return false (it ICEd in previous releases I believe) and thus you
won't stop
On Tue, 2012-01-03 at 09:36 +0100, Eric Botcazou wrote:
AFAICT, we previously wanted to handle restart safety by adding
abnormal edges to all calls to the TM runtime library (which could in
turn call the libitm longjmp that actually restarts a transaction).
Richard mentioned that we could
This fixes another piece of PR51070 -
stmt_has_scalar_dependences_outside_loop was not handling calls.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-01-03 Richard Guenther rguent...@suse.de
PR tree-optimization/51070
* tree-loop-distribution.c
This fixes PR51692, we shouldn't remove the lhs of allocation
calls before the special malloc/free pair removal code kicks in.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-01-03 Richard Guenther rguent...@suse.de
PR tree-optimization/51692
*
On Tue, 2012-01-03 at 10:41 +0100, Richard Guenther wrote:
On Tue, Jan 3, 2012 at 9:36 AM, Eric Botcazou ebotca...@adacore.com wrote:
AFAICT, we previously wanted to handle restart safety by adding
abnormal edges to all calls to the TM runtime library (which could in
turn call the libitm
On Mon, Jan 2, 2012 at 9:31 PM, Richard Henderson r...@redhat.com wrote:
On 01/03/2012 06:47 AM, Uros Bizjak wrote:
if (d-testing_p)
return true;
+ hi = shift nelt ? d-op1 : d-op0;
+ lo = shift nelt ? d-op0 : d-op1;
+
+ shift %= nelt;
This bit only works for little-endian.
Hi,
As described in PR 51269, the vectorizer adjusts number of prologue loop
iterations according to cost model, but never uses the result. This happens
because the result is not returned from the function that computes it, and
is, therefore, ignored.
Bootstrapped and tested on
Sorry for the late notice, but this regressed memcpy-1.c for n32 and n64
on mips64-linux-gnu. I realise memcpy-1.c isn't viewed as being a proper
SRA test, but in this case I think it really is showing a genuine problem.
We have:
struct a {int a,b,c;} a;
int test(struct a a)
{
On Mon, 2 Jan 2012, Jason Merrill wrote:
On 01/02/2012 10:49 AM, Richard Guenther wrote:
For the idea creating the DIE at the point we process the limbo DIE
yes. But would you consider doing that unconditional or only for LTO?
Unconditional. Anything that already passed the assert
Shouldn't we go back and unconditionally return false if lhs and (or?) rhs
are BLKmode? I suppose they are, in this case. Or should we truncate
the alignment from get_object_alignment to TYPE_ALIGN if it is bigger
than that to avoid this situation?
Sorry, I didn't read your message before
Eric Botcazou ebotca...@adacore.com writes:
Sorry for the late notice, but this regressed memcpy-1.c for n32 and n64
on mips64-linux-gnu. I realise memcpy-1.c isn't viewed as being a proper
SRA test, but in this case I think it really is showing a genuine problem.
We have:
struct a {int
On Tue, Jan 3, 2012 at 12:26 PM, Eric Botcazou ebotca...@adacore.com wrote:
Shouldn't we go back and unconditionally return false if lhs and (or?) rhs
are BLKmode? I suppose they are, in this case. Or should we truncate
the alignment from get_object_alignment to TYPE_ALIGN if it is bigger
# of unexpected failures14
# of unresolved testcases 2
# of unsupported tests 224
/home/uros/gcc-build/gcc/xgcc version 4.7.0 20120103 (experimental)
[trunk revision 182829] (GCC)
Uros.
On Jan 2, 2012, at 13:45 , Richard Guenther wrote:
Ok.
Thanks Richard.
Hi!
Referring to malloced strings from GC hashtable macinfo_table entries
and then freeing them at the end of compilation process is problematic
with PCH, because without PCH the strings are malloced, but with PCH
ggc allocated after restore and thus free on them is invalid.
Fixed by making the
On Tue, Jan 3, 2012 at 2:25 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
Referring to malloced strings from GC hashtable macinfo_table entries
and then freeing them at the end of compilation process is problematic
with PCH, because without PCH the strings are malloced, but with PCH
ggc
Hi,
in this issue, filed by Martin Sebor and confirmed at the time by the
EDG people (indeed ICC accepts the testcase), we reject an array as
source v of a dynamic_cast, because we don't decay it to pointer, as we
should when T is a pointer type, per 5, p8 in C++03 about an lvalue
expression
The fix for PR49651 was too conservative as I noticed when trying
to backport it to the 4.5 branch. The following adjusts it to
preserve the optimization cases we have in the tree-ssa testsuite.
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Richard.
2012-01-03 Richard Guenther
On 12/23/11 03:31, Richard Guenther wrote:
On Thu, Dec 22, 2011 at 8:47 PM, Aldy Hernandezal...@redhat.com wrote:
The problem here is that with -fnon-call-exceptions, a memory dereference
may trap, but when we instrument the store, we have lost the landing pad
information.
One solution would
OK.
Jason
On 01/03/2012 08:25 AM, Jakub Jelinek wrote:
Hi!
Referring to malloced strings from GC hashtable macinfo_table entries
and then freeing them at the end of compilation process is problematic
with PCH, because without PCH the strings are malloced, but with PCH
ggc allocated after restore and thus
On Tue, Jan 03, 2012 at 10:22:05AM -0500, Patrick Marlier wrote:
@@ -20909,7 +20905,6 @@ output_macinfo (void)
if (!VEC_empty (macinfo_entry, files))
{
macinfo_entry *file = VEC_last (macinfo_entry, files);
- free (CONST_CAST (char *, file-info));
Hello world,
the attached patch fixes the PR by unconditionally disabling warnings
about unused variables in common blocks.
The reasons are outlined in the PR; there is quite a lot of unnecessary
clutter caused by common blocks in module interfaces.
Regression-tested. OK for trunk?
When compiling with a compiler that is conformant to the c++11 spec for PR
c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
Backported from revision 180159. The rest of the revision includes new
functionality, so only this part should be applied to 4.6. This has been
Fixing a typo when Cc'ing Matthias Klose.
---
When compiling with a compiler that is conformant to the c++11 spec for PR
c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
Backported from revision 180159. The rest of the revision includes new
functionality, so only
On 01/03/2012 01:18 AM, Eric Botcazou wrote:
When I was looking at some LTO-related test failures last week (see mail
on gcc@), I found that the many punctuation and grammatical errors in
the -flto documentation made this section of the GCC manual hard to
read. I made a pass over it to clean up
On 3 January 2012 16:23, Chase Douglas wrote:
When compiling with a compiler that is conformant to the c++11 spec for PR
c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
This has already been fixed in GCC 4.7, see PR 50500
PR 51699 is another example of Clang
On 3 January 2012 16:59, Jonathan Wakely wrote:
On 3 January 2012 16:23, Chase Douglas wrote:
When compiling with a compiler that is conformant to the c++11 spec for PR
c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
This has already been fixed in GCC 4.7, see PR
For the following testcase, we display indirect calls as memory
addresses, which can confuse the user:
struct list {
void (*compare)();
} *listPtr;
static void (*compare)();
__attribute__((transaction_safe))
static void func () {
listPtr-compare();
/* ^^ */
/*
On 01/03/2012 12:01 PM, Jonathan Wakely wrote:
On 3 January 2012 16:59, Jonathan Wakely wrote:
On 3 January 2012 16:23, Chase Douglas wrote:
When compiling with a compiler that is conformant to the c++11
spec for PR c++/50500, std::shared_ptr must have an explicitly
defined copy constructor.
On 01/03/12 11:04, Aldy Hernandez wrote:
For the following testcase, we display indirect calls as memory
addresses, which can confuse the user:
struct list {
void (*compare)();
} *listPtr;
static void (*compare)();
__attribute__((transaction_safe))
static void func () {
listPtr-compare();
/*
On 3 January 2012 17:13, Stephen M. Webb wrote:
On 01/03/2012 12:01 PM, Jonathan Wakely wrote:
On 3 January 2012 16:59, Jonathan Wakely wrote:
On 3 January 2012 16:23, Chase Douglas wrote:
When compiling with a compiler that is conformant to the c++11
spec for PR c++/50500, std::shared_ptr
On 01/03/2012 09:01 AM, Jonathan Wakely wrote:
On 3 January 2012 16:59, Jonathan Wakely wrote:
On 3 January 2012 16:23, Chase Douglas wrote:
When compiling with a compiler that is conformant to the c++11 spec for PR
c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
On 3 January 2012 18:07, Chase Douglas wrote:
I rebuilt the library with this
change to gcc and ran the test suite. All passed normally.
That's what I needed to know, your original mail didn't say anything
about running the test suite.
Looking at the patch again, why have you added destructors
Hi,
so this is what I did earlier today to add the missing bits to the
parser. The work turned out to be very easy, maybe too easy? ;) Is there
something I'm missing? I'm also adding a 'dg-do run' library testcase.
Booted and tested x96_64-linux.
Thanks,
Paolo.
///
/gcc/cp
Hello!
-mieee is needed for this runtime test to avoid
FAIL: gfortran.dg/typebound_operator_8.f03 -O0 execution test
FAIL: gfortran.dg/typebound_operator_8.f03 -Os execution test
on alpha-linux-gnu.
Probably underflow, or something exceptional, gdb is not a friend with
fortran code on this
On 01/03/2012 10:13 AM, Jonathan Wakely wrote:
On 3 January 2012 18:07, Chase Douglas wrote:
I rebuilt the library with this
change to gcc and ran the test suite. All passed normally.
That's what I needed to know, your original mail didn't say anything
about running the test suite.
Hi!
My previous patch apparently wasn't enough. If at add_mem_*
time mem_elt is still its own canonical cselib_val, but only afterwards
new_elt_loc_list adds a new canonical cselib_val to it (and moves
over its locs), then we can still crash in cselib_invalidate_mem.
This patch ensures that
When compiling with a compiler that is conformant to the c++11 spec for PR
c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
Backported from revisions 180159 and 173882. The rest of the revisions include
new functionality, so only this part should be applied to 4.6.
OK.
Jason
On Mon, 2012-01-02 at 19:10 +0100, Torvald Riegel wrote:
- Do we potentially get unnecessary warnings (if vars are live across
a transaction begin)? I didn't get such warnings in the STAMP app
that wasn't working though. Does anyone has suggestions for a test
case?
Attached is a test
On 01/04/2012 04:18 AM, Aldy Hernandez wrote:
PR middle-end/51696
* trans-mem.c (diagnose_tm_1): Display indirect calls with no name
correctly.
Ok.
r~
On 01/04/2012 01:10 AM, Aldy Hernandez wrote:
I can certainly do this. I am however, waiting for the final approval. It
wasn't clear whether that was an approval from Richard Henderson, or whether
I should wait for an official ok.
OK for mainline?
Yes, it was approval.
r~
On 3 January 2012 19:17, Chase Douglas wrote:
PR c++/50500
* include/bits/shared_ptr.h: Add lazy copy ops even if there's a move
That is the ChangeLog for the front-end part of 50500, isn't it?
Should be something like Default copy ctor and assignment.
Otherwise this is OK to check in,
On 01/03/2012 09:50 PM, Uros Bizjak wrote:
I tried to investigate -mbig-endian a bit, but unfortunately almost
all gcc.dg/torture/vshuf-*.c tests FAIL with -O2 on unpatched gcc.
Tests pass with -O0, though.
Tests without -O don't actually test this code.
And -mbig-endian doesn't get
Attached patch applied.
2012-01-03 François Dumont fdum...@gcc.gnu.org
* include/bits/hashtable_policy.h (_Ebo_helper): Rename to
the more
specific _Hashtable_ebo_helper. Hide this implementation detail
thanks
to private inheritance.
I was about to roll the
On 01/03/2012 12:34 PM, Jonathan Wakely wrote:
On 3 January 2012 19:17, Chase Douglas wrote:
PR c++/50500
* include/bits/shared_ptr.h: Add lazy copy ops even if there's a move
That is the ChangeLog for the front-end part of 50500, isn't it?
Should be something like Default copy ctor and
On 3 January 2012 20:45, Chase Douglas wrote:
On 01/03/2012 12:34 PM, Jonathan Wakely wrote:
On 3 January 2012 19:17, Chase Douglas wrote:
PR c++/50500
* include/bits/shared_ptr.h: Add lazy copy ops even if there's a move
That is the ChangeLog for the front-end part of 50500, isn't it?
On 01/04/2012 06:14 AM, Jakub Jelinek wrote:
PR bootstrap/51725
* cselib.c (new_elt_loc_list): When moving locs from one
cselib_val to its new canonical_cselib_val and the
cselib_val was in first_containing_mem chain, but
the canonical_cselib_val was not, add the
On 01/03/2012 09:36 PM, François Dumont wrote:
I was about to roll the ChangeLog but I saw that there is already a
January entry in it so I keep on adding to the current one.
For the record, it's just that I was in a hurry, there is no plan behind
that.
Paolo.
On 01/03/12 14:01, Richard Henderson wrote:
On 01/04/2012 04:18 AM, Aldy Hernandez wrote:
PR middle-end/51696
* trans-mem.c (diagnose_tm_1): Display indirect calls with no name
correctly.
Ok.
r~
Sorry for the noise, but I forgot to check that we actually have a
On 01/04/2012 08:19 AM, Aldy Hernandez wrote:
PR middle-end/51696
* trans-mem.c (diagnose_tm_1): Display indirect calls with no name
correctly.
Ok.
r~
On Mon, Jan 2, 2012 at 1:06 PM, Jonathan Wakely jwakely@gmail.com wrote:
libgcc/ChangeLog
2012-01-02 Jonathan Wakely jwakely@gmail.com
PR bootstrap/51006
* enable-execute-stack-mprotect.c (getpagesize): Do not define
for NetBSD.
This removes the definition of
I get testsuite failures with this change applied:
FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for errors, line 858)
FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for excess errors)
FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for warnings, line 354)
FAIL:
On 01/03/2012 01:38 PM, Jonathan Wakely wrote:
I get testsuite failures with this change applied:
FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for errors, line 858)
FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for excess errors)
FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test
On 3 January 2012 21:48, Chase Douglas wrote:
On 01/03/2012 01:38 PM, Jonathan Wakely wrote:
I get testsuite failures with this change applied:
FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for errors, line 858)
FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for excess errors)
FAIL:
On 01/03/2012 09:42 PM, Torvald Riegel wrote:
Why does the explicit CFG approach not work exactly? cfun-calls_setjmp is
thought to be quite a big hammer.
I don't know, actually. When I looked at the miscompilation case, all
abnormal edges seemed to be in place.
@rth: Do you have an
Dear Uros,
Thanks for that. It is not a problem that I encountered on either the
32 bit or 64 bit machines that I use but, as you say, an underflow is
the most likely explanation. I guess that without any loss, as far as
the test is concerned, a test that obj%c(i,j) is greater than 1e-5,
say,
69 matches
Mail list logo
