Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > On i386 we replace (add sp -4) with (push reg). This generates faster
> > and smaller code.
> >
> > However, we are not copying RTX_FRAME_RELATED_P from the old
> >
On Dec 20, 2005, at 2:02 AM, Eric Fisher wrote:
Hello,
For such a program,
int a=0;
int main(void)
{
...
}
We will see the compiler put the variable 'a' into the bss section.
That means that 'a' is a non-initialized variable. I don't know if this
is the gcc's strategy.
Yes for zero'd initi
how should we treat
> this?
Look at Section 6.5.6, Para 8. The code is undefined.
Andrew.
Richard Guenther writes:
> On Wed, 21 Dec 2005, Andrew Haley wrote:
>
> > Richard Guenther writes:
> > >
> > > The problem in this PR is that code like in the testcase (from
> > > OpenOffice) assumes that pointer overflow is defined. As the
>
On Dec 21, 2005, at 2:43 PM, Gabriel Dos Reis wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
| >However, we have an obligation to define what those mappings are.
| >
| Why?
Because it is an implementation-defined behaviour and we have to
document how the choice is made.
We actually documen
s made.
Can you state some language in the standard that says we have to do
this?
Andrew.
Richard Guenther writes:
>
> So the basic question remains - is pointer overflow defined?
No. You've already asked, and it's already been answered, with
langauge from the standard. What more do you want?
Andrew.
Richard Guenther writes:
> On Thu, 22 Dec 2005, Andrew Haley wrote:
>
> > Richard Guenther writes:
> > >
> > > So the basic question remains - is pointer overflow defined?
> >
> > No. You've already asked, and it's already been a
e the
variable as not
being call clobbered. I use an attribute instead of a bit in the
decls' structure
since it seems only to happen for Fortran code.
Thanks,
Andrew Pinski
Index: fortran/trans-decl.c
===
--- fortran/tr
>
> On Mon, Dec 26, 2005 at 11:34:16PM -0800, Geoff Keating wrote:
> > We've had Real Problems with this feature since it was introduced. I
> > expect it'll take at least another two or three months before it
> > settles down and starts to work on most targets; that's only to be
> > expecte
On Dec 27, 2005, at 6:36 PM, Jakub Jelinek wrote:
It has nothing to do with libgfortran actually, libgfortran only ever
uses the weak pthread function aliases within libgfortran.
The reason why weakref attribute has been added is primarily libstdc++,
see PR4372, because unlike libgfortran or lib
>
> Hi,
> Could you tell me what it means for 'test for excess errors'?
> I run make check-gcc RUNTESTFLAGS='dg.exp' on my machine, and got
> many failed tests for these errors on my porting gcc.
That usually means there are some internal compiler errors while
compiling the testcase, look at gcc.
On Dec 28, 2005, at 4:33 AM, Jakub Jelinek wrote:
I still support a reverting of the weakref patch as it was put way too
late
for 4.1 (stage 3 is not a good idea for a new feature).
Depends on if you consider it a new feature or a bug fix.
It was a new feature to work around a bug which is o
going to back port my fix, if
someone else
wants to do it, it is up to them.
Thanks,
Andrew Pinski
On Dec 29, 2005, at 1:39 PM, Mike Stump wrote:
On Dec 29, 2005, at 8:37 AM, Andrew Pinski wrote:
As far as I can tell the -fobjc-exceptions flag is supposed to work
with the GNU runtime as of GCC 4.0. However, invoke.texi still
states that "Currently, this option is only availab
On Dec 30, 2005, at 1:53 PM, H. J. Lu wrote:
Gcc build executable linking against dynamic libraries by default.
"-static" will link against all static libraries. For run-time
portability, we may want to link against static gcc libraries, like
libstdc++.a, libgfortran.a, libgcj.a, , but agai
On Dec 30, 2005, at 1:58 PM, H. J. Lu wrote:
Are you saying "gcc -static" doesn't work with libobjc and libgcj?
Yes, they have never really worked. You need to cause to import all of
the .a file instead of just letting the linker link in the parts that
it says it needs.
-- Pinski
|| AGGREGATE_TYPE_P (TREE_TYPE (lhsop))
|| TREE_CODE (rhsop) == CALL_EXPR)
Or I am missing that a constraint that can happen?
Thanks,
Andrew Pinski
.
Please, post instructions about how to turn on the old style VM layout
in the kernel. Sooner or later, many of us on this list will need to
know...
Andrew.
Maybe the real solution to all of is is to
have a representation for virtual calls in the IL, but...
So, what I'm thinking of doing is writing a post-inlining pass that
rewrites the trees and then tidies up the CFG. Is this the right
approach?
Thanks,
Andrew.
On Jan 5, 2006, at 8:09 AM, Andrew Haley wrote:
I've been experimenting with devirtualizing method calls, and
sometimes a construct like this can pay dividends:
Another possibility is to have the inliner convert virtual calls into
something like the above. Maybe the real solution to a
Andrew Pinski writes:
>
> On Jan 5, 2006, at 8:09 AM, Andrew Haley wrote:
>
> > I've been experimenting with devirtualizing method calls, and
> > sometimes a construct like this can pay dividends:
>
> > Another possibility is to have the inliner conver
be
more to the point of what seems to be wrong.
Andrew
>
>
> I hit an ICE inside an optimizer pass because the code had a glaring syntax
> error that we diagnosed correctly, but since we kept going, the
> transformation didn't find the CFG in the assumed state, causing the ICE.
We do stop the optimization passes from running in general.
/* Gate: e
On Jan 9, 2006, at 2:46 PM, Diego Novillo wrote:
On Monday 09 January 2006 14:42, Andrew Pinski wrote:
the only passes which do run are cfg creation, expand, and maybe a
couple other simple ones.
I know that. It's expand the one bothering me. Are we issuing errors
that
late i
On Jan 12, 2006, at 1:40 PM, Jon BLOOMFIELD wrote:
Can somebody tell me whether there is a known bug in g++ 4.0.1 wrt
scoping
of members of a template base class. The following contrived test case
generates a compiler error on 4.0.1, complaining that 'a' is not in the
scope scope of D::f()
.
On Jan 13, 2006, at 8:18 PM, Alfred M.. Szmidt wrote:
Thanks, will do so later today.
But this seems very awkward for people who only send a patch ones in a
blue moon; and not much good info on that either, the manual just says
`report bugs to the bugtracker'; more or less.
Please read the w
n the stack. Otherwise the offsets are not sufficiently
> rounded, even if the stack register is aligned on BIGGEST_ALIGNMENT on
> function entry.
Huh? Where is this requirement documented because I don't see it at all
in tm.texi? Also what is Ada using BIGGEST_ALIGNMENT for, that just seems
wrong.
Thanks,
Andrew Pinski
On Jan 16, 2006, at 3:00 PM, H. J. Lu wrote:
This patch works for me.
But not the real problem. The real problem is the use of "gcc_assert
(FALSE);"
which just can be turned into gcc_unreachable as mentioned in my other
email.
-- Pinski
On Jan 17, 2006, at 5:57 PM, Frank Ch. Eigler wrote:
If not would it be a good idea to disable mudflap by default on mips?
Tried native? If that also doesn't work I'd be up for disabling.
I was under the impression that libmudflap was disabled by default
almost everywhere. Unless libmudflap
The testsuite is way broken and does not run all the tests:
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00878.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00876.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00886.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00898.htm
On Jan 17, 2006, at 8:45 PM, Andrew Pinski wrote:
The testsuite is way broken and does not run all the tests:
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00878.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00876.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00886.html
http
On Jan 18, 2006, at 6:16 AM, Eric Botcazou wrote:
mkdir.o socket.o raise-gcc.o \
-Wl,-flat_namespace \
-lm
ld: Undefined symbols:
__Unwind_Resume
__Unwind_ForcedUnwind
__Unwind_GetDataRelBase
__Unwind_GetIP
__Unwind_GetLanguageSpecificData
__Unwind_GetRegionStart
__Unwind_GetTe
On Jan 18, 2006, at 12:28 PM, Chris Douty wrote:
On Jan 18, 2006, at 6:23 AM, Andrew Pinski wrote:
On Jan 18, 2006, at 6:16 AM, Eric Botcazou wrote:
OK, I can reproduce the failure.
Darwin specialists, what are we missing here?
Well it would be helpful if the reporter reran the link
>
> On Wed, Jan 18, 2006 at 11:41:39AM -0600, Perry Smith wrote:
> > In the course of doing my work last week to get exception handling
> > working in my device driver, I learned that the exception processing
> > code calls malloc during the exception. This seems weak to me. It
> > seems l
ggest that but the wiki was about using git mirror.
"With a normal git repository 'git clone' grabs all branches, but
because of the SVN mirror we need to do something more elaborate" :).
This is no longer true and even wrong as the branches are in a
different location really.
Tha
t purposes, but they still have the same
risks as reference repos "I don't need that old tree any more."
Both are best left for the advanced tricks section.
Andrew
tree is more
> important.
One thing which you could do is kinda of what glibc did when they
merged glibc and glibc-ports.
Really it would useful if you get GM2 into the base sources of gcc
instead for GCC 11 :).
Thanks,
Andrew Pinski
>
> regards,
> Gaius
he years before that appear to have escaped the problem.
Andrew
m:
>
> https://forms.gle/4Tocg6JnTwqyJbwq8
One comment, the there is no xxl for tshirt sizes
Thanks,
Andrew Pinski
>
> If unable to use this form, please visit the Wiki page above for
> alternative instructions on how to register.
>
> The Cauldron is organized by a
chars, again as the
output of the likes of 'git log' indent the message by 4 chars.
Using vim as the git commit message editor, vim will show you when your
subject line is over 50 chars and it wraps the message body after 72
chars.
Cheers,
Andrew
ckly decide what not to read.
I see that some people are using a "[email tag] git tag: msg" format,
and I quite like that.
Andrew
It doesn't explain the !
> though, and not wildcards even.
>
> (dir.c in git.git, if you like spelunking).
Note I was not able to get it to work with "git version 1.8.3.1"
(which is included with CentOS 7) but it worked with "git version
2.17.1".
Thanks,
Andrew Pinski
>
>
> Segher
can_atomic_load_p (mode))
return boolean_true_node;
else
return boolean_false_node;
Thanks,
Andrew Pinski
> I'd like to change clang to eagerly evaluate __atomic_is_lock_free to 0 for
> apparently oversized types.
> This helps some platforms to avoid a dependency on libatomic.
&
On Mon, Feb 10, 2020 at 8:40 PM Andrew Pinski wrote:
>
> On Mon, Feb 10, 2020 at 8:35 PM Fangrui Song wrote:
> >
> > GCC never evaluates __atomic_is_lock_free to 0.
> > (gcc/builtins.c:fold_builtin_atomic_always_lock_free)
>
> Huh?
Oh it is this, you quoted the wr
ble encoding), so the asm problem is mitigated somewhat, at
the cost of a few "far" branches where they're not strictly necessary.
There were also addition problems because "far" branches clobber the
condition register, and "near" branches do not, but that's another story.
Andrew
omewhat
trivial, but the explosion in the number of generated patterns would be
enormous, and it still won't allow arbitrary size vectors.
Thank you for your time; I'm trying to decide where my efforts should lie.
Andrew
On 03/03/2020 15:57, Richard Sandiford wrote:
Andrew Stubbs writes:
Hi all,
Up until now the AMD GCN port has been using exclusively 64-lane vectors
with masking for smaller sizes.
This works quite well, where it works, but there remain many test cases
(and no doubt some real code) that
wrong documentation
page. It points to Warning-Options.html when it should be
Static-Analyzer-Options.html.
I expect you knew that already. I'll shut up now.
Andrew
her issues with this commit,
so this may be a duplicate issue, somehow.
Andrew
On 27/05/2020 15:46, Andrew Stubbs wrote:
I'm testing amdgcn-amdhsa, and I get lot of PCH test failures with
errors like this:
gcc.dg/pch/common-1.c:1:22: error: one or more PCH files were found, but
they were invalid
gcc.dg/pch/common-1.c:1:22: error: use -Winvalid-pch for more inform
toolchain, but the (now
inactive) option remains. I don't recall why; it may have been for
backward compatibility, or it may have been an unintentional omission.
Either way, I don't think we need it in GCC 11, so I can just rip it out.
Thanks again
Andrew
), Topaz is GCN 1,
and therefore too old.
GCC 10 supports only the specific devices listed.
Andrew
rc to keep such junk out of my working directories.
" Keep .swp files all in one place
set dir=~/tmp
" same for undo files
set undodir=~/tmp
set undofile
Andrew
his, but of course GCC does not
support this yet.
How can I best implement this new feature, both in dwarf2out and in the
target hooks?
The proposed standard changes are here:
http://llvm.org/docs/AMDGPUUsage.html#dwarf-debug-information
http://llvm.org/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.html
Thanks in advance
Andrew
in the md_reorg pass, perhaps).
You might have V2, V4, V8, and V16, for example.
Or both: for GCN, arbitrary masks work fine, but not all of GCC can take
advantage of them, so I've been experimenting with adding multiple
vector length modes to make up the difference.
Andrew
be the best (least effort) way to implement this?
I think I need shift, rotate, multiply, divide, and modulus, but there's
probably more.
Thanks, any advise will be appreciated.
Andrew
attern clobbers CRIS_CC0_REGNUM. Did I get that right?
The best (only?) way to understand define_subst is to read the expanded
machine description. This is not written anywhere, by default, but
there's a way to get it.
cd /gcc
make mddump
less tmp-mddump.md
Not only are all the define_subst expanded, but so are all the other
iterators.
HTH
Andrew
nois license is not actually active
here? Or is it that it is active and binary distributors really should
be obeying this attribution clause already?
Can anybody help me untangle this, please?
Are the files acceptable, and if not, how is this different from the
other cases?
Thanks very much
Andrew
Ping.
On 14/09/2020 17:56, Andrew Stubbs wrote:
Hi All,
I need to update include/hsa.h to access some newer APIs. The existing
file was created by copying from the user manual, thus side-stepping
licensing issues, but the updated user manual omits some important
details from the APIs I need
On 21/09/2020 12:31, Richard Biener wrote:
On Mon, Sep 21, 2020 at 10:55 AM Andrew Stubbs wrote:
Ping.
Sorry, but you won't get any help resolving license issues from the
mailing list.
Instead you should eventually ask the SC to "resolve" this issue with the FSF.
Agreed,
s implementation is that the RTL level
optimizers are not always up to removing the byteswaps.
GCSE is very weak on the RTL level compared to PRE on the gimple level.
Thanks,
Andrew Pinski
>
> The bulk of the implementation is in the FEs (sanity checks, propagation, etc)
> and the RTL expander
On Mon, Jun 8, 2015 at 4:19 PM, Andrew Pinski wrote:
> On Mon, Jun 8, 2015 at 4:05 PM, Eric Botcazou wrote:
>> Hi,
>>
>> I'd like to propose merging the scalar-storage-order branch that I have been
>> maintaining for a couple of years into mainline. Orig
way is to base vector name on original name of
declaration, not asm declaration name (use DECL_NAME instead of
DECL_ASSEMBLER_NAME)?
According libc-alpha thread is
https://sourceware.org/ml/libc-alpha/2015-06/msg00213.html
--
WBR,
Andrew
On Mon, Jun 15, 2015 at 9:06 AM, Andrew Senkevich
wrote:
> Hi,
>
> compilation with options -fopenmp -ffast-math -O1 -msse4
>
> of the test
>
> #pragma omp declare simd notinbranch simdlen(2)
> extern double log (double);
>
> int N = 3200;
> double b[3200];
>
c if GLIBC version
>= 2.22 found on configure?
May be some other way needed to achieve similar drivers behavior?
--
WBR,
Andrew
On 06/24/2015 03:12 PM, Andrew Senkevich wrote:
> Can anybody tell something about this difference in drivers?
It's a UNIX tradition to require -lm for the floating-point
library in C programs. It doesn't make much sense now, but it's
hard to change it.
Andrew.
oing to require major surgery in many
places. The HotSpot optimizing compilers are written with GC as a
basic requirement and it touches many places.
Andrew.
On 07/10/2015 07:35 PM, Jeff Law wrote:
> I wonder how much overlap there is between this need and what we're
> going to need to do for resumable functions which are being discussed in
> the ISO C++ standards meetings.
A considerable amount, I'll be bound.
Andrew.
e.
Im not very good with configure and Makefiles and how we parallelize
this... Anyone with any bright ideas?
Andrew
config.status: linking /gcc/2015-07-14/gcc/libgcc/unwind-generic.h to
unwind.h
/gcc/2015-07-14/build/./gcc/xgcc -B/gcc/2015-07-14/build/./gcc/
-B/gcc/2015-07-14/install/x8
which ends up overwriting gthr-default.h at what
turns out to be a poor time ? that sort of makes sense I guess. Im
not sure how we synchronize the parallel bits.
Andrew
so it probably is related to rerunning config.status
On 07/15/2015 10:07 AM, Andrew MacLeod wrote:
I occasionally get a build
On 07/15/2015 02:58 PM, Jeff Law wrote:
On 07/15/2015 08:33 AM, Andrew MacLeod wrote:
Maybe if gthr-default already existed (as well as config.status), the
makefile would spawn the libgcov-interface.c object builds... meanwhile
a reconfigure is going which ends up overwriting gthr-default.h
On 07/28/2015 04:40 PM, Paulo Matos wrote:
> The block skips the test for ((unsigned int) xx << 1 == 0 && yy == -1),
> should we skip it if they're both zero as well?
Yes. It's undefined behaviour. If we don't want to invoke nasal
daemons we shouldn't do this.
Andrew.
utput_Constants *)&style]._vptr.Output_Constants =
> &MEM[(void *)&_ZTV16Output_Constants + 16B];
> style.D.4064._vptr.Output_Constants = &MEM[(void *)&_ZTV11Output_Enum
> + 16B];
> style._indentation = "";
>
> Why is this different? Why is __c
simplistic. It
resulted in git attributions like:
commit 90e2fa9c54de04a52fd5980238a1087b9291750f
Author: Andrew Cagney
Date: Mon May 11 21:21:47 2009 +
2009-05-11 Andrew Cagney
* MAINTAINERS: Orphan ppc.
commit 8e70166dc52cf82a61e0a414f364f3ff7c45dfa7
Author: Andrew Cagney
Da
On 28 August 2015 at 13:24, Jeff Law wrote:
> cagney = Andrew Cagney
cag...@gnu.org?
On 15 September 2015 at 21:36, Frank Ch. Eigler wrote:
>
>>> cagney = Andrew Cagney
>> cag...@gnu.org?
>
> Good point. The email identities of people change over time; forcing
> a single arbitrary one to label all contributions is at best imprecise
> and at worse
lements != size)
return NULL;
void *ptr = malloc (ns);
asm ("":"+r"(ptr));
memset (ptr, 0, ns);
Notice I put in a check for overflow in there.
Thanks,
Andrew Pinski
>
> Thanks,
>
>Daniel.
On 03/10/15 21:41, Matthijs van Duin wrote:
> Anyhow, it only took four years, but you can now throw
> NullPointerExceptions on ARM. Enjoy. ;-)
Ok, nice. :-)
Do you have GCC copyright assignment, and will you turn this into
a patch which can be applied?
Thanks,
Andrew.
e new frame pointer of the 'main' function.
>
> Is it acceptable from ABI point of view?
Yes, as long as the generated code for main gets its first argument
from the correct place.
Andrew.
ogrammer knows that the virtual PC
and SP should live in a register. GCC does not know this and is
forever spilling them. Explicit local reg vars fixed this nicely.
Andrew.
On 10/20/2015 05:12 PM, Jeff Law wrote:
> On 10/20/2015 10:05 AM, Andrew Haley wrote:
>> On 10/20/2015 05:00 PM, Jeff Law wrote:
>>> But the technical reality is I can't see a use outside the extended asm.
>>
>> I can. In the past (and probably still today) GC
On 10/20/2015 05:22 PM, Jeff Law wrote:
> On 10/20/2015 10:15 AM, Andrew Haley wrote:
>>> But in that case, what do we guarantee.
>>>
>>> We certainly don't guarantee that those objects will be in their
>>> requested register at any point other than at
urely helps - thanks.
Basically NVIDIA bought PGI and now is open source their fortran
front-end. Nothing magical really.
Basically NVIDIA is trying to have the "community" do more of their
development for them.
This is an anti-open/free source way of doing things.
Thanks,
Andrew
>
hing being debugged.
I think that's really pretty unlikely. Besides, if you need a
breakpoint for debugging you really don't want operations to move
across that breakpoint.
Andrew.
t; anyone's priority list to get resolved. I wouldn't be at all surprised if
> Richard filed this bug to ensure that it didn't get lost. That's standard
> development procedure for items we notice, but aren't actively working on.
>
> It's unfortunate that
r
void xx() {
for (int x=0; x < 1000; x++)
asm volatile("#stuff" : : : "memory");
}
What you're describing looks like a bug: x doesn't have its address
taken.
Andrew.
> #define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11",
> "r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory"
Hmm. I would not be at all surprised to see this cause reload
failures. You certainly shouldn't clobber the frame pointer on
any machine which needs one.
Andrew.
s. This is why Jeff didn't fix this in 1999. So, if we really
do want to clobber "all" registers in basic asm it'll take a lot of
work.
Andrew.
On 23/11/15 21:02, David Wohlferd wrote:
>> On 11/23/2015 2:04 AM, Andrew Haley wrote:
>> > My warning still holds: there are modes of compilation on some
>> > machines where you can't clobber all registers without causing reload
>> > failures. This is why Je
ry confusing, to say the least, if this were to be defined
in C++ but not C.
Andrew.
a rule which says that all registers which are used must be
saved and restored.
This won't break any existing usages, and is AFAICS entirely in the spirit
of what was originally intended and with the ISO C specification.
Andrew.
es anyone actually do
foo(1)bar(2)bar(3) ?
That's what I'm talking about.
Andrew.
y to clear up the ambiguity is to
> start deprecating basic asm, not to add to the confusion by changing its
> behavior after all these years.
Well, I disagree. The warning is good, but so is the memory clobber.
They're not exclusive.
Andrew.
y
> output), and that move could be moved out of the loop (it's not).
> Where should I look for the root cause?
Hmm,
I want to say the predicates on movdf_64 are too lose allowing the
above when it should not. That is movdf_64 should have pushed the
load of the
ber memory, but not registers. That allows most of the
effects that people intuitively want and expect, but avoids the
breakage of register clobbers. It allows basic asm to be used in a
sensible way by pushing and popping all used registers.
Andrew.
enously insist that it gets fixed the way you want
and complain about the difficulty of reaching consensus, y'know. :-)
A basic asm which clobbers memory and saves registers has no
correctness problems whatsoever. There is no reason that people
should not use it, and continue to use it if it suits them.
Andrew.
ion
> but Clang uses the point of definition. g is a dependent name here, and the
> standard says "template definition context" should be used; but I am not
> very sure about the wording. I suspect this to be a GCC bug, but not sure,
> so asking here first.
There is also argume
that it is a good idea.
Good idea or bad idea? This will prevent cases like PR 68948 from
happening and make it easier to understand why the wrong code is
happening.
Thanks,
Andrew
On 17/12/15 01:41, David Wohlferd wrote:
> On the contrary, I would be surprised to learn that there are ANY
> compilers (other than clang) that support gcc's extended asm format.
Prepare to be surprised: Sun Studio compilers seem to support it
just fine.
Andrew.
901 - 1000 of 3432 matches
Mail list logo
