These tests check the sched2 dump, so skip them for optimization levels
that do not enable sched2.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/mcpu-6.c: Skip for -O0, -O1, -Og.
* gcc.target/riscv/mcpu-7.c: Likewise.
---
gcc/testsuite/gcc.target/riscv/mcpu-6.c | 1 +
are contributing, and listing
your name in our monthly newsletter?
Thank you for your contribution!
All the best,
Craig Topham
Copyright & Licensing Associate
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652
Email: cra...@fsf.org
GPG key:
The intrinsics that use macros are the ones that require an integer constant
expression for one of the arguments. Clang needs to be able to see the constant
expression as an argument to the underlying builtin. Thus the macro.
Based on my previous x86 experience, gcc may only require a macro for
tience and I appreciate you following through.
~Craig
> On Tue, 2023-02-28 at 15:29 -0500, Craig Topham via RT wrote:
> > On 2023-02-27 10:33:46, boua...@zoho.com wrote:
> > > Hi.
> > > Any update on this?
> > > Regards.
> > >
> >
> &g
Antoni,
You'll want to get an employer disclaimer signed by your employer to
make sure your contributions cannot be claimed by them. Please email
ass...@fsf.org and we can work through the process.
--
All the best,
Craig Topham
Copyright & Licensing Associate
Free Software Foundatio
On Wed, Jul 14, 2021 at 12:45 AM Hongtao Liu via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> > >
> > Set excess_precision_type to FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 to
> > round after each operation could keep semantics right.
> > And I'll document the behavior difference between soft-fp and
> >
On Thu, Jul 1, 2021 at 4:02 PM H.J. Lu via llvm-dev
wrote:
> On Thu, Jul 1, 2021 at 3:40 PM Joseph Myers
> wrote:
> >
> > On Thu, 1 Jul 2021, H.J. Lu wrote:
> >
> > > BTW, _Float16 software emulation may require more than just SSE
> > > since we need to do _Float16 load and store with XMM
for your contribution!
All the best,
Craig Topham
Copyright & Licensing Associate
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652
cc - mainta
best,
Craig Topham
Copyright & Licensing Associate
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652
On 12/05/2020 23:33, Jim Wilson wrote:
> On Mon, Apr 27, 2020 at 10:08 AM Craig Blackmore
> wrote:
>> Thanks for the review. I have updated the following patch with those changes.
> This looks good, and the tree is open for development work again, so I
> committed both parts
On 08/04/2020 17:04, Jim Wilson wrote:
> On Wed, Feb 19, 2020 at 3:40 AM Craig Blackmore
> wrote:
>> On 10/12/2019 18:28, Craig Blackmore wrote:
>> Thank you for your review. I have posted an updated patch below which I think
>> addresses your comments.
>>
>&g
On 10/12/2019 18:28, Craig Blackmore wrote:
>
> Hi Jim,
>
> Thank you for your review. I have posted an updated patch below which I think
> addresses your comments.
>
Ping
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00712.html
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00713.html
Craig
Hi Jim,
On 31/10/2019 00:03, Jim Wilson wrote:
> On Fri, Oct 25, 2019 at 10:40 AM Craig Blackmore
> wrote:
>> The sched2 pass undoes some of the addresses generated by the RISC-V
>> shorten_memrefs code size optimization (patch 1/2) and consequently increases
>> code s
Hi Jim,
Thank you for your review. I have posted an updated patch below which I think
addresses your comments.
On 30/10/2019 23:57, Jim Wilson wrote:
> On Fri, Oct 25, 2019 at 10:40 AM Craig Blackmore
> wrote:
>> This patch aims to allow more load/store instructions to b
This patch aims to allow more load/store instructions to be compressed by
replacing a load/store of 'base register + large offset' with a new load/store
of 'new base + small offset'. If the new base gets stored in a compressed
register, then the new load/store can be compressed. Since there is an
The sched2 pass undoes some of the addresses generated by the RISC-V
shorten_memrefs code size optimization (patch 1/2) and consequently increases
code size. This patch prevents sched-deps.c from changing an address if it is
expected to increase address cost.
Tested on bare metal rv32i, rv32iac,
Hi Kito,
Thank you for taking the time to review my patch. I am posting an updated
patchset taking into account your comments.
On 18/09/2019 11:01, Kito Cheng wrote:
> Hi Craig:
>
> Some general review comment:
> - Split new pass into new file.
> - Add new option to enable/di
This patch aims to allow more load/store instructions to be compressed by
replacing a load/store of 'base register + large offset' with a new load/store
of 'new base + small offset'. If the new base gets stored in a compressed
register, then the new load/store can be compressed. Since there is an
looking forward to hearing from you soon.
Sincerely,
Craig T. Dedo
17130 W. Burleigh Place
P. O. Box 423 Mobile Phone: (414) 412-5869
Brookfield, WI 53008-0423 E-mail: cr...@ctdedo.com
USA
Linked-In: http://www.linkedin.com/in/craigdedo
--- Comment #7 from craig dot schlenter at gmail dot com 2009-11-16 04:37
---
(In reply to comment #3)
I brought this up on the Google-internal C list. They reduced it further:
$ cat main.cc
#include map
int main(void)
{
typedef std::mapint, char* MyMap2;
MyMap2 map2_
) (GCC)
--
Summary: Aliasing errors in stl_tree.h
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: craig
--- Comment #2 from craig dot schlenter at gmail dot com 2009-11-13 19:34
---
(In reply to comment #1)
Might be related to PR 39390.
Would it be possible for someone to test the code from the description section
with trunk please .. if error messages were removed, the problem should
: unassigned at gcc dot gnu dot org
ReportedBy: craig dot powers at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39933
--- Comment #5 from craig dot powers at gmail dot com 2009-04-25 17:23
---
(In reply to comment #4)
Also, I omitted the link invocation:
gfortran -O3 -o (exe_name) (big honkin' list of object files)
Can you double check that in the big honkin' list of object files the file
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: craig dot powers at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet
--- Comment #1 from craig dot powers at gmail dot com 2009-04-25 05:23
---
(In reply to comment #0)
I neglected to give my compiler info...
/usr/gcc44/bin/gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.4.0/configure --prefix=/usr/gcc44
--- Comment #2 from craig dot powers at gmail dot com 2009-04-25 05:25
---
(In reply to comment #0)
Also, I omitted the link invocation:
gfortran -O3 -o (exe_name) (big honkin' list of object files)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39890
--- Comment #3 from craig dot powers at gmail dot com 2009-04-25 05:29
---
(In reply to comment #0)
Compiler invocation for each source file:
/usr/gcc44/bin/gfortran -c -fbacktrace -x f95-cpp-input -DF2003
-DF2003_NO_ASSOCIATE (source file)
--
http://gcc.gnu.org/bugzilla
at gcc dot gnu dot org
ReportedBy: craig dot powers at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37888
of how the @file option is supposed to work. What is the proper structure
of such a file? Can it include comments? If so, how are those comments
delimited?
Please feel free to contact me at any time with any questions or
concerns that you may have.
Sincerely,
Craig Dedo
17130 W. Burleigh
--- Comment #2 from craig dot powers at gmail dot com 2007-08-15 19:08
---
(In reply to comment #0)
Came across this head-scratcher in building Qt with GCC 4.2.0. Heavily
simplified version:
foo.cxx:
typedef void (*funcptr)(void);
typedef void GLvoid;
typedef
--- Comment #3 from craig dot powers at gmail dot com 2007-08-15 19:13
---
Looking at CVS for glu.h, the official patch is:
#ifdef __cplusplus
typedef GLvoid (*_GLUfuncptr)();
#else
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32364
Hello,
Does anyone know of a good web site for sample C code supported by GCC
3.3.2?
Specifically, I am looking for code that can read files from a directory and
do I/O.
thanks,
Craig
_
PC Magazines 2007 editors choice
.
Regards
Craig
This message was sent using IMP, the Internet Messaging Program.
--- Comment #28 from craig dot lawson at centrify dot com 2007-03-22 23:44
---
For HP-UX, SunOS, and Irix:
#if !defined(_POSIX_C_SOURCE)
# define _POSIX_C_SOURCE 199506L
#elif _POSIX_C_SOURCE199506L
# error Conflict
#endif
(why would anyone compile C++ with POSIX 1995.06
--- Comment #16 from craig dot lawson at centrify dot com 2007-03-15 18:15
---
(In reply to comment #15)
Tried it. Did not work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
--- Comment #18 from craig dot lawson at centrify dot com 2007-03-15 18:39
---
(In reply to comment #17)
Why?
Don't know. The file and change were included as expected.
Without fully understanding how CPP is evaluating these files, we're shooting
in the dark. gcc's -E and -CC
--- Comment #21 from craig dot lawson at centrify dot com 2007-03-15 19:07
---
(In reply to comment #17)
Why?
OK, now I know why. Reason is that os_defines.h is included after errno.h.
Here's the include sequence:
c++locale.cc
cerrno
/usr/include/errno.h-- extern
--- Comment #23 from craig dot lawson at centrify dot com 2007-03-15 19:26
---
(In reply to comment #22)
Oh yes, you are totally right. The problem is that cerrno is one of the very
few c headers not including bits/c++config.h first. We can easily fix that.
Why did cerrno
--- Comment #25 from craig dot lawson at centrify dot com 2007-03-15 20:28
---
(In reply to comment #24)
Oh, that's excellent news, because we have to include bits/c++config.h first
in cerrno anyway... But now you make me curious!!! If you look at
c++config.h
it doesn't appear do
--- Comment #27 from craig dot lawson at centrify dot com 2007-03-15 21:17
---
(In reply to comment #26)
I understand. I'll collect this information from the systems I have, and then
post it here ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
--- Comment #10 from craig dot lawson at centrify dot com 2007-03-14 18:13
---
Found it.
The problem is that the library is not be ing properly compiled for
multi-threaded use, but that by some luck basic_file.cc happened to be compiled
that way anyway. c++locale.cc was not so lucky
10 SPARC
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: craig dot lawson at centrify dot com
http://gcc.gnu.org
--- Comment #3 from craig dot lawson at centrify dot com 2007-03-14 20:00
---
Yeah... I missed that one.
I have bash installed. If bash works, why can't the configure script find it
automatically?
--
craig dot lawson at centrify dot com changed:
What|Removed
--- Comment #4 from craig dot lawson at centrify dot com 2007-03-14 20:01
---
Yeah... I missed that one.
I have bash installed. If bash works, why can't the configure script find it
automatically?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31177
--- Comment #5 from craig dot lawson at centrify dot com 2007-03-14 20:01
---
(oops. hit verified by mistake.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31177
--- Comment #13 from craig dot lawson at centrify dot com 2007-03-15 02:02
---
(reply to comment #11)
Shear luck: Fair enough. I don't claim to understand it all, either, especially
how it came to be this way.
What appears to be happening on Solaris 10 is that bits/c++config.h
--- Comment #4 from craig dot lawson at centrify dot com 2007-03-12 18:26
---
Perhaps there are different degrees of thread safety here.
If I write my multi-threaded program such that only one thread does stream I/O
with libstdc++, I would expect it to operate safely with respect
does not catch return value mismatch
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: craig dot lawson at centrify dot
--- Comment #1 from craig dot lawson at centrify dot com 2007-03-12 18:53
---
Test program (Create a New Attachment is not working for me today):
const int i = -1;
unsigned int slip_one_by()
{
return i;
}
unsigned int caught_me()
{
return -1;
}
$ gcc -c unsigned_return.c
--- Comment #6 from craig dot lawson at centrify dot com 2007-03-12 19:23
---
Anyway, what happens in the GNU systems is that errno is a per-thread variable
and the __convert_to_v code has to do nothing special, just safely use it.
I agree. The problem is that this is not happening
--- Comment #8 from craig dot lawson at centrify dot com 2007-03-12 20:07
---
Not on Linux: correct.
I could give it a try, but I haven't built this library before. If you could
point me to a brief how-to, I could give it a try on a Solaris 10 SPARC.
Rather than code around it, I
.
--
Summary: c++locale.o thread-unsafe in libstdc++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: craig
--- Comment #2 from craig dot lawson at centrify dot com 2007-03-10 00:15
---
Seems like that define should come from gcc's -pthread option so it applies
to all source files.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
directory. Can't see anything for ada or objc, but I
wouldn't know what I was looking for anyway. ;)
Distribution/OS details:
Fedora Core 3
kernel-2.6.12-1.1378_FC3
glibc-2.3.5-0.fc3.1
--
Dr Craig Scott
CFD group, CSIRO (CMIS)
Melbourne, Australia
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: craig dot powers at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
--- Additional Comments From craig dot powers at gmail dot com 2005-02-08
21:53 ---
Further testing indicates that the bug is caused by an array in a derived type
-- the pointer is not necessary.
program test
implicit none
type test_type
integer, dimension(5) :: a
end type
--- Additional Comments From craig dot powers at gmail dot com 2005-02-07
20:48 ---
The specific problem statement appears to be line 1799/1801 in
gfc_simplify_bound:
return gfc_copy_expr (as-upper[i-1]);
or
return gfc_copy_expr (as-lower[i-1]);
The problematic execution
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-traildatabase=gccpr=3250
==
PR 5425,
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-traildatabase=gccpr=5425
is a followup to this PR, but occurs under HPUX with gcc
59 matches
Mail list logo
