Because sizeof(void*) is 4 but POINTER_SIZE is 3, we have to handle
some things manually. This is yet another one. Committed.
* config/msp430/msp430.c (msp430_asm_integer): Support addition
and subtraction too.
Index: config/msp430/msp430.c
On targets with 2 byte int the vectors are 16 values long, which
breaks the index count in __builtin_shuffle() using more than one
input vector. Ok?
* gcc.dg/pr64252.c: Fix assumption about sizeof(int).
2015-06-05 Thomas Koenig tkoe...@gcc.gnu.org
Index: gcc.dg/pr64252.c
Sorry, I meant unsigned int.
Symbols are normally PSImode, and the MSP430 has PSImode registers and
PSImode moves to reg/mem. But sometimes gcc uses an SImode move
instead, if the result will later be used in SImode (as in getP() in
gcc/testsuite/gcc.dg/torture/pr65077.c). Committed.
* config/msp430/msp430.md
This patch updates gthr-tpf.h to the current gthr.h API and TPF API. Ok?
* gthr-tpf.h (__GTHREADS_CXX0X): Define.
(__gthread_t): Define.
(__gthread_cond_t): Define.
(__gthread_time_t): Define.
(__GTHREAD_HAS_COND): Define.
(__GTHREAD_COND_INIT):
Ok. Thanks!
This is the same patch as 09/16. There is only one libiberty master,
controlled by gcc, it is not neccessary to submit separate patches for
each copy of it.
The convention is: Any libiberty patch approved by gcc maintainers is
auto-approved for the other repos.
+/* Fill an lvalue with zero bits. */
+#define CLEAR_VAR(S) \
+ do { memset ((S), 0, sizeof (S)); } while (0)
Hmmm... I don't see the point in this. The macro is almost as long as
a bare memset() would be, and replaces a well-known function with
something unknown outside this project. It
libiberty is not an API to gcc, it is a portability library. If GCC
is exporting a timer, GCC's headers should have the interface in it.
FWIW I'm not in love with the name of the macro, but I find it useful.
In the initial version of patches 10 and 12 (state purging within gas
and ld subdirs) I didn't have this macro, and had about 30 memset
invocations.
Another option is to save the state as it was initialized, and restore
* expmed.c (extract_bit_field_1): Avoid clobbering a
yet-to-be-used base/index register.
OK.
jeff
Thanks! committed.
In config/s390/s390.c we accept addresses that are SImode:
if (!REG_P (base)
|| (GET_MODE (base) != SImode
GET_MODE (base) != Pmode))
return false;
However, there doesn't seem to be anything in the s390's opcodes that
masks the top half of address
A few minor nits...
Your patch includes many whitespace changes, which makes reviewing
your patch more difficult. Please limit whitespace changes when
they're unrelated to the patch.
Assuming you've looked at the actual diffs for them, and see nothing
beyond changes related to your patch, it's
Done. Thanks!
20040625-1 fails on targets with pointers bigger than WORD_SIZE (rl78,
msp430/-mlarge) because the base register is clobbered, partially
rebuilt with the new value, then used as a base for the second part of
the calculation. Ok?
* expmed.c (extract_bit_field_1): Avoid clobbering a
Ping?
http://lists.gnu.org/archive/html/libtool-patches/2012-04/msg3.html
Date: Mon, 30 Apr 2012 18:36:39 -0400
From: DJ Delorie d...@redhat.com
* m4/libtool.m4: Since we know that all TPF builds are cross-
builds, do not attempt to run linker tests during config. Use
known
Copied the way other tests get uint32_t. Ok?
* gcc.c-torture/execute/pr65369.c: Don't assume int is 32 bits.
Index: gcc.c-torture/execute/pr65369.c
===
--- gcc.c-torture/execute/pr65369.c (revision 223737)
+++
If the other c file only includes libiberty.h and does not include the
libiberty/config.h and
In general, such other c files should have their own config.h that
does the same test and has its own HAVE_DECL_ASPRINTF.
That way, the config.h matches the compiler options being used, and
not the
OK to apply ?
Ok but..
+case SECCAT_TBSS:
+ return default_select_section (decl, reloc, align);
+
+default:
+ gcc_unreachable ();
Would it be better to just default: everything to
default_select_section, instead of enumerating everything we know
about today?
What I was confused about is that the first set isn't valid rtl.
The SET_SRC and SET_DEST always have to have the same mode
(or VOIDmode in the case of a CONST_INT, etc., where the mode
is implicitly the same as the SET_DEST). So wouldn't it have
to be:
(set (reg:SI 1)
; This pattern is identical to the truncsipsi2 pattern except
; that it uses a SUBREG instead of a TRUNC. It is needed in
; order to prevent reload from converting (set:SI (SUBREG:PSI (SI)))
; into (SET:PSI (PSI)).
I'm not sure what that's supposed to mean (what's an SI set of a PSI
* mkstemps.c: #include time.h if HAVE_TIME_H is defined
but not HAVE_SYS_TIME_H.
Ok.
OK to apply ?
Ok, but...
- if (regno == FRAME_POINTER_REGNUM frame_pointer_needed)
+ if (regno == FRAME_POINTER_REGNUM
+ (frame_pointer_needed || df_regs_ever_live_p (regno)))
Do we want regs_ever_live or regs_ever_written_to ? I seem to recall
changing a port... mep perhaps...
(1) Sources could not be downloaded automatically. You need browser.
What should distributive build cluster do?
There's nothing magic about downloading the sources, just use any
command-line URL tool (wget, curl, etc):
wget
OK to apply ?
Ok.
gcc/ChangeLog
2015-04-15 Nick Clifton ni...@redhat.com
* config/rl78/rl78-opts.h (enum rl78_mul_types): Add MUL_G14 and
MUL_UNINIT.
(enum rl78_cpu_type): New.
* config/rl78/rl78-virt.md (attr valloc): Add divhi and divsi.
OK to apply ?
Ok!
2015-04-14 Nick Clifton ni...@redhat.com
* config/rl78/rl78.c (rl78_expand_prologue): Mark large stack
decrement instruction as being frame related.
(rl78_print_operand_1): Handle 'p' modifier to add +0 to HL
based addresses.
If
Is this ok for trunk now?
Yes.
Yup, ntp didn't start (and still can't access any servers) so the time
never got set when I rebooted it. I manually set the time and I'm
working on figuring out why ntp won't work.
--
Mailing list: https://launchpad.net/~geda-developers
Post to : geda-developers@lists.launchpad.net
Mis-applied patch, committed.
* config/rl78/rl78.c (rl78_print_operand_1): Move 'p' test to
correct clause.
Index: config/rl78/rl78.c
===
--- config/rl78/rl78.c (revision 221648)
+++ config/rl78/rl78.c (working
Committed.
* config/rl78/rl78-virt.md (andqi3_virt): Allow far operands.
(iorqi3_virt): Likewise.
Index: config/rl78/rl78-virt.md
===
--- config/rl78/rl78-virt.md(revision 221505)
+++ config/rl78/rl78-virt.md
This is a common problem. I guess newlib/cygwin got the oldest set
and, afaik, the GCC toplevel stuff is kind of the master. It would
be nice if we had some automatism in place to keep all former src
repos in sync.
There was never any agreement on who the master was for toplevel
sources -
This is a common problem. I guess newlib/cygwin got the oldest set
and, afaik, the GCC toplevel stuff is kind of the master. It would
be nice if we had some automatism in place to keep all former src
repos in sync.
There was never any agreement on who the master was for toplevel
sources -
Why not? The user surely knows better what a good password is than the
software does. If the user picks a crappy password, there's probably a good
reason.
You have an alarmingly naive understanding of our user base...
(not that *I* want to give up control of my passwords, but I'm not an
The problem appears to be that GCC will create a multiply-plus-add
instruction to access the table regardless of whether the backend
supports such an instruction. I could not work out where in the
middle end this was occurring, so instead I created the patch below
which contains a
OK to apply ?
Ok.
More edge cases regarding far addresses. Committed.
* config/rl78/rl78-real.md (*addqi_real): Allow SADDR types for
inc/dec.
(*addhi3_real): Likewise.
* config/rl78/rl78-virt.md (*incmode3_virt): Additional
pattern to match incrementing memory.
*
SFmode moves were using 8-bit transfers instead of 16-bit. This patch
copies the SImode move pattern, which expands into 16-bit moves.
Since this only affects rl78, and the SImode code is well tested, I'm
applying this now so it will be in gcc 5.
* config/rl78/rl78-protos.h
The branch limits are a bit too far, resulting in reloc errors in rare
cases. Ok?
* config/v850/v850.md (branch_normal): Adjust branch limits.
(branch_invert): Likewise.
(branch_z_normal): Likewise.
(branch_z_invert): Likewise.
(branch_nz_normal):
Just a request, when reporting errors against the assembler, please
give the assembler's version number, not the compiler's version
number:
$ msp430-elf-as --version
GNU assembler (GNU Binutils) 2.25.51.20150212
FWIW I've reproduced this with the FSF assembler reporte above, which
is the
The m32c parts are OK.
Ok.
So here's what I'm trying to do... I want to build gcc, binutils, and
newlib, run tests, and IF the tests pass, THEN install them all.
However, gcc needs an installed newlib to build it's libraries.
I tried installing newlib into $DESTDIR$PREFIX but gcc ignores
$DESTDIR during the compile.
Any
Aren't current Windows file systems case-preserving? Then they
shouldn't have no problems with .C files.
They are case preserving, but not case sensitive. A wildcard search
for *.c will match foo.C and bar.c, and foo.c can be opened as FOO.C.
pins...@gmail.com writes:
No because they are c++ code so capital C is correct.
However, we should avoid relying on case-sensitive file systems
(Windows) and use .cc or .cxx for C++ files (+ is not a valid file
name character on Windows, so we can't use .c++).
I can't say if this fixes a bug important enough for stage4, but if
someone wants to claim that, you won't have to wait for stage 1 :-)
memcpy (*argvp + i, file_argv, file_argc * sizeof (char *));
This code copies all the pointers in file_argv[] into argv[], so if
you freeargv them via file_argv, argv[] will point to free'd memory.
Hence the comment:
/* Free up memory allocated to process the response file. We do
Does the patch look sane?
I don't think anything in the toplevel configury looks sane any
more, but I think this patch is OK.
a later release (4.6 I think). Attempts
to build with 4.4 (i.e. on RHEL 6) causes warnings on most files.
2010-06-21 DJ Delorie d...@redhat.com
* diagnostic.h (diagnostic_classification_change_t): New.
(diagnostic_context): Add history and push/pop list
See $subj. Committed.
* config/rl78/rl78.c (move_elim_pass): Don't optimize away
volatile memory references.
Index: config/rl78/rl78.c
===
--- config/rl78/rl78.c (revision 220150)
+++ config/rl78/rl78.c (working
OK to apply ?
Ok.
OK to apply ?
Ok.
OK for trunk.
OK for 4.9 branch if it's OK with the release manager.
Do you need someone to apply it for you?
Here is a small patch to fix a code-gen problem for the RL78. The bug
was that the register death pass was not looking inside PARALLELs, and
thus missing some USE and SET cases. I considered adding code to scan
all of the elements in the PARALLEL, but the only ones that can be
Thanks. Do I need to hear from someone else approving this, or can I
go ahead and commit?
Go ahead and commit.
Various RL78-specific fixes and tweaks wrt volatiles and addressing
modes. Committed.
* config/rl78/rl78-real.md (addqi3_real): Allow volatiles.
(addhi3_real): Likewise. Fix [HL+0] syntax.
(subqi3_real): Likewise.
(subhi3_real): Likewise.
So if we truly want to address this feature, we should also disallow
non-root user password based ssh logins.
Do I get this right? You want to disallow any remote logins (which
nowadays means using ssh)?
No, he means that ssh connections should require a pre-shared key. My
systems are
Ok, but the converse — if the general_operand is accessed by more
than one instruction, it is not safe — is correct, right?
In general, I'd agree, but the ISO spec talks about sequence points
and there are times when you *can* access a volatile multiple times as
long as the state is correct at
Matt Godbolt m...@godbolt.org writes:
GCC's code generation uses a load; add; store for volatiles, instead
of a single add 1, [metric].
GCC doesn't know if a target's load/add/store patterns are
volatile-safe, so it must avoid them. There are a few targets that have
been audited for
What is involved with the auditing?
Each pattern that (directly or indirectly) uses general_operand,
memory_operand, or nonimmediate_operand needs to be checked to see if
it's volatile-safe. If so, you need to change the predicate to
something that explicitly accepts volatiles.
There's been
One question: do you have an example of a non-volatile-safe machine so
I can get a feel for the problems one might encounter? At best I can
imagine a machine that optimizes add 0, [mem] to avoid the
read/write, but I'm not aware of such an ISA.
For example, the MSP430 backend uses a macro
and developers deserve a better environment.
No, developers deserve the environment they ask for, not what someone
else thinks is better.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
I looked in the documentation and didn’t see this described.
AFAIK it's not documented. Only recently was it agreed (and even
then, reluctantly) that the ISO spec could be met by such opcodes.
To try to generalize from that: it looks like the operating
principle is that an insn that expands into multiple references to a
given operand isn’t volatile-safe, but one where there is only a
single reference is safe?
No, if the expanded list of insns does what the standard says, no
more,
The code that this macro enables will never do anything anyway on
RL78. Applied.
2014-12-15 DJ Delorie d...@redhat.com
* config/rl78/rl78.h: Remove SHORT_IMMEDIATES_SIGN_EXTEND.
Index: config/rl78/rl78.h
===
--- config
Next time, don't be 6 month late if you're going to be flippant.
I, for one, am happy to welcome our new more-reasonable-less-paranoid
overlords. I've been disabling my firewall for ages, as my machines
are behind an enterprise firewall anyway.
--
devel mailing list
I, for one, am happy to welcome our new more-reasonable-less-paranoid
overlords. I've been disabling my firewall for ages, as my machines
are behind an enterprise firewall anyway
that don't apply for a notebook, especially not if the enduser is=20
connected to a public WLAN and if you
So the target audience has shifted from developers to developers who
don't understand ports, don't like user prompts and are behind
enterprise firewalls.
Certainly not. I've never assumed I was an average user. There are
many different reasons why people might want a more open firewall
The best analogy would probably be a condom with a whopping 129024
holes in it.
That's a horrible analogy, and totally inappropriate for this mailing
list. Could we please keep this civil and reasonable?
--
devel mailing list
devel@lists.fedoraproject.org
My memories of why I did MeP the way I did are... vague. I recall it
had to do with getting the attributes to apply to C++ objects
correctly, since C++ objects tend to be complicated and gcc didn't
always pass me what I expected.
think they are suppose to. They build, but I cant test them...
That's also a questionable feature. Such a text box should not send
anything before you confirm it.
Perhaps as part of the firewall installation step, the user could be
given a list of sites that their PC may call home to - including
official repos - and let them opt-in or opt-out
Not every user understands the connection between website does not
work - firewall configuration
True, which means that we have to use words that they *do* understand.
For extra coolness, a per-user firewall and some way of popping up a
query dialog when they violate a firewall rule. We
Fixes newlib/libgcc build problems, many test cases. No regressions.
Applied.
* config/m32c/cond.md (movqicc_code_mode): Remove mode of
conditional.
(movhicc_code_mode): Likewise.
* config/m32c/m32c.c (encode_pattern_1): Specialise PSImode
subregs.
Last time you mentioned this, I asked what the contents of that
config.log were...
Ok. For the branch please wait until after 4.9.2 is out.
4.9.2 being out, I applied this to the branch.
Ok. For the branch please wait until after 4.9.2 is out.
Thanks! Committed to trunk.
, x86 32/64, and arm32.
2014-10-29 DJ Delorie d...@redhat.com
* expmed.c (strict_volatile_bitfield_p): Fix off-by-one error.
2014-10-29 DJ Delorie d...@redhat.com
* gcc.dg/20141029-1.c: New.
Index: expmed.c
Fixed PR/63582. Tested with no regressions on x86-64 and ix86. Ok?
* tree.c (build_common_tree_nodes): Don't even store the
__int128 types if they're not supported.
OK.
Thanks! Committed.
* config/mep/mep.c: Include rtl-iter.h.
(global_reg_mentioned_p_1): Take a const_rtx and return a bool.
(xtensa_tls_referenced_p): Return a bool. Use FOR_EACH_SUBRTX.
OK.
* config/mep/mep.c (mep_store_find_set): Take a const_rtx and
return a bool. Replace void * with specific type. Iterate
over all subrtxes.
(mep_store_data_bypass_1): Update calls accordingly.
OK.
gcc/
* config/mep/mep.c (mep_mul_hilo_bypass_1): Delete.
(mep_mul_hilo_bypass_p): Use FOR_EACH_SUBRTX.
OK.
Fixed PR/63582. Tested with no regressions on x86-64 and ix86. Ok?
* tree.c (build_common_tree_nodes): Don't even store the
__int128 types if they're not supported.
Index: tree.c
===
--- tree.c (revision
Fixes BISX.A bug. Committed.
2014-10-23 DJ Delorie d...@redhat.com
* config/msp430/msp430.c (msp430_print_operand): 'x' modifier is
independend of -mlarge.
* config/msp430/constraints.md (Ys): Update comment.
Index: config/msp430/constraints.md
This is okay.
Thanks! Committed.
With a ChangeLog entry yes.
Thanks! Committed.
In the event that pointer sizes aren't powers of two, choose a more
suitable alignment than (unsigned)(-1), which results in HUGE file
sizes. Ok?
Ok.
Thanks! Committed.
FAIL: g++.dg/init/enum1.C -std=gnu++11 (test for errors, line 12)
FAIL: g++.dg/init/enum1.C -std=gnu++1y (test for errors, line 12)
FAIL: g++.dg/init/enum1.C -std=gnu++98 (test for errors, line 12)
That used to complain about enum1.C:12:1: error: no integral type can
represent all of
As long as you commit to gcc first, or at the same time as other
commits, you'll be fine. If you commit elsewhere first or only, it
may be reverted by a script.
If you could implement the second option, it would be appreciated.
Could you please test this for me? It builds as a powerpc-elf
cross-compiler (at least the host half) but I don't have a power
machine here to test on.
Index: rs6000-c.c
In the event that pointer sizes aren't powers of two, choose a more
suitable alignment than (unsigned)(-1), which results in HUGE file
sizes. Ok?
Index: gcc/lto/lto-object.c
===
--- gcc/lto/lto-object.c(revision 216287)
+++
Since flag-types.h is used in target code, it needs to be -Wall-safe
for targets with 16-bit int. OK?
Index: gcc/flag-types.h
===
--- gcc/flag-types.h(revision 216287)
+++ gcc/flag-types.h(working copy)
@@ -229,17 +229,17
A few more cases where pointers were assumed to be whole bytes.
Ok?
Index: gcc/c-family/c-cppbuiltin.c
===
--- gcc/c-family/c-cppbuiltin.c (revision 216287)
+++ gcc/c-family/c-cppbuiltin.c (working copy)
@@ -668,13 +668,13 @@
I don't see what the stor-layout.c changes have to do with that
description, or why they are correct (they look wrong to me; the
existing addition of BITS_PER_UNIT_LOG + 1 looks logically correct
for bitsizetype).
sooo... the type for bitsizetype will *always* be a bigger type than
sizetype?
The other changes are OK.
Committed those then. Thanks!
extensions. Is this OK? If so, is there anything else, or can I
check the whole mess in yet?
Go ahead.
Thanks! Committed.
../../gcc/gcc/config/rs6000/rs6000-c.c:237:24: error: ‘RID_INT128’ was not
declared in this scope
Two options:
1. If you know the RS6000 will never have any __intN other than
__int128, just use RID_INT_N_0, although this is a hack it will
work as long as there *is* an __int128 for
This is the MSP430-specific use of the new intN framework to enable
true 20-bit pointers. Since I'm one of the MSP430 maintainers, this
patch is being posted for reference, not for approval.
Now that the other parts are committed, I'm checking this one in too.
gcc/config/msp430
*
This is what I ended up with for the test case. It was a bit tricky
since it only works with msp430x (not msp430) and requires the gnu
extensions. Is this OK? If so, is there anything else, or can I
check the whole mess in yet?
// { dg-do compile { target msp430*-*-* } }
// { dg-options
if (same_type_p (TYPE_MAIN_VARIANT (t1), long_long_unsigned_type_node)
|| same_type_p (TYPE_MAIN_VARIANT (t2),
long_long_unsigned_type_node))
return build_type_attribute_variant (long_long_unsigned_type_node,
Otherwise, I don't see what moving the test would accomplish. If
long is never 128 bits, it doesn't matter if the int128 test is
before or after it, and the other intN are never the same size as
standard types,
I don't see how you can assert that these will never happen.
It's checked
Note that there is a separate __int128_t type that isn't part of the
standard extension. Maybe it's there for that type?
Otherwise, I don't see what moving the test would accomplish. If
long is never 128 bits, it doesn't matter if the int128 test is
before or after it, and the other intN are
301 - 400 of 6592 matches
Mail list logo
