[Bug c/70619] Wrong warning with VLA, comma and sizeof

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70619

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-30
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to Alexander Cherepanov from comment #0)
> Compiling the program:
> 
> int main()
> {
>   int a[1][(0, 1)];
>   int i = 0;
>   sizeof a[i++];
> }
> 
> gives such warnings:
> 
> $ gcc -Wall example.c
> example.c: In function ‘main’:
> example.c:3:14: warning: left-hand operand of comma expression has no effect
> [-Wunused-value]
>int a[1][(0, 1)];
>   ^
> example.c:5:10: warning: right-hand operand of comma expression has no
> effect [-Wunused-value]
>sizeof a[i++];
>~~~^~
> 
> The first one is fine but the second one is wrong and confusing.

Confirmed that the wording is confusing since there's no comma expression being
pointed to. The result of the sizeof is actually unused though, so ideally the
warning would just get reworded.

[Bug c/55976] -Werror=return-type should error on returning a value from a void function

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976

Eric Gallager  changed:

   What|Removed |Added

 CC||bastien.penavayre at epitech 
dot e
   ||u

--- Comment #2 from Eric Gallager  ---
*** Bug 71743 has been marked as a duplicate of this bug. ***

[Bug c/71743] return with no value cannot be ignored [Possible regression or undocumented change on https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Warning-Options.html#Warning-Options]

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71743

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #4 from Eric Gallager  ---
I think this is a dup of bug 55976; there's probably some calls in GCC to the
warning() function that aren't being passed the correct variable that controls
-Wreturn-type

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

[Bug target/81613] [7/8 regression] FAIL: gfortran.dg/intrinsic_modulo_1.f90 -O3 -g execution test

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81613

--- Comment #1 from Andreas Schwab  ---
Looking at the difference the old code didn't make any sense:

--- intrinsic_modulo_1.s-good   2017-07-30 01:21:37.757618984 +0200
+++ intrinsic_modulo_1.s-bad2017-07-30 01:20:30.321837737 +0200
@@ -100,13 +100,11 @@
fmovecr #0x32,%fp0
fcmp.s -32(%fp),%fp0
fjne .L6
-   moveq #1,%d0
-   cmp.l %d0,%d0
+   subq.l #1,%d0
jne .L6
fcmp.s -28(%fp),%fp1
fjne .L6
-   moveq #-2,%d0
-   cmp.l %d0,%d0
+   addq.l #2,%d0
jne .L6
fmovecr #0xf,%fp0
fcmp.s -24(%fp),%fp0
@@ -120,14 +118,12 @@
fmove.s -16(%fp),%fp1
fcmp.s #0x4000,%fp1
fjne .L6
-   moveq #2,%d0
-   cmp.l %d0,%d0
+   subq.l #2,%d0
jne .L6
fmove.s -12(%fp),%fp1
fcmp.s #0xbf80,%fp1
fjne .L6
-   moveq #-1,%d0
-   cmp.l %d0,%d0
+   addq.l #1,%d0
jne .L6
fcmp.s -8(%fp),%fp0
fjne .L6

[Bug target/81613] New: [7/8 regression] FAIL: gfortran.dg/intrinsic_modulo_1.f90 -O3 -g execution test

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81613

Bug ID: 81613
   Summary: [7/8 regression] FAIL:
gfortran.dg/intrinsic_modulo_1.f90   -O3 -g  execution
test
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: law at gcc dot gnu.org
Blocks: 25112
  Target Milestone: ---
Target: m68k-*-*

gfortran.dg/intrinsic_modulo_1.f90 started to fail after r241000, but that only
uncovered a regression in r242605, when the test is compiled with
-ftree-vectorize.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25112
[Bug 25112] [m68k] Suboptimal equality comparisons with small integers

[Bug c/70924] Wrong position for "warning: missing braces around initializer [-Wmissing-braces]"

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70924

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Current gcc output:

$ /usr/local/bin/gcc -c -std=c11 -pedantic -Wall -Wextra -O3 70924.c
70924.c: In function ‘main’:
70924.c:3:49: warning: missing braces around initializer [-Wmissing-braces]
  struct { int w; struct { int x, y; } ss; } s = { 1, .ss = 2, 3 };
 ^
{}
70924.c: At top level:
70924.c:7:15: warning: missing braces around initializer [-Wmissing-braces]
 int a[3][1] = { { 0 }, { 1 }, 2 };
   ^
   { }
$

So now there's a fixit in the right place, although the caret is still wrong.
So confirming for the caret part.

[Bug c/71598] Wrong optimization with aliasing enums

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed (that the testcase aborts when run)

[Bug middle-end/46932] Inefficient code sequence to access local variable

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46932

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #7 from Rainer Orth  ---
The testcase comes up as UNSUPPORTED on many targets (Linux/x86_64,
Solaris/SPARC,
Solaris/x86, ...):

UNRESOLVED: gcc.dg/pr46932.c scan-rtl-dump-not auto_inc_dec "success"

The log file has

gcc.dg/pr46932.c: dump file does not exist

and indeed no log file is created at all.

  Rainer

[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80569

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #10 from Rainer Orth  ---
There are some problems with the testcase:

* Solaris/x86 with /bin/as, I get

FAIL: gcc.target/i386/pr80569.c (test for excess errors)

Excess errors:
Assembler: pr80569.c
"/var/tmp//ccB_4KXd.s", line 2 : Illegal mnemonic
Near line: ".code16gcc"
"/var/tmp//ccB_4KXd.s", line 2 : Syntax error
Near line: ".code16gcc"

  i386.c (x86_file_start) unconditionally emits .code16gcc without any check
that
  the assembler supports it.

* on Linux/i686, I get

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/pr80569.c:7:24:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  new from

  gcc is called with-m16 -march=haswell -c -m64 

  Rainer

[Bug lto/81612] New: lto1: internal compiler error: Segmentation fault

[vctrex at mailfence dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81612

Bug ID: 81612
   Summary: lto1: internal compiler error: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vctrex at mailfence dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

With avr-gcc-6.3.0_1 compiling anything with Serial.begin() results an error.

Arduino:1.8.3 (Linux)

lto1: internal compiler error: Segmentation fault
0x8b64df crash_signal
../../gcc/toplev.c:333
0x7f4f10c34a8f ???
   
/builddir/glibc-2.25/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7428b6 maybe_record_node
../../gcc/ipa-devirt.c:2468
0x747245 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
../../gcc/ipa-devirt.c:3186
0x747d0e possible_polymorphic_call_targets(cgraph_edge*, bool*, void**, bool)
../../gcc/ipa-utils.h:115
0x747d0e ipa_devirt
../../gcc/ipa-devirt.c:3597
0x747d0e execute
../../gcc/ipa-devirt.c:3913
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /usr/bin/avr-gcc returned 1 exit status
compilation terminated.
/usr/bin/avr-ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
exit status 1

[Bug c/69505] attribute aligned changes alignment of the same type

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69505

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |RESOLVED
  Known to work||4.9.3, 5.4.0, 6.4.0, 7.1.0,
   ||8.0
 Resolution|--- |FIXED
  Known to fail||5.3.0, 6.3.0

--- Comment #2 from Martin Sebor  ---
Looks like r234626 fixed it.  What's still missing is a warning when an attempt
is made to reduce the alignment of a declaration where a stricter one was
previously specified.

[Bug c/71422] Total size of static objects is not limited

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71422

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #1)
> IMNSHO gcc shouldn't, after all, if you just put each into a separate CU,
> gcc won't even see them together.  It should be linker's responsibility to
> complain.

What if you use LTO?

[Bug c/71188] missing warning converting constant integer expression zero to pointer

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71188

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
Confirmed that gcc only prints the same warnings you noticed.

[Bug c/70952] Missing warning for likely-erroneous octal escapes in string literals

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
(In reply to Alexander Monakov from comment #0)
> GCC doesn't warn for:
> 
> const char s[] = "\008";
> 

Confirmed.

[Bug c/70257] #line incorrectly handled in error messages

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70257

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirming that this happens; I had it happen to me in something else with
#line directives but I assumed I was just generating them wrong...

[Bug c/63398] Cilk errors out incorrectly for spawn inside statement expressions

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63398

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that it errors out:

$ /usr/local/bin/gcc -c -fcilkplus 63398.c
63398.c: In function ‘f’:
63398.c:4:10: error: use of ‘_Cilk_spawn’ in a return statement is not allowed
  return ({ _Cilk_spawn f2(); 0; });
 ~^
$

[Bug inline-asm/54450] Extended asm in global scope

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54450

Eric Gallager  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |INVALID

--- Comment #8 from Eric Gallager  ---
(In reply to Georg-Johann Lay from comment #7)
> (In reply to Eric Gallager from comment #6)
> > (In reply to Marek Polacek from comment #2)
> > > Probably dup of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045
> > 
> > Agreed, closing as a duplicate of it
> > 
> > *** This bug has been marked as a duplicate of bug 41045 ***
> 
> Really?
> 
> What the OP wants is
> 
> >> void *ptr;
> >>
> >>   __asm__ ("my_function:\n\t"
> >>"jmp *%0\n\t" : : "r"(ptr));
> 
> Constraint "r" cannot work at toplevel, hence this PR is invalid.
> 
> What PR41045 is about is top-level asm arguments that are compiler-time
> constants (constraint "n") and maybe also symbols (constraints "i" and "s").
> 
> So the initial request is only valid if the address of ptr was used (and
>  is CONST_INT, CONST or SYMBOL_REF etc.):
> 
> void *ptr;
> 
> __asm__ ("my_function:\n\t"
>  "jmp ??? %0" : : "i" ());

Oh OK, changing to INVALID then.

[Bug c/66286] Inconsistent handling of Cilk+ array sections

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66286

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that the testcase aborts on me. (btw should we have a cilkplus
keyword for bugs on this Bugzilla?)

[Bug c/69505] attribute aligned changes alignment of the same type

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69505

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
My results:

$ /usr/local/bin/gcc -Wall -Wextra -pedantic -o 69505.exe 69505.c
$ ./69505.exe
1, 1
32, 32
32, 32
$ /usr/local/bin/g++ -Wall -Wextra -pedantic -o 69505++.exe 69505.c
$ ./69505++.exe
1, 1
32, 32
32, 32
$

Did this get fixed or something?

[Bug inline-asm/54450] Extended asm in global scope

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54450

--- Comment #7 from Georg-Johann Lay  ---
(In reply to Eric Gallager from comment #6)
> (In reply to Marek Polacek from comment #2)
> > Probably dup of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045
> 
> Agreed, closing as a duplicate of it
> 
> *** This bug has been marked as a duplicate of bug 41045 ***

Really?

What the OP wants is

>> void *ptr;
>>
>>   __asm__ ("my_function:\n\t"
>>"jmp *%0\n\t" : : "r"(ptr));

Constraint "r" cannot work at toplevel, hence this PR is invalid.

What PR41045 is about is top-level asm arguments that are compiler-time
constants (constraint "n") and maybe also symbols (constraints "i" and "s").

So the initial request is only valid if the address of ptr was used (and 
is CONST_INT, CONST or SYMBOL_REF etc.):

void *ptr;

__asm__ ("my_function:\n\t"
 "jmp ??? %0" : : "i" ());

[Bug other/81611] New: gcc un-learned loop / post-increment optimization

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611

Bug ID: 81611
   Summary: gcc un-learned loop / post-increment optimization
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

C test case:

void func1 (unsigned char x, char *str)
{
do {
*str++ = '0' + (x & 1);
x = x / 2;
} while (x);
*str = 0;
}

$ avr-gcc-8 foo.c -S -mmcu=atmega8 -O2

foo.s:

func1:
movw r30,r22; ok, need the address in some
; address register (here Z=r30)
rjmp .L2; ???
.L3:
movw r30,r18 ; what the heck? Moving address back...
.L2:
movw r18,r30;; ...and forth to some fresh register, just to increment
subi r18,-1  ; the address from the *PREVIOUS* loop
sbci r19,-1  ; slow, bloat, increases reg pressure
mov r25,r24  ; ok
andi r25,lo8(1)  ; ok
subi r25,lo8(-(48)) ; ok
st Z,r25 ; Why not just "st Z+, r25" ???
lsr r24  ; ok
brne .L3
std Z+1,__zero_reg__
ret


Just for reference the code from 4.7:

* Using 5 instructions less
* Occupying 2 registers less
* Loop consumes 4 cycles less (8 instead of 12).

func1:
movw r30,r22
.L2:
mov r25,r24
andi r25,lo8(1)
subi r25,lo8(-(48))
st Z+,r25
lsr r24
brne .L2
st Z,__zero_reg__
ret

That's code I expect from a 3rd millenium compiler!! ;-)

[Bug fortran/52162] Bogus -fcheck=bounds with realloc on assignment to unallocated LHS

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52162

--- Comment #12 from Dominique d'Humieres  ---
On darwin the test in comment 8 fails with -m32. The 'int(asin(c)*100.0)'
should be replaced with 'nint(asin(c)*100.0)'.

[Bug tree-optimization/81588] [7/8 Regression] Wrong code at -O2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81588

--- Comment #2 from Jakub Jelinek  ---
Created attachment 41860
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41860=edit
gcc8-pr81588.patch

Untested fix.

[Bug tree-optimization/81607] Conditional operator: "type mismatch in shift expression" error

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607

Marc Glisse  changed:

   What|Removed |Added

   Keywords||ice-checking
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-29
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
The original dump has
(void) (f = (char) ((long int) d.c << a))

(using long instead of int) This happens only for a bitfield of size 32, not 31
or 33, we probably get confused about a NOP conversion somewhere along the way.