ng,
so we strip the scope prefix, but we may need to deal with the suffix
created by the compiler. */
But on second glance, I noticed that this is a suffix with a dot - not the
"order" of a cgraph_node with a slash.
Is it possible to access this order in output_stack_usag
umstances are there missing functions in the cgraph?
For my example AVR program, all identifiers appearing in the stack-usage output
also appeared in the cgraph output.
On Mon, 9 May 2016 23:47:10 +0200
Sebastian wrote:
> - In -fstack-usage, use the same unique identifiers as in -fdump-ipa
I have all prerequisites for GCC but no stdc-predef.h that seems to be is
needed.
So what prerequisite do I need else for GCC to get compiled ... includes
stdc-predef.h ?
build:
i686-pc-linux-gnu
linux-2.6.26.2
gcc-4.3.1
bash-3.2.33
GNU Make 3.81
glibc-2.7...ups, but I sent you this mail anyway...
Hi,
can gcc show the size of the stackframe of functions, so you can, given
a callgraph without cycles, calculate the worst case stack size?
(Assuming no use of alloca or C99 variable size arrays)
Can gcc (or ld) dump a callgraph?
regards,
Sebastian
ich functions call other
functions, only which modules refer to them.
Static analysis which work on source code are not ideal, either. They
don't know which functions will be inlined by the compiler.
So it would be nice if gcc could provide a call graph.
Thanks,
Sebastian
Am Mittwoch, den 13.10.2010, 14:54 -0700 schrieb Joe Buck:
> On Wed, Oct 13, 2010 at 02:43:18PM -0700, Sebastian wrote:
> > On Wed, Oct 13, 2010 H.J. Lu wrote:
> > > gcc can not dump a callgraph. Both GNU ld and gold can dump a
> > > cross-reference table, which is
ctures. I'm not sure that
we want to create a new node for data dependences as well...
Sebastian
> > quite a lot at the moment). To keep the information valid, we need
> > to prevent optimizations from destroying it (e.g., if the number
> > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want
> > DCE to remove it); this is easy to achieve if n_1 would be the
> > argume
> You are proposing to complete the ssa representation such that
> foreach_ssa_uses also iterates over the niter information (a bit like vrp
> modifies the ssa chains with its extra assert information). Wouldn't it
> be possible to not insert this niter information in the representation of
> the
On 11/13/06, Ferad Zyulkyarov <[EMAIL PROTECTED]> wrote:
Hi,
May you point me out some sources about writing new #pragma directives
in GCC. I looked at the internet for something to start from but
unfortunately I could not find anything.
google("site:gcc.gnu.org inurl:gcc-patches pragma")
http
cc.gnu.org/wiki/OptimizationCourse?action=AttachFile&do=get&target=loop-distribution-patch-against-gcc-4.1.0-release.patch
Sebastian
On 11/15/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 11/15/06, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> There is a ddg in this patch if somebody wants the classic Allen&Kennedy
> way to look at the dependences:
>
http://gcc.gnu.org/wiki/OptimizationCourse
ar and Integer Programming" by Alexander Schrijver,
etc.
Sebastian
On 3/9/07, jimmy <[EMAIL PROTECTED]> wrote:
Steven Bosscher wrote:
> Hi,
>
> I found this old patch
> (http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01669.html) that refers
> to pages 202-214 of Muchnick's
tract.php?content_key=9
Sebastian
Zack Weinberg wrote:
>
> and report (a) the numbers reported by the "time" command,
real0m7.819s
user0m4.442s
sys 0m0.513s
> (b) what sort of machine this is and how old, and
x86_64-unknown-linux-gnu, AMD Athlon(tm) 64 Processor 3700+
> (c) whether or not you would be willing to
re already prepared by the decl.
Is this a hard optimization to accomplish? It's quite obvious for a
human, but I don't know how this looks from a compiler perspective...
Sebastian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James E Wilson wrote:
> Sebastian Biallas wrote:
>
>> But I noticed some smaller optimization issues on x86, and on of them is
>> a regression to gcc 3.3 so I'm reporting this here. Accept my apologies
>> if this is al
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James E Wilson wrote:
> Sebastian Biallas wrote:
>
>> You don't need to reserve a stack slot for the return address on x86.
>> The stack slot will be allocated implicitly by the "call" instruction.
>
> OK, t
ing identification; -fkeep-static-consts is ineffective with
> optimization turned on
> */
> static const char rcs_sccs_id[] =
> "$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string1\\ $";
Use
static const char rcs_sccs_id[] __attribute__((used)) = ".."
S
Daniel Berlin wrote:
> On Thu, 2005-05-12 at 10:01 -0600, Zan Lynx wrote:
> > I'm not subscribed to the list (please CC replies to me) and this isn't
> > a real bug report, just a sort of quick check to see if its a known
> > problem.
> >
> > When I compiled openssl-0.9.7g using -O3 and -ftree-loo
Daniel Berlin wrote:
>
> Does -fno-tree-ch fix it? (i'm just curious)
>
No. It still ICEs.
only difficulty remaining to the charge of
the compiler constructor is to effectively characterize the
fingerprints of programs with respect to a given transformation. Lots
of engineering, and cool speedups...
Sebastian
loop bounds
from undefined behavior of overflowing signed induction variables is
still not implemented. I will propose a patch with the corresponding
warning messages.
Sebastian
sider this extension useful for mainline only the day when
some optimizer will show a net improvement that justifies the extra
burden of maintaining the code.
I also have decided to restrict the polynomials to a degree less or
equal than 2 (affine evolutions) because all the other constructs are
just pure nonsense, and not used by any optimizer or other analyzer.
It's too bad that I have not restricted the analyzer earlier based on
the suggestions from Zdenek Dvorak.
Sebastian
DJ Delorie wrote:
>
> > Then, you will like the following kind of patches:
> >
> > + warning (0, "%H undefined behavior if loop runs for more than %qE
> > iterations",
> > + find_loop_location (loop), estimation);
>
> I think we would like them better if you could choose to silenc
ng like ": undefined behavior
if loop runs more than 122 iterations: access over allocated data
bounds".
Sebastian
arning will be effective only
on loops that have statically determinable number of iterations.
In my opinion both these warnings are useful.
Sebastian
Michael Veksler wrote:
> This is problematic:
> 1. I am not sure it will turn the warning off.
So you don't want a warning that cannot be turned off simply by
modifying the code. Then, I withdraw the patch that I have proposed
to implement the warning.
Hello,
I was just looking at the output of the data dep analyzer for
ltrans-1.c and I was quite surprised to see that array indexes are
analyzed twice, as in the following output:
(analyze_array
(ref = u[D.1485_16];
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = D.1485_16)
(get_scala
Daniel Berlin wrote:
> On Mon, 2005-08-01 at 17:27 +0300, Dorit Naishlos wrote:
> >
> > I don't think there was an intention to force recomputation - probably just
> > overlooked what the third argument actually stands for. These occurrences
> > could probably be changed to false.
> >
>
> Yeah,
Have fun,
Sebastian
Omega data dependence test
We propose a Practical Oracle Program (POP) for exactly solving
Integer Linear Programs (ILP): an adaptation of Bill Pugh's Omega
solver (BOP) that is experimentally known to be fast for small
problems, but is also known to be exponen
Dan Kegel wrote:
> Sebastian Pop wrote:
> > [http://gcc.gnu.org/wiki/Omega%20data%20dependence%20test]
> > ...
> I can't understand a word of the proposal.
> Mabe you were trying to be funny, but it ended up being obscure.
I'm sorry. This was not my intent.
>
Dave Korn wrote:
>
> Well, I'll pitch in, because I also wasn't sure at first whether it was
> for real and what it was about, but I think I know now. Did you google
> "bill pugh omega solver" and do some background reading? It didn't take me
> too long to get the basic gist of what they're pr
Bandwidth usage: size of incoming mail patch + size of answer + "cvs
update -dP" every morning.
Sebastian
Laurent GUERBY wrote:
> Looks good. I think it would be slightly more secure to have people
> commit the patch with a unique name in some access-controlled CVS
> (either some subdir of the GCC one or a new local one) than relying on
> email "From" fields at the cost of minor inconvenience.
>
We a
Joe Buck wrote:
> Algorithms that are sometimes exponential can still be used if there is
> a cutoff mechanism, to abort the algorithm if it exceeds a budget. This
> assumes that we can then fall back to an algorithm that might produce
> inferior results, but will produce something usable in reaso
Joe Buck wrote:
> The problem with using time as a cutoff is that you then get results that
> can't be reproduced reliably. Better to count something that is a feature
> of the algorithm, e.g. number of executions of some inner loop, number of
> nodes visited, or the like,
On the other hand, it
Daniel Berlin wrote:
>
> Sebastian, I really think you are worrying too much.
right.
> It's pretty rare that it will take going all the way to omega to be able
> to disambiguate two dependences.
>
for dependence tests we exercise only a limited part of omega, but now
su
Hi Laurent,
Laurent GUERBY wrote:
> Here is the initial wiki page for the CompileFarm project:
>
> http://gcc.gnu.org/wiki/CompileFarm
>
> Feel free to add detailed proposals there.
>
For the moment the compile farm will host only i686 machines. I'm
proposing a project to diversify the availa
Andrew Pinski wrote:
>
> On Aug 15, 2005, at 4:03 PM, Gerald Pfeifer wrote:
>
> >Can someone else reproduce this on an i386 or some other target?
>
> This should been already fixed by:
> 2005-08-15 Sebastian Pop <[EMAIL PROTECTED]>
> PR 23386
&g
Steven Bosscher wrote:
> Hi,
>
> Something commited a few days ago had resulted in a serious performance
> hit for SPEC sixtrack on 64 bits machines... The obvious suspect is
> Sebastian Pop's scev patch. The affected targets are at least AMD64 [1]
> and PP
g that anybody
gets hurt by this one: this is already what we're doing in the
autovect branch.
Sebastian
Steven Bosscher wrote:
>
> So GCC 4.1 right now is a small compile time disaster. Are there any
> ideas for what can be done about it before releasing it?
>
I was looking at the testcase sent by Dale Johannesen both at tree
level and at rtl level:
> extern int a[];
> int foo(int w) {
> int n
7;re using the -fwrapv
semantics.
I'm not sure whether at rtl level we have this distinction of
wrapping/non wrapping operations, but from the code that I've read,
everything wraps (probably Roger Sayle knows more about the wrapping
behavior that is expected at rtl level). Having said this, we have to
adjust the code at the tree level such that it catches this case
(conditionally on signed iv and !fwrapv).
sebastian
Daniel Berlin wrote:
>
> I agree completely.
> We need to be a lot smarter about invalidating certain types of
> expensive to compute information.
The way that we compute niter, for the moment, could be considered as
not expensive. But the fact that we think that this is inexpensive
makes us c
u'll have to ask a middle-end
maintainer for checking this fix in.
Thanks,
Sebastian
Richard Kenner wrote:
> [Sorry for the missing line in my last message.]
>
> I'm watching it deal with
>
> # small_1 = PHI <32(0), 1(1)>
>
> vrp_meet is called with [32, 32] and [1,1].
>
> It determines that the ranges don't intersect and then comes up with
> ~[0,0] since neither co
y allocate its elements. */
decl_t decls [1];
};
Sebastian
Gabriel Dos Reis wrote:
>
> If VRP is doing what you described in the comment as "its work", then
> VRP is broken. Period. The fix is to fix VRP. It is such a C
> idomatic construct than I would not have expected any "optimizer" to
> break it. And that is very worrisome and scary.
>
Okay, VR
Thanks for all the explanations.
Richard Henderson wrote:
>
> In the case of the (fake) flexible array member, you do not know
> how large the object allocated from malloc was unless you can
> track down the actual malloc call.
>
Gabriel Dos Reis wrote:
> typedef struct {
> int dat
s already there ;-)
Sebastian
l the same way.
>
Seconded. I will help porting the missing analysis and optimization
bits such as the data dependence and loop transforms to LLVM.
Sebastian
80 columns. I feel this behavior annoying
for patches that get scrambled.
Sebastian
Daniel Berlin wrote:
>
> If you attach a patch and your mail client is sane, it will be marked as
> a patch attachment to the bug
>
Okay, thanks.
Richard Guenther wrote:
> On Tue, 13 Dec 2005, Arnaud Charlet wrote:
> > Except that unlike C, Ada needs a run-time, even for simple things,
> > so you need in addition to point (using e.g. -I) to the runtime,
> > which is built under obj/gcc/ada/rts,
> >
> > so from obj/gcc directory, you can do
test act as volunteers, it
is possible to provide the client scripts to other gcc developers that
can decide to help test the patches with their spare machines. Once
the patch is bootstrapped and tested, the results are sent back to
gcc-patches.
Sebastian
Ronny Peine wrote:
>
> -ftree-loop-linear is removed from the testingflags in gcc-4.0.2 because it
> leads to an endless loop in neural net in nbench.
Could you fill a bug report for this one?
Thanks,
Sebastian
Hello,
I tried to build a recent GCC master on FreeBSD 12.1 and it failed with
a compile error:
$ clang --version
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on
LLVM 8.0.1)
Target: x86_64-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin
../../gnu-mirror-
reinterpret_cast.
(pod_hash_traits::is_empty): Likewise.
This is ok for trunk.
Thanks.
This should now be fixed on master (r10-6434-
g1dae549dccfec1edb0cb4e65feadc4722bb3bcc8); I verified the build with
the patch with gcc, and Sebastian verified it with clang.
Thanks a lot for the quick fix. The
Hi,
is somebody already working on backporting -moutline-atomics to gcc 8.x and 9.x
branches?
Thanks,
Sebastian
n could also be very very helpful. Any ideas?
Thank you!
Sebastian
[1] https://gcc.gnu.org/wiki/plugins
[2] https://gcc.gnu.org/legacy-ml/gcc/2016-02/msg4.html
[3] https://github.com/bedatadriven/renjin/
[4] https://github.com/mobanisto/gcc-bridge
[5] https://github.com/mobanisto/gcc-brid
termination. Would such changes be
acceptable for GCC integration or is this too specific?
Kind regards,
Sebastian
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax: +49-89-18 94 741 - 08
PGP
Hallo Martin,
On 10/11/2020 13:05, Martin Liška wrote:
On 11/9/20 6:45 PM, Sebastian Huber wrote:
Hello,
Hello.
There was a similar need some time ago:
https://gcc.gnu.org/legacy-ml/gcc/2019-11/msg9.html
Please take a look for a possible inspiration.
thanks for the pointer.
I
bably need also a patch for the GCC options documentation, test
cases, a GCC bootstrap on Linux, release notes, ...? Do I have to wait
for the GCC 11 development start?
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +4
On 10/11/2020 17:23, Sebastian Huber wrote:
I am not sure how I can make the new section read-only. Currently, it
is writable:
.section .gcov_info,"aw"
.align 2
.type .LPBX2, @object
.size .LPBX2, 4
.LPBX2:
.long .LPBX0
I c
to get the
data from the target.
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
embedded brains GmbH
Registergericht: Amtsgericht
rror: switch '-mcustom-round' has no effect unless
'-fno-math-errno' is specified [-Werror]
I am not sure how to fix this.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 -
On 14/01/2021 15:16, Sebastian Huber wrote:
Hello,
I try to add a nios2 multilib to support the "Nios II Floating Point
Hardware 2 Component":
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_nios2_custom_instruction.pdf
If I add all custom in
} "
SANITIZER_SPEC " \
+ %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} " \
+ SANITIZER_SPEC " " SYSTEM_LINK_SPEC " \
%{!nostdlib:%{!r:%{!nodefaultlibs:%(link_ssp)
%(link_gcc_c_sequence)}}}\
%{!nostdlib:%{!r:%{!nostartfiles:%E}}} %{T*} \n%
On 22/01/2021 10:46, Sebastian Huber wrote:
Hello,
for RTEMS we have in gcc/config/rtems.h the following LIB_SPEC:
#undef LIB_SPEC
#define LIB_SPEC "%{!qrtems:" STD_LIB_SPEC "} " \
"%{qrtems:%{!nostdlib:%{!nodefaultlibs:" \
"--start-group -lrtemsbsp -lrtem
for the APIs defined by bar.h, mutex.h, ptrlock.h and sem.h in the
testsuite. Would it be acceptable to add tests for this area?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail
;
__gthread_key_t k2;
__gthread_key_create(&k1);
k2 = k1;
__gthread_setspecific(k2, 0xdeadbeef);
__gthread_key_delete(k2);
?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-
}
Why can you not immediately free the team?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese N
e one extra
integer for the mutex?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachrich
if (team->barrier.generation & BAR_CANCELLED)
+ if (bar->generation & BAR_CANCELLED)
{
gomp_mutex_unlock (&team->task_lock);
return;
}
- team->barrier.generation |= BAR_CANCELLED;
+ bar->generation |= BAR_CANCELLED;
gomp_mutex_unlock (&team->ta
On 17/07/15 08:40, Sebastian Huber wrote:
Hello,
the libgomp configuration for RTEMS uses currently the POSIX
implementation. Unfortunately the performance is unacceptable bad, so
I work currently on a specialized RTEMS configuration. I would like to
reuse the code of the Linux futex barrier
On 17/07/15 13:26, Jakub Jelinek wrote:
On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
>On 17/07/15 08:40, Sebastian Huber wrote:
> >Hello,
> >
> >the libgomp configuration for RTEMS uses currently the POSIX
> >implementation. Unfortunately the perf
On 17/07/15 13:43, Jakub Jelinek wrote:
On Fri, Jul 17, 2015 at 01:33:41PM +0200, Sebastian Huber wrote:
Attached is a more complete example.
I'd prefer not to share the two implementations, just copy and adjust
the linux/bar.[ch] into rtems/bar.[ch].
Ok, I understand that you wa
On 17/07/15 14:36, Torvald Riegel wrote:
On Fri, 2015-07-17 at 13:33 +0200, Sebastian Huber wrote:
>On 17/07/15 13:26, Jakub Jelinek wrote:
> >On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
> >> >On 17/07/15 08:40, Sebastian Huber w
Hello,
in this test case there are two bool test variables (global and local).
Is this intentional?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded
"#endif"
The default architecture version on arm-rtems is v4, so
__GCC_ATOMIC_BOOL_LOCK_FREE == 1 and __GCC_ATOMIC_INT_LOCK_FREE == 1.
How do the other ARM testers tackle this issue? Would it be possible to
add for example a "-march=armv7-a" option if the target selector
contains "
On 01/09/15 14:22, Andreas Schwab wrote:
Sebastian Huber writes:
How do the other ARM testers tackle this issue? Would it be possible to
add for example a "-march=armv7-a" option if the target selector contains
"arm"?
RUNTESTFLAGS=--target_board=unix\{,-march=armv7-a
poor job at scheduling at the end of a
block, and we do not have a way to improve the situation, because we don't have
enough insns outside the critical path to be scheduled towards the end of the
bb.
Sebastian
On 10/09/15 19:52, David Edelsohn wrote:
https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
Is there specific reason why the SYNC L,E (Elemental Memory Barriers)
defined by Power-ISA V2.07 doesn't appear in this table?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr.
c/sys/rtems/sys/cpuset.h ? Just send the patches to you or should
I push them to the respective lists with you CC?
Please send them as patches to the corresponding lists and CC
de...@rtems.org.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
> Sebastian,
>
> I have tried to build GCC with Graphite and ISL on AIX and encountered
> two problems:
>
> (1) isl/ctx.h
>
> typedef enum {
> isl_stat_error = -1,
> isl_stat_ok = 0,
> } isl_
IN_GCC in the graphite files.
I don't understand why these symbols are poisoned in GCC.
If there is a good reason to poison these functions, why would they
be fine to be used in Graphite and ISL?
Would it be possible to relax these constraints and remove the
poisoning of these functions in GCC?
Thanks,
Sebastian
On Fri, Nov 20, 2015 at 10:23 AM, Sven Verdoolaege wrote:
> On Fri, Nov 20, 2015 at 10:14:47AM -0600, Sebastian Pop wrote:
>> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
>> > Sebastian,
>> >
>> > I have tried to build GCC with Graphite and ISL on A
On Fri, Nov 20, 2015 at 10:43 AM, David Edelsohn wrote:
> On Fri, Nov 20, 2015 at 11:28 AM, Sebastian Pop wrote:
>> Thanks David for reporting these problems.
>>
>> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
>>> (2) All of the graphite*.c files in
d(__ARM_ARCH_6ZK__)
# define HAVE_STREX1
# define HAVE_STREXBHD 1
-#elif __ARM_ARCH__ == 6
+#elif __ARM_ARCH__ == 6 && !defined(__ARM_ARCH_6M__)
# define HAVE_STREX1
#endif
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +4
On 19/04/16 10:52, Sebastian Huber wrote:
Hello,
I tried to build the libatomic for RTEMS on ARM and I got this error:
make[2]: Entering directory
`/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/armv6-m/libatomic'
/bin/sh ./libtool --tag=CC --mode=compile
/build/git-bu
st" seemed to prevent this optimization. I
know that this linker set stuff is quite non-standard, but is there a
way to get this to work again on GCC 7?
The nice thing with the "type volatile const X[0]..." construct is that
you can generate arbitrary linker sets via it without a
On 22/09/16 14:11, Sergey Organov wrote:
Sebastian Huber writes:
Hello,
for RTEMS we use linker sets to initialize the system. The following
code worked up to GCC 6, but no longer in GCC 7:
typedef void ( *rtems_sysinit_handler )( void );
typedef struct {
rtems_sysinit_handler handler
00c4 t parse_unsigned_long
Thus the libgomp constructor is not linked in into executables.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP
- Alexander Monakov schrieb:
> Hello,
>
> On Tue, 29 Nov 2016, Sebastian Huber wrote:
> > * env.c: Split out ICV definitions into...
> > * icv.c: ...here (new file) and...
> > * icv-device.c: ...here. New file.
> >
> > the en
order and
command line order is related. The documentation doesn't mention
multilib and multiarch options.
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
If we assume that the command line order determines the search order,
then its not clear why for_each_path() first iterates f
Hallo Joseph,
On 05/12/16 23:02, Joseph Myers wrote:
On Mon, 5 Dec 2016, Sebastian Huber wrote:
If we assume that the command line order determines the search order, then its
not clear why for_each_path() first iterates for all paths with the multilib
postfix and then without. Shouldn'
On 06/12/16 18:09, Joseph Myers wrote:
On Tue, 6 Dec 2016, Sebastian Huber wrote:
thanks for the detailed explanation. I guess, then the root cause for my
problem is that the Newlib provided crt0.o files in the build tree are not in
the same relative location of the installation tree. In the
s intended?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilun
The Git mirror seems to have no gcc-4_9_0-release tag.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request
1 - 100 of 421 matches
Mail list logo
