[Bug target/56439] global and local register variables don't work in a useful way -- AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56439
Chung-Ju Wu changed:
What|Removed |Added
CC||jasonwucj at gmail dot com
--- Comment #5 from Chung-Ju Wu 2013-02-25
06:32:05 UTC ---
(In reply to comment #4)
> Wouldn't that be a reason /against/ doing this:
>
> mov r24,r4
> lsl r24
> mov r4,r24
>
> instead of just lsl r4?
Just guess...
Is that possibly related to zero_extend RTL transformation?
Either in gcc optimization, or the design of machine description?
Try to use this declaration (use 'int' instead of 'char'):
register unsigned int foo asm ("r4");
Is there any difference on code generation?
[Bug libstdc++/56437] basic_string assumes that allocators are default-constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56437 --- Comment #3 from Thomas Neumann 2013-02-25 06:31:43 UTC --- (In reply to comment #1) > This is hardly the only C++11 allocator requirement missing from std::string, > ALL of the new requirements are missing, and unlikely to be implemented until > we switch to a non-COW string implementation. Well, but this would be an allocator requirement that is easy to fix. There are only three places with "_Alloc()" in basic_string.tcc, and only two would have to be fixed as far as I can see it. I am not sure yet why the code even tries to construct the allocator, but if necessary we could use is_default_constructible to figure out of the constructor is available. I could try to produce a patch myself if you prefer. But as of new basic_string is quite unusable with stateful allocators.
[Bug target/56439] global and local register variables don't work in a useful way -- AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56439 --- Comment #4 from Robert "Finny" Merrill 2013-02-25 05:46:29 UTC --- Wouldn't that be a reason /against/ doing this: mov r24,r4 lsl r24 mov r4,r24 instead of just lsl r4?
[Bug target/56439] global and local register variables don't work in a useful way -- AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56439 --- Comment #3 from Andrew Pinski 2013-02-25 03:53:25 UTC --- (In reply to comment #2) > Any specific sections you can point me to? I'd be interested to hear a > justification for this behavior. Simple answer, an interrupt can happen any time after the access/assignment of the global register variable so it needs to be set to the value and treated as a volatile variable.
[Bug target/56439] global and local register variables don't work in a useful way -- AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56439 --- Comment #2 from Robert "Finny" Merrill 2013-02-25 03:30:47 UTC --- Any specific sections you can point me to? I'd be interested to hear a justification for this behavior.
[Bug target/56439] global and local register variables don't work in a useful way -- AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56439 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #1 from Andrew Pinski 2013-02-25 03:10:35 UTC --- I think this is correct behavior if you read the manual.
[Bug c/56439] New: global and local register variables don't work in a useful way -- AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56439
Bug #: 56439
Summary: global and local register variables don't work in a
useful way -- AVR
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rfmerr...@berkeley.edu
I am writing some interrupt code for an Atmel AVR microcontroller and I'm
trying to shave cycles off, specifically at the beginning of the interrupt. I
want to achieve this by minimizing the registers that need to be saved, so I
decided to declare a few variables as global register variables.
What I found is that GCC will "optimize away" the register assignment and
instead produce code that is almost what I want, except it copies the value in
and out of another register (allocated the usual way) instead of operating on
the assigned one.
For example the following C:
register unsigned char foo asm ("r4");
void baz();
void quux();
void bar() {
foo = foo * 2;
if (foo > 10)
baz();
else
quux();
}
generates the following assembly:
mov r24,r4
lsl r24
mov r4,r24
cpi r24,lo8(11)
brsh .L4
rjmp quux
.L4:
rjmp baz
It does the same thing (copy to r24, manipulate, copy back) on every
optimization level.
Surely this can't be desired behavior? If you use local register variables it's
often even worse, as gcc won't touch the assigned register at all but instead
produce identical code that uses a different register.
I'm fairly certain this shouldn't work this way...
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117
--- Comment #15 from Tilo Schwarz 2013-02-25 01:02:45
UTC ---
This week I used the Fortran namelist feature for the first time and I was
really impressed, that it does all the parsing for me.
But since I ran into this issue I was wondering and curious how the magic in
libgfortran works.
I had a look at the code and could observe the following:
If I apply the attached patch (comment 14, namelist.diff) on gcc version 4.8.0
20130224
- my example from comment 11 works
- the example from comment 3 seems to work
- the changed namelist_64.f90 from comment 13 works
- the example from PR 51825 seems to work
- make check-fortran runs with no additional errors
- the example from comment 6 (type extension) does not work
The type extension problem might be related to the fact, that gfortran does not
generate a namelist entry for the implicit component %x of t1e_t:
(no "t1e%x" below)
_gfortran_st_set_nml_var (&dt_parm.1, &t1e, &"t1e"[1]{lb: 1 sz: 1}, 0, 0,
40);
... maybe "t1e%x" should be here? ...
_gfortran_st_set_nml_var (&dt_parm.1, &t1e.t1_t, &"t1e%t1_t"[1]{lb: 1 sz: 1},
0, 0, 40);
_gfortran_st_set_nml_var (&dt_parm.1, &t1e.t1_t.x, &"t1e%t1_t%x"[1]{lb: 1 sz:
1}, 4, 0, 24);
_gfortran_st_set_nml_var (&dt_parm.1, &t1e.string, &"t1e%string"[1]{lb: 1 sz:
1}, 1, 8, 48);
_gfortran_st_set_nml_var (&dt_parm.1, &answer, &"answer"[1]{lb: 1 sz: 1}, 4,
0, 8);
So maybe this patch gives a hint to someone, who has a deeper understanding of
the io-stuff than me (looked at it this weekend for the first time) ...
Tilo
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #14 from Tilo Schwarz 2013-02-25 01:00:01 UTC --- Created attachment 29532 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29532 Namelist patch
[Bug libstdc++/56437] basic_string assumes that allocators are default-constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56437
--- Comment #2 from Jonathan Wakely 2013-02-25
00:11:16 UTC ---
C++11 allocators are not required to define any of these:
typedef T* pointer;
typedef const T* const_pointer;
typedef T& reference;
typedef const T& const_reference;
typedef unsigned size_type;
typedef int difference_type;
template struct rebind { typedef MyAllocator other; };
But if your allocator fails to define any of them then std::string (and some of
the other containers) will fail to compile. This is a known issue.
[Bug libstdc++/56437] basic_string assumes that allocators are default-constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56437 --- Comment #1 from Jonathan Wakely 2013-02-25 00:08:35 UTC --- This is hardly the only C++11 allocator requirement missing from std::string, ALL of the new requirements are missing, and unlikely to be implemented until we switch to a non-COW string implementation.
[Bug c++/56438] New: [4.8 regression] ICE in value_dependent_expression_p, at cp/pt.c:19551
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56438
Bug #: 56438
Summary: [4.8 regression] ICE in value_dependent_expression_p,
at cp/pt.c:19551
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: manisan...@gmail.com
gcc version 4.8.0 20130220 (Red Hat 4.8.0-0.14) (GCC)
g++ -c ice.cc
ice.cc: In function ‘void foo()’:
ice.cc:19:25: internal compiler error: in value_dependent_expression_p, at
cp/pt.c:19551
a << bar(b.size(), C());
^
== ice.cc ==
struct A { };
A& operator<<(A&, const char*);
struct B {
int size();
};
struct C { };
template
S bar(const S& s, const T& t) {
return s;
}
template
void foo() {
A a;
B b;
a << bar(b.size(), C());
}
===
gcc version 4.7.2 20121109 (Red Hat 4.7.2-9) (GCC), gives get the expected
result
g++ -c ice.cc
ice.cc: In function ‘void foo()’:
ice.cc:19:25: error: no match for ‘operator<<’ in ‘a << bar(b.B::size(), C())’
ice.cc:19:25: note: candidate is:
ice.cc:2:4: note: A& operator<<(A&, const char*)
ice.cc:2:4: note: no known conversion for argument 2 from ‘int’ to ‘const
char*’
[Bug libstdc++/56437] New: basic_string assumes that allocators are default-constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56437 Bug #: 56437 Summary: basic_string assumes that allocators are default-constructible Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: tneum...@pi3.informatik.uni-mannheim.de Created attachment 29531 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29531 example The empty-string optimization of basic_string assumes that allocators are default constructible. While this used to be the case in C++98, it is no longer true in C++11, as now allocators are allowed to have state. Consider the attached example program. Compiling with g++ -std=c++11 -c t.cpp produces an error message, even though it should compile fine. The problem is the the "_S_construct" calls "_Alloc()", which does not exist. Note that the C++11 standard does not require default constructors. (Section 17.6.3.5, Table 28). In particular, the SimpleAllocator example from Section 17.6.3.5 would trigger the same bug, too.
[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857
Andrew Ayer changed:
What|Removed |Added
CC||bugs at mm dot beanwood.com
--- Comment #4 from Andrew Ayer 2013-02-24
22:05:26 UTC ---
(In reply to comment #2)
> I want to understand how critical this additional underflow is,
> performance-wise
There are also correctness implications: what if you're trying to ignore
all the bytes you know are available to be read without blocking? Then
the extra underflow blocks, possibly forever if the program is prevented
from taking action that would result in the underflow completing.
I got bitten by this because I was trying to ignore data from a socket.
Note that the standard has similar language for read(char_type*,
streamsize) ("either of the following conditions") but the library in
effect checks for n characters being reached before checking for eof:
if you read() exactly the number of characters left in the stream,
eofbit is not set. So the library isn't currently consistent across
all the various istream functions.
I would argue that the current behavior of ignore() is actually contrary
to the standard. If the standard says "until any" then ignore()
needs to terminate when n characters have been extracted. But if it
first checks for eof and blocks forever, then it doesn't terminate.
Perhaps this is why getline explicitly mentions the order: in that case
the standard really does want eof to be checked first.
[Bug bootstrap/56424] [4.8 Regression] ICE at tree-inline.c:2833 on a-nllcef.ads at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56424 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot| |gnu.org | AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org Target Milestone|--- |4.8.0 --- Comment #3 from Eric Botcazou 2013-02-24 21:45:29 UTC --- Investigating.
[Bug bootstrap/56424] [4.8 Regression] ICE at tree-inline.c:2833 on a-nllcef.ads at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56424 --- Comment #2 from Rainer Emrich 2013-02-24 19:41:51 UTC --- Am 24.02.2013 17:05, schrieb ebotcazou at gcc dot gnu.org: > --- Comment #1 from Eric Botcazou 2013-02-24 > 16:05:44 UTC --- Confirmed, but libada isn't stage #3 since it's a target > library. Sorry, of course you are right.
[Bug c/56371] When building GCC from combined tree, configure is making wrong assumptions about 'gas' and 'ld'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56371 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #3 from Hans-Peter Nilsson 2013-02-24 19:33:22 UTC --- Related to PR54373, or at least similar.
[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555 --- Comment #14 from Jakub Jelinek 2013-02-24 18:54:42 UTC --- Author: jakub Date: Sun Feb 24 18:54:37 2013 New Revision: 196245 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196245 Log: PR target/52555 * target-globals.c (save_target_globals): For init_reg_sets and target_reinit remporarily set this_fn_optabs to this_target_optabs. Modified: trunk/gcc/ChangeLog trunk/gcc/target-globals.c
[Bug ada/56436] New: Documentation states restriction that's not enforced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56436
Bug #: 56436
Summary: Documentation states restriction that's not enforced
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: si...@pushface.org
Created attachment 29530
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29530
Patch to remove documentation inconsistency
gcc/ada/projects.texi states, for Spec_Suffix, that (amongst other rules)
It cannot start with an alphanumeric character
It cannot start with an underscore followed by an alphanumeric character
Neither of these rules is enforced, in other words this is legal:
project Prj is
package Naming is
for Spec_Suffix ("Ada") use "_s.ada";
for Body_Suffix ("Ada") use "_2.ada";
end Naming;
end Prj;
There is at least one user who uses _s.ada, _b.ada, so it should be appropriate
to remove the stated restriction as in the attached patch.
[Bug bootstrap/56424] [4.8 Regression] ICE at tree-inline.c:2833 on a-nllcef.ads at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56424 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-24 CC||ebotcazou at gcc dot ||gnu.org Summary|[4.8 Regression] bootstrap |[4.8 Regression] ICE at |fails in libada, gnat1 |tree-inline.c:2833 on |asserts in |a-nllcef.ads at -O2 |declare_return_variable, at | |tree-inline.c:2833 | Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2013-02-24 16:05:44 UTC --- Confirmed, but libada isn't stage #3 since it's a target library.
