Skip to content

Issue 9766 - align(n) with n compile-time constant#5750

Closed
9rnsr wants to merge 1 commit intodlang:masterfrom
9rnsr:fix9766
Closed

Issue 9766 - align(n) with n compile-time constant#5750
9rnsr wants to merge 1 commit intodlang:masterfrom
9rnsr:fix9766

Conversation

@9rnsr
Copy link
Contributor

@9rnsr 9rnsr commented May 9, 2016

Implement the feature.

@dlang-bot
Copy link
Contributor

Fix Bugzilla Description
9766 align(n) with n compile-time constant

@9rnsr
Copy link
Contributor Author

9rnsr commented May 9, 2016

Note that, under the current design of align attribute, we still cannot reset alignment to default by the CTFEed value.

@9rnsr
Copy link
Contributor Author

9rnsr commented May 9, 2016

PR for language spec: dlang/dlang.org#1293

src/attrib.d Outdated
return STRUCTALIGN_DEFAULT;

auto n = ealign.toInteger();
if (!tb.isunsigned() && n > long.max)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be simply:

n >= 1 && n < structalign_t.max;

Copy link
Contributor Author

@9rnsr 9rnsr May 9, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, n is dinteger_t, it's unsigned.

And when n is bigger than structalign_t.max, currently it's silently accepted.

https://github.com/dlang/dmd/pull/5750/files/891ecfbf40c6a7a657c897cff9ea804eee5f5dd0#diff-e55efe6f4373bd0f2e2da9a75322a544L981

dmd/src/parse.d

Line 981 in d28f6bb

n = cast(uint)token.uns64value;

Should I add a new error check in here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, n is dinteger_t , it's unsigned.

The signed-ness is actually irrelevant for the test. Your line also doesn't check for 0, and it's absurd to have alignments greater than long.max.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please read my repply. Currently alignment value greater than long.max is silently accepted. Your proposal would be legitimiate, but it's unrelated with the new feature implementation. Shouldn't it go to separated bugfix PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And, lack of check for 0 is my mistake. Will fix.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it go to separated bugfix PR?

Replicating an extremely minor bug just so it can be fixed later doesn't seem worthwhile.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug is bug. You've been rejected to do two things in a PR, so I follow the principle in here. If the bugfix is important, please file it to bugzilla by your hand.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really sorry, I was wrong. Even in current master, alignment value greater than structalign_t.max is rejected.

In

dmd/src/parse.d

Line 977 in d28f6bb

if (token.value == TOKint32v && token.uns64value > 0)

By the test token.value == TOKint32v, the upper boundary of parsed integer literal has been limited to uint.max...

I updated code to follow Walter's suggestion.

src/attrib.d Outdated
if (!tb.isunsigned() && n > long.max)
return showError();

salign = cast(structalign_t)n;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The downcast silently chops any values between stackalign_t.max and long.max. Please use the formula I gave, which won't do that.

@9rnsr
Copy link
Contributor Author

9rnsr commented May 9, 2016

I fix most of issues pointed out by @WalterBright.

@9rnsr 9rnsr force-pushed the fix9766 branch 4 times, most recently from 4178c61 to 60e6c7c Compare May 13, 2016 21:53
@qchikara
Copy link
Contributor

@9rnsr So amazing your quick play!
But..., I am sorry that I found to require a way to reset to the default, unfortunately.

I thik that we could use zero, -1, 0xffff, or something like ALIGN_DEFAULT.

Anyways, thank you for your favor.

@WalterBright
Copy link
Member

WalterBright commented Jun 17, 2016

comment deleted because it was wrong


sc = sc.startCTFE();
ealign = ealign.semantic(sc);
ealign = resolveProperties(sc, ealign);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems to me ctfeInterpret() should be put here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and then just do toInteger(), which will take care of most of the cases below. Then, just have one:

n >= 1 && n <= structalign_t.max && !(n & (n - 1))

should do it.

@WalterBright
Copy link
Member

Rebased and rebooted as #5880

@9rnsr 9rnsr deleted the fix9766 branch July 10, 2016 11:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants