[Bug target/57949] [powerpc64] Structure parameter alignment issue with vector extensions

[wschmidt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949

--- Comment #7 from Bill Schmidt  ---
I rewrote the test case to use the IBM vector extensions and ran it through
xlc.  The generated code shows that xlc addresses the code as expected by the
ABI (and contrary to what's done by gcc).  So this adds weight to the argument
that gcc should change its default behavior, and provide an option to generate
code for the old behavior when necessary.

[Bug rtl-optimization/58034] New: glibc nptl/tst-cleanup2 fail due to scheduling

[amodra at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034

Bug ID: 58034
   Summary: glibc nptl/tst-cleanup2 fail due to scheduling
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com

Created attachment 30575
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30575&action=edit
preprocessed test case

nprl/tst-cleanup2 fails when compiled with -O2 -mcpu=power6 due to sched1
moving an assignment to a REG over code that traps.

The relevant test case source:

  if (setjmp (jmpbuf))
{
  puts ("Exiting main...");
  return 0;
}

  sprintf (p, "This should segv\n");

  return 1;
}

The sprintf is optimised to three loads and stores.  The problem occurs due to
the assignment of 1 to the REG holding the function return value being
scheduled before the sprintf expansion.

[Bug rtl-optimization/58033] counterproductive bb-reorder

[tejohnson at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58033

--- Comment #4 from Teresa Johnson  ---
On Tue, Jul 30, 2013 at 2:40 PM, olegendo at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58033
>
> --- Comment #3 from Oleg Endo  ---
> Created attachment 30574
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30574&action=edit
> bbro dump
>
> (In reply to Teresa Johnson from comment #2)
>>
>> I assume it is the above branch that is the issue (not the bf/s .L2
>> below as that is the same in both versions of the code). I'm assuming
>> this is not build with FDO?
>
> Right, no FDO.
>
>> In that case bbro is probably at the mercy
>> of whatever probabilities the static heuristics assigned to the
>> branches. Although if it is 50-50 then I'm not sure offhand what
>> happens - maybe it is biasing in favor of having the shortest trace?
>> This is a great test case for motivating range propagation. =)

Thanks for the dump. The issue is the heuristically assigned edge frequencies:

;;  succ:   6 [29.0%]  (FALLTHRU,CAN_FALLTHRU)
;;  4 [71.0%]  (CAN_FALLTHRU)

BB 6 contains the code within the then clause that is in fact always
executed. But it is being assigned only 29% probability, which is why
bbro lays out the code as it does.

I'm not familiar with the static edge weight heuristics in gcc, but it
would be interesting to see why it is predicting that the if statement
will be false.

Teresa

>>
>> Can you attach the dump created with -fdump-rtl-bbro-all? We can see
>> what the edge probabilities are. For some reason it is not compiling
>> for me - what options do you use? My (4_7-based) g++ is complaining
>> about the "auto":
>
> Sorry, it's C++11, so you need to specify -std=c++11.
>
> Here's a C++03 version, which on my setup (4.9 trunk rev 201282) results in
> exactly the same code:
>
> #include 
>
> std::bitset<32> make_bits2 (void)
> {
>   static const int ii[] = { 4, 5, 6, 10 };
>   std::bitset<32> r;
>   for (int i = 0; i < 4; ++i)
> if (ii[i] < r.size ())
>   r.set (ii[i]);
>
>   return r;
> }
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/58032] Bogus error: declared using local type ..., is used but never defined

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58032

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Paolo Carlini  ---
AFAICS this never worked. It's a dup of PR51048.

*** This bug has been marked as a duplicate of bug 51048 ***

[Bug c++/51048] Class template inheritance doesn't work well with function-local types

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51048

Paolo Carlini  changed:

   What|Removed |Added

 CC||ppluzhnikov at google dot com

--- Comment #2 from Paolo Carlini  ---
*** Bug 58032 has been marked as a duplicate of this bug. ***

[Bug middle-end/57748] [4.8/4.9 Regression] ICE on ARM with -mfloat-abi=softfp -mfpu=neon

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #8 from Bernd Edlinger  ---
(In reply to Martin Jambor from comment #7)
> In any event, it is clear that
> the code in expand_assignment cannot cope with unaligned tem and non-NULL
> offset.  So currently I'm considering the following patch, although I am not
> really sure it is enough (it does fix the ICE, though).  If you can run the
> testcase on the platform, would you run it with this patch applied, please?

No, unfortunately I can only look at the assembler listing.

But wait a moment...

If the object is assumed to be unaligned here this patch will
likely just compute the unaligned address, add the offset,
and store the result there without any special precautions.
While the code in the if statement seems to store the expression
on a register and move that register to the final destination.

Well, I believe this unaligned arrays are generally broken.

consider this example:

struct test
{
  char x;
  long long y[10];
} __attribute__((packed));

long long foo(struct test *x, long long y, long long z)
{
   long long a = x->y[y];
   x->y[y] = z;
   return a;
}

gets compiled to:

foo:
@ Function supports interworking.
@ args = 8, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
stmfd   sp!, {r4, r5}
add r5, sp, #8
ldmia   r5, {r4-r5}
add r2, r0, r2, asl #3
add r1, r2, #1
ldmia   r1, {r0-r1}
str r4, [r2, #1]
str r5, [r2, #5]
ldmfd   sp!, {r4, r5}
bx  lr

Won't these ldmia statements statements fault on unaligned
addresses, even on a cortex-a9 ?

Furthermore str on odd addresses are always there, regardless of the
-mno-unaligned-access setting.

[Bug c++/57673] pack sizeof ... groups ellipsis with preceding expression

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57673

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Paolo Carlini  ---
Fixed for 4.9.0.

[Bug rtl-optimization/58033] counterproductive bb-reorder

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58033

--- Comment #3 from Oleg Endo  ---
Created attachment 30574
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30574&action=edit
bbro dump

(In reply to Teresa Johnson from comment #2)
> 
> I assume it is the above branch that is the issue (not the bf/s .L2
> below as that is the same in both versions of the code). I'm assuming
> this is not build with FDO?

Right, no FDO.

> In that case bbro is probably at the mercy
> of whatever probabilities the static heuristics assigned to the
> branches. Although if it is 50-50 then I'm not sure offhand what
> happens - maybe it is biasing in favor of having the shortest trace?
> This is a great test case for motivating range propagation. =)
> 
> Can you attach the dump created with -fdump-rtl-bbro-all? We can see
> what the edge probabilities are. For some reason it is not compiling
> for me - what options do you use? My (4_7-based) g++ is complaining
> about the "auto":

Sorry, it's C++11, so you need to specify -std=c++11.

Here's a C++03 version, which on my setup (4.9 trunk rev 201282) results in
exactly the same code:

#include 

std::bitset<32> make_bits2 (void)
{
  static const int ii[] = { 4, 5, 6, 10 };
  std::bitset<32> r;
  for (int i = 0; i < 4; ++i)
if (ii[i] < r.size ())
  r.set (ii[i]);

  return r;
}

[Bug rtl-optimization/58033] counterproductive bb-reorder

[tejohnson at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58033

--- Comment #2 from Teresa Johnson  ---
On Tue, Jul 30, 2013 at 2:00 PM, olegendo at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58033
>
> Bug ID: 58033
>Summary: counterproductive bb-reorder
>Product: gcc
>Version: 4.9.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: rtl-optimization
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: olegendo at gcc dot gnu.org
> CC: steven at gcc dot gnu.org, tejohnson at google dot com
> Target: sh*-*-*
>
> On SH, compiling the following code with -O2
>
> #include 
>
> std::bitset<32> make_bits (void)
> {
>   std::bitset<32> r;
>   for (auto&& i : { 4, 5, 6, 10 })
> if (i < r.size ())
>   r.set (i);
>
>   return r;
> }
>
> results in the following code:
>
> mov.l   .L8,r1
> mov #0,r0
> mov #31,r7
> mov #1,r6
> mov #4,r2
> .L2:
> mov.l   @r1,r3
> cmp/hi  r7,r3
> bf/s.L7

I assume it is the above branch that is the issue (not the bf/s .L2
below as that is the same in both versions of the code). I'm assuming
this is not build with FDO? In that case bbro is probably at the mercy
of whatever probabilities the static heuristics assigned to the
branches. Although if it is 50-50 then I'm not sure offhand what
happens - maybe it is biasing in favor of having the shortest trace?
This is a great test case for motivating range propagation. =)

Can you attach the dump created with -fdump-rtl-bbro-all? We can see
what the edge probabilities are. For some reason it is not compiling
for me - what options do you use? My (4_7-based) g++ is complaining
about the "auto":

$ g++ -O2 pr58033.cc -S
pr58033.cc: In function 'std::bitset<32ul> make_bits()':
pr58033.cc:6:12: error: expected unqualified-id before '&&' token
   for (auto&& i : { 4, 5, 6, 10 })

Teresa

> mov r6,r5
> .L3:
> dt  r2
> bf/s.L2 // branch if value not > 31, i.e. in each iteration
> add #4,r1
> rts
> nop
> .align 1
> .L7:
> shldr3,r5
> bra .L3
> or  r5,r0
> .L9:
> .align 2
> .L8:
> .long   _._45+0
>
> _._45:
> .long   4
> .long   5
> .long   6
> .long   10
>
> Disabling the bb-reorder pass or using -Os results in more compact and faster
> code:
>
> mov.l   .L7,r1
> mov #0,r0
> mov #31,r7
> mov #1,r6
> mov #4,r2
> .L2:
> mov.l   @r1,r3
> cmp/hi  r7,r3
> bt/s.L3// branch if value > 31, i.e. never.
> mov r6,r5
> shldr3,r5
> or  r5,r0
> .L3:
> dt  r2
> bf/s.L2
> add #4,r1
> rts
> nop
>
> Of course the bb-reorder pass doesn't know that the values in this case are
> always in range.  Still, maybe it could be improved by not splitting out a BB
> if it consists only of a few insns?  I've tried increasing the branch cost but
> it won't do anything.
>
> Teresa, Steven,
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug rtl-optimization/58033] counterproductive bb-reorder

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58033

--- Comment #1 from Oleg Endo  ---
... according to the changelog you've been doing some things on bb-reorder.c,
maybe you have an idea?

[Bug rtl-optimization/58033] New: counterproductive bb-reorder

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58033

Bug ID: 58033
   Summary: counterproductive bb-reorder
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
CC: steven at gcc dot gnu.org, tejohnson at google dot com
Target: sh*-*-*

On SH, compiling the following code with -O2

#include 

std::bitset<32> make_bits (void)
{
  std::bitset<32> r;
  for (auto&& i : { 4, 5, 6, 10 })
if (i < r.size ())
  r.set (i);

  return r;
}

results in the following code:

mov.l   .L8,r1
mov #0,r0
mov #31,r7
mov #1,r6
mov #4,r2
.L2:
mov.l   @r1,r3
cmp/hi  r7,r3
bf/s.L7
mov r6,r5
.L3:
dt  r2
bf/s.L2 // branch if value not > 31, i.e. in each iteration
add #4,r1
rts
nop
.align 1
.L7:
shldr3,r5
bra .L3
or  r5,r0
.L9:
.align 2
.L8:
.long   _._45+0

_._45:
.long   4
.long   5
.long   6
.long   10

Disabling the bb-reorder pass or using -Os results in more compact and faster
code:

mov.l   .L7,r1
mov #0,r0
mov #31,r7
mov #1,r6
mov #4,r2
.L2:
mov.l   @r1,r3
cmp/hi  r7,r3
bt/s.L3// branch if value > 31, i.e. never.
mov r6,r5
shldr3,r5
or  r5,r0
.L3:
dt  r2
bf/s.L2
add #4,r1
rts
nop

Of course the bb-reorder pass doesn't know that the values in this case are
always in range.  Still, maybe it could be improved by not splitting out a BB
if it consists only of a few insns?  I've tried increasing the branch cost but
it won't do anything.

Teresa, Steven,

[Bug target/54682] [SH] Replace constant loads with reg-reg copies

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54682

--- Comment #2 from Oleg Endo  ---
A related case, but the other way around:

#include 

std::bitset<32> make_bits (void)
{
  std::bitset<32> r;
  for (auto&& i : { 4, 5, 6, 10 })
if (i < r.size ())
  r.set (i);

  return r;
}

results in the following code (-O2):

mov.l   .L8,r1
mov #0,r0
mov #31,r7
mov #1,r6   // load constant '1' for '1 << x'
mov #4,r2
.L2:
mov.l   @r1,r3
cmp/hi  r7,r3
bf/s.L7
mov r6,r5   // copy constant '1' to r5
.L3:
dt  r2
bf/s.L2
add #4,r1
rts
nop
.align 1
.L7:
shldr3,r5  // r5 <<= r3
bra .L3
or  r5,r0

In this case one register is used to hold an imm8 constant that can be loaded
with a single insn.  Even though the insn 'mov Rm,Rn' is a zero-latency on SH4
and SH2A, freeing one register might result in better overall code.

[Bug c++/58032] New: Bogus error: declared using local type ..., is used but never defined

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58032

Bug ID: 58032
   Summary: Bogus error: declared using local type ..., is used
but never defined
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Google ref: b/9771363

Test:

template 
struct ResultCallback {
  virtual void Run(T) = 0;
};

template 
struct FunctionResultCallback: public ResultCallback {
  void Run(T a) { }
};

template 
ResultCallback*
NewCallback(void (*function)(T))
{
  return new FunctionResultCallback;
}

int main(int argc, char** argv) {
  struct Bar {
static void Do(Bar*) { }
  };
  NewCallback(&Bar::Do)->Run(0);
}


Using
g++ (GCC) 4.9.0 20130730 (experimental)

pp.ii:3:16: error: 'void ResultCallback::Run(T) [with T = main(int,
char**)::Bar*]', declared using local type 'main(int, char**)::Bar', is used
but never defined [-fpermissive]
   virtual void Run(T) = 0;
^

Broken since at least 4.7

[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001

--- Comment #8 from Steve Kargl  ---
On Tue, Jul 30, 2013 at 06:16:27PM +, dominiq at lps dot ens.fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001
> 
> --- Comment #7 from Dominique d'Humieres  ---
> > With -Wno-tabs, gfortran should report a warning for the
> > occurence of every tab used in the context of a character
> > from the Fortran character set.  Taking your code, which I've
> > deleted here, and replace all whitespace by tabs, I get the
> > expected number of warnings.  Historically, I wanted to use
> > -Wtabs as you expected, but there was too much wailing on 
> > the gfortran lists, so it was changed to -Wno-tabs with the
> > meaning that "no tabs are allowed" in the context of the
> > Fortran character set.  You'll notice that tabs within
> > a literal character string are not flagged.
> 
> I cannot understand the rationale of this choice, but I guess it's too late to
> change it!-(
> 
> > The history of -Wtabs verse -Wno-tabs can be found in the mailinglist
> > archive.
> 
> No interest to dig the archives on this issue.

http://gcc.gnu.org/ml/fortran/2006-03/msg00226.html

[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001

--- Comment #7 from Dominique d'Humieres  ---
> With -Wno-tabs, gfortran should report a warning for the
> occurence of every tab used in the context of a character
> from the Fortran character set.  Taking your code, which I've
> deleted here, and replace all whitespace by tabs, I get the
> expected number of warnings.  Historically, I wanted to use
> -Wtabs as you expected, but there was too much wailing on 
> the gfortran lists, so it was changed to -Wno-tabs with the
> meaning that "no tabs are allowed" in the context of the
> Fortran character set.  You'll notice that tabs within
> a literal character string are not flagged.

I cannot understand the rationale of this choice, but I guess it's too late to
change it!-(

> The history of -Wtabs verse -Wno-tabs can be found in the mailinglist
> archive.

No interest to dig the archives on this issue.

[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001

--- Comment #6 from Steve Kargl  ---
On Tue, Jul 30, 2013 at 12:59:00PM +, dominiq at lps dot ens.fr wrote:
> 
> If compiled with -Wno-tabs, it gives
> 
> pr58001.f90:2.1:
> 
>  print 1894
>  1
> Warning: Nonconforming tab character at (1)
> pr58001.f90:3.14:
> 
> 1894  format( '123')
>   1
> Warning: Nonconforming tab character at (1)
> pr58001.f90:3.14:
> 
> 1894  format( '123')
>   1
> Warning: Extension: Tab character in format at (1)
> 
> Is this the expected behavior?

With -Wno-tabs, gfortran should report a warning for the
occurence of every tab used in the context of a character
from the Fortran character set.  Taking your code, which I've
deleted here, and replace all whitespace by tabs, I get the
expected number of warnings.  Historically, I wanted to use
-Wtabs as you expected, but there was too much wailing on 
the gfortran lists, so it was changed to -Wno-tabs with the
meaning that "no tabs are allowed" in the context of the
Fortran character set.  You'll notice that tabs within
a literal character string are not flagged.  The history
of -Wtabs verse -Wno-tabs can be found in the mailinglist
archive.

Now, for the problem at hand, it seems that there is a
bug in io.c.   Here the code in question:


/* Eat up the spaces and return a character.  */

static char
next_char_not_space (bool *error)
{
  char c;
  do
{
  error_element = c = next_char (NONSTRING);
  if (c == '\t')
{
  if (gfc_option.allow_std & GFC_STD_GNU)
gfc_warning ("Extension: Tab character in format at %C");
  else
{
  gfc_error ("Extension: Tab character in format at %C");
  *error = true;
  return c;
}
}
}
  while (gfc_is_whitespace (c));
  return c;
}

Notice that there is no check for gfc_option.warn_tabs.

[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001

--- Comment #5 from Dominique d'Humieres  ---
Created attachment 30573
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30573&action=edit
test case with tabs

[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001

--- Comment #4 from Dominique d'Humieres  ---
> According to both vi and nedit, there are no tabs in the
> above code.  I assume that this is cut-n-paste from an
> xterm term.

With Safari I see the tabs in comment #2, but not in what has been pasted in
comment #3. I am attaching the code.

[Bug libfortran/58020] Code for handling IEEE exceptions

[fkrogh#gcc at mathalacarte dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020

--- Comment #9 from Fred Krogh  ---
Concering Fortran language standards, our guru is W. Van Snyder a long time
member of the Fortran Standards committee.  He has said to me in an email:
"It's OK not to support stuff, but the inquiry functions have to be there to
tell you."

[Bug fortran/58023] [F03] ICE on invalid with bad PPC declaration

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58023

--- Comment #5 from janus at gcc dot gnu.org ---
Comment 0 can be fixed by the following additional hunk in resolve.c:


@@ -12148,7 +12147,7 @@ resolve_fl_derived0 (gfc_symbol *sym)
 "must have at least one argument",
 c->name, &c->loc);
  c->tb->error = 1;
- return false;
+ continue;
}
  me_arg = c->ts.interface->formal->sym;
}

[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001

--- Comment #3 from Steve Kargl  ---
On Tue, Jul 30, 2013 at 12:59:00PM +, dominiq at lps dot ens.fr wrote:
> 
>   print *, "AstringwithTabsinsteadofspaces"
> print 1894
> 1894  format('123')
>   end
> 

According to both vi and nedit, there are no tabs in the
above code.  I assume that this is cut-n-paste from an
xterm term.

[Bug libfortran/58020] Code for handling IEEE exceptions

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020

--- Comment #8 from Steve Kargl  ---
On Tue, Jul 30, 2013 at 05:31:01PM +, dominiq at lps dot ens.fr wrote:
> 
> with -m32. The gfortran rationale is that Z'FF80' is converted to the
> highest integer kind (8 with -m32 or 16 with -m64) as 2**32-8388608, i.e., a
> positive number larger that huge(1)=2**31-1.

It is not a gfortran rationale.  It is what the Fortran mandates!

[Bug fortran/58023] [F03] ICE on invalid with bad PPC declaration

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58023

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> Draft patch:

Unfortunately, this patch only fixes comment 1, but not comment 0!

[Bug libfortran/58020] Code for handling IEEE exceptions

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020

--- Comment #7 from Dominique d'Humieres  ---
> I see your bug report. There are two matters to track down here. 
> The first one is the diagnostic of 'PR58027'. This may require you 
> to report a line number. That would be great. Testing that I have 
> done is with the gfortran compiler on Krogh's machine and my own 
> with the Intel compiler. I do not have access to the machine you 
> are using.

The ICE leading to PR58027 is

[macbook] bug/IEEE_1% gfc -c IEEE_tests_gfortran.f90
IEEE_tests_gfortran.f90: In function 'ieee_tests':
IEEE_tests_gfortran.f90:304:0: internal compiler error: in
gfc_conv_array_initializer, at fortran/trans-array.c:5512
 SA=transfer(ISCLASS(I),SA)

However any use of ISCLASS leads to the ICE because the parameter array is not
built. To understand why, I have compiled the following test

integer, parameter :: isclass = Z'FF80'
end

and got

isclass_2.f90:1.35:

integer, parameter :: isclass = Z'FF80'
   1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1). This
check can be disabled with the option -fno-range-check

with -m64 and

isclass_2.f90:1.35:

integer, parameter :: isclass = Z'FF80'
   1
Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1). This
check can be disabled with the option -fno-range-check

with -m32. The gfortran rationale is that Z'FF80' is converted to the
highest integer kind (8 with -m32 or 16 with -m64) as 2**32-8388608, i.e., a
positive number larger that huge(1)=2**31-1.

> The second matter is the difference in a line of output. That is the
> printing of the 4 digit approximation to \pi. The internal constant \pi
> itself comes from the stored value in the x87. The output of the number
> comes from the routine messy. I expect the hardware value is correct. So
> one machine writes 3.141 wit messy, and the other 3.142.

Apparently 'CALL IEEE_SET_ROUNDING_MODE(IEEE_TO_ZERO)' propagates into

call messy(E,'$N Double precision rounding mode IEEE_DOWN&
  & for \pi ~= $R agrees with IEEE_TO_ZERO.',rdat=[DA])

If I add

  CALL IEEE_SET_ROUNDING_MODE(IEEE_NEAREST)

before the line

  IF(DC == DA) THEN ! Round down should agree withround to zero, here.

then my output matches the one in list.

[Bug c++/55004] [meta-bug] constexpr issues

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004

Bug 55004 depends on bug 57901, which changed state.

Bug 57901 Summary: [4.8/4.9 Regression] Cannot call-by-value such that class 
has non-trivial (constexpr) move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57901

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/57901] [4.8/4.9 Regression] Cannot call-by-value such that class has non-trivial (constexpr) move constructor

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57901

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Jason Merrill  ---
Fixed for 4.8.2/4.9.0.

[Bug c++/58022] [4.8 Regression] Compiler rejects abstract class in template class with friend operator<

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58022

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #5 from Jason Merrill  ---
Fixed for 4.8.2

[Bug c++/57947] internal compiler error: Segmentation fault using extended initializer lists without -std=c++11 or -std=gnu++11

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57947

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Paolo Carlini  ---
Fixed.

[Bug c++/57673] pack sizeof ... groups ellipsis with preceding expression

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57673

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.9.0

--- Comment #3 from Paolo Carlini  ---
Mine.

[Bug c++/58031] New: invalid class template partial specialization accepted where argument list identical to primary template

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58031

Bug ID: 58031
   Summary: invalid class template partial specialization accepted
where argument list identical to primary template
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

template class T>
  struct X
  { };

  template class T>
  struct X
  { };

  template struct Y { };

  X x;

The partial specialization is ill-formed, 14.5.5 [temp.class.spec] p8 says

  Within the argument list of a class template partial specialization,
  the following restrictions apply:
   - [...]
   - [...]
   - The argument list of the specialization shall not be identical
 to the implicit argument list of the primary template.

The implicit argument list of the primary template is T, which is identical to
that of the partial specialization.

Clang and MSVC reject it.

[Bug target/57989] gcc for ARM defines __ARM_FEATURE_SIMD32, but does provide SIMD32 (ARMv6) intrinsics

[rearnsha at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57989

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-07-30
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
Implementing ACLE is work-in-progress.  It's unfortunate that this define was
added before the intrinsics were.

[Bug c++/57673] pack sizeof ... groups ellipsis with preceding expression

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57673

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-07-30
 Ever confirmed|0   |1

--- Comment #2 from Paolo Carlini  ---
With current mainline and 4_8-branch, I can only reproduce the problem with
d::n, not that with d::m. g is in any case fine.

[Bug rtl-optimization/58029] base_alias_check says pretend-args saves and varargs accesses don't alias

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58029

--- Comment #1 from Jorn Wolfgang Rennecke  ---
Created attachment 30572
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30572&action=edit
patch

This patch fixes the problem for the epiphany, however, it appears to
cause 37 guality regressions for i686-pc-linuc-gnu - looking in the log
file, I find numerous instances where gdb just says  .

[Bug libstdc++/58030] Mismatched tags in std::hash friends

[bluescarni at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58030

--- Comment #3 from Francesco Biscani  ---
Sorry, I did search for "mismatched tags" but it seemed like nothing came up :/

Thanks for taking the time to reply.

[Bug libstdc++/58030] Mismatched tags in std::hash friends

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58030

--- Comment #2 from Jonathan Wakely  ---
There's nothing to "fix", the code is correct, the warning is stupid.

[Bug libstdc++/56627] class hash instead of struct hash

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627

Jonathan Wakely  changed:

   What|Removed |Added

 CC||bluescarni at gmail dot com

--- Comment #12 from Jonathan Wakely  ---
*** Bug 58030 has been marked as a duplicate of this bug. ***

[Bug libstdc++/58030] Mismatched tags in std::hash friends

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58030

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan Wakely  ---
Did you even try using the search feature?!

You don't even need to search, when you typed in the bug summary it would have
shown the existing report in the results.

*** This bug has been marked as a duplicate of bug 56627 ***

[Bug middle-end/57748] [4.8/4.9 Regression] ICE on ARM with -mfloat-abi=softfp -mfpu=neon

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #7 from Martin Jambor  ---
(In reply to Bernd Edlinger from comment #6)
> hhmm..
> 
> set_ptr_info_alignment is always called with align=4,
> and by the way, the crash goes away if I change this line
> (but I cannot tell if the code is correct):

No, the comment is a bit misleading but this change is incorrect and
would lead to misaligned access traps.

The returned alignment is OK because MALLOC_ABI_ALIGNMENT is 32 and
the pointer the problematic MEM_REF is based on is a result of calloc.
So it is the old value that is incorrect.  If MALLOC_ABI_ALIGNMENT is
incorrectly low for this target, increasing it to the correct value
will make the ICE go away.

In any event, it is clear that the code in expand_assignment cannot
cope with unaligned tem and non-NULL offset.  So currently I'm
considering the following patch, although I am not really sure it is
enough (it does fix the ICE, though).  If you can run the testcase on
the platform, would you run it with this patch applied, please?


diff --git a/gcc/expr.c b/gcc/expr.c
index 2c5f21a..267174b 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -4707,6 +4707,7 @@ expand_assignment (tree to, tree from, bool nontemporal)
   mode = TYPE_MODE (TREE_TYPE (tem));
   if (TREE_CODE (tem) == MEM_REF
  && mode != BLKmode
+ && !offset
  && ((align = get_object_alignment (tem))
  < GET_MODE_ALIGNMENT (mode))
  && ((icode = optab_handler (movmisalign_optab, mode))

[Bug libstdc++/58030] New: Mismatched tags in std::hash friends

[bluescarni at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58030

Bug ID: 58030
   Summary: Mismatched tags in std::hash friends
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bluescarni at gmail dot com

I am testing out clang in conjunction with GCC 4.8.1's libstdc++ in c++11 mode.
I routinely get these warnings when compiling with -Wall and -Wextra:

---

/home/yardbird/repos/piranha/src/rational.hpp:1753:1: warning: 'hash' defined
as a struct template here but previously declared as
  a class template [-Wmismatched-tags]
struct hash
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../include/c++/4.8.1/bits/stl_bvector.h:523:31:
note: did you mean struct here?
template friend class hash;
  ^
/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../include/c++/4.8.1/bitset:763:33:
note: did you mean struct here?
  template friend class hash;
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../include/c++/4.8.1/bits/stl_bvector.h:523:31:
note: did you mean struct here?
template friend class hash;
  ^

---

Indeed, these friendship declarations in bitset and stl_bvector.h use 'class'
instead of 'struct' when referring to std::hash. It is my understanding that
this behaviour does not constitute a violation of the standard... still it irks
my compiler warnings OCD :)

Any chance this could be fixed sometimes?

[Bug libfortran/58020] Code for handling IEEE exceptions

[richard.koolhans at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020

--- Comment #6 from richard.koolhans at gmail dot com ---
Bonjour Dominique-
Le reste sera l'anglais! Voilà pour mon cours de français.

I see your bug report. There are two matters to track down here. The first
one is the diagnostic of 'PR58027'. This may require you to report a line
number. That would be great. Testing that I have done is with the gfortran
compiler on Krogh's machine and my own with the Intel compiler. I do not
have access to the machine you are using.

The second matter is the difference in a line of output. That is the
printing of the 4 digit approximation to \pi. The internal constant \pi
itself comes from the stored value in the x87. The output of the number
comes from the routine messy. I expect the hardware value is correct. So
one machine writes 3.141 wit messy, and the other 3.142.

I appreciate the feedback. Hope we can find the issues and clear them up.

Richard

[Bug fortran/58026] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1521

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58026

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> Draft patch:

... seems to regtest cleanly.

[Bug libfortran/58020] Code for handling IEEE exceptions

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020

--- Comment #5 from Tobias Burnus  ---
Cross-ref: See also PR29383.

(In reply to Fred Krogh from comment #0)
> Dr. Richard Hanson has written code to provide IEEE exception handling to
> gfortran.

Cool! I think it should be linked from the Wiki and somewhat made known. Even
prior (or without) inclusion in GCC/gfortran, the code is very useful for
users!


(In reply to kargl from comment #1)
> 1) Hanson needs to have a copyright assignment on file with FSF
>before the code can be used.

Or rather: Before it can be included in GCC/shipped with gfortran.

(In reply to Fred Krogh from comment #2)
> 1. Hanson is willing to assign the copyright if you expect to be using this
> work.  There were thoughts to include this work on a SIAM website where we
> think SIAM would want the copyright

The Free Software Foundation (FSF) only requires a nonexclusive copyright
transfer (for inclusion in GCC). Thus, it could be additionally posted to the
SIAM webpage - assuming SIAM also is fine with a nonexclusive copyright
transfer. See http://gcc.gnu.org/wiki/GettingStarted (Basics, Item 1) for
details.


(In reply to kargl from comment #1)
> 2) More importantly, the code appears to only support the i386
>and amd64 architectures.  gfortran runs are far more processors
>than these.

My personal long-term plan is to add the necessary bits for IEEE to
libgfortran/config/ - and then to use them from there. Currently supported are
setting/getting the rounding mode, obtaining the set exceptions flags and
setting the exception trapping. That's supported for i386/x86-64, GLIBC, SysV
(at least: FreeBSD and Solaris) and AIX; see
http://gcc.gnu.org/viewcvs/gcc/trunk/libgfortran/config/

[Note: Those are currently only internally exported. Before making them
externally callable, one should ensure that the ABI won't change.]

Additionally, I'd like to generate the IEEE modules "on the fly" - like
ISO_C_Binding and Fortran_Dev. That gives some more optimization possibilities
and also could be used to honor SH's/Alpha's -mieee compiler flag.


One way forward would be to check whether libgfortran/config/'s function are
sufficient - and if not, add more or modify the ABI. Those could then be
exported (public ABI).

In principle, one could then also ship the modules - However, the biggest
question is how to handle the functions in the module. Those then become part
of the public ABI of gfortran and has to continued to be supported, even if we
could move some function to the compiler itself (generated code).


> 3) messy_m.f90 includes the statement:
>I haven't looked at the code to determine if messy_m.f90 is actually
>needed.

It seems to be only used for testing. (In any case, it would be useful to have
some test cases in the testsuite.)

[Bug rtl-optimization/58029] New: base_alias_check says pretend-args saves and varargs accesses don't alias

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58029

Bug ID: 58029
   Summary: base_alias_check says pretend-args saves and varargs
accesses don't alias
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amylaar at gcc dot gnu.org

When the frame is set up by the prologue, some pretend args saves have to
be done using the stack pointer, as the frame pointer can't be saved until
later.
For va_arg, OTOH, it is natural to use the hard frame pointer, if no frame
pointer elimination takes place.

gcc.dg/torture/stackalign/vararg-1.c fails at -Os / -O2 or higher for
epiphany-elf because base_alias_check says the store of the pretend args
and the va_arg loads don't alias, and the stores get scheduled after the
load.

[Bug rtl-optimization/53705] wrong code with custom flags - stores to memory are lost

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53705

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org

--- Comment #3 from Jorn Wolfgang Rennecke  ---
(In reply to Zdenek Sojka from comment #0)
> Created attachment 27640 [details]
> reduced testcase (from testsuite/gcc.c-torture/execute/loop-2e.c)
> 
> GCC 4.3-4.8 fails, while with GCC 4.2, the code is reduced just to return 0.
> I am not sure if this should be marked as a regression.
> 
> Compiler output:
> $ gcc -O2 -fno-omit-frame-pointer -fpeel-loops -fsched2-use-superblocks
> -fno-tree-loop-optimize -fno-web --param=max-completely-peel-times=256
> testcase.c
> $ ./a.out
> Aborted
> 
> Looking at the assembly:
> ...
>   sub rsp, 320#,
>   mov rdx, QWORD PTR p[rip]   # p.0, p
>   lea rcx, [rbp-320]  # q,
> ...
>   mov QWORD PTR [rcx+240], rdi# *q_19, tmp73
>   lea rax, [rdx+144]  # tmp73,
>   lea rsi, [rdx+148]  # tmp73,
>   lea rdi, [rdx+152]  # tmp73,
>   lea rdx, [rdx+156]  # tmp73,
>   cmp QWORD PTR [rbp-8], rdx  # q, tmp73
>   mov QWORD PTR [rcx+280], rax# *q_19, tmp73
>   mov QWORD PTR [rcx+248], r8 # *q_19, tmp73
>   mov QWORD PTR [rcx+256], r9 # *q_19, tmp73
>   mov QWORD PTR [rcx+264], r10# *q_19, tmp73
>   mov QWORD PTR [rcx+272], r11# *q_19, tmp73
>   mov QWORD PTR [rcx+288], rsi# *q_19, tmp73
>   mov QWORD PTR [rcx+296], rdi# *q_19, tmp73
>   mov QWORD PTR [rcx+304], rdx# *q_19, tmp73
>   jne .L46#,
> ...
> It seems the dependency between storing to *q++ (esp. q[39]) in foo() and
> verifying it in main() is lost. Furthermore, it seems q[39] ([rcx+312]) is
> not stored to at all.

I can't reproduce the unrolling with an i686-pc-linux-gnu X x86_64-pc-linux-gnu
compiler, neither for 4.8.2 20130729 (prerelease) , nor for 4.9.0 20130729
(experimental) sources.

Is that an issuse with the cross-compiler, or with the compiler version?

[Bug tree-optimization/58028] New: [4.9 Regression] Several failures in libgomp.graphite after revision 200946

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028

Bug ID: 58028
   Summary: [4.9 Regression] Several failures in libgomp.graphite
after revision 200946
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: grosser at gcc dot gnu.org

At revision 200946 the following failures (not seen in r200874) appeared (see
also http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg02544.html ):

FAIL: libgomp.graphite/bounds.c scan-tree-dump-times graphite "0 loops carried
no dependency" 1
FAIL: libgomp.graphite/force-parallel-4.c execution test
FAIL: libgomp.graphite/force-parallel-4.c scan-tree-dump-times graphite "2
loops carried no dependency" 1
FAIL: libgomp.graphite/force-parallel-6.c scan-tree-dump-times graphite "1
loops carried no dependency" 1
FAIL: libgomp.graphite/pr41118.c scan-tree-dump-times optimized "loopfn" 0

with -m32 and -m64 (for r201008, the libgomp.graphite/force-parallel-4.c
execution test failed only with -m32, for r201274 and newer it fails with both
-m32/-m64).

[Bug fortran/58023] [F03] ICE on invalid with bad PPC declaration

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58023

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> Draft patch:

Regtests cleanly. Will commit as obvious.

[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-07-30
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Compiling the following code with -Wtabs

  print *, "AstringwithTabsinsteadofspaces"
print 1894
1894  format('123')
  end

gives

pr58001.f90:3.14:

1894  format( '123')
  1
Warning: Extension: Tab character in format at (1)

If compiled with -Wno-tabs, it gives

pr58001.f90:2.1:

 print 1894
 1
Warning: Nonconforming tab character at (1)
pr58001.f90:3.14:

1894  format( '123')
  1
Warning: Nonconforming tab character at (1)
pr58001.f90:3.14:

1894  format( '123')
  1
Warning: Extension: Tab character in format at (1)

Is this the expected behavior?-(I was expecting the later output for -Wtabs,
and no warning with -Wno-tabs: on most options Wno-* suppress the warnings for
the corresponding option.)

[Bug libfortran/58020] Code for handling IEEE exceptions

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-07-30
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
I have tested the code at http://mathalacarte.com/hpcconsult (without reading
it).
The files IEEE_ARITHMETIC.f90 and IEEE_tests_gfortran.f90 must be compiled with
the -fno-range-check option (for the second file it triggers PR58027). On
x86_64-apple-darwin10 the output differs from the one in 'list':

--- tmp2013-07-30 12:33:24.0 +0200
+++ list2013-07-25 21:27:02.0 +0200
@@ -77,7 +77,7 @@

  Double precision rounding mode IEEE_DOWN for \pi ~= 3.142 is < value with
IEEE_UP.

- Double precision rounding mode IEEE_DOWN for \pi ~= 3.141 agrees with
IEEE_TO_ZERO.
+ Double precision rounding mode IEEE_DOWN for \pi ~= 3.142 agrees with
IEEE_TO_ZERO.

  Double precision a=IEEE_REM(4, \pi) correctly satisfies a + \pi==4.

[Bug fortran/58027] New: "Arithmetic overflow converting ..." in PARAMETER triggers an ICE

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58027

Bug ID: 58027
   Summary: "Arithmetic overflow converting ..." in PARAMETER
triggers an ICE
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr

Compiling the following code (extracted from
http://mathalacarte.com/hpcconsult):

  INTEGER, PARAMETER :: ISCLASS(1) = &
(/&
Z'FF80'& ! IEEE_NEGATIVE_INF
/)
print *, isclass
end

gives the following ICE

isclass_3.f90: In function 'MAIN__':
isclass_3.f90:5:0: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:5473
 print *, isclass

while it compiles with -fno-range-check.

[Bug c++/57947] internal compiler error: Segmentation fault using extended initializer lists without -std=c++11 or -std=gnu++11

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57947

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #6 from Paolo Carlini  ---
Ok, I think I have a way to fix this.

[Bug fortran/58026] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1521

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58026

--- Comment #4 from janus at gcc dot gnu.org ---
Draft patch:

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c(revision 201331)
+++ gcc/fortran/decl.c(working copy)
@@ -4286,12 +4286,10 @@ gfc_match_data_decl (void)
   || current_ts.u.derived->attr.zero_comp))
 goto ok;

-  /* Now we have an error, which we signal, and then fix up
- because the knock-on is plain and simple confusing.  */
   gfc_error_now ("Derived type at %C has not been previously defined "
  "and so cannot appear in a derived type definition");
-  current_attr.pointer = 1;
-  goto ok;
+  m = MATCH_ERROR;
+  goto cleanup;
 }

 ok:

[Bug fortran/58026] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1521

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58026

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
Summary|[4.9 Regression] internal   |[4.9 Regression] [OOP] ICE
   |compiler error: in  |in
   |generate_finalization_wrapp |generate_finalization_wrapp
   |er, at fortran/class.c:1521 |er, at fortran/class.c:1521

--- Comment #3 from janus at gcc dot gnu.org ---
Slightly modified test case:


  type sysmtx_t
 type(ext_complex_t), allocatable :: S(:)
  end type
contains
  subroutine init (this)
class(sysmtx_t) :: this 
  end subroutine
end

[Bug fortran/57987] Fortran finalizers considered extern-inline by middle-end

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-07-30
 Ever confirmed|0   |1

--- Comment #4 from Jan Hubicka  ---
I suppose the old test was simply a bug: cgraph_finalize_function creates node
when it does not exist and uses existing one otherwise. So I suppose the new
patch is OK - the conditional ought to match condition on which
generate_coarray_init is called. What we had was just latent bug hidden by the
cgraph_finalize_function lazyness.

If things get complex, simply calling cgraph_get_create_node on all nested
functions may be better option.

Honza

[Bug testsuite/57413] FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler on x86_64-apple-darwin10, Solaris/x86

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57413

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Dominique d'Humieres  ---
>> Closing this bug was premature: as I've mentioned before, I've been 
>> working on a patch to detect if the necessary support is present.
>
> Sorry, but the "mentioned before" is not part of the audit trail. Could you
> provide a pointer to the relevant post?

I'd have to look it up myself, but it doesn't matter now.

Rainer

[Bug fortran/58026] [4.9 Regression] internal compiler error: in generate_finalization_wrapper, at fortran/class.c:1521

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58026

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
Failing is the following assert in generate_finalization_wrapper:

  /* If there is no new finalizer and no new allocatable, return with
 an expr to the ancestor's one.  */
  if (!expr_null_wrapper && !finalizable_comp
  && (!derived->f2k_derived || !derived->f2k_derived->finalizers))
{
  gcc_assert (ancestor_wrapper && ancestor_wrapper->ref == NULL
  && ancestor_wrapper->expr_type == EXPR_VARIABLE);

[Bug testsuite/57413] FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler on x86_64-apple-darwin10, Solaris/x86

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57413

--- Comment #4 from Dominique d'Humieres  ---
> Closing this bug was premature: as I've mentioned before, I've been 
> working on a patch to detect if the necessary support is present.

Sorry, but the "mentioned before" is not part of the audit trail. Could you
provide a pointer to the relevant post?

[Bug testsuite/57413] FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler on x86_64-apple-darwin10, Solaris/x86

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57413

Rainer Orth  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|WONTFIX |---
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #3 from Rainer Orth  ---
Closing this bug was premature: as I've mentioned before, I've been working on
a patch to detect if the necessary support is present.

  Rainer

[Bug c++/57947] internal compiler error: Segmentation fault using extended initializer lists without -std=c++11 or -std=gnu++11

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57947

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #5 from Paolo Carlini  ---
Not now, sorry. The issue is a bit tricky, not a straightforward error
recovery: the name initializer_list triggers magic, necessary to fully
implement the C++11 semantics. Thus the issue boils down to treating it as any
other name in C++98.

[Bug tree-optimization/52402] IPA-SRA creates aligned loads from unaligned memory

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52402

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org
  Known to fail||4.8.1, 4.9.0

--- Comment #5 from Jorn Wolfgang Rennecke  ---
(In reply to Richard Biener from comment #4)
> Fixed on trunk sofar.

What I see on epiphany (at O2 and above, enabling SRA) for
gcc.dg/torture/pr52402.c is that the call of foo.isra.0 in main is done
using an aligned type:

Breakpoint 5, epiphany_function_arg (cum_v=..., mode=TImode, type=0xb7c5f960, 
named=true)
at /home/amylaar/adapteva/git/sdk/srcw/gcc/config/epiphany/epiphany.c:2177
2177  CUMULATIVE_ARGS cum = *get_cumulative_args (cum_v);
(gdb) call debug_tree(type)
 
unit size 
align 32 symtab 0 alias set 3 canonical type 0xb7bed360 precision 32
min  max 
pointer_to_this >
TI
size 
constant 128>
unit size 
constant 16>
align 64 symtab 0 alias set 3 canonical type 0xb7c5f960 nunits 4 context

pointer_to_this >

but when the callee foo.isra.0 was compiled before, it got allegedly passed
an unaligned type:

Breakpoint 5, epiphany_function_arg (cum_v=..., mode=TImode, type=0xb7c6f300, 
named=true)
at /home/amylaar/adapteva/git/sdk/srcw/gcc/config/epiphany/epiphany.c:2177
2177  CUMULATIVE_ARGS cum = *get_cumulative_args (cum_v);
(gdb) call debug_tree(type)
 
unit size 
align 32 symtab 0 alias set 3 canonical type 0xb7bed360 precision 32
min  max 
pointer_to_this >
TI
size 
constant 128>
unit size 
constant 16>
align 8 symtab 0 alias set -1 canonical type 0xb7c5f960 nunits 4 context
>

When passing 64-bit aligned types, the epiphany ABI uses register pair(s)
to enable double load-store, thus in this case where r0 has already been
used, the argument starts at r2; in the less-aligned case, it starts at
r1.  Thus, the callee expects the argument in a different place than where
it has been put by the caller.

[Bug c++/58014] vshuf-v2si.C fails at -O3 on hppa64

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58014

--- Comment #1 from Ramana Radhakrishnan  ---

No access to any hppa machine for me to consider reproducing the issue and the
compile farm machines are down. 

I did do some work in this area a year ago but I don't have any commits in the
range mentioned below .. Not sure how I can help :( . 

ramana

[Bug rtl-optimization/57968] MODE_EXIT switches inserted too early

[chrbr at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57968

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chrbr at gcc dot gnu.org

--- Comment #2 from chrbr at gcc dot gnu.org ---
Created attachment 30571
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30571&action=edit
Same issue on SH4

Same problem with the attached test on 4.8.1 SH4 whereas I also see the EXIT
block inserted before the FP use.

Testing with your patch on 4.8

[Bug c++/57947] internal compiler error: Segmentation fault using extended initializer lists without -std=c++11 or -std=gnu++11

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57947

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.9.0

--- Comment #4 from Paolo Carlini  ---
Mine.

[Bug rtl-optimization/57637] [4.9 regression] Miscompare on 178.galgel in SPEC2000 on arm

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from ktkachov at gcc dot gnu.org ---
I can confirm as of r201326:

2013-07-30  Zhenqiang Chen  

PR rtl-optimization/57637
* function.c (move_insn_for_shrink_wrap): Also check the
GEN set of the LIVE problem for the liveness analysis
if it exists, otherwise give up.

the segfault is gone.

Thanks,
Kyrill

[Bug rtl-optimization/57637] [4.9 regression] Miscompare on 178.galgel in SPEC2000 on arm

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug fortran/58023] [F03] ICE on invalid with bad PPC declaration

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58023

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
Draft patch:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 201283)
+++ gcc/fortran/resolve.c(working copy)
@@ -12043,9 +12043,11 @@ resolve_fl_derived0 (gfc_symbol *sym)
 {
   gfc_symbol *ifc = c->ts.interface;

-  if (!sym->attr.vtype
-  && !check_proc_interface (ifc, &c->loc))
-return false;
+  if (!sym->attr.vtype && !check_proc_interface (ifc, &c->loc))
+{
+  c->tb->error = 1;
+  return false;
+}

   if (ifc->attr.if_source || ifc->attr.intrinsic)
 {

[Bug fortran/58023] [F03] ICE on invalid with bad PPC declaration

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58023

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-07-30
 CC||janus at gcc dot gnu.org
Summary|ICE on invalid with missing |[F03] ICE on invalid with
   |NOPASS  |bad PPC declaration
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed. The same ICE occurs on this variant:


  implicit none

  type :: sfd
procedure(mr), pointer :: mr2
  end type

  type(sfd):: d
  print *, d%mr2()

end

[Bug libstdc++/56627] class hash instead of struct hash

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627

--- Comment #11 from Jonathan Wakely  ---
I'm think I'm just going to change the code to shut everyone up, despite it
being a nonsense warning about a non-issue, because I'm sick of these
discussions.

Fine, you win, we'll silence the stupid warning.

[Bug fortran/58026] [4.9 Regression] internal compiler error: in generate_finalization_wrapper, at fortran/class.c:1521

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58026

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-07-30
 CC||bur...@net-b.de
Summary|internal compiler error: in |[4.9 Regression] internal
   |generate_finalization_wrapp |compiler error: in
   |er, at fortran/class.c:1521 |generate_finalization_wrapp
   ||er, at fortran/class.c:1521
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The ICE has been introduced between revisions 198750 (2013-05-09) and 199418
(2013-05-29): r199409?

[Bug bootstrap/39968] Should plugins use shared library?

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39968

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||pinskia at gmail dot com

--- Comment #11 from Dominique d'Humieres  ---
Any point to keep this four year old PR open?

[Bug fortran/57530] [OOP] Wrongly rejects type_pointer => class_target (which have identical declared type)

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57530

--- Comment #8 from Tobias Burnus  ---
The original test case (cf. comment 0) is now solved.

However, only "type => class" is handled. Still missing is "type = class",
where CLASS is a (coarray) scalar or (coarray) array variable, function or an
array constructor. See also comment 3.

[Bug fortran/57530] [OOP] Wrongly rejects type_pointer => class_target (which have identical declared type)

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57530

--- Comment #6 from Tobias Burnus  ---
Author: burnus
Date: Tue Jul 30 07:18:54 2013
New Revision: 201328

URL: http://gcc.gnu.org/viewcvs?rev=201328&root=gcc&view=rev
Log:
2013-07-30  Tobias Burnus  

PR fortran/57530
* trans-expr.c (gfc_trans_class_assign): Handle CLASS array
functions.
(gfc_trans_pointer_assign): Ditto and support pointer assignment
of a polymorphic var to a nonpolymorphic var.

2013-07-30  Tobias Burnus  

PR fortran/57530
* gfortran.dg/pointer_assign_8.f90: New.
* gfortran.dg/pointer_assign_9.f90: New.
* gfortran.dg/pointer_assign_10.f90: New.
* gfortran.dg/pointer_assign_11.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/pointer_assign_10.f90
trunk/gcc/testsuite/gfortran.dg/pointer_assign_11.f90
trunk/gcc/testsuite/gfortran.dg/pointer_assign_8.f90
trunk/gcc/testsuite/gfortran.dg/pointer_assign_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/57530] [OOP] Wrongly rejects type_pointer => class_target (which have identical declared type)

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57530

--- Comment #7 from Tobias Burnus  ---
Author: burnus
Date: Tue Jul 30 07:20:43 2013
New Revision: 201329

URL: http://gcc.gnu.org/viewcvs?rev=201329&root=gcc&view=rev
Log:
2013-07-30  Tobias Burnus  

PR fortran/57530
* symbol.c (gfc_type_compatible): A type is type compatible with
a class if both have the same declared type.
* interface.c (compare_type): Reject CLASS/TYPE even if they
are type compatible.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/symbol.c