Searched hist:8321 (Results 1 - 5 of 5) sorted by relevance

/gem5/site_scons/site_tools/
H A Dmercurial.py12558:81a22bff9cdc Wed Feb 14 13:38:00 EST 2018 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> scons: Import print_function from future

Scons on Fedora 27 imports print_function from the future[1] as a
result of which a gem5 build errors out with a syntax error. Make all
the scons scripts that use the print statement import the print_function
from future and replace the statements with print function calls.

[1] https://github.com/SCons/scons/commit/34cf3bdb1743de9a5534bfd25998d0a01297f004

Change-Id: I67b7ef978fd7567f94d3cd9a904f8a0c1af07ffb
Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/8321
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
H A Dgit.py12558:81a22bff9cdc Wed Feb 14 13:38:00 EST 2018 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> scons: Import print_function from future

Scons on Fedora 27 imports print_function from the future[1] as a
result of which a gem5 build errors out with a syntax error. Make all
the scons scripts that use the print statement import the print_function
from future and replace the statements with print function calls.

[1] https://github.com/SCons/scons/commit/34cf3bdb1743de9a5534bfd25998d0a01297f004

Change-Id: I67b7ef978fd7567f94d3cd9a904f8a0c1af07ffb
Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/8321
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
/gem5/site_scons/
H A Dsite_init.py12558:81a22bff9cdc Wed Feb 14 13:38:00 EST 2018 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> scons: Import print_function from future

Scons on Fedora 27 imports print_function from the future[1] as a
result of which a gem5 build errors out with a syntax error. Make all
the scons scripts that use the print statement import the print_function
from future and replace the statements with print function calls.

[1] https://github.com/SCons/scons/commit/34cf3bdb1743de9a5534bfd25998d0a01297f004

Change-Id: I67b7ef978fd7567f94d3cd9a904f8a0c1af07ffb
Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/8321
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
/gem5/src/python/m5/
H A Dparams.py8321:9f34cf472451 Mon May 23 17:29:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> config: reinstate implicit parenting on parameter assignment
Last summer's big rewrite of the initialization code (in
particular cset 6efc3672733b) got rid of the implicit parenting
that used to occur when an unparented SimObject was assigned as
a parameter value to another SimObject. The idea was that the
new adoptOrphanParams() step would catch these anyway so it was
unnecessary.

Unfortunately it turns out that adoptOrphanParams() has some
inherent instability in that the parent that does the adoption
depends on the config tree traversal order. Even making this
order deterministic (e.g., by traversing children in
alphabetical order) can introduce unwanted and unexpected
hierarchy changes between similar configs (e.g., when adding a
switch_cpu in place of a cpu), causing problems when trying to
restore checkpoints across similar configs. The hierarchy
created by implicit parenting is more stable and more
controllable, so this patch turns that behavior back on.

This patch also cleans up some long-standing holes regarding
parenting of SimObjects that are created in class definitions
(either in the body of the class, or as default parameters).

To avoid breaking some existing config files, this necessitated
changing the error on reparenting children to a warning. This
change fixes another bug where attempting to print the prior
error message would fail on reparenting SimObjectVectors
because they lack a _parent attribute. Some further issues
with SimObjectVectors were cleaned up by getting rid of the
get_parent() call (which could cause errors with some
SimObjectVectors where there was no single parent to return)
with has_parent() (since all the uses of get_parent() were just
boolean tests anyway).

Finally, since the adoptOrphanParam() step turned out to be so
problematic, we now issue a warning when it actually has to do
an adoption. Future cleanup of config files will get rid of
current warnings.
H A DSimObject.py8321:9f34cf472451 Mon May 23 17:29:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> config: reinstate implicit parenting on parameter assignment
Last summer's big rewrite of the initialization code (in
particular cset 6efc3672733b) got rid of the implicit parenting
that used to occur when an unparented SimObject was assigned as
a parameter value to another SimObject. The idea was that the
new adoptOrphanParams() step would catch these anyway so it was
unnecessary.

Unfortunately it turns out that adoptOrphanParams() has some
inherent instability in that the parent that does the adoption
depends on the config tree traversal order. Even making this
order deterministic (e.g., by traversing children in
alphabetical order) can introduce unwanted and unexpected
hierarchy changes between similar configs (e.g., when adding a
switch_cpu in place of a cpu), causing problems when trying to
restore checkpoints across similar configs. The hierarchy
created by implicit parenting is more stable and more
controllable, so this patch turns that behavior back on.

This patch also cleans up some long-standing holes regarding
parenting of SimObjects that are created in class definitions
(either in the body of the class, or as default parameters).

To avoid breaking some existing config files, this necessitated
changing the error on reparenting children to a warning. This
change fixes another bug where attempting to print the prior
error message would fail on reparenting SimObjectVectors
because they lack a _parent attribute. Some further issues
with SimObjectVectors were cleaned up by getting rid of the
get_parent() call (which could cause errors with some
SimObjectVectors where there was no single parent to return)
with has_parent() (since all the uses of get_parent() were just
boolean tests anyway).

Finally, since the adoptOrphanParam() step turned out to be so
problematic, we now issue a warning when it actually has to do
an adoption. Future cleanup of config files will get rid of
current warnings.

Completed in 36 milliseconds